Trabalhos Desenvolvidos no Âmbito da Unidade Curricular de Análise e Concepção de Sistemas de Informação

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

Download "Trabalhos Desenvolvidos no Âmbito da Unidade Curricular de Análise e Concepção de Sistemas de Informação"

Transcrição

1 Trabalhos Desenvolvidos no Âmbito da Unidade Curricular de Análise e Concepção de Sistemas de Informação Ricardo J. Machado, Maribel Santos, Pedro Ribeiro (eds.) SEMAG Educational Reports, vol. 1 semag- vol1-2011acsi.pdf ISSN: UNIVERSIDADE DO MINHO Escola de Engenharia Março 2011

2 Este relatório compila os trabalhos desenvolvidos pelos estudantes que frequentaram a unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI), no ano lectivo de 2010/11, no âmbito do Mestrado em Engenharia e Gestão de Sistemas de Informação (MEGSI), do Mestrado em Sistemas de Informação (MSI) e do Programa Doutoral em Tecnologias e Sistemas de Informação (PDTSI) da Escola de Engenharia da Universidade do Minho. Índice MEGSI 01] Levantamento de Standards Técnicos (ESB e SBPM) Alexandre Barbosa ] Relatório de Acompanhamento do Grupo 3 de Processos e Metodologias de Software Ana Lisboa ] Impactos do Papel de Consultor e Gestor de Projectos no Trabalho de Equipa Ângelo Conde ] Gestão de Projecto na Fase Inception do RUP Arménio Antunes ] Estudo de Standards Relativos a Cloud Computing: Levantamento de Standards Técnicos Bruno Ferreira ] Coordenação de Grupo de Projecto de Processos e Metodologias de Software Bruno Meira ] Interdependência em Requisitos Carina Campos ] Design Patterns: Creational Patterns Carlos Santos ] Ontologias Cristina Pereira ] Interacção ACSI com PMS Diogo Aarão ] Ensaio sobre a Execução de Serviços do Referencial ITIL v3 João Gonçalves ] Relatório de Acompanhamento e Coordenação de um Grupo de Processos e Metodologias de Software Jorge Aguiar ] Coordenação do Projecto de PMS Mário Braga ] Gestão de Projectos Marta Abreu ] A Interacção com uma Equipa de Trabalho Ser Consultor vs. Ser Coordenador de Projecto Micael Henriques ] Dificuldades e Decisões de Consultadoria & Gestão de Projectos Ricardo Cardoso ] Consultor de Projecto: Processos e Metodologias de Software Rui Correia

3 18] Information Technology Infrastructure Library Sandra Antunes ] Consultor e Coordenador de Projecto Académico: Planear, Coordenar, Controlar e Avaliar Sérgio Costa MSI 20] ITIL vs ISO/IEC Abílio Casanova ] Níveis de Maturidade do Processo de Software Fábio Cosme ] Redes de Petri Coloridas Uma Abordagem Prática Nuno Costa ] Uso de Artefatos PMBoK para Engenharia de Requisitos em Gerenciamento de Projetos de Software Vanilde Lima PDTSI 24] Modeling Organizations and Processes Carlos Salgado

4 Levantamento de standards técnicos (ESB e SBPM) Alexandre Barbosa (17504) 1 1 Universidade do Minho, Guimarães, Portugal Abstract. No âmbito do projecto ISOFIN Cloud, este documento pretende efectuar uma análise de standards técnicos nomeadamente o Enterprise Service Bus (ESB) e o Semantic Business Process Management (SBPM). Inicialmente será apresentada a definição de um ESB, os seus benefícios, a sua relação com SOA, um conjunto de funcionalidades e que padrões relativos ao uso de um ESB existem. Quanto ao SBPM será analisada a sua definição, os seus benefícios, a framework ontológica em que assenta e o ciclo de vida de um processo no SBPM. No fim serão expressas um conjunto de conclusões sobre a utilidade destes standards técnicos no projecto ISOFIN Cloud, no fundo que valor podem acrescentar. Keywords: Enterprise Service Bus, BPM semânticos, Semantic Business Process Management,ISOFIN 1 Introdução Este documento tem como propósito efectuar o levantamento, a análise de standards técnicos, Enterprise Service Bus (ESB) e Semantic Business Process Mangement (SBPM), no âmbito do projecto ISOFIN Cloud. O projecto ISOFIN Cloud tem como principal objectivo a criação de uma plataforma que agilize o desenvolvimento e deployment de serviços a serem vendidos a clientes e utilizadores do domínio financeiro (banca e seguros). Um dos resultados esperados deste projecto será um conjunto de ferramentas e mecanismos que permitam de forma ágil a criação de novos serviços recorrendo à plataforma referida. Assim este documento efectua uma análise dos standards, Enterprise Service Bus (ESB) e Semantic Business Process Mangement (SBPM), que poderão vir a fazer parte desse conjunto de ferramentas e mecanismos utilizados na criação de novos serviços, ou então para outras tarefas que tecnologia permita. A primeira parte do documento é relativa à analise do Enterprise Service Bus, onde será apresentada a sua definição, os seus benefícios, a sua relação com SOA, um conjunto importante de funcionalidades e um conjunto de padrões de alto nível, relativos ao uso de um ESB. A segunda parte apresenta o Semantic Business Process Management, que apesar de recente poderá ser considerado bastante interessante. Será apresentada a sua

5 definição, os seus benefícios, a framework ontológica em que este assenta, de uma forma muito simples, e o ciclo de vida de um processo de negócio no SBPM. Por último, serão apresentadas algumas conclusões relativas à analise efectuada ao Enterprise Service Bus e Semantic Business Process Management e da sua utilidade no projecto ISOFIN Cloud. 2 Enterprise Service Bus 2.1 Definição O Enterprise Service Bus (ESB) é um termo relativamente novo na indústria do software, mas que tem ganho interesse no âmbito da integração aplicacional. No entanto, é complicado perceber o que é um ESB visto que não existe consenso relativamente ao seu significado. Para ajudar a perceber vejamos algumas definições segundo alguns autores. Um Enterprise Service Bus é uma infraestrutura de integração distribuída baseada no uso de mensagens e de open standards, que suporta o encaminhamento, invocação e mediação de serviços com o objectivo de facilitar a interacção entre diferentes aplicações e serviços de uma forma segura e de confiança [8]. Um ESB poderá ser visto também, de uma forma simples, como uma tecnologia que tem o objectivo de resolver problemas de integração [9]. Noutra perspectiva, um ESB actua como um middleware que dá suporte à implementação de uma Service-oriented architecture (SOA) numa organização [7]. Este suporte é dado através da capacidade do ESB em: integrar e gerir os serviços de uma organização, tornar transparentes os aspectos técnicos das interacções entre serviços e tornar transparente a implementação de um serviço ao utilizador do mesmo [2, 7]. No geral um ESB deverá ter as seguintes funcionalidades [2, 9]: Transparência (Location Transparency) Conversão de protocolos de transporte (Transport protocol conversion) Transformação de mensagens (Message transformation) Encaminhamento de mensagens (Message routing) Reforço de mensagens (Message enhancement) Segurança (Security) Monitorização e gestão (Monitoring and management) Estas funcionalidades serão vistas com mais detalhe noutra secção.

6 2.2 Benefícios Como foi dito anteriormente, um Enterprise Service Bus (ESB) apresenta-se basicamente como uma tecnologia que tem o propósito de resolver questões de integração. Mas para perceber-mos melhor o propósito e os benefícios que um ESB traz, vejamos um exemplo (figura 1) de integração de várias aplicações sem recorrer a um ESB ou tecnologia semelhante (ex: Enterprise Application Integration Broker). É importante alertar, que apesar do exemplo dado nesta secção mencionar um conjunto de aplicações de uma determinada organização, um ESB não integra apenas aplicações. Um ESB integra aplicações, serviços, entre outros componentes de software, que podem ser da organização em questão ou externos à organização. Pois independentemente dos componentes de software que estejam ligados ao ESB estes serão sempre vistos como serviços, a secção seguinte ajudará a perceber melhor este pormenor. Fig. 1: Integração de aplicações sem o uso de um ESB, adaptado de [9] Neste exemplo de integração entre aplicações, representado por uma arquitectura ponto a ponto (point-to-point arquitecture), o grande problema encontra-se na complexidade em ligar, integrar as várias aplicações. Cada linha representa uma ligação entre duas aplicações, e por cada linha seria necessário criar ou comprar uma solução que integre as duas aplicações. Integrar este conjunto enorme de aplicações traria um vasto leque de problemas. Entre esses problemas, está o tempo necessário em integrar as várias aplicações

7 prejudicando muito provavelmente o negócio, a complexidade em criar e/ou configurar as ligações entre as aplicações e o custo associado a toda a integração mais o custo ligado à gestão das ligações entre as várias aplicações. Assim os benefícios de um ESB podem resumir-se aos seguintes [9]: Aumento da flexibilidade do ambiente composto pelas várias Tecnologias de Informação de uma organização mais os serviços externos a que esta tem acesso. Consequentemente ajudando a organização a criar novos produtos, melhorar os que já possui, etc. Diminuição na complexidade de gerir e integrar o leque de aplicações e serviços de uma organização. Redução do custo em gerir e integrar o leque de aplicações e serviços de uma organização A figura 2 mostra a integração de um conjunto de aplicações recorrendo a um ESB. Fig. 2: Integração de aplicações recorrendo a um ESB, adaptado de [9] De notar que a complexidade de integração das várias aplicações diminui, em certos

8 casos mais do que noutros, no entanto não desaparece. A complexidade apenas se encontra escondida pelo ESB [9]. Outro aspecto relevante, é que em casos que o número de aplicações a integrar ou número de ligações entre as aplicações for reduzido poderá não ser muito vantajoso o uso de um ESB. Apesar das várias vantagens que um ESB traz, cada caso é um caso e deve ser analisado, estudado antes de tomar a decisão de usar ou não um ESB. 2.3 SOA e ESB Nesta secção será efectuada uma análise, de uma forma simples, à relação entre um ESB e SOA (Service-oriented architecture). É importante referir que uma SOA, pode ser descrita como uma arquitectura que define que as aplicações apresentam as suas funções, o seu valor para o negócio através de serviços, podendo ser estes usados por outras aplicações que podem por sua vez estar sobre a forma de serviços [8]. Assim, a relação entre ESB e SOA será analisada com base nestes dois pontos: Como um ESB aplica uma SOA Que valor um ESB acrescenta a uma SOA Respondendo ao primeiro ponto, um ESB aplica uma SOA recorrendo ao conceito de abstract endpoints, em que estes representam tudo que é ligado ao ESB [3]. Fisicamente estes abstract endpoints são representados por service containers, em que estes são processos remotos ligados a componentes de software [3]. Um service container é visto pelo ESB como um serviço, apesar de na realidade poder representar por exemplo uma aplicação ligada ao ESB através de um adaptador, um serviço, um sistema legacy, entre outros componentes de software, como podemos ver na figura 3. Além disso o service container pode conter um ou mais componentes ligados de forma a criar um determinado serviço [3].

9 Fig. 3: Service Containers de um ESB, adaptado de [3] Em relação ao segundo ponto, um ESB acrescenta valor a uma comum SOA nas operações de find/bind/invoke [3]. O modelo find/bind/invoke passa por procurar (find) um serviço no service registry (este contêm informação sobre o local, a função e outros aspectos relativos um conjunto de serviços) com base em determinados critérios, associar (bind) a ligação entre quem solicita o serviço e quem o presta e por fim invocar (invoke) o serviço em questão. O problema de uma comum SOA é que cada solicitador de um serviço precisa de definir toda a lógica de ligação, find/bind/invoke, na sua aplicação. Enquanto que recorrendo a um ESB estas tarefas são efectuadas pelo mesmo retirando toda a carga ao solicitador, este apenas terá trabalho de configuração [3]. Resumindo, um Enterprise Service Bus apresenta-se como uma solução ideal para implementar uma Service-oriented architecture, pois disponibiliza os mecanismos necessários para interligar o conjunto de serviços que compõem um determinada solução sem comprometer a segurança, fiabilidade, performance e escalabilidade [8]. 2.4 Funcionalidades Vejamos as seguintes funcionalidades que são mais ou menos genéricas a um ESB.

10 Transparência Um ESB deverá de ser capaz de criar uma transparência em relação à localização de um solicitador de serviços (service requestor) e de um prestador de serviços (service provider). Por outras palavras, se um determinado prestador de serviços mudar a localização do seu servidor não deverá ter qualquer impacto no solicitador de serviços [9]. Esta transparência pode ser implementada de três maneiras [9]: Através do uso de uma simples configuração em XML Com uma base de dados, tornado a configuração dinâmica Com o Service Registry Este último, o service resgistry, apesar de mais complexo irá permitir adicionar um conjunto de características interessantes, tais como o controlo da qualidade de serviço e a descoberta e gestão das capacidades de um determinado serviço. A qualidade de serviço será útil quando houver a necessidade de garantir que o ESB suporte interacções com níveis mínimos de qualidade para proteger a informação transmitida [7]. Assim por exemplo, um solicitador de serviços pode escolher um serviço com um nível de qualidade reduzido e ver um aumento na performance, na qualidade da comunicação, isto porque o ESB foi capaz de modificar certas características da comunicação melhorando a sua qualidade, como por exemplo o protocolo usado para as mensagens [10]. Para que o que foi dado como exemplo da qualidade de serviço se torne possível, o service registry teria que primeiro ter efectuado a descoberta das características de um determinado serviço. O ESB service registry é capaz de efectuar a descoberta e consequente gestão dos meta dados sobre as características de um serviço, como por exemplo as capacidades, políticas, qualidade de serviço, etc [10]. Com esta informação o ESB irá efectuar a melhor ligação possível entre um solicitador e prestador de serviços. Conversão de protocolos de transporte Outra das funcionalidades bastante útil num ESB é a Conversão de protocolos de transporte (Transport protocol conversion). Perante uma situação em que um solicitador de um serviço utiliza um protocolo de transporte diferente do prestador do serviço, o ESB deverá ser capaz de efectuar a conversão permitindo a comunicação entre os dois [9]. Os componentes que permitem efectuar a conversão de protocolos num ESB são denominados de adaptadores de protocolos (protocol adaptares), se o ESB utilizado não suportar um determinado protocolo poderá sem comprado ou criado o adaptador [9]. Isto torna-se possível graças à agilidade disponibilizada pelo ESB. De referir que as funcionalidades descritas aqui de conversão de protocolos de transporte, transformação de mensagens e reforço de mensagens normalmente (as duas últimas serão apresentadas à frente) são denominadas em conjunto de mediação [8].

11 Transformação de mensagens Caso o formato de uma mensagem trocada entre um solicitador de um serviço e o prestador de um serviço não coincida o ESB deverá transformar a mensagem gerada pelo solicitador no formato usado pelo prestador [9], e vice-versa. Um exemplo desta transformação poderá ser visto na figura 4. Fig. 4: Exemplo da transformação do formato de uma mensagem num ESB, adaptado de [9] A transformação do formato de uma mensagem pode ser feita de várias maneiras como por exemplo, através de uma ferramenta adquirida no mercado, criando uma aplicação específica para o efeito ou então recorrendo a uma XSLT (Extensible Stylesheet Language Transformation) style sheet [9]. Encaminhamento de mensagens O encaminhamento (routing) é a funcionalidade que permite ao ESB escolher o destino de um determinada mensagem. Esta funcionalidade será uma das mais importantes num ESB, pois permitirá que uma determinada mensagem não esteja restringida a apenas um prestador de serviços [8]. O ESB irá escolher o prestador que seja mais adequado perante determinadas condições. Estas condições podem ser: Baseadas no conteúdo (content-based) da mensagem. Em que o destino da mensagem será baseado no conteúdo da mesma [8,9]. Baseadas num filtro (message filter), que pode prevenir que a mensagem chegue a um determinado destino [9] ou então apenas é enviada se o conteúdo da mesma cumprir um determinado critério, caso contrário a mensagem é apagada [8]. Baseadas numa lista de destinos (recipient list), em que a mesma mensagem é enviada para múltiplos destinos [8,9]. Reforço de mensagens O reforço de mensagens (message enhancement) e transformação de mensagens estão ligadas uma à outra, no entanto não devem ser confundidas pois a transformação de mensagens é relativa ao formato das mesmas e o reforço ao conteúdo [9].

12 Pode ser solicitado a um determinado prestador de serviços informação sobre um cliente, no entanto o solicitador do serviço requer um determinado nível de detalhe de informação sobre esse cliente que o prestador não possui. O ESB pode então acrescentar a informação que o solicitador requer à mensagem, questionando outras base de dados sobre esse cliente. Este exemplo pode ser melhor compreendido recorrendo à figura 5, Fig. 5: Exemplo de reforço de mensagens num ESB, adaptado de [9] Segurança Devido à sensibilidade da informação que um ESB controla, uma das grandes funcionalidades que o mesmo deverá disponibilizar é a segurança da informação. Assim deverão ser disponibilizadas pelo ESB, como parte da funcionalidade de segurança da informação, as seguintes funções [7,8,9]: Identificação e autenticação Controlo de acessos Confidencialidade da informação Integridade da informação Gestão e administração da segurança Recuperação da informação Relatórios de incidentes Monitorização e gestão Finalmente, um ESB deverá possuir um conjunto de ferramentas que ajudem a gerir e monitorizar o mesmo. Esta funcionalidade de monitorização e gestão tornar-se-à indispensável à medida que o ESB aumenta em tamanho e complexidade.

13 As ferramentas de monitorização e gestão e as suas características vão depender de ESB para ESB, no entanto no geral deverão ter funcionalidades como: monitorizar o estado de um determinado web service, ou seja se está disponível ou não, gerir o conjuntos de web services ligados a um ESB, entre outras [9]. 2.5 Padrões para um ESB O conjunto de padrões apresentado nesta secção é descrito de uma maneira simples mas que no entanto vale a pena referir. Este conjunto de padrões é denominado de usage patterns e permite perceber a relação, o comportamento dos vários componentes ao nível da solução [10]. É também importante referir, que este conjunto de padrões são variações do broker application pattern que tem como objectivo separar as regras de distribuição das aplicações, aumentando a flexibilidade na distribuição de pedidos e eventos, consequentemente simplificando a gestão da rede e do sistema [10]. Ou seja o padrão que descreve o comportamento de um ESB. Service and event-routing pattern Um pedido ou evento é enviado para um de múltiplos prestadores de serviços. Escolha do prestador do serviço pode ser baseada no conteúdo do pedido, na disponibilidade ou não do prestador, na carga do prestador, etc [10]. Protocol switch pattern Um padrão em que solicitadores e prestadores de serviços usam protocolos de rede diferentes, existe portanto um mapeamento de protocolos permitindo a comunicação entre os dois [10]. Proxy or gateway pattern Neste padrão existe um mapeamento dos interfaces relativos aos serviços, permitindo por exemplo a adição de funções de segurança [10]. Um exemplo do uso deste padrão será a existência de um portal de serviços, em que esse portal é o único ponto de acesso a um conjunto de serviços, em que os detalhes deste conjunto de serviços está escondido dos solicitadores [10]. Event distribution pattern Um evento pode ser distribuído para um conjunto de prestadores de serviços, com base numa lista de assinantes controlada pelo ESB, ou seja este conjunto de assinantes é notificado quando um determinado evento de uma determinada natureza ocorre [10].

14 Service transformation pattern Solicitadores e prestadores de serviços podem usar variadíssimos interfaces, no entanto o ESB é capaz de garantir a sua comunicação, actuando como um mediador [10]. Matchmaking pattern Para um determinado pedido o prestador do serviço é descoberto dinamicamente com base num conjunto de politicas do serviço guardadas no service registry, este padrão é normalmente usado em ambientes muito complexos e com muitos serviços ligados [10]. De notar que muitos dos padrões descritos, deste conjunto de padrões, estão directamente relacionados com funcionalidades de um ESB, mencionadas numa secção anterior. 3 Semantic Business Process Management 3.1 Definição / Origem O Semantic Business Process Management (SBPM), desenvolvido no âmbito do projecto SUPER (Semantic Utilised for Process Management with and between Enterprises), tem como princípio combinar frameworks de Semantic Web Services (SWS), ontologias e metodologias e ferramentas de Business Process Management (BPM), criando uma tecnologia capaz de representar a perspectiva do negócio e a perspectiva dos sistemas de uma determinada organização, por outras palavras uma mediação automática entre as duas perspectivas [5, 6, 11]. A necessidade ligada à criação do SBPM surge da falta ou dificuldade de comunicação entre a perspectiva do negócio em relação às operações de uma organização, efectuada pelos especialistas do negócio e a perspectiva dos sistemas, que está preocupada com a execução das operações, efectuada pelos especialistas das tecnologias de informação. O BPM tem como objectivo dar suporte à modelação, gestão e monitorização das operações de uma organização ao nível dos processos, no entanto não é capaz de disponibilizar uma representação uniforme do espaço dos processos de uma organização (ou seja, o espaço que agrega todos os processos de uma organização) a um nível semântico e que possa ser lida por máquinas [5]. Esta representação do espaço dos processos a nível semântico, estaria acessível a queries e a implementação ágil de processos, características que são disponibilizadas pelo SBPM [5]. Aliados à falta de representações dos processos e de informação sobre os processos que seja compreendida por máquinas, o BPM actual apresenta os seguintes problemas

15 [5]: Falta de automação no que toca à modelação dos processos Atraso no tempo entre a modelação e a implementação dos processos Gestão dos processos de negócio demasiado complexa Atraso na criação ou análise de processos devido à necessidade de verificar determinados aspectos (ex: viabilidade de determinadas modificações, cumprimentos com regulamentos, etc) Demasiados problemas com modificações devido a questões de interdependência Assim, o processo relativo ao SBPM tem a sua ideia fundamental representada na figura 6 e é constituído pelos seguintes passos [5]: 1. descrição semântica de todos os processos e as suas respectivas actividades numa organização 2. representação dos recursos relativos às tecnologias da informação numa organização, recorrendo a uma ontologia 3. descrição das regras do negócio 4. mapeamento da informação transaccional dos vários sistemas usados para um instância virtual 5. descrição de queries numa linguagem ontológica 6. modelar as necessidades dos especialistas de negócio como objectivos de negócio 7. utilizar um ambiente de execução de SWS para efectuar a mediação entre as queries e objectivos de negócio e espaço do processo. Fig. 6: Semantic Business Process Management, adaptado de [5]

16 3.2 Benefícios Como foi referido anteriormente de forma leve, o SBPM apresenta dois principais benefícios, a capacidade de efectuar queries e manipular o espaço dos processos de uma organização. Queries ao espaço dos processos Com o intuito de ajudar na tomada de decisão a capacidade de efectuar queries sobre o espaço dos processos, o conjunto de processos de uma organização revela-se deveras importante [5]. Tais queries podem ser por exemplo: Quais são os processos que envolvem uma determinada entidade externa? Pode ser criado um processo que englobe determinadas características e custe x? De modo a que tais queries possam ser respondidas é necessário [5]: uma representação, compreensível por uma máquina, que contenha todos os factos relevantes sobre a implementação e execução uma representação, compreensível por uma máquina, das queries Manipular o espaço dos processos A manipulação de processos irá permitir a criação, modificação ou exclusão de processos no espaço dos processos de uma organização[5]. Esta capacidade de manipulação permitirá realizar necessidades da organização como por exemplo: Criar um processo que atinja um determinado objectivo de negócio Substituir determinada tarefa em determinado processo Executar um determinado processo perante determinadas circunstâncias Para que tal seja possível é necessário [5]: uma representação, compreensível por uma máquina, que contenha todos os factos relevantes sobre a implementação e execução uma representação, compreensível por uma máquina, das queries capacidade de invocar uma determinada funcionalidade um componente que possa orquestrar um determinado pedido um ambiente que possa executar a orquestração de um pedido

17 3.3 Framework ontológica para o SBPM Para que os benefícios descritos anteriormente, queries ao espaço dos processos e manipular o espaço dos processos, se tornem realidade (logicamente satisfazendo algumas das restrições apresentadas com esses benefícios) foi criada no âmbito do projecto SUPER uma framework ontológica, composta por ontologias relativas ao processo, à organização e ao domínio [1, 4]. As ontologias relativas ao processo descrevem a estrutura de um processo, contendo informação relativa às tarefas, estruturas de controlo, etc; as ontologias relativas à organização abordam informação sobre estrutura e os componentes de uma organização; e as ontologias do domínio têm informação sobre uma organização mas que está directamente relacionada com um determinado domínio, sector em que esta se insere [1, 4]. Dos três tipos de ontologias o mais interessante será o conjunto de ontologias relativas à organização, pois são estas que vão permitir uma descrição semântica do conteúdo de um processo (process content), em que está relacionado com os componentes, o ambiente de uma organização [1, 4]. O conjunto de ontologias relativas à organização é constituído pelas seguintes [4]: Organisational Structure Ontology (OSO), tem como objectivo definir as estruturas de uma organização. Estas estruturas englobam departamentos, funcionários, as responsabilidades dos funcionários, os recursos da organização, etc e as relações entre estes elementos. Organisational Units Ontology (OUO), é utilizada para definir determinadas estruturas de pessoas numa organização, como por exemplo um departamento, um grupo, uma equipa, etc. Business Roles Ontology (BROnt), representa o conjunto de papeis tomados pelos actores ligados a uma organização, internos ou externos. Esses papeis podem estar sobre a forma de comportamentos, obrigações, etc. Business Functions Ontology (BFO) é conjunto de funções, sobre a forma de uma área, dentro de uma organização. Por exemplo, gestão de recursos humanos, gestão de vendas, etc. Business Goals Ontology (BGO) é representação do conjunto de objectivos do negócio, de uma forma hierárquica, e as suas características. Business Resource Ontology (BRO) é utilizada para representar os recursos tangíveis e intangíveis de uma organização e que são utilizados nas suas operações. Estes recursos estão directamente ligados ao espaço dos processos de uma organização e podem ser por exemplo uma ferramenta necessária para efectuar uma determinada tarefa, um sistema, etc. Estes conjuntos de ontologias deverão depois ser instanciadas recorrendo à linguagem WSML (Web Service Modeling Language) e que permitirá descrever o processo e o seu conteúdo de uma forma que é acessível a máquinas, tornando possível efectuar queries e manipular o espaço dos processos de uma organização [1].

18 A figura 7 e 8 mostram um exemplo da instância de uma ontologia e de uma querie efectuada ao espaço dos processos recorrendo a WSML, respectivamente. Fig. 7: Exemplo de instância de uma ontologia, adaptado de [1] Fig. 8: Exemplo de uma querie ao espaço dos processos, adaptado de [4] 3.4 Ciclo de vida de um processo no Semantic Business Process Management Nesta secção será apresentado de uma forma simples, no que toca a complexidade, o ciclo de vida de um processo de Semantic Business Process Mangement (SBPM). Será necessário especificar este ciclo de vida de um processo para ajudar a compreender as várias fases, os vários componentes de um projecto SBPM. O ciclo de vida encontra-se representado na figura 9.

19 Fig. 9: Ciclo de vida de um processo no SBPM, adaptado de [6] O ciclo de vida de um processo no SBPM inicia-se com o input de modelos de processos de negócio, que podem ter como origem [6]: Business Process Modeling Tools, ou seja modelos de processos desenhados por humanos através de uma ferramenta de modelação que pretendem representar o as-is ou o to-be. Standards Reference Process Libraries. Um conjunto de especificações de processos que são vistos como boas práticas e fornecidos por vendedores de ERPs. Reverse Business Engineering. Uma metodologia e um conjunto de ferramentas utilizadas para extrair e interpretar dados oriundos de sistemas ERP, de forma a analisar o conjunto de processos de uma organização. Process Mining, que passa pela análise dos processos de negócio de uma organização com base nos ficheiros de registo de um sistema de informação. Pode se acrescentar, que as especificações destes processos de negócio podem ser de dois tipos [6]: Standard, ou seja representações, notações de processos que são standards (ex: BPEL, BPMN,etc) Representações de processos proprietárias De seguida, todos estes inputs, os processos de negócio e a sua informação, devem ser instanciados recorrendo a ontologias [6], esta tarefa é denominada de ontological lifting. As ontologias a serem usadas correspondem às mencionadas anteriormente e

20 que fazem parte da framework ontológica do SBPM, Organisational Strcture Ontology (OSO), Organisational Units Ontology (OUO), Business Roles Ontology (BROnt), Business Functions Ontology (BFO), Business Resources Ontology (BRO) e Business Goals Ontology (BGO). O resultado desta tarefa, ontological lifting, será um conjunto de representações dos processos de SBPM (SBPM process models). De referir que este trabalho de instanciar os processos e a sua informação para ontologias é geralmente um trabalho manual [6]. Estes processos de SBPM serão guardados num repositório que permitirá, através de ferramentas de modelação específicas para o SBPM (SBPM Modeling Tools), a criação de novos processos ou modificação de processos que já existem [6]. Por outras palavras o benefício de manipular o espaço dos processos, mencionado numa secção anterior. Será também possível usufruir do outro benefício mencionado, efectuar uma queries ao espaço dos processos, ou seja através de ferramentas analíticas específicas para o SBPM (Analytic SBPM Tools) será possível analisar o conjunto de processos que o repositório contêm [6]. Haverá também a possibilidade de exportar estes processos de SBPM para formatos como Business Process Execution Language (BPEL) e Event-Driven Process Chains (EPC). Por fim, poderá também ser utilizado um ambiente de execução para o SBPM (SBPM execution engine), que permitirá executar directamente os processos de SBPM [6]. 4 Conclusão Ao longo deste documento, foi efectuada uma análise de dois standards técnicos no âmbito do projecto ISOFIN Cloud, o Enterprise Service Bus (ESB) e o Semantic Business Process Management (SBPM). Estes, ESB e SBPM, são sem dúvida úteis para o projecto, e poderão ajudar-lo a alcançar o seu objectivo, ou seja a criação de uma plataforma que agilize o desenvolvimento e deployment de serviços a serem vendidos a clientes e utilizadores do domínio financeiro (banca e seguros). Utilizando um ESB, este irá apresentar-se como uma ferramenta crucial na criação desta plataforma, possibilitando facilmente criar, gerir e integrar serviços. Esses novos serviços depois poderão ser disponibilizados aos clientes, em que estes pouco ou nenhum trabalho terão em consumir-los graças a agilidade e flexibilidade de um ESB. O SBPM poderá ser útil, no sentido que irá permitir uma gestão mais eficaz e automática dos processos de uma organização. Ou seja, facilmente poderão ser analisados os processos actuais e consequentemente com essa informação alterar, criar ou eliminar processos, no fundo os benefícios do SBPM analisados neste documento.

21 Assim, recorrendo ao controlo do SBPM sobre os processos de uma organização, será mais fácil para esta utilizar os seus recursos na criação de serviços que irão ser posteriormente disponibilizados aos clientes. No entanto, visto que o SBPM é muito recente e se houver interesse em utilizar-lo, deverá ser efectuado um estudo muito mais detalhado e cuidado. Pois ao contrário de por exemplo um ESB, não é algo que seja vendido como uma solução que é facilmente utilizável e configurável. Referências 1. W. Abramowicz, et al., Organization structure description for the needs of semantic business process management, Citeseer, J. Bean, SOA and Web Services Interface Design: Principles, Techniques, and Standards, Morgan Kaufmann, D. Chappell, Enterprise service bus, O'Reilly Media, Inc., A. Filipowska, et al., Organisational ontology framework for semantic business process management, Springer, 2009, pp M. Hepp, et al., Semantic business process management: A vision towards using semantic web services for business process management, IEEE, 2005, pp M. Hepp and D. Roman, An ontology framework for semantic business process management, Proceedings of Wirtschaftsinformatik, vol. 2007, M. Keen, et al., Patterns: SOA with an Enterprise Service Bus, IBM Redbooks, F. Menge, Enterprise service bus, T. Rademakers and J. Dirksen, Open-source ESBs in action, Manning, M. Schmidt, et al., The enterprise service bus: making service-oriented architecture real, IBM Systems Journal, vol. 44, no. 4, 2010, pp B. Wetzstein, et al., Semantic business process management: A lifecycle based requirements analysis, Citeseer, pp Bibliografia 1. G. Hohpe and B. Woolf, Enterprise integration patterns: Designing, building, and deploying messaging solutions, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, J. Jung, Semantic business process integration based on ontology alignment, Expert Systems with Applications, vol. 36, no. 8, 2009, pp M. Nagarajan, et al., Semantic interoperability of web services-challenges and experiences, C. Pedrinaci, et al., Semantic business process management: Scaling up the management of business processes, IEEE, 2008, pp

22 Relatório de acompanhamento do grupo 3 de Processos e metodologias de software Ana Isabel Oliveira Lisboa pg17259 Análise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão, Universidade do Minho Abstract. O propósito deste relatório é descrever como decorreu o processo de acompanhamento do grupo 3 da unidade curricular Processos e Metodologias de Software da Licenciatura em Tecnologias e Sistemas de Informação. O trabalho de grupo decorreu com alguns percalços, mas foi notória uma evolução geral no grupo. O objectivo do trabalho foi atingido com sucesso. Keywords Processos e metodologias de software, Análise e Concepção de Sistemas de Informação, Acompanhamento 1

23 Introdução O propósito deste relatório é descrever como decorreu processo de acompanhamento do grupo 3 da unidade curricular PMS (Processos e Metodologias de Software) da Licenciatura em Tecnologias e Sistemas de Informação. Será descrito o grupo de trabalho, o trabalho proposto, como decorreu o projecto e os resultados alcançados. consultor. Irá também ser abordada a temática do trabalho do coordenador e do Composição do grupo O grupo de trabalho é constituído pelos seguintes elementos: Bárbara Lopes Carlos Moreira David Ribeiro Rita Rodrigues Selma Barbosa Tânia Miranda Trabalho proposto Foi proposto ao grupo que realizassem a fase da Inception do RUP ( Rational Unified Process) para o projecto SMIG (Sistema de Informação da Misericórdia de Guimarães), esta fase consiste na modelação do negócio e dos requisitos do sistema de informação seguindo a metodologia do RUP. O SMIG é o sistema informático integrado que vai apoiar o funcionamento da Misericórdia de Guimarães, uma IPSS (Instituição Privada de Serviço Social) que deve estar em concordância com a norma ISO 9001:2008 que foi recentemente adoptada na organização. Esta primeira fase do RUP estava agendada para decorrer entre Dezembro de 2010 e Janeiro de 2011 (1). Observando o RUP o principal desta entrega era a Visão, e os Diagramas de Casos de uso, Sequência e Robustez, sendo que a Visão é de extrema importância para a compreensão do negócio e do que se pretende do sistema. Os diagramas de casos de uso são de grande importância para a compreensão do sistema a desenvolver, assim como da interacção das pessoas com este e como decorre a sequência de eventos de um actor que usa o sistema para completar um 2

24 processo (2). Os diagramas de robustez servem para descrever cada requisito funcional definido anteriormente pelos casos de uso (3). Os diagramas de sequência permitem visualizar a evolução temporal das mensagens trocadas (4). Reuniões Durante o decorrer do trabalho reuniões semanais com o grupo eram aconselhadas, e a presença nestas obrigatória para os elementos do grupo. Posto isto, e para não haver conflitos de horário com outras unidades curriculares decidi marcar as reuniões durante as aulas práticas da unidade curricular de Processos e Metodologias de Software. A ordem de trabalhos era saber como correu o trabalho durante a semana transacta, recolher as dúvidas dos elementos, esclarecelas e questionar o docente sobre alguma dúvida mais específica, assim como inteira-lo do trabalho efectuado no grupo. Também tinha início a preparação da tabela com a divisão de tarefas pelos elementos. Na primeira semana de trabalho do projecto ainda havia certa confusão com as tarefas a realizar por isso a distribuição não foi das mais justas. Este facto foi notado e corrigido quando o erro foi detectado e a distribuição foi mais justa. Na semana das férias de natal como os elementos do grupo residem em locais distantes, decidi marcar duas reuniões pela internet. Na primeira semana indiquei-lhes que iria estar nas instalações da universidade para irem ter comigo ou podiam apenas comunicar pela internet. Nesse dia todos os elementos do grupo interagiram comigo. Na semana seguinte, enviei um ao grupo para indagar sobre o andamento do trabalho e se existiam dúvidas. Devido às respostas que obtive do grupo e ser uma semana de férias, resolvi tirar as dúvidas pela internet com os elementos do grupo e aconselhei-os a prepararem um pré-relatório para que não descurassem a montagem do relatório final. Na semana final de trabalho infelizmente tive um falecimento na família que me impediu de realizar um acompanhamento próximo do grupo. Avisei-os atempadamente da situação e eles tomaram a iniciativa de se organizarem com a distribuição das tarefas e esclareceram as suas dúvidas com o docente das aulas práticas. Nas restantes semanas de trabalho as reuniões seguiram o planeado, mas não foram referidas pois o trabalho decorreu sem percalços. 3

25 Distribuição de tarefas Para que não houvesse dúvidas sobre as tarefas que cada elemento teria que realizar, elaborei uma tabela em que estava explicita a distribuição por elemento de grupo, esta tabela registava também o tempo que era expectável despender-se para realizar certa tarefa e o tempo que de facto essa tarefa tomou. Inicialmente os elementos não perceberam bem a ideia da tabela, nem comunicavam muito entre si, pelo que existiram situações em que em vez de os elementos trabalharem em conjunto estavam separados a realizar o mesmo trabalho. Para evitar estas situações melhorei a tabela, para que a visualização das tarefas ser mais fácil e também reforcei a ideia de que os elementos devem comunicar não só entre sub-grupos de trabalho, mas também com todos os outros elementos, já que havia tarefas que dependiam de outras. Depois deste primeiro refinamento inclui uma coluna para registar as presenças nas reuniões, numa fase posterior (realização dos diagramas) acrescentei ainda mais uma coluna em que cada elemento escrevia com ainda mais detalhe as tarefas e diagramas que realizava para não haver sobreposição de trabalho. A distribuição era feita de modo a que o trabalho a efectuar fosse equilibrado pelos elementos do grupo, para que não houvesse elementos a trabalhar por excesso e outros por defeito. Também tinha em atenção algumas aptidões pessoais, se algum elemento expressasse o desejo de realizar certa tarefa por gostar mais da mesma essa tarefa era-lhe atribuída. Controlo do trabalho efectuado Outra das minhas competências prendia-se com controlar o trabalho realizado pelo grupo. Este controlo era efectuado aquando da construção da nova tabela de tarefas. Na secção da crítica ao trabalho do grupo irei elaborar com decorreu o trabalho no geral. Quando notava um atraso nas tarefas que os elementos tinham que realizar eu comunicava-lhes esse atraso e relembrava-os do trabalho ainda por fazer e do tempo que lhes restava, para que eles tentassem perceber que se não fizessem as actividades atempadamente iriam ficar muito sobrecarregados nas últimas semanas ou entregar o trabalho incompleto. 4

26 Foi com algum contentamento que mesmo com o abrandamento do trabalho devido às férias do Natal, na primeira aula prática depois das férias, em conversa com os colegas notei que o meu grupo se encontrava com o trabalho bastante avançado. Facto que teve um papel importante quando se verificou a perda de alguns documentos importantes para o projecto. Como havia uma certa folga o grupo conseguiu compensar o trabalho extra que tiveram que realizar para contrabalançar a perda. Quanto ao controlo de qualidade efectuado este pode-se distinguir em duas partes, controlo quanto a plágios e controlo quanto ao conteúdo. Como para certas partes do trabalho o grupo tinha que recolher informações (como por exemplo para fazer textos explicativos sobre os diagramas) assumi como função importante controlar os plágios e a referenciação desses textos. Infelizmente notei que alguns dos elementos do grupo fizeram cópia integral numa primeira versão desses textos, acto para o qual foram alertados, assim como para incluírem as referências, para constarem no relatório final. Controlo quanto ao conteúdo era realizado, geralmente uma vez por semana para verificar se os conteúdos produzidos estavam correctos e completos. Escrevia notas nos documentos produzidos com algumas correcções e perguntas para que os elementos corrigissem e pensassem melhor nas actividades a desenvolver. As dúvidas que não conseguia esclarecer ao grupo, ou que mesmo depois de algum esclarecimento careciam de confirmação eram encaminhadas ao docente das práticas de PMS. Para tal criei um documento partilhado para que todos os elementos escrevessem as suas dúvidas, depois da revisão das mesmas por mim realizada, as que não conseguia responder eram esclarecidas com o docente nas aulas práticas. Devido ao mesmo motivo pelo qual não me foi possível acompanhar o grupo na última semana de trabalho, foi-me também impossível realizar uma verificação ao documento submetido para avaliação. Crítica ao trabalho do grupo Devo referir que no inicio do trabalho com o grupo, quando ainda estavam a realizar o projecto anterior, eles tinham ficado com a ideia que os consultores iam ser mais um elemento do grupo que ia realizar as tarefas com eles. Durante 5

27 esta fase eles não estavam interessados em tirar dúvidas, as únicas vezes que alguns elementos do grupo me contactavam era durante os intervalos das aulas para esclarecerem um ou outro ponto. Notei que durante esta fase o grupo estava muito dividido e que não havia interesse da maioria dos elementos. Este facto levou a que aquando da entrega eu tivesse que de facto ajudar o grupo com algumas tarefas executando-as numa fase inicial para que eles percebessem como era. Devo referir que o eles era somente a Selma, já que os outros elementos estavam completamente desligados do trabalho deixando a planificação toda nas mãos dela e não a ajudando nas suas dificuldades. O nosso novo papel de coordenador foi clarificado com o grupo a partir da aula em que lhes foi explicado devidamente o nosso papel e o que eles deveriam exigir de nós. Penso que se calhar, durante a fase de consultores o grupo não percebeu como era suposto decorrer a interacção comigo. No inicio do trabalho de grupo os elementos não tomavam iniciativa de sub-dividir as tarefas que eu lhes atribuía, por exemplo, atribuindo a um grupo de 3 elementos a visão eles começaram todos a fazer o mesmo trabalho sem comunicarem uns com os outros para combinarem os pontos que cada um trataria. Outro facto que notei era que os elementos comunicavam pouco entre si o que originou a algumas confusões como a sobreposição de tarefas p.e. À medida que eu notava estas falhas (a mais grave foi a primeira) eu indiquei ao grupo como deveriam proceder e adaptei a tabela de distribuição de tarefas para que a sua visualização fosse mais fácil. Penso que este ponto ficou muito bem esclarecido com o grupo, já que nas últimas semanas eles já se organizavam entre si (seguindo a tarefa que eu distribuía) e interagiam melhor, coisa que se notou quando começaram a tratar dos diagramas já que alguns diagramas dependiam de outros feitos pelos restantes elementos. No inicio do trabalho foi notório que alguns elementos não demonstravam interesse no trabalho nem se esforçavam muito. Com o andar do trabalho notei um aumento do interesse pela parte da maioria dos elementos mas um ou outro continuava a tentar fazer o mínimo possível. Postos todos estes contratempos e evoluções positivas, chegado Janeiro constatei que o grupo era dos mais avançados nas suas tarefas (já tinham vários diagramas feitos, quando outros grupos ainda nem os tinham começado). Para que 6

28 o grupo se começasse a organizar para a preparação do relatório, nomeei um dos elementos do grupo para começar a preparar uma espécie de entrega intermédia para que a estruturação do relatório tivesse início. Este avanço nas tarefas foi a chave para o grupo ter conseguido recuperar da perda de alguns diagramas de caso de uso. Eles partilhavam o ficheiro recorrendo à Dropbox, contudo o ficheiro ficou corrompido e apenas alguns diagramas eram acessíveis. Este acidente podia ser evitado se os elementos responsáveis pelos diagramas tivessem tirado print screen quando eu lhes indiquei (quando os primeiros ficaram prontos), mas um dos elementos, mesmo após várias chamadas de atenção ainda não os tinha tirado e quando tentou é que reparou no que tinha acontecido. Entre o primeiro pedido dos prints e o reparo passaram sensivelmente 3 semanas. O que mais me espantou neste problema foi que o elemento que atrasava sucessivamente a realizar os print screens aquando da corrupção dos ficheiros estava a tentar distanciar-se do problema dizendo que a culpa não era dele, o que demonstrou um grande individualismo dentro do grupo de trabalho. Selma Desde o inicio do trabalho que demonstrou grande interesse e sempre realizou as tarefas atempadamente. Barbara Este elemento embora demonstrasse interesse demorou muito tempo até instalar a ferramenta necessária para trabalhar com os diagramas, embora esta já fosse necessária e estava disponível há muito tempo. Passou uma semana a fazer pouco rendimento comparando com os colegas pois dizia não ter a ferramenta instalada. Respondia atempadamente aos s de contacto. Rita Este elemento demonstrou interesse pelo trabalho, não contestou o trabalho atribuído e entregou os artefactos atempadamente. 7

29 Tânia Demonstrava interesse pelo trabalho. Respondia atempadamente aos s de contacto. Não rejeitou o trabalho que lhe foi atribuído e entregou os artefactos atempadamente. Carlos Demonstrava interesse pelo trabalho, respondia-me atempadamente aos s. Nunca rejeitou trabalho que lhe era atribuído e entregou os artefactos atempadamente. David Era o elemento mais individualista. Os diagramas realizava-os atempadamente, mas quando houve o problema dos diagramas corrompidos tentou culpar os colegas e esqueceu-se que já tinha sido avisado há muito tempo para tirar print screens e nunca os tinha feito. Era raro responder-me aos s. Só apareceu a uma reunião. Coordenador Observando o dicionário da língua portuguesa coordenador é uma pessoa que organiza e orienta um projecto ou actividade de grupo (5). Segundo Andalo (6) um coordenador tem que exibir as seguintes características: Gostar e acreditar em grupos; Amor às verdades; Coerência; Senso de ética; Respeito pelas características dos participantes; Paciência; [ ] Função de pensar; Discriminação; Comunicação (verbal e não verbal); [ ] Empatia; Síntese e integração. Condensando estas características, resumidamente pode-se dizer que um coordenador tem que ter uma série de aspectos ligados a valores; características que demonstram equilíbrio emocional; Funções cognitivas; Boa comunicação. Outro factor que não deve ser descurado é a competência técnica e teórica na área em questão, já que sem competências base não consegue liderar o grupo nem fazer uma distribuição de tarefas ponderada. São tarefas do coordenador de grupo definir claramente as tarefas a executar, alocar as tarefas aos recursos, definir pontos de controlo, controlar o cumprimento dos pontos de controlo e gerir pessoas (membros da equipa). (7) 8

30 Consultor Segundo o dicionário da língua portuguesa, um consultor é um perito em determinado assunto adstrito a algum organismo ou empresa, para proporcionar consultas sempre que se levante alguma dúvida sobre a matéria da sua especialidade (5). O papel do consultor é acompanhar o grupo de trabalho desde o iníco até ao fim, e orientar o grupo de forma a que o projecto se enquadre no âmbito, tempo e custo definidos. (8) Conclusão No início o grupo não sabia o que esperar dos consultores, pensavam que éramos mais um elemento do grupo, que ia realizar tarefas com eles. E nunca chegaram a ter grandes solicitações. Depois de uma sessão em que lhes foi apresentado o nosso papel de coordenadores o grupo começou a perceber o que devia esperar e exigir de nós. O trabalho de grupo decorreu com alguma falta de interesse dos elementos e um ou outro com mais interesse. Apesar de tudo o trabalho foi sendo realizado até com algum adianto, o que foi importante por causa do contratempo que houve que os pôs ao nível dos outros grupos. Bibliografia 1. Ribeiro, Pedro. PMS projecto 1. Guimarães : Universidade do Minho, 2010/ Ambysoft Inc. UML 2 Use Case Diagrams. Agile Modeling. [Online] [Citação: 24 de Janeiro de 2011.] 3.. Agile Modeling. Robustness Diagrams. [Online] [Citação: 25 de Janeiro de 2011.] 4. Ambisoft. Agile Modeling. UML 2 Sequence Diagrams. [Online] [Citação: 25 de Janeiro de 2011.] 9

31 5. Porto editora. Dícionário da Língua Portuguesa. Infopedia - Enciclopedias e Dicionários Porto Editora. [Online] [Citação: 4 de Fevereiro de 2011.] 6. ANDALO, Carmen Silvia de Arruda. O papel de coordenador de grupos. Psicol. USP [online]. n.1, 2001, Vols. vol.12,. 7. Kerzner, Harold. Project management: A systems approach to planning, scheduling and controlling. Hoboken, New jersey - USA : John Wiley and Sons Inc., Schawlbe, Kathy. Information Tecnology Project Management. Boston, MA, USA : Cengage Learning, Inc, Porto Editora. Dicionário da Língua Portuguesa. Infopédia - Enciclopédia e Dicionários Porto Editora. [Online] [Citação: 4 de Fevereiro de 2011.] Anexos A1 - Lista de distribuição de tarefas e presenças nas reuniões 10

32 Imagem 1 - Semana de trabalho 1, de a Imagem 2 - Semana de trabalho 2, de a Imagem 3 - Semana de trabalho 3, de a

33 Imagem 4 - Semana de trabalho 4, de a Imagem 5 Semana de trabalho 5, de a

34 Impactos do papel de consultor e gestor de projectos no trabalho de equipa Ângelo Conde DSI, Universidade do Minho, Portugal Abstract. Este relatório intermédio pretende mostrar os benefícios e dificuldades da envolvência entre o consultor, numa primeira fase, e posteriormente de gestor/coordenador, e a equipa da unidade curricular de Processo e Metodologias de Software (PMS), no âmbito da unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI). Dentro de um ambiente aproximado da realidade, onde o trabalho do grupo é supervisionado, surgem dificuldades idênticas ao mundo do trabalho, enriquecendo e preparando o coordenador para o que lhe reserva o mundo do trabalho. Keywords: coordenação, planeamento, gestão de projectos, consultoria 1 Introdução Este relatório intermédio pretende mostrar os benefícios e dificuldades da envolvência entre o coordenador e a equipa da unidade curricular de Processo e Metodologias de Software (PMS), no âmbito da unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI). Inicialmente foi atribuído uma equipa de cinco elementos, onde o coordenador terá que ser capaz de planear as tarefas a realizar, distribuir essas mesmas tarefas pelos vários recursos disponíveis, supervisionando a qualidade destas e o modo como foram desempenhadas. Este desempenho é relatado semanalmente, de preferência, ou então quinzenalmente, em casos extremos.

35 Baseando-se na metodologia RUP (Rational Unified Process), a equipa focar-se-á na fase de Inception, essencialmente nas disciplinas de modelação de negócio e de requisitos. Todas as actividades planeadas e atribuídas pela equipa irão gerar os artefactos relevantes para a conclusão da fase de Inception. Este relatório está organizado primeiramente por uma secção de fundamentos, essencial perceber, as várias metodologias adoptadas no decorrer do projecto. Seguidamente, serão abordados todos os aspectos que dizem respeito à interacção do coordenador com o grupo de trabalho, desde o papel desempenhado de consultor e o de gestor/coordenador do projecto. Por fim, será feita uma análise de toda a experiência vivida com este tipo de simulação da vida no mercado de trabalho para o meio académico, destacando as vantagens e novos conhecimentos adquiridos com este tipo de regime de avaliação diferente do habitual. 2 Fundamentos Primeiramente, é essencial perceber o teor das unidades curriculares para o qual se realizou este projecto, Análise e Concepção de Sistemas de Informação (ACSI) e Processo e Metodologias de Software (PMS). É essencial perceber, as várias metodologias adoptadas no decorrer do projecto, necessárias de interiorizar, para transmitir o conhecimento à equipa de trabalho, essencial para atingir as metas delineadas. 2.1 Análise e Concepção de Sistemas de Informação Esta unidade curricular foi o grande motor que permitiu simular os papéis de consultor e gestor de projectos. Para tal, é necessário compreender a sua finalidade, e o porquê de nos proporcionar esta experiência, que dará uma perspectiva do que se poderá esperar no mundo real do trabalho. Segundo Machado e Santos [1], os frequentadores desta unidade curricular serão capazes de identificar os problemas e discutir alternativas de resolução dos problemas inerentes à execução das fases de análise e de concepção de sistemas de informação; executar as tarefas de engenharia de requisitos e de transposição para modelos lógicos 2

36 e arquitecturais, em projectos de mediana complexidade de sistemas de informação; implementar repositórios de dados, recorrendo a técnicas avançadas de projecto de sistemas de informação. Dividida em dois métodos de avaliação, os frequentadores seriam capazes de escolher entre a escrita de um artigo sobre um determinado assunto, dentro do âmbito de ACSI, ou então envergarem um papel dentro de uma equipa de trabalho, que permitirá simular, em contexto académico, as dificuldades esperadas em liderar uma equipa de trabalho. Ao envergar por um destes dois tipos de avaliação, o aluno será capaz de adquirir todos os resultados de aprendizagem (RA) propostos. Obviamente, cada método possui características diferentes de aprendizagem. Em relação ao escolhido - integrar uma equipa de trabalho de PMS - para além dos RA inicialmente definidos, permitirá melhorar outra componente essencial, a parte social/comunicativa. 2.2 Processo e Metodologias de Software Esta unidade curricular será essencial para pôr em prática o método escolhido em ACSI. Permitirá recriar um cenário do mundo real do trabalho, onde será possível a percepção das dificuldades que se encontrará em liderar/coordenar uma equipa de trabalho, bem como transmitir conhecimento à equipa e enfrentar a pressão de cumprir com os prazos definidos pela organização para a qual estamos a desempenhar funções (neste caso será dos docentes da unidade curricular de PMS). Segundo Ribeiro [2], no final do projecto (no qual estará a equipa a liderar) os alunos serão capazes de identificar as áreas de conhecimento propostos pelo SWEBOK 2004; compreender os modelos do processo de desenvolvimento de software; identificar as diferentes estratégias de avaliação e melhoria do processo de desenvolvimento de software; elaborar o plano de um projecto de desenvolvimento de software, seguindo as orientações do PMBoK 2004; aplicar as técnicas propostas pelo UML para realizar a disciplina de Modelação de Negócio, no âmbito do RUP. Será fundamental para o resultado final, que sejam entendidas todas as metodologias desta unidade curricular, que serão aplicáveis em todo o processo do projecto, para da melhor forma ajudar a equipa a atingir os seus objectivos. 3

37 2.2.1 Software Engineering Body of Knowledge O guia do SWEBOK é um projecto da IEEE Computer Society, onde é apresentado uma caracterização explícita dos limites da engenharia de software [3]. Segundo Abran [4], o guia tem como propósito descrever que porção do corpo do conhecimento (BoK) é aceite, para organizar essa parte e posteriormente fornecer um acesso mais facilitado por tópicos. O SWEBOK é subdividido em dez áreas de conhecimento (KAs) em engenharia de software. Contém também, um apêndice (apêndice A) onde é fornecida uma visão geral das KAs. As dez KAs são: requisitos de software, concepção de software, construção de software, teste de software, manutenção de software, gestão de configuração de software, gestão de engenharia de software, processo de engenharia de software, ferramentas e métodos de engenharia de software e qualidade do software [3]. Este guia foi estabelecido com o objectivo de promover uma visão coerente de engenharia de software a nível mundial; clarificar o lugar (e definir os limites) da engenharia de software em relação a outras disciplinas; caracterizar o conteúdo da disciplina de engenharia de software; fornecer uma base para o desenvolvimento do currículo e para a certificação individual e licença de materiais [3] Project Management Body of Knowledge O principal objectivo do guia do PMBoK é identificar o conjunto de conhecimentos (KAs) em gestão de projectos que é reconhecido como uma boa prática. Como boa prática entende-se que a equipa é responsável por determinar o que é apropriado para o seu projecto, e não que o conhecimento implícito seja aplicado uniformemente em todos os projectos [5]. O PMBoK organiza os quarenta e quatro processos de gestão dentro de nove KAs: gestão da integração do projecto, gestão do âmbito do projecto, gestão do tempo do projecto, gestão do custo do projecto, gestão da qualidade do projecto, gestão dos recursos humanos do projecto, gestão das comunicações do projecto, gestão de riscos do projecto e gestão das aquisições do projecto. 4

38 Este guia será fundamental para perceber os conceitos de projecto, e gestão de projectos que serão postos em prática no trabalho com a equipa, onde o processo de planeamento a ser adoptado é baseado numa perspectiva top-down de acordo com o PMBoK Unified Modeling Language A Unified Modeling Language (UML) é uma linguagem de modelação visual que é utilizada para especificar, visualizar, construir e documentar os artefactos de um sistema de software. Captura as decisões e a percepção sobre os sistemas que devem ser construídos. É utilizado para entender, conceber, pesquisar, configurar, manter e controlar informações sobre esses sistemas [6]. Para Dzidek [7], o UML permite a representação visual da especificação de um sistema em vários níveis de concepção e é utilizado para construir e documentar os artefactos de um sistema de software orientado a objectos. Apesar de ser amplamente utilizado, existem autores que apontam várias limitações quanto ao modo como permite a descrição da arquitectura. Woods e Emery [8] realçam duas limitações. Em primeiro lugar, o UML não permite aos arquitectos descrever os construtores que geralmente são utilizados para conceber softwareintensive systems. Em segundo lugar, não expressa muitas das preocupações que os arquitectos devem ter em conta. A título de curiosidade, em 2005, foi realizado um estudo [9] sobre a percentagem de utilização das principais componentes de UML utilizadas em projectos por utilizadores com alguma experiência. Os resultados obtidos indicam que os diagramas mais utilizados são os de classe, seguido dos casos de uso, sequência, actividade, estado e colaboração Rational Unified Process O ciclo de vida do Rational Unified Process [10] é constituído por quatro fases: inception, elaboration, construction e transition. Cada uma destas fases é composta por iterações, onde estão presentes as várias actividades a executar. As fases estão 5

39 cruzadas com as disciplinas de engenharia (modelação de negócio, requisitos, análise e concepção, implementação, teste, e deployment) e de suporte (gestão da configuração e mudança, gestão do projecto e ambiente). Para este projecto serão consideradas apenas as disciplinas de modelação de negócios e requisitos, cruzadas com a fase da Inception. Este cruzamento permitirá conhecer quais as actividades a executar pela equipa de trabalho. 3 Interacção com o grupo de trabalho Antes de perceber os papéis desempenhados na interacção com a equipa de trabalho, é necessário entender no que iremos debruçar. O objectivo é planear e executar a fase da Inception do projecto SIMG (Modelação de Negócios e Requisitos), sendo no final produzida uma proposta para ser apresentado ao Cliente. Mas afinal o que é um projecto? Segundo o PMBoK [5], um projecto é um esforço temporário empreendido para criar um produto, serviço ou resultado. Para Munns e Bjeirmi [11], pode ser considerado como a realização de um objectivo específico, que envolve uma série de actividades e tarefas que consomem recursos. Tem que ser concluído dentro de um prazo estabelecido, com início e data final definidos. Independente do papel que for desempenhado, é necessário ter em mente atingir um determinado objectivo (concluir o projecto), com a realização de determinadas actividades e tarefas, utilizando os recursos disponíveis, sejam eles com capacidades, ou não, o resultado final o dirá. 3.1 Consultor Inicialmente foi assumido o papel de consultor da equipa de trabalho. Com a inclusão de um consultor, a equipa de trabalho ganhava um recurso extra para conseguir alcançar um trabalho de qualidade. Para entender qual o verdadeiro papel de consultor, seria necessário rever alguma literatura. Como consultor, era esperado que acrescentasse valor à equipa, com uma nova perspectiva, objectividade, uma base de conhecimento específico ou uma determinada 6

40 especialidade a que não tinham possibilidade de acesso [12]. Para Stroh e Johnson [13], um consultor é definido como alguém que aconselha um cliente sobre a conveniência de tomar uma determinada acção, ou que auxilia o cliente a tomar uma decisão, auxiliando, posteriormente, o cliente no planeamento ou implementação de determinadas acções, conforme determinado pelo cliente. Segundo Cohen [14], um consultor é alguém que fornece conselhos ou executa outros serviços de natureza profissional ou semiprofissional, em troca de compensação. De acordo com Block ([15] referenciado em [16]), devem ser consideradas três competências para se ser um consultor de sucesso - competências técnicas, interpessoais e de consultor. No que diz respeito às competências técnicas, o autor deu o exemplo da área das tecnologias de informação, onde as competências técnicas tornavam-se obsoletas rapidamente, sendo importante que o consultor mantivesse actualizadas as suas competências técnicas. Em relação às competências interpessoais, o autor assume que o consultor deve possuir a destreza de passar as suas ideias para palavras, ouvir os outros e de fornecer suporte à equipa, sendo capaz de discordar e de sugerir ideias que contrariem o proposto pelo cliente. Quanto às competências de consultor, o autor afirma que assumem o papel similar ao de um gestor de projecto. Existem também, as cinco fases que um consultor deve seguir para ter sucesso no seu projecto [15, 17]. Contudo, como este papel não foi além do planeamento da Inception, não faz muito sentido mencionar cada uma delas. Revista a literatura, é possível fazer uma comparação com o que foi realizado com a equipa de trabalho. Como tinha mais experiência que a minha equipa, visto que já passei por as dificuldades que eles iriam encontrar, já seria possível indicar qual o melhor caminho a seguir, e as razões de não seguir pelo caminho menos apropriado. A compensação deste trabalho, em vez da monetária, ou então da subida para um cargo mais elevado, será a atribuição de uma nota final à unidade curricular de ACSI, a obtenção de conhecimento em determinadas áreas (que apesar de já ter passado por elas, muitas delas foram cimentadas com este trabalho) e sobretudo enfrentar as dificuldades deste trabalho, muito idênticas ao que nos espera no mundo do trabalho. 7

41 3.2 Gestor/Coordenador Com este novo papel seriam necessárias novas competências de gestão, para lidar correctamente com a equipa de trabalho. Para tal, nada melhor que voltar atrás no tempo, e recordar o que Fayol afirmou em Segundo Fayol ([18] referenciado em [19]), um gestor deve ser capaz de planear, controlar, organizar e dirigir. Segundo o PMBoK [5], o gestor de um projecto é a pessoa responsável por realizar os objectivos do projecto. Para Wateridg [19], o gestor de projecto está envolvido na criação do projecto e na supervisão do mesmo até ao final. O mesmo autor afirma ainda, que a cooperação e o trabalho em equipa desempenham papéis importantes na gestão de projectos. Thamhain ([20] referenciado em [19]) identificou três áreas de conhecimento na gestão de projectos: competências administrativas, interpessoais e técnicas. Outros factores a ter em conta na gestão do projecto são as três restrições - âmbito, tempo e custo. Segundo o PMBoK [5], a qualidade do projecto final é afectada pelo balanceamento destes três factores. Turner e Müller [21] afirmam que o sucesso do projecto depende muito das competências do gestor, tais como o estilo de liderança que compreende a inteligência emocional (referenciado em [22]). Contudo, outros autores ([23] referenciado em [24], [22]) garantem que pessoas diferentes julgam o sucesso do projecto de maneiras diferentes, dependendo dos seus objectivos pessoais. Por exemplo, enquanto eu posso afirmar que este projecto foi um sucesso para mim, devido às competências que me trouxe e à nota final obtida (recompensa), já a minha equipa (alunos da unidade curricular de PMS) pode achar que foi um fracasso, porque acharam que não lhes trouxe nada de novo, ou então porque não foram devidamente recompensados na nota final. 3.3 Troca de papéis Tudo corria bem ao inicio do projecto, apresentações com o cliente (Santa Casa da Misericórdia de Guimarães), reuniões iniciais com o grupo de trabalho. Contudo, a certa altura da fase do planeamento da Inception, o cenário começou a não ser tão favorável como seria de esperar. A equipa começou a desleixar-se, não apresentava 8

42 dúvidas nas reuniões semanais, tornando assim o trabalho de consultor difícil. Se não colocavam dúvidas, era difícil corroborar as opiniões deles (que eram nulas) e orientálos pelo melhor caminho. Era necessário ter maior controlo sobre eles. Como não tinha o poder de exercer liderança, nem de os obrigar a fazer, mas sim só a aconselhar, alinhado ao facto de já conhecer pessoalmente todos os membros da equipa, veio afectar o rendimento da equipa, bem como a qualidade final da primeira fase do projecto (planeamento da fase de Inception). Devido a estes problemas, o melhor foi mudar a influência dentro do seio da equipa de trabalho. Um novo papel foi proposto, gestor/coordenador da equipa de trabalho. Com este novo papel tivemos direito a usar novos poderes sobre a equipa de trabalho. Segundo Dahl [25], poder é a capacidade que um indivíduo (coordenador) tem de influenciar o comportamento de outros (membros da equipa de trabalho), levando-os a fazer algo que de outra forma não faria sem a intervenção do coordenador. Era exactamente o que faltava. Os membros da equipa de trabalho encontravam-se descansados, pensando que o consultor resolveria tudo. Para corrigir este problema, foi-nos concebido o poder de: Agendar reuniões; Planear tarefas; Distribuir tarefas pelos vários membros da equipa; Supervisionar a qualidade técnica dos artefactos produzidos; Reportar periodicamente o desempenho de cada membro da equipa; A partir deste momento, eram delineadas tarefas a cada um para realizar até à próxima reunião. Nessas reuniões as dúvidas dos membros eram dissipadas, e era monitorizada a percentagem de conclusão da tarefa. Era neste ponto, que era feita a avaliação do trabalho de cada membro, para assim conseguir reportar o que cada um produziu ao docente responsável. Com este controlo sobre o grupo, os membros passaram a produzir muito mais. Mais produção implica mais dúvidas. Mais dúvidas implicam mais interacção entre membro e gestor/coordenador. Mais interacção implica melhor capacidade de avaliar 9

43 um membro. Melhor capacidade de avaliação realizada leva a um melhor report de cada membro aos docentes das unidades curriculares de PMS e ACSI. Mas nem tudo correu como estava planeado. Muitas das tarefas não foram cumpridas na data planeada, alguns membros não executaram as actividades que estavam planeadas para eles, e sobretudo falta de empenho. A soma destes factores ao factor tempo contribuiu para que a qualidade do projecto final fosse baixa. É certo que a culpa pode não ter sido só dos membros da equipa. Eu posso ter falhado também em alguns aspectos da gestão do projecto. Avots [26] afirma que as principais razões para não se obter sucesso num projecto se deve à escolha da pessoa errada para o gerir, à definição inadequada das tarefas, técnicas de gestão não apropriadas ou a data final do projecto não foi planeada. Olhando para as razões apontadas por Avots, a mais preocupante no projecto, foi mesmo a não utilização de técnicas apropriadas à gestão de projectos. A troca de papéis a meio do projecto foi fundamental para que não houvesse o cuidado de aplicar as técnicas adequadas. 3.4 Experiência alcançada No fim de tudo, é necessário olhar para trás e ver de que proveito pode ser retirado desta experiência. A partir do momento que houve a troca de consultor para gestor do projecto, os membros da equipa de trabalho foram forçados a apresentar trabalho feito, o que facilitou a interacção entre os dois lados, permitindo que as competências de comunicação fossem treinadas. O planeamento de tarefas foi essencial para saber organizar uma equipa e saber distribuir o trabalho por cada membro. Foi essencial esta mudança para que a competência de liderança, comando da equipa fosse posta em prática. 4 Conclusão A simulação deste ambiente parecido com o mundo do trabalho, entre as unidades curriculares de PMS e ACSI deve ser posto em prática entre outras unidades curriculares. É essencial obter esta experiência no mundo académico, para cometer os 10

44 erros e aprender com esses mesmos erros, para obtermos a percepção do que nos espera lá fora. Os erros cometidos nestes ambientes simulados, permitirá que não se caia nestes erros no mundo real do trabalho, preparando de maneira mais eficaz os frequentadores deste tipo de experiência. Seria interessante, analisar se o facto de o coordenador da equipa conhecer pessoalmente os membros da equipa, afecta ou não este tipo de experiências simulados em nível académico. Uma possível abordagem no próximo ano, seria colocar coordenadores que conhecessem os membros, e outros que não conhecessem a equipa, e comparar os resultados finais. Isto levaria, a que nos anos posteriores, a distribuição dos frequentadores deste tipo de experiência pelos grupos não fosse escolhida por eles (onde ambas as partes já se conhecessem), mas sim colocá-los em grupos onde trouxesse melhores resultados para ambas as partes. Não é possível concluir, precisamente, qual das duas fases deu mais resultado para lidar com os membros da equipa. É de notar, que houve um melhoramento desde que foi assumido o novo papel de gestor/coordenador. Mas será que se fosse invertida a ordem de papéis o resultado não seria diferente? É uma pergunta pertinente, em que a resposta só é possível, se for testado noutros anos lectivos, onde o papel de gestor/coordenador entra na fase de planeamento da Inception e o de consultor apenas na sua execução. Deixa-se aqui o conselho, para que este teste seja executado, para sim depois responder a esta pergunta. 5 Referências [1] R. Machado, and M. Santos, "Análise e Concepção de Sistemas de Informação (Apresentação)," Análise e Concepção de Sistemas de Informação, [2] P. Ribeiro, "Apresentação da Unidade Curricular," Processos e Metodologias de Software, [3] A. Abran, J. W. Moore, P. Bourque et al., SWEBOK : Guide to the Software Engineering Body of Knowledge: IEEE Computer Society, [4] A. Abran, J. J. Cuadrado, E. García-Barriocanal et al., "Engineering the Ontology for the SWEBOK: Issues and Techniques," Ontologies for 11

45 Software Engineering and Software Technology, C. Calero, F. Ruiz and M. Piattini, eds., pp : Springer Berlin Heidelberg, [5] I. Project Management, A guide to the project management body of knowledge: PMBOK Guide: Project Management Institute Newtown Square PA, USA, [6] J. Rumbaugh, I. Jacobson, and G. Booch, Unified Modeling Language Reference Manual, The, Massachussetts: Addison-Wesley, [7] W. J. Dzidek, E. Arisholm, and L. C. Briand, A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance, IEEE Trans. Softw. Eng., vol. 34, no. 3, pp , [8] E. Woods, and D. Emery, Is UML Sufficient for Describing Architectures?, IEEE Software, vol. 27, no. 6, [9] B. Dobing, and J. Parsons, "Current Practices in the Use of UML," Perspectives in Conceptual Modeling, Lecture Notes in Computer Science J. Akoka, S. Liddle, I.-Y. Song et al., eds., pp. 2-11: Springer Berlin / Heidelberg, [10] RUP, "Rational Unified Process," IBM. [11] A. K. Munns, and B. F. Bjeirmi, The role of project management in achieving project success, International Journal of Project Management, vol. 14, no. 2, pp , [12] O. MIT Careers. "Consulting," (Acedido em 25 de Janeiro de 2011); [13] L. Stroh, and H. Johnson, The Basic Principles of Effective Consulting, New Jersey: Lawrence Erlbaum Associates, [14] W. Cohen, How to Make It Big as a Consultant, New York: AMACOM, [15] P. Block, Flawless consulting: A guide to getting your expertise used, California: Pfeiffer, [16] I. Akri Consulting, "3 Skills a Consultant Must Have," Information Technology Consulting Blog, Akri Consulting, [17] M. Kubr. "Management Consulting: A Guide to the Profession," 12

46 [18] H. Fayol, I. Gray, E. Institute of et al., General and industrial management: Pitman London, [19] J. Wateridge, Training for IS/IT project managers: A way forward, International Journal of Project Management, vol. 15, no. 5, pp , [20] H. J. Thamhain, Developing project management skills, Project Management Journal, vol. 22, no. 3, pp , [21] R. Müller, and J. R. Turner, Matching the project manager's leadership style to project type, International Journal of Project Management, vol. 25, no. 1, pp , [22] R. Müller, and R. Turner, The Influence of Project Managers on Project Success Criteria and Project Success by Type of Project, European Management Journal, vol. 25, no. 4, pp , [23] J. K. Pinto, and D. P. Slevin, Critical success factors in R&D projects, Research technology management, vol. 32, no. 1, pp , [24] A. Murphy, and A. Ledwith, Project management tools and techniques in high-technology SMEs, Management Research News, vol. 30, no. 2, pp , [25] R. A. Dahl, The concept of power, Behavioral science, vol. 2, no. 3, pp , [26] I. Avots, Why does project management fail?, California Management Review, vol. 12, pp , Bibliografia A. Aurum, and C. Wohlin, Engineering and managing software requirements: Springer Verlag, R. F. Goldsmith, Discovering real business requirements for software project success: Artech House Publishers,

47 Gestão de Projecto na Fase Inception do RUP Arménio Antunes Departamento de Sistemas de Informação Universidade do Minho, Guimarães, Portugal Abstract. Este documento foca o RUP, o a linguagem de modelação UML e a gestão de projectos, tentando perceber o seu valor nas actividades decorridas durante o primeiro semestre do ano lectivo 2010/2011. Pretende-se transmitir as dificuldades presentes na realização da função de gestão de projecto em especifico, tal como perceber a sua influência no mesmo.

48 1 Introdução O objectivo deste documento será analisar a actividade prática de gestão de projecto, ocorrida ao longo do final do último semestre com um grupo da unidade curricular de PMS, à luz de alguns princípios e boas práticas existentes sobre o tema. Será realizada uma análise de alguns factores de sucesso e a maneira como influenciaram o projecto e a sua gestão. 2 Apresentação do Tema Analisado Neste documento são focados alguns princípios teóricos importantes na actividade de gestão de projecto de software. São focados o RUP, uma framework para o processo de desenvolvimento de software, a linguagem de modelação UML, e fundamentos da gestão de projectos. Estes princípios tiveram de ser levados em conta na discussão da realização da fase de inception de um projecto de software. 3 Fundamentos 3.1- RUP O Rational Unified Process (RUP) define uma framework para um processo de desenvolvimento de software baseado em boas práticas de engenharia de software. Utiliza a abordagem iterativa e incremental de desenvolvimento e é personalizável de acordo com as necessidades específicas de cada projecto de desenvolvimento de software (Campos 2009). O RUP implementa as práticas de engenharia de software listadas anteriormente através de uma abordagem em duas dimensões, ilustradas na Figura 1. A dimensão horizontal representa o tempo e divide o ciclo de vida de desenvolvimento em quatro fases, a Concepção, a Elaboração, Construção e Transição. A dimensão vertical agrupa as actividades por natureza nas disciplinas de Modelação de Negócio, Requisitos, Análise e Design, Implementação, Testes, 2

49 Instalação, Gestão de Configuração e Mudança e Gestão de Projecto e Ambiente (IBM 2006). Figura 1 Fases e Disciplinas do RUP (IBM 2006) No entanto o RUP não aborda por completo todos os processos de gestão de projectos, conforme estão descritos no PMBOK, mesmo possuindo uma disciplina específica para tal finalidade, mostrada na Figura 1.O próprio RUP lista as lacunas não cobertas por ele gestão de recursos humanos, gestão de custos, gestão de aquisições e os pontos que são cobertos planeamento do projecto, monitorização do progresso, métricas e gestão de riscos. Comparando a abordagem do RUP para gestão de projectos de desenvolvimento de software, com o que é coberto pelo PMBOK para gestão de projectos em geral, nota-se uma deficiência do RUP em diversos processos de gestão de projectos, como por exemplo no que diz respeito ao âmbito, tempo, custos, comunicação, recursos humanos e aquisições (Campos 2009). 3

50 3.2- UML UML (Unified Modeling Language) é um sistema de notação orientada a objectos, permitindo a abstracção de várias tecnologias, num único modelo normalizado. Hoje em dia, UML é aceite pelo Object Management Group (OMG) como a norma para modelação de programas orientados a objectos (SmartDraw 2011). O UML captura informação de estruturas estáticas e comportamentos dinâmicos dum sistema. Esse sistema é concebido como uma colecção de objectos discretos que interagem entre si. A estrutura estática define o tipo de objectos importantes para o sistema e para a sua implementação, tal como as relações entre os objectos. O comportamento dinâmico define a história dos objectos ao longo do tempo e a comunicação entre os objectos para atingir um objectivo. Modelar um sistema de vários, embora relacionados, pontos de vista diferentes, permite-lhe ser interpretado para propósitos diferentes (Rumbaugh et al. 1999). Esta notação define nove tipos de diagramas. Diagramas de classe, objectos, casos de uso, sequencia, colaboração, estado, actividades, componente e de instalação. Diagrama de classe: É um tipo de diagrama estrutural de qualquer método orientado a objectos. Descrevem a estrutura estática de um sistema. Diagrama de Objectos: São utilizados para descrever a estrutura estática de um sistema numa altura em particular, Podem ser usados para testar diagramas de classe. Diagrama de Casos-de-Uso: Servem para modelar as funcionalidades do sistema utilizando actores e casos de uso. Essenciais para o levantamento inicial de requisitos. Diagrama de Sequência: Descrevem interacções entre classes, por meio de troca de mensagens, que vão ocorrendo ao longo do tempo. 4

51 Diagrama de Colaboração: Representam interacções entre objectos como trocas de mensagens sequenciadas. Descrevem tanto a estrutura estática como o comportamento dinâmico do sistema. Diagrama de Estado: Descrevem o comportamento dinâmico do sistema em resposta a estímulos externos. São úteis para modelar objectos reactivos cujos estados são accionados por eventos específicos. Diagrama de Actividades: Este tipo de diagrama ilustra a natureza dinâmica do sistema modelando o fluxo de controlo de actividade para actividade. Uma actividade representa uma operação numa classe do sistema que resulta na mudança do estado do sistema. Normalmente este tipo de diagrama é usado para modelar fluxo de trabalho, processos de negócio, ou operações internas. Diagrama de Componente: Este tipo de diagrama descreve a organização dos componentes físicos de software, como código fonte, código binário de execução, ou executáveis. Diagrama de Instalação: Descrevem os recursos físicos num sistema, incluindo nodos, componentes e conexões No projecto de grupo referido neste artigo, a inception foi única fase do RUP tratada, e no levantamento de requisitos, além dos diagramas de casos de uso e sequencia, foi utilizado também um tipo de diagrama que não faz parte do UML. Esse diagrama é o de Robustez. Neste usa-se tipicamente os estereótipos controlo, interface e entidade. O diagrama de Robustez permite verificar a transição entre o diagrama de Caso de Uso (analisando o texto desse diagrama) e o diagrama de Sequência. Através desse 5

52 processo de análise (do diagrama de Caso de Uso para o diagrama de Sequência) é feita a conhecida verificação de sanidade do caso de uso (Borba 2010) Gestão de Projecto Gestão de projecto é a aplicação de conhecimento, aptidões, ferramentas e técnicas às actividades de projecto para que os seus objectivos sejam cumpridos. Esta gestão é conseguida através da aplicação e integração de processos de gestão como inicialização, planeamento, execução, monitorização, controlo e encerramento(project Management 2004). Já na óptica mais direccionada a projectos de software, gestão de projecto refere-se aos processos que são levadas a cabo para assegurar que as actividades de engenharia de software são efectuadas de forma consistente com as politicas, objectivos e normas da organização (Abran et al. 2004). A utilidade do uso destes processos, quando comparada com o incremento de burocracia e trabalho que podem fazer surgir, prende-se com o facto de os processos representarem conhecimento colectivo, portanto, usando-os aumenta a probabilidade de sucesso. Um processo poderá ter alguns passos extra, mas é difícil perceber logo à partida quais é que não serão necessários, podendo haver risco caso sejam tomados atalhos. Os processos permitem prever o desfecho do projecto e aprender efectivamente, criando conhecimento de valor nas organizações relativamente a gestão de projectos. Processos também podem baixar a ansiedade ao possibilitarem conhecer-se o estado do trabalho (Jalote 2001). Gerir um projecto também inclui identificar requisitos, estabelecer objectivos claros e realistas, equilibrar qualidade, âmbito, tempo e custo, e adaptar a especificações, planos e abordagem ás diferentes preocupações e expectativas dos vários stakeholders (Project Management 2004). A Engenharia de software é uma área que envolve riscos altos, e necessita do uso de uma abordagem diferente para a gestão de projectos. Normalmente os projectos tradicionais são organizados por estruturas top-down, onde o produto é decomposto em componentes menores (especificações, plantas, subsistemas, etc.), seguindo um 6

53 processo em cascata com fases sequenciais. Dessa forma, o planeamento precisa de ser desenvolvido com base na estrutura do produto, que precisa de ser definida no inicio do projecto. No entanto essa abordagem falha para projectos de desenvolvimento de software, uma vez que no inicio do projecto pouco se sabe sobre o sistema que será desenvolvido. Normalmente esses projectos sofrem várias mudanças durante seu ciclo de vida, o que dificulta bastante a sua gestão, com a utilização de técnicas tradicionais de gestão de projectos (Campos 2009) Planeamento das Fases Plano do Projecto O plano de fases é abrangente, há somente um para todo o projecto e seu objectivo e registar as informações globais do projecto, pertinentes às fases previstas no RUP. O planeamento inicial é elaborado através de uma abordagem top-down, com base na estimativa global para o projecto Âmbito O âmbito de cada fase deriva dos objectivos da fase e estes, por sua vez, são a base para a definição do âmbito das iterações. A EAP (Estrutura Analítica do Projecto) pode ser definida em quatro níveis : fases, iterações, artefactos e tarefas resumo. As actividades que serão desempenhadas em cada iteração dependem dos objectivos. Por exemplo, uma iteração de transição pode ter o objectivo de instalar o sistema, corrigir bugs ou adicionar novas funcionalidades Tempo O perfil de tempo varia para cada projecto, no entanto, tipicamente a divisão de tempo entre as fazes será 10% para a concepção, 30% para Elaboração, 50% para Construção e 10% para a Transição. 7

54 4 Projecto O Projecto aqui discutido foi o realizado no âmbito da cadeira de PMS, com um grupo de 5 pessoas, em que foi pedido inicialmente que os alunos de ACSI adoptassem o papel de consultores. Esse grupo estava encarregue de desenvolver a fase de inception do RUP. Mais tarde, devido à ineficácia deste método visto que havia subaproveitamento do recurso consultor, o papel adoptado passou a ser de gestor de projecto. 5 Discussão O projecto no qual os alunos da disciplina de ACSI participaram, primeiro como consultores e só depois como gestores de projecto, tratou-se de desenvolver um sistema de informação para a Misericórdia de Guimarães, apenas abordando as tarefas respeitantes à fase de incepcion. Como é natural, ao primeiro contacto com o RUP os membros do grupo sentiram grandes dificuldades logo à partida em perceber o relacionamento das fases com as actividades. Derivado desta confusão e também da falta de empenho inicial, houve muita dificuldade em organizar convenientemente a work breakdown structure (WBS). Foi quando foi acordado que se passaria a existir o papel de gestor de grupo que se abriu a possibilidade de intervir no trabalho que estava a ser feito e participar proactivamente na monitorização e direcção dos esforços. É de salientar que não foram planeados, executados e produzidos todas as tarefas e artefactos existentes no RUP, devido principalmente à complexidade que lhes é inerente, à falta de dados e de recursos para a sua descoberta, à dimensão reduzida da equipa relativamente ao tempo, além do RUP ter uma complexa relação entre fases e actividades, não sendo transparente e objectivo exactamente o que deverá ser feito, e em que quantidade, numa determinada fase, deixando espaço para adaptação a cada projecto. Os meios para a análise de requisitos, como é normal no meio académico, ficou muito aquém do que se poderia passar na realidade, estando a informação num conjunto de 8

55 slides de conteúdo muito limitado para a modelação que já se pedia, e sem meios para completar essa informação. Existiram alguns problemas também relacionados com o facto de se tratar do meio académico. O planeamento rigoroso das actividades nunca foi possível visto dois elementos serem trabalhadores estudantes com horário de trabalho indefinido. Na realidade, e em parte devido ao tipo de relacionamento familiar existente com os membros do grupo, faltaram formas de pressionar o grupo a cumprir os prazos, resultando em acumulação do trabalho para a data de entrega. Este factor dificultou a verificação do trabalho realizado, promoveu a falta de rigor na elaboração dos artefactos, como por exemplo, a falta de descrição para os diagramas UML. Os diagramas de robustez e de sequência foram entregues com muitos erros devido à falta de tempo para estudar melhor o assunto e reflectir na sua elaboração, nem havendo oportunidade para validação ou correcção por parte do docente. Relativamente ao sucesso do projecto, independentemente de ser requisito apenas a conclusão da fase de inception, Hartman and Ashrafi (2002) identificam alguns factores influenciadores que podem ser analisados também à luz do projecto tratado (Turner et al. 2005): Factor de Sucesso 1. Missão do Projecto 2. Apoio da Gestão de Topo Descrição e Análise No que toca à clarificação de objectivos e direcção a tomar, houve suficiente comunicação através do enunciado fornecido e da exposição feita pela representante da Misericórdia de Guimarães, tal como foi um assunto razoavelmente desenvolvido pelo grupo de trabalho. Este factor refere-se aos recursos, autoridade e poder para a implementação. Diz respeito principalmente ao gestor do projecto. Diria que neste projecto, devido ao cariz académico, seria um forte factor de insucesso, visto que os recursos eram inflexíveis e a autoridade do gestor de projecto era, naturalmente, muito reduzida. 9

56 3. Calendário e Plano 4. Comunicação com Cliente 5. Recursos Humanos 6. Tarefas Técnicas 7. Aceitação do cliente 8. Monitorização e Feedback 9. Comunicação Especificação detalhada de Implementação foi elaborada, de dimensão suficiente para o projecto em mãos, e apenas para a fase de inception, como era pretendido. O que não quer dizer que fosse cumprido pelas razões apontadas no ponto anterior. Devido à natureza académica do projecto, também houve insuficiente percepção das necessidades dos stakeholders, pois não se estabeleceu um interesse de ambas as partes da comunicação necessária. Este factor fica completamente fora do âmbito do projecto, visto que este foi realizado por elementos predefinidos, não existindo por isso recrutamento. O treino destes elementos foi da sua própria responsabilidade no processo de aprendizagem. Mais um factor naturalmente negativo, visto que a maior parte dos conhecimentos necessários para a realização do projecto vão sendo adquiridos ao longo da sua execução. Este factor diz respeito à venda do produto final ao cliente. Factor que não pode ser analisado neste projecto, visto que não foi uma actividade real. Este factor tem de ser levado em conta pelo gestor de projecto, no entanto, no projecto tratado, teve falhas devido ao que foi expresso no ponto 2. Do ponto de vista de gestor, o facto de o trabalho ser acumulado para o fim também comprometeu o sucesso deste factor. Este factor diz respeito à provisão de informação atempada aos elementos chave. Devido à proximidade e tecnologias utilizadas no desenvolvimento do projecto, este factor foi salvaguardado respectivamente ao grupo 10

57 de trabalho, embora deficiente em relação aos stakeholders, como expresso no ponto Resolução de Problemas Relativamente à dimensão do projecto, a falta de experiência dos intervenientes dificilmente iria ser uma barreira à resolução de problemas inesperados, sendo os mesmos pouco espectáveis. Tabela 1 Factores de Sucesso/Insucesso de Projecto Já no que toca à gestão de projecto, poderão ser considerados alguns factores que podem por em causa o seu sucesso (Munns et al. 1996): Base inadequada para o projecto Pessoa errada como gestor de projecto Falta de apoio da gestão de topo Tarefas inadequadamente definidas Falta de técnicas de gestão de projecto Técnicas de gestão mal empregues Término do projecto não planeado Falta de compromisso para com o projecto Estes factores sugerem que uma gestão de projecto bem sucedida precisa de planeamento com compromisso de completar o projecto, nomeação cuidadosa de um gestor de projecto capaz, definir o projecto adequadamente, planear as actividades do projecto correctamente, assegurar fluxo de informação correcto e adequado, mudar actividades para acomodar mudanças frequentes na dinâmica, acomodar os objectivos pessoais dos trabalhadores com o seu rendimento e as respectivas recompensas, começar de novo quando se identificam erros na implementação (Munns et al. 1996). Em alguns pontos é visível uma relação com os factores de sucesso de projecto, como por exemplo na falta de apoio da gestão de topo, que é também considerado no ponto 2 desses factores. 11

58 6 Conclusão Quando contraposta a actuação como gestor de grupo com as indicações fornecidas na literatura, rapidamente se conclui que a actuação nesse campo ficou muito aquém do que seria natural ver no mundo profissional, sendo mais vezes utilizada a via da ajuda directa do que do planeamento. Os requisitos básicos impostos na framework do RUP foram cumpridos no que toca a gestão, no entanto poderiam ter sido utilizada alguma forma de quantificar e controlar mais de perto o trabalho que ia sendo realizado. O facto de ser um projecto académico influencia só por si o sucesso do projecto, visto que grande parte dos factores de sucesso ficam assim comprometidos. O sucesso do projecto não é totalmente dependente do sucesso da sua gestão e viceversa, visto que possuem factores de sucesso distintos, embora não na sua totalidade. Por exemplo, poderia haver um planeamento e gestão, mas os objectivos do projecto serem cumpridos. A proximidade decorrente da passagem a gestor de projecto permitiu participar activamento no andamento do trabalho, tendo, na minha opinião, sido um factor de grande ajuda para o grupo em questão, pelo simples facto de que não estavam a surgir as perguntas certas para o consultor. 7 Referências Abran, A., Moore, J.W., Bourque, P., Dupuis, R., and Tripp, L.L. SWEBOK : Guide to the Software Engineering Body of Knowledge IEEE Computer Society, Borba, G. "http://gilmarborba.com.br/?p=175," Campos, L.M.L.d. "Gerenciamento de Projetos de Desenvolvimento desoftware com o RUP e o PMBOK," A.S. Lima (ed.), IBM "Rational Unified Process,"

59 Jalote, P. Software project management in practice Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, Munns, A.K., and Bjeirmi, B.F. "The role of project management in achieving project success," International Journal of Project Management (14:2) 1996, pp Project Management, I. "A guide to the project management body of knowledge: PMBOK Guide," Project Management Institute Newtown Square PA, USA, Rumbaugh, J., Jacobson, I., and Boosh, G. "The Unified Modeling Language Reference Manual," Addison Wesley Longman, Inc., SmartDraw "http://www.smartdraw.com/resources/tutorials/uml-diagrams/," Turner, J.R., and Müller, R. "The project manager s leadership style as a success factor on projects: A literature review," Project management journal (36:2) 2005, pp

60 Estudo de standards relativos a Cloud Computing Levantamento de Standards Técnicos Bruno L S Ferreira 1 1 Aluno de Análise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão de Sistemas de Informação, Universidade do Minho Guimarães, Portugal Resumo. Cloud computing é um termo cada vez mais utilizado, em contextos diferentes, designando coisas aparentemente distintas. Este ensaio pretende definir e caracterizar cloud computing, para melhor percebermos as suas potencialidades, que serão depois aplicadas ao projecto ISOFIN. Pretende-se fazer também um levantamento dos standards técnicos, e das arquitecturas que melhor se adequam a esta temática, e que possam contribuir ou comprometer o desenvolvimento do projecto. Palavras-chave: ISOFIN, Cloud Computing. 1 INTRODUÇÃO Cloud computing é algo que todos dizem conhecer, mas poucos sabem explicar. Este novo modelo de negócio está a agitar o mundo dos negócios, sendo poucos, aqueles que conseguem resistir às poupanças milionárias que este modelo promete. Porque as nuvens podem ter as mais variadas formas e feitios, e para evitar situações de cloud-washing 1 este ensaio pretende esclarecer o que é verdadeiramente cloud computing, quais as suas características e quais as suas variantes. Este ensaio, enquadrado no projecto ISOFIN Cloud, pretende também fazer um levantamento dos standards técnicos existentes, assim como de modelos arquitecturais que possam contribuir para o sucesso do projecto. 1 Situação em que o termo é apenas utilizado para efeitos de puro marketing, não possuindo nenhuma característica de cloud computing 1

61 2 CONTEXTUALIZAÇÃO 2.1 CLOUD COMPUTING O lançamento de serviços cloud tem acelerado fortemente o mercado das Tecnologias de Informação (TI). Este novo modelo de negócio orientado à subscrição de serviços pelo cliente, de acordo com as necessidades de negócio, a cada momento, através de um portal de self-care, integra novos processos de automação no provisioning e gestão da capacidade, dotando as soluções TI de maior agilidade e flexibilidade [1]. O paradigma da cloud tem subjacente um modelo de facturação indexado ao consumo real de recursos por utilizador, permitindo sustentar as decisões de investimento e minimizar o risco associado a novos projectos. Por outro lado, tem vindo a dinamizar o mercado empresarial com novas parecerias, novos players e com o lançamento de ofertas [1]. Cada vez mais as organizações procuram os benefícios da flexibilidade, rapidez, elasticidade e a competitividade disponibilizados pela cloud. Mas também exigem ter como garantias a segurança, a integração, a migração, a qualidade e o retorno de investimento (ROI) da solução [1]. 2.2 SISTEMAS DE INFORMAÇÃO DA INDÚSTRIA FINANCEIRA Os sistemas de informação da indústria financeira (banca e seguros) enfrentam hoje em dia muitos e variados problemas. Desde o peso das aplicações legadas, provenientes do inicio do seu negócio, com a inerente herança tecnológica, até às novas formas de contacto com os clientes, parceiros e reguladores, efectuada através de múltiplos canais, como a internet, telefone ou balcão. A interacção dos clientes e funcionários com os sistemas informacionais presentes neste tipo de indústria tem-se vindo a intensificar nos últimos anos. Os sistemas legados são estáveis, mas muitos deles não são escaláveis o suficiente para dar resposta a este tipo de novas solicitações. Essas solicitações podem variar, indo desde os pedidos de informação necessárias ao trabalho diário, informações legais e contabilísticas, operacionais, de resposta a solicitações de clientes que interagem através dos balcões ou do site, entre outras. Como o volume de informação aumenta, também aumenta o tempo que leva para fornecer soluções e/ou respostas. Este processo pode muitas vezes desencadear operações que consomem imensos recursos e tempo. O peso das aplicações informáticas legadas em plataformas da indústria financeira, a necessidade de fornecimento de informações não-padronizadas a clientes, a dinâmica deste mercado e a contínua necessidade de se adaptar a sistemas e a realidades de mercado tão distintas obriga à criação de um sistema muito modular que possa atingir metas de execução e rigorosas o suficiente. O projecto ISOFIN Cloud (acrónimo para Interoperabilidade Software Financeiro) tem como principal objectivo o desenvolvimento de uma plataforma que agilize o desenvolvimento e distribuição de serviços a serem vendidos a clientes e utilizadores 2

62 do domínio financeiro. Permitindo a todos os interessados (Brokers, Clientes, Banca, seguradoras) aceder a qualquer serviço dentro da cloud, de forma transparente, passando do domínio da banca para o domínio dos seguros através desta plataforma. Será ainda possível, através desta plataforma a criação de novos serviços de forma facilitada para serem vendidos a clientes/utilizadores. Este projecto nasce das necessidades sentidas pelos clientes e pelos próprios promotores do projecto, de uma plataforma que unifique ontologicamente o domínio financeiro, tomemos por exemplo a definição dos papéis de um cliente, que pode ser simultaneamente um credor ou um indemnizado. [2] 3 CLOUD COMPUTING O termo Cloud Computing, referido pela primeira num artigo do Massachusetts Institute of Technology em 1996 [3], é por diversas vezes empregue em contextos discordantes, designando coisas aparentemente distintas [4-5]. Este termo teve a sua origem em diagramas de arquitecturas aplicacionais, onde a Internet é vulgarmente representada através de uma nuvem (cloud) [4] conforme se poderá observar na Figura 1. Figura 1. Exemplo de uma arquitectura [6] Apesar de ainda desconhecida por alguns, uma definição que começa a ganhar consenso, por parte dos profissionais do sector, é a definição elaborada em 2009 pelo National Institute of Standards and Technology (NIST). Segundo o NIST, Cloud Computing é um modelo conveniente que permite acesso à rede a pedido (on demand) para um conjunto compartilhado de recursos de computação configurável (por exemplo, redes, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente provisionados e lançado com o mínimo esforço de gestão ou prestador de serviços interacção [7]. Este modelo promove a disponibilidade de recursos e é composto por cinco características essenciais, quatro modelos de distribuição e três modelos de serviço [7]. 3

63 3.1 CARACTERÍSTICAS ESSÊNCIAS Segundo a definição de Cloud Computing do NIST, este modelo de computação é constituído por cinco características essenciais: utilização self-service, acesso através da rede, disponibilidade de recursos, rápida elasticidade e mensuração do serviço [7]. Utilização Self-Service Um consumidor pode, unilateralmente, dispor de recursos de computação, como o tempo de processamento, armazenamento e servidores de rede, automaticamente, conforme as suas necessidades e sem que seja necessária a interacção humana [7-8]. Para serem eficazes e aceitáveis para o consumidor, as interfaces gráficas, pelas quais os consumidores interagem com o produtor, devem ser de fácil utilização e proporcionar meios eficazes para gerirem a oferta de serviços [8]. A facilidade de utilização e eliminação de interacção humana proporciona ganhos de eficiência e redução de custos, tanto para o utilizador, como para os produtores de serviços [8]. Acesso através da rede Os recursos estão disponíveis através da rede e são acedidos por meio de mecanismos standards, que promovem o uso por plataformas heterogéneas, como por exemplo: telemóveis, computadores portáteis, e PDAs [7]. Para que este modelo de computação seja uma alternativa efectiva aos data-centers in-house, deverão existir ligações de banda larga que liguem os consumidores aos serviços cloud [8]. Disponibilidade de recursos Os recursos estão organizados de forma a servirem múltiplos consumidores, usando um modelo multi-tenant, recorrendo a diferentes recursos físicos e virtuais e de acordo com a procura do cliente [7]. O utilizador não tem controlo ou conhecimento da localização exacta onde estão os recursos, mas poderá existir a possibilidade de definir, em alto nível, a sua localização [7]. Este modelo de computação, deverá possuir um vasto leque de recursos de forma a poder responder às necessidades dos clientes, atingir economias de escala e respeitar a qualidade de serviço contratado [8]. As aplicações precisam de recursos para a sua execução e esses deverão ser alocados eficientemente para uma óptima performance [8], mesmo que estejam localizados em áreas geográficas dispersas [8]. Rápida elasticidade Os recursos deverão ser fornecidos de uma forma rápida e elástica, e em algumas situações de forma automática, de forma a assegurar a escalabilidade do sistema [7]. Para o consumidor, os recursos deverão parecer ilimitados, podendo ser adquiridos em qualquer número e altura [7], cujo custo resultará do tempo de utilização e quantidade de recursos consumida [8]. Esta característica diz respeito à habilidade de rapidamente aumentar ou diminuir os recursos alocados, de forma a cumprir com os requisitos de self-service [8]. 4

64 Mensuração do serviço Estes sistemas de computação controlam e optimizam a utilização de recursos, automaticamente, e de acordo com os níveis apropriados para o tipo de serviço (ex: armazenamento, processamento, largura de banda e número de contas activas) [7]. A utilização de recursos pode ser monitorizada, controlada e comunicada, tornando o serviço transparente, tanto para o consumidor, como para o produtor [7]. Em virtude das características deste modelo de computação, o número de recursos consumido, poderá ser monitorizado e definido de forma dinâmica [8]. Dessa forma, serão depois facturados os consumos relativos aos recursos alocados para uma determinada sessão [8]. 3.2 MODELOS DE DISTRIBUIÇÃO Esta forma de classificação, classifica as infra-estruturas em termos de quem possui e gere a infra-estrutura de cloud. Public Cloud Figura 2. Modelos de distribuição [9] A infra-estrutura de cloud está disponível ao público em geral, ou a um grande grupo industrial, sendo propriedade de uma organização que comercializa serviços de cloud [7]. Este tipo de cloud é o mais comum, os serviços são disponibilizados aos clientes através de um fornecedor, sendo que os recursos disponibilizados são partilhados com outros clientes [9]. A segurança e a governação dos dados são as maiores preocupações desta abordagem [9]. Private Cloud A infra-estrutura de cloud é operada unicamente por uma organização, podendo existir dentro ou fora das instalações, sendo gerida pela própria organização ou por uma outra entidade [7]. Muitas destas infra-estruturas são operadas por grandes 5

65 empresas, ou departamentos governamentais, que preferem manter os seus dados num ambiente mais controlado e seguro [9]. A Figura 3 apresenta uma comparação entre as nuvens públicas e privadas. Figura 3. Public Cloud vs Private Cloud [9] Community Cloud A infra-estrutura da cloud é partilhada por diversas organizações, suportando uma comunidade com idênticas preocupações (ex: missão, requisitos de segurança, politicas, etc.), podendo existir dentro ou fora das instalações, sendo gerida pelas organizações que a compõem, ou por uma entidade [7]. Hybrid Cloud A infra-estrutura da cloud é uma composição de duas ou mais nuvens (privadas, comunitárias, ou públicas) que permanecem entidades únicas, e que estando ligadas, através de tecnologia standard ou proprietária, permitem a portabilidade de dados e aplicações [7]. Desta forma, uma organização poderá manter os seus dados e aplicações críticas, dentro das suas instalações, colocando as menos críticas numa public cloud [9]. 3.3 Modelos de Serviço Este sistema de computação é basicamente uma classe de sistemas que disponibilizam recursos de IT, sobre a forma de serviço, a utilizadores remotos. Esses recursos poderão incluir hardware, ambientes de programação, ou aplicações [9]. A definição actual do NIST considera que existem basicamente três modelos de serviço: Infrastructure as a Service, Platform as a Service, e Software as a Service 6

66 [7]. Nesta definição não fazem parte os Business Process Management as a Service, talvez por serem considerados uma subcategoria de SaaS. Conforme se poderá verificar na Figura 4, diferentes organizações poderão desempenhar papéis diferentes na construção e utilização de sistemas cloud [9]. Esses papéis variam entre Technology Enablers (disponibilizam as tecnologias que tornam possível este modelo de computação), Cloud Providers (distribuem as suas infra-estruturas e plataformas aos clientes), Cloud Customers (recorrem aos fornecedores para melhorar as suas aplicações Web) e Cloud Users (utilizam as aplicações Web, sem possivelmente saber que estão alojados na cloud) [9]. Figura 4. Perfis de utilização da cloud [9] Infrastructure as a Service (IaaS) É colocado á disposição do consumidor tempo de processamento, armazenamento, redes e outros recursos de computação fundamentais, podendo o consumidor alojar e executar qualquer software, incluindo sistemas operativos e aplicações [7]. O consumidor não gere ou controla a infra-estrutura base da cloud, mas tem controlo sobre o sistema operativo, armazenamento, alojamento de aplicações, podendo ter a possibilidade de controlar um leque limitado de componentes de rede (ex: firewalls) [7]. Esta categoria poderá ser subdividida em duas outras: Computation as a Service (CaaS), na qual são alugados servidores baseados em máquinas virtuais; e Data as a Service (DaaS), nesta última subcategoria, é alugado espaço em disco, sendo facturado o serviço normalmente ao Gbyte [9]. Na Figura 5 é possível analisar as características dos três maiores fornecedores de CaaS. 7

67 Figura 5. Comparativo de serviços CaaS (subcat. IaaS) [9] Platform as a Service (PaaS) É possibilitado ao consumidor o alojamento, na infra-estrutura da cloud, de aplicações criadas ou adquiridas pelo consumidor, desde que desenvolvidas em linguagens de programação/ferramentas suportadas pela infra-estrutura [7]. O consumidor não gere ou controla a infra-estrutura base da cloud, incluindo rede, servidores, sistemas operativos ou armazenamento, mas tem controlo sobre as aplicações alojadas, e possivelmente pode controlar as configurações de alojamento das aplicações [7]. Na Figura 6 é possível analisar as características dos quatro mais fornecedores de PaaS. Software as a Service (SaaS) É permitido ao consumidor a utilização de aplicações disponibilizadas pelo produtor na arquitectura da cloud [7]. As aplicações podem ser acedidas através de vários dispositivos clientes, mediante um interface gráfico como um browser ou similar [7]. O consumidor não gere ou controla a infra-estrutura base da cloud, incluindo a rede, servidores, sistemas operativos, armazenamento, ou até mesmo recursos das próprias aplicações, excluindo-se a configuração de alguns parâmetros, específicos do utilizador [7]. 8

68 Figura 6. Comparativo de serviços PaaS [9] 3.4 CLASSIFICAÇÃO ISOFIN CLOUD A classificação da cloud do projecto ISOFIN deverá comportar duas vertentes, a vertente do proprietário da solução (I2S) e a do cliente final. Uma vez que a I2S apenas deseja tirar partido, e não criar a sua própria infraestrutura, do ponto de vista do seu papel, esta será classificada como sendo uma cloud customer. Os clientes que irão trabalhar com a aplicação, mesmo não sabendo que a solução está a ser suportada por um cloud provider (à qual a I2S recorreu), desempenharão o papel de cloud users. Do ponto de vista da sua interacção com o sistema (modelo de serviço), a ISOFIN Cloud é um SaaS. Para suportar o projecto ISOFIN a I2S poderá contratar, a um cloud provider, qualquer modelo de serviço. No entanto o modelo que escolher poderá condicionar todo o projecto, isto porque os modelos PaaS e SaaS condicionam o cliente à utilização das ferramentas e linguagens de programação suportadas pelo cloud provider. O modelo IaaS, por permitir controlar toda a infra-estrutura, parece ser o mais flexível, mas no entanto, pode obrigar a mais esforços de implementação. Isto porque, por ser um modelo de baixo nível, poderá exigir a implementação de funcionalidades próprias dos PaaS e dos SaaS. 4 MODELOS ESCALÁVEIS Segundo [6], existem basicamente quatro modelos/abordagens que descrevem a forma como as organizações poderão tirar partido da cloud, para lidar com aplicações 9

69 altamente escaláveis. Esses modelos serão aqui abordados pela seguinte ordem: Transference, Internet scale, Burst compute e Elastic storage (Figura 7). 4.1 TRANSFERENCE Este modelo consiste na transferência de uma aplicação, já existente, para a infraestrutura da cloud. Esta medida poderá ser motivada por questões económicas, uma vez que poderá ser mais económico recorrer a recursos disponibilizados pela cloud, do que a manter esses mesmos recursos na organização [6]. Quando este modelo for o mais apropriado é necessário ter em conta as configurações específicas das aplicações, pois o cloud provider poderá não suportar ou permitir essa configuração (ex: hardware, drivers, etc.) [6]. 4.2 INTERNET SCALE Ao contrário do modelo anterior, este, pressupõem a criação de uma aplicação para a cloud, que permita lidar com um grande número de utilizadores (como acontece com o YouTube, Flickr, ou Facebook), sem que sejam necessários grandes investimentos [6]. Este é um modelo muito usual para a prototipagem de novas aplicações, uma vez que não exige grandes investimentos, como acontecia até ao aparecimento deste modelo de negócio [6, 10]. A organização poderá contratar apenas a capacidade que necessitar, ajustando-a às suas necessidades [6, 10]. Este modelo poderá ser também utilizado como medida de mitigação de risco para as aplicações com um crescimento imprevisível [6]. Um dos maiores desafios deste modelo é o desenho da estrutura da base de dados, pois se não forem tomadas medidas, a base de dados poderá condicionar a escalabilidade da aplicação [6]. 4.3 BURST COMPUTE As aplicações que se enquadrem neste modelo têm a capacidade de, sempre que necessário, lidar com recursos computacionais adicionais, sem que seja necessário reiniciar o sistema [6]. Este modelo é impulsionado pelos factores económicos da cloud, pois os custos de reproduzir este comportamento internamente, seria proibitivo para as organizações [6]. 10

70 4.4 ELASTIC STORAGE Este modelo adequa-se às aplicações que exijam uma capacidade de armazenamento exponencial [6]. Apesar do armazenamento local ser hoje em dia relativamente barato, a sua gestão poderá envolver custos consideráveis, pelo que o recurso à cloud se poderá justificar [6]. No entanto, no que diz respeito ao acesso aos dados, a utilização deste modelo requer uma planificação e um planeamento cuidado, pois se o processamento for local, poderão existir implicações na performance [6]. Figura 7. Resumo dos modelos escaláveis, adaptado de [6] 5 STANDARDS Talvez por cloud computing ser algo ainda relativamente recente, a pesquisa de standards técnicos, não revelou grandes resultados. Actualmente, os fornecedores destes serviços, têm as suas próprias implementações o que prejudica a portabilidade de aplicações entre fornecedores. A falta de entendimento, entre os fornecedores, poderá ser uma das razões que justifique a falta de literatura que aborde os padrões arquitecturais de cloud computing. A literatura analisada e que aborda esta temática, apenas refere como standards, as tecnologias que permitem o desenvolvimento Web (XHTML, CSS, JavaScript, etc.), assim como alguns protocolos de comunicação e segurança [5, 9]. No entanto, foi possível encontrar dois grupos de trabalho que se estão a debruçar na criação de standards para a cloud, esses grupos são o Open Cloud Consortium [11] e o Distributed Management Task Force (DMTF) [12-13]. O DMTF esteve já envolvido na criação de um standard para máquinas virtuais (OVF), mas no entanto esse formato não é adequado ao modelo de funcionamento da cloud [14]. Actualmente este grupo de trabalho tem-se focado no desenvolvimento de 11

71 standards para a gestão da cloud, principalmente no que diz respeito à interoperabilidade entre sistemas de diferentes fornecedores (providers). Segundo Larry Dignan, a Oracle irá submeter em breve uma proposta de API como standard [15]. 6 ARQUITECTURAS ESCALÁVEIS 6.1 SHARDING Foi referido que uma das causas que dificulta a escalabilidade dos sistemas é o desenho da base de dados. Isto acontece quando a memória disponível é insuficiente para lidar com os registos acedidos, e quando os discos I/O não conseguem lidar com o aumento do número de actualizações [6]. Organizações como o Facebook, Flickr e Yahoo! enfrentaram estes mesmos problemas, pelo que devemos aprender com eles [6]. Estas organizações resolveram o problema recorrendo ao sharding da base de dados [6]. Esta técnica consiste na decomposição da base de dados em pequenas e múltiplas bases de dados (chamadas de shards), que passavam a lidar com os pedidos individualmente [6]. Esta técnica está relacionado com um conceito de escalabilidade chamado de shared-nothing, que consiste na remoção de dependência entre partes da aplicação de forma a que possam executar individualmente e em paralelo para um desempenho maior [6]. Existiu uma altura em que se garantia a escalabilidade através da aquisição de computadores mais rápido e mais caros [6]. Apesar de esta solução ser do agrado dos fornecedores de sistemas, é insuportável para a maioria dos serviços gratuitos disponíveis actualmente na Web, não só pelos valores envolvidos mas também porque face a serviços como o Google, não existe uma só máquina com a capacidade de lidar com um tão grande número de pedidos [6]. É aqui que entra o sharding! Esta nova arquitectura de base de dados, permitiu ao Flickr lidar com mais de um bilião de transacções por dia, respondendo aos pedidos em poucos segundos, e permitindo uma escalabilidade linear e a um custo baixo [6]. No seu modelo mais simples, podemos armazenar os dados do Utilizador1 num servidor, e os dados do Utilizador2 noutro servidor (Figura 8) [6]. Num sistema como o Flickr, podemos armazenar até utilizadores na mesma partição (shard). Neste modelo simples o critério para a arrumação dos dados, é números ímpares num lado e pares no outro (Figura 8) [6]. 12

72 Figura 8. Particionamento dos dados [6] Vantagens do sharding Esta técnica, face ao modelo típico de base de dados, apresenta as seguintes vantagens: Alta disponibilidade Se um servidor for abaixo, os outros poderão continuar a trabalhar [6]. Neste modelo, se algum utilizador ficar sem serviço, outras partes poderão continuar em execução [6]. Normalmente existe algum tipo de replicação, pelo que se um servidor for abaixo, o utilizador é redireccionado para outro, não existindo uma falha de serviço para o utilizador [6]. Querys mais rápidas Uma vez que os dados não estarão concentrados, mas sim dispersos por diferentes servidores, isso irá fazer com que as querys sejam respondidas mais rapidamente [6]. Os serviços mais maduros, que conheçam os padrões de utilização dos seus utilizadores, poderão particionar os dados de acordo com esses padrões [6]. Esta funcionalidade permite obter um bom tempo de resposta e manter os utilizadores satisfeitos. 13

73 Maior largura de banda Uma vez que os dados estão distribuídos por diferentes máquinas, será possível actualizar/escrever em várias máquinas mantendo uma largura de banda constante [6]. Numa aplicação bem desenhada, esta abordagem vai obrigar a alterar a forma como a conexão à base de dados é efectuada [6]. Em vezes de passarmos o caminho directo para a base de dados, devemos criar uma função, que dado um determinado argumento (neste caso o número do cliente), nos devolva o caminho para a base de dados correcta [6]. Partimos do principio que a função GetDatabaseFor() consegue determinar onde estão os dados desse cliente, tudo o restante código deverá permanecer igual (Figura 9) [6]. Figura 9. Ligação à base de dados Problemas e desafios Além de complicada, esta técnica tem alguns problemas e coloca alguns desafios [6]. Esses desafios derivam do facto das operações sobre as tabelas e/ou registos, serem agora executadas em servidores distintos [6]. A seguir serão traçados alguns cenários. Rebalanceamento de dados Um dos problemas desta técnica é o rebalanceamento dos dados, imaginemos que os dados do Utilizador1, por já terem ultrapassado o limite da capacidade do Servidor1, têm de ser transferidos para outra máquina [6]. Como é que os podemos transferir para o Servidor2 sem que isso obrigue a uma falha do serviço? Para evitar que isso aconteça é necessário pensar nesta situação que deve a fase de desenho da aplicação [6]. Em aplicações como as aquelas disponibilizadas pela Google, o rebalanceamento é efectuado de forma automática [6]. Na Figura 10 é apresentada uma forma de rebalanceamento automático. 14

74 Figura 10. Rebalanceamento de dados O cenário traçado na Figura 10 é o seguinte: é efectuado um pedido para colocar uma fotografia na ficha de um utilizador, a execução da função GetDatabaseFor() diz-nos que o servidor onde estão esses dados (servidor do meio), mas no entanto esse servidor já está lotado, pelo que os dados e a fotografia terão de ser movidos para um servidor disponível servidor da esquerda [6]. Depois dos dados serem movidos a função GetDatabaseFor() é actualizada, e os novos pedidos recairão no servidor da esquerda [6]. Juntar dados de múltiplos shards Uma vez que os dados estão agora dispersos por vários servidores, a junção de dados de diferentes tabelas, já não poderá ser efectuado através de uma simples query [6]. Os dados terão agora de ser pedidos, individualmente, a cada servidor onde se encontram os dados [6]. Felizmente, por causa da velocidade actual das redes e das técnicas de caching, este processo é suficientemente rápido pelo que o tempo de carregamento das páginas Web poderá ser excelente. 15

75 Integridade referencial É extremamente difícil forçar a integridade referencial, como por exemplo através de chaves estrangeiras, numa base de dados sharded [6]. A maioria dos Sistemas de Gestão de Base de Dados (SGBD) não suportam chaves estrangeiras entre bases de dados que estejam alojadas em servidores diferentes [6]. As aplicações que recorram a esta técnica devem forçar a integridade referencial através de código hard-coded [6]. Falta de suporte O maior problema de todos é a falta de experiência e conhecimentos neste tipo de técnica [6], pelo que quando existirem problemas não vai ser fácil encontrar alguém que nos possa ajudar. Ao contrário do que acontece com os SGBD relacionais, ainda existe pouca literatura sobre esta técnica, mas o futuro parece promissor pois algumas aplicações, como o Hibernate e o MySQL, têm já projectos em desenvolvimento para suportar esta técnica [6]. 6.2 CLOUDBURSTING O termo bursting já era utilizado nas Tecnologias de Informação, mas em contextos associados à alocação de recursos e aprovisionamento de largura de banda [6]. No que diz respeito à cloud, esse termo é utilizado para designar qualquer recurso computacional, ou infra-estrutural, que permita o acesso aos recursos conforme as necessidades do utilizador (on-demand) e que tenha a capacidade de se expandir, ou contrair, conforme necessário e sem intervenção manual [6]. Este tipo de arquitectura é bastante útil para lidar com picos de tráfego que levem os sistemas ao limite, mas porque esses picos são esporádicos, não justificam um investimento em hardware [6]. Esta arquitectura assenta na utilização de máquinas virtuais, que representam clones das máquinas reais, que serão iniciadas quando o volume de tráfego se justificar. Se hipoteticamente a Comissão Nacional de Eleições, utilizasse esta arquitectura, quando o seu data-center estivesse a atingir o máximo da sua capacidade, era automaticamente iniciada uma nova máquina, sendo novos utilizadores encaminhados para essa mesma máquina (Figura 11). 16

76 Figura 11. Cloudbursting [6] 6.3 CLOUD STORAGE Cloud storage é uma forma de armazenamento, onde os dados são acedidos através de uma rede, interna ou externa, e através de APIs disponibilizadas sobre a forma de webservices REST [6]. Esta forma de armazenamento, tirando partido da elasticidade da cloud, coloca à disposição do utilizador uma grande capacidade de recursos, que poderão ser acedidos através da rede, tendo este apenas que pagar o espaço que utilizar [6]. Os atributos mais importantes que esta forma de armazenamento possui são a escalabilidade, fiabilidade, velocidade, custo e simplicidade [6]. Um dos fornecedores com mais sucesso neste tipo de soluções é a Amazon, que disponibiliza o Amazon S3 [6, 16]. 7 Conclusão Uma vez que a cloud é algo relativamente recente, existe ainda um vazio no que diz respeito a standards e a padrões arquitecturais, o que irá condicionar a portabilidade entre aplicações alojadas em fornecedores diferentes. Actualmente apenas existem propostas de standards. 17

77 A falta de standards, poderá obrigar os clientes deste tipo de soluções, a ficarem reféns dos seus fornecedores, pelo que se sugere alguma cautela no desenho da arquitectura dos sistemas. Neste ensaio, além de ter sido clarificado o conceito de cloud computing, foram também referidas algumas técnicas e arquitecturas, que permitem não só lidar com a escalabilidade dos sistemas, como também a tirar partido deste tipo de tecnologias. 8 Referências 1. Roberto, C., Cloud Computing: Oportunidades, Drivers de Sucesso & Cases Study PT Virtual Desktop, in Semana Informática Norte, M., Projecto ISOFIN Cloud Gillett, S.E. and M. Kapor (1996) The Self-governing Internet: Coordination by Design. 4. Reese, G., Cloud Application Architectures. 2009: O'Reilly. 5. Velte, A.T., T.J. Velte, and R. Elsenpeter, Cloud Computing: A Practical Approach. 2010: McGraw-Hill. 6. Rosenberg, J. and A. Mateos, The Cloud at Your Service - The when, how, and why of enterprise cloud computing. 2010: Manning. 7. Mell, P. and T. Grance, The NIST Definition of Cloud Computing Krutz, R.L. and R.D. Vines, Cloud Security - A Comprehensive Guide to Secure Cloud Computing. 2010: Wiley. 9. Furht, B. and A. Escalante, Handbook of Cloud Computing. 2010: Springer. 10. Speciale, P. (2010) Accelerating Time to Market: Application Development and Test in the Cloud. 11. Open Cloud Consortium. [ ]; URL: 12. Distributed Management Task Force. [ ]; URL: 13. Rittinghouse, J.W. and J.F. Ransome, Cloud Computing Implementation, Management, and Security. 2010: CRC Press. 14. Waschke, M. OVF and Cloud Computing 2010; URL: 15. Dignan, L. Oracle submits cloud interoperability API. [ ]; URL: 16. Amazon S3. [ ]; URL: 18

78 Relatório: Coordenação de grupo de projecto de Processos e Metodologias de Software Bruno Meira, Universidade do Minho, Guimarães Abstract. Este relatório visa descrever a experiência de acompanhamento de um grupo de projecto, formado no âmbito da unidade curricular de Processos e Metodologias de Software (PMS) do 2º ano da Licenciatura em Tecnologias e Sistemas de Informação, focando as dificuldades encontradas pelo autor e pelo grupo de PMS. Keywords: planeamento, gestão de projectos, processos e metodologias de software, consultadoria, análise e concepção de sistemas de informação 1 Introdução Este relatório foi realizado no âmbito da unidade curricular de Analise e Concepção de Sistemas de Informação, enquadrada no Mestrado em Engenharia e Gestão de Sistemas de Informação, e o seu objectivo é descrever o acompanhamento, pela perspectiva do autor, de um grupo de trabalho composto por alunos de licenciatura. O grupo de trabalho acompanhado tem como objectivo o planeamento de um projecto de desenvolvimento de software, bem como a modelação inicial da solução. O projecto está enquadrado na disciplina de Processos e Metodologias de Software, do 2º ano da licenciatura em Tecnologias e Sistemas de Informação. 2 Descrição e âmbito do projecto O projecto, descrito, anteriormente visa o desenvolvimento de um sistema informático para uma Instituição Privada de Solidariedade Social, denominada MG. Este projecto, denominado SIMG, encontra-se divido em dois sub-projectos:

79 2 Inception e Desenvolvimento. O acompanhamento do autor incidiu sobre o primeiro sub-projecto, que decorreu entre Dezembro de 2010 e Janeiro de Durante a execução do sub-projecto Inception existiram duas fases distintas: planeamento e execução. Durante a primeira fase, planeamento, o autor assumiu o papel de consultor externo e, durante a segunda, assumiu o papel de gestor de projecto. A fase de planeamento culminou com uma entrega realizada no dia 28 de Novembro de 2010 e consistiu no planeamento da fase inicial da execução do projecto SIMG. O Processo de desenvolvimento escolhido para adopção foi o Rational Unified Process (RUP), e a entrega do grupo de trabalho, consistia no planeamento da fase Inception do RUP, focado nas disciplinas de Business Modeling e Requirements. A fase de execução foi caracterizada pela execução do anteriormente planeado, ou seja, foi necessário que o grupo apresentasse os resultados da execução da fase Inception identificada no RUP. Para esta fase, era expectável que fossem entregues os principais artefactos necessários para a fase de Inception, bem como a modelação incial do sistema usando a Unified Modeling Language (UML). A data de entrega para esta última fase foi no dia 16 de Janeiro de Resumo do enunciado do projecto de PMS A empresa sw-ltsi dedica-se ao desenvolvimento de software. Entre os seus clientes encontra-se uma Instituição de Solidariedade Social (IPSS), denominada MG. A MG está sediada em Guimarães e é uma instituição sem fins lucrativos, vocacionada para ajudar as pessoas mais carenciadas. A sw-ltsi vai desenvolver um sistema informático integrado para apoiar o funcionamento da MG. Embora a MG tenha alguns subsistemas informatizados, a recente certificação ISO 9001:2008 trouxe novos desafios e a Direcção da MG coloca a possibilidade de adquirir um novo sistema integrado, alinhado com o sistema de qualidade. O projecto global (SIMG) será constituído por dois subprojectos. O subprojecto Inception, cobrindo as actividades de Modelação de Negócio e Requisitos, decorrerá entre Dezembro de 2010 e Janeiro de O subprojecto Desenvolvimento dependerá da aprovação do subprojecto inicial e nesse caso está previsto decorrer entre Fevereiro de 2011 e Junho de A MG tem as suas actividades espalhadas por diversas localizações físicas, nomeadamente: sede, unidade de apoio à saúde, lares, residenciais, recolhimentos e centros de dia. Na recente certificação de qualidade foram definidos 13 processos, cada um descrito num manual de procedimentos. Os manuais de procedimentos são detalhados em instruções de trabalho e toda a informação é armazenada em registos, que permitem comprovar a execução dos processos, analisar métricas e propor acções de melhoria. A sw-ltsi é uma empresa CMMI nível 2 e usa um processo de desenvolvimento de software baseado no Rational Unified Process (RUP), com um número de iterações dependente de cada projecto específico. A sw-ltsi conta nos seus quadros técnicos com cinco analistas de negócio, para o subprojecto Inception. Os

80 3 requisitos funcionais especificados pela MG à sw-ltsi relativos ao SIMG são a implementação das áreas referidas. Como requisitos não funcionais foram especificados: a disponibilidade 24h/dia x7dias/semana dos módulos que suportam as áreas MG-CSL e MG-AL, o registo de todas as operações sobre dados na Orçamentação e usability elevada em todos os módulos. 3 RUP Como referido anteriormente, a metodologia de desenvolvimento adoptada foi o RUP. As vantagens na utilização desta metodologia estão grandemente ligadas com a necessidade de garantir, não só a qualidade do software, mas também o cumprimento de prazos de execução e orçamento do projecto de desenvolvimento. O Rational Unified Process é um processo de engenharia de software ( ). É uma abordagem disciplinada para atribuir e controlar tarefas e responsabilidades ( ). O objectivo deste processo é produzir, num espaço de tempo e orçamento previsíveis, software com elevada qualidade que vá de encontro as necessidades dos utilizadores [3]. Diferentes projectos de desenvolvimento falham de formas diferentes e, infelizmente, demasiados falham mas é possível no entanto identificar um conjunto de sintomas comuns que caracterizam este tipo de projectos: Compreensão pouco precisa das necessidades dos utilizadores; Incapacidade para lidar com mudança nos requisitos; Módulos com problemas de integração; Software que é difícil de manter ou estender; Descoberta tardia de falhas de projecto graves; Software de fraca qualidade; Performance de software inaceitável; Elementos do grupo de projecto atrapalham-se uns aos outros, tornando impossível reconstruir quem mudou o que, quando, onde e porquê; Um pouco confiável processo de construção e lançamento; [3]. O RUP é uma abordagem de desenvolvimento de software que é iterativa, centrada na arquitectura e use-case-driven [4]. 3.1 RUP, Processo ICONIX e CMMI Durante a fase de execução descrita anteriormente, para além dos artefactos e diagramas especificados no RUP, o grupo de projecto teve que entregar um outro conjunto de diagramas, diagramas de Robustez. Estes diagramas não se encontram formalmente identificados no RUP e não são pedidos ou documentados em nenhuma das fases e disciplinas do RUP. Estes diagramas estão presentes numa outra metodologia de desenvolvimento de software, o ICONIX Process que pode ser considerada como uma metodologia ágil. Embora não exista uma definição formal aceite globalmente pela indústria, que diga exactamente o que são métodos ágeis, de uma forma geral, podem-se caracterizar como métodos de desenvolvimento de software com um menor foco no controlo sobre o processo. Ou seja, o controlo e documentação possibilitados pelo uso de um

81 4 processo como o RUP, são sacrificados pela produção rápida de protótipos funcionais para apresentar e validar com o cliente [5] [6]. O processo ICONIX é um processo minimalista, use-case-driven e ágil. O processo foca-se na área que se encontra entre os UCs e o código. O seu ênfase é no que é necessário que aconteça nesse ponto do ciclo de vida aquando do inicio do projecto: os UCs já foram iniciados, e agora é necessário uma boa analise e modelação [7]. O RUP é adaptável o suficiente para ter um nível de documentação variável consoante a complexidade e dimensão do projecto em que está a ser implementado, no entanto, não é um método ágil como o ICONIX. CMMI (Capability Maturiry Model Integration) é uma abordagem de melhoria de processo que proporciona as organizações elementos essenciais de processos efectivos que, em última instância, aumentam a sua performance. O CMMI pode ser usado para guiar a melhoria de processos num projecto, num departamento ou numa organização inteira [8]. Um estudo feito em 12 casos, de 11 organizações diferentes, de diferentes dimensões, mostrou ganhos efectivos ao nível de custo, calendarização de tarefas, qualidade e satisfação do cliente após a adopção do modelo CMMI. As organizações estudadas actuam em vários sectores, desde, tecnologias de informação, banca, industria automóvel, etc [9]. No que ao desenvolvimento de software concerne, a relação entre o CMMI e o RUP é óbvia. Quanto maior a adopção do processo RUP, maior é a pontuação atingida no modelo CMMI. No entanto, neste ponto, o autor não pode deixar de comentar uma pequena incongruência no decorrer do projecto de PMS. Foi dito aos alunos de PMS que a sw-ltsi, empresa que os alunos integraram figurativamente, para realizar o projecto, era um empresa CMMI nível 2 e, naturalmente, a qualidade do sub-projecto inception deveria reflectir este facto. É efectivamente possível fazer um match entre os dois processos e, tendo em conta que o CMMI é um modelo que pretende avaliar o nível de orientação a processos, é possível comparar ambos os processos face ao nível de CMMI.

82 5 Fig. 1 métodos ágeis, retirado de [4] Fig. 2 Metodologia RUP, retirado de [4]

83 6 Fig. 3 CMMI, retirado de [4] Estas ilustrações enquadram ambas as metodologias num referencial que analisa, no eixo horizontal, o nível de documentação, sendo que low ceremony representa pouca documentação e high ceremony representa boa documentação, o que permite alta rastreabilidade. O eixo vertical analisa o tipo da metodologia, isto é, se é linear como a waterfall ou iterativa. Como se pode verificar, é possível que o RUP seja seguido de uma forma mais próxima dos métodos ágeis. No entanto, o nível de documentação e rastreabilidade exigido pelo modelo CMMI torna impossível essa abordagem. O processo ICONIX, ao ser incluído na entrega, torna pouco provável que a sw-ltsi consiga atingir o nível 2 no referencial CMMI. 4 UML Como já foi referido, a modelação da solução foi feita recorrendo a UML. A Unified Modeling Language (UML) é uma família de notações gráficas, assentes num único meta-modelo, que ajuda a descrever e a modelar sistemas de software, particularmente sistemas de software construídos usando o paradigma de orientação a objectos (OO) [1]. Captura decisões e compreensão sobre o que o sistema à ser construido. É usada para compreender, desenhar, procurar, configurar, manter e controlar informação sobre este tipo de sistemas [2]. O domínio sobre esta linguagem é fundamental para garantir uma boa modelação da solução. O seu propósito e proporcionar um meio de comunicação que todos os envolvidos no desenvolvimento do projecto consigam perceber, o que é conseguido através de uma definição rigorosa da linguagem. Todos os tipos de diagramas encontram-se rigorosamente documentados, de forma a não existir ambiguidade na

84 7 sua leitura ou dúvidas sobre o que deve ou não deve ser representado e como deve ser representado. O RUP, descrito anteriormente, assenta em grande parte nesta linguagem, fazendo uso da mesma para representar todos os diagramas necessários, dando assim à metodologia o rigor de representação que necessita. 4.1 UML e os diagramas de robustez Se, por um lado, o UML se encontra altamente documentado de forma a não criar ambiguidade na leitura dos diagramas, o mesmo não pode ser dito dos diagramas de robustez. Existe muita confusão à volta destes diagramas, não é claro o que pode ser representado ou não. Não existe documentação concisa sobre como representar concretamente estes diagramas. A titulo de exemplo, na documentação existente do processo, isto é, na página web oficial, em nenhum lado são explicadas as regras dos diagramas de robustez. Algumas destas regras têm de ser derivadas de informação solta, presente em outras páginas web, o que torna consideravelmente difícil a sua concreta validação. 5 Grupo de projecto O grupo acompanhado era composto por 4 elementos. Gonçalo Sousa (58333), José Oliveira (60187), José Santos (58342) e Rui Magalhães (58306). Não foi atribuído nenhum número de identificação ao grupo 6 Interacção com o grupo As interacções com o grupo ocorreram durante as aulas de PMS, com uma duração aproximada de 2 horas. Para alem da reunião semanal, foram frequentes contactos adicionais através de , telemóvel e instant messaging, à medida que o grupo foi considerando necessário. Adicionalmente, foi aproveitada uma sessão de PMS em que o professor Pedro Ribeiro não compareceu para explicar ao grupo como modelar em UML. Esta sessão de explicação teve a duração de 2 horas. Durante as diversas interacções fui fornecendo diversos recursos ao grupo, como livros e links úteis, que os poderiam ajudar na execução do projecto. 6.1 Dificuldades enquanto consultor Enquanto consultor, a interacção com o grupo estava, de certa forma, limitada a dar alguma ajuda ao grupo, ou seja, tentava ajudar o grupo, dando indicações e conselhos que considerava úteis e que os podiam ajudar na execução do projecto. Durante esta fase senti que o grupo, de uma forma geral, estava à espera de um envolvimento diferente da minha parte. De certa forma, pareceu-me que eles

85 8 esperavam uma ajuda directa na elaboração do planeamento. Não quero com isto dizer que o grupo quisesse que eu lhes resolvesse o projecto, como muitos dos meus colegas foram relatando durante as aulas de ACSI. No entanto, pareceu-me que contava com uma ajuda no sentido de corrigir completamente o trabalho efectuado antes de este ser entregue. Durante esta fase, tentei ajudar o grupo de trabalho de diversas formas. Analisei conjuntamente com eles o enunciado do projecto e expliquei-lhes o que lhes era pedido no mesmo. Alertei-os para os impactos de alguns pontos do relatório, como por exemplo, o facto de os objectivos do projecto estarem em conformidade com a norma ISO Explanei-lhes o esquema de navegação do RUP mostrando ao mesmo tempo onde poderiam ler o que era pretendido de cada fase e disciplina e onde poderiam fazer o download dos templates associados às diferentes tarefas e objectivos. As minhas recomendações, de uma forma geral, não foram seguidas. Durante esta fase do projecto, estava à espera que o grupo colocasse dúvidas mais concretas sobre o planeamento do projecto e sobre as decisões que poderiam tomar quanto a execução do mesmo. Na maioria dos casos, o grupo procurou a minha ajuda, não para colocar estas questões ou pedir clarificações, mas para validar o trabalho efectuado e tirar pequenas dúvidas do género: Gostava de saber qual o modelo do RUP que deveríamos utilizar no projecto. Esta questão surgiu exactamente como está escrita, no dia 20 de Novembro, 2 dias após eu ter dado uma pequena esclarecimento ao grupo sobre o RUP. 6.2 Dificuldades enquanto gestor de projecto Enquanto gestor de projecto, foi extremamente difícil fazer com que o grupo cumprisse as datas que estavam estipuladas. As tarefas definidas foram, de uma forma geral, cumpridas fora do prazo establecido e tratadas de uma forma bastante superficial, em comparação com as minhas expectativas. O planeamento, entregue na fase anterior, tinha alguns erros e foi devidamente corrigido, na tentativa de que coincidisse mais assertivamente com o que foi de facto executado. Mesmo assim, houve atrasos consideráveis. A título de exemplo, os UCs deveriam ter estado finalizados até ao dia 6 de Janeiro, mas na verdade, no dia 29 de Dezembro, o grupo apresentou-me uma versão textual muito básica e pouco detalhada dos UCs, onde nem sequer estavam representados actores. Na reunião anterior ao início do período de férias atribuí, a cada um dos elementos a tarefa de detalhar 2 UCs de nível 0 em nível 1. Como já foi demonstrado, esta tarefa não foi cumprida. Foi só na reunião do dia 14 que o grupo me apresentou versões quase finais dos UCs de nível 0, 1 e 2 e também do artefacto Vision. O maior atraso sofrido foi sem dúvida durante o período de ferias, período durante o qual o grupo não trabalhou ou então trabalhou muito pouco como já foi referido. Independentemente de eu os alertar, e ter dado tarefas específicas, estas tarefas não foram cumpridas e foram constantemente adiadas.

86 9 6.3 Dificuldades encontradas pelo grupo As dificuldades demonstradas pelo grupo foram variadas. De uma forma geral, as maiores dificuldades centraram-se no entendimento do processo de desenvolvimento, RUP, e na modelação em UML. Quanto ao RUP, para alem da dificuldade em entender o processo em si, constatei que os alunos tiveram muitos problemas em utilizar e navegar pela documentação do RUP. Quanto a modelação em UML, o grupo mostrou bastantes dificuldades em modelar a solução a desenvolver. Neste aspecto, o grupo teve alguns problemas em traduzir os processos de negocio da MG em funcionalidades e requisitos da solução. Este facto foi facilmente observado pela validação inicial que efectuei dos UCs, em que o grupo me apresentou, num desses diagramas, um UC designado Preparação de alimentos e outro chamado Ministrar medicação adequada. As deficiências mostradas pelo grupo na modelação não se limitam apenas aos UCs. De facto, o grupo teve bastantes dificuldades na realização dos diagramas de robustez, que se devem, na minha opinião, ao nível de abstracção necessário para modelar aplicações e sistemas informáticos. Em adição ao nível de abstracção necessário, é também importante salientar que, os diagramas de robustez não se encontram devidamente documentados e não são formalmente especificados pela Object Management Group (OMG). A inclusão destes diagramas trouxe uma complexidade adicional a esta fase que não é normalmente necessária. Obrigou o grupo a familiarizar-se com estes diagramas e obrigou-os também a representar os diagramas de sequência com base nos diagramas de robustez. Este facto introduziu uma complexidade consideravelmente superior ao que é esperado para esta fase do projecto ao nível dos diagramas de sequência: representar as interacções entre utilizador e o sistema. Ao introduzir estes diagramas, o sistema transformou-se em Objectos de Fronteira, Entidades e Controladores, o que necessita de uma capacidade de abstracção superior a que o grupo possuía. Muito francamente, o grupo não estava preparado para esta tarefa. A qualidade dos diagramas apresentados mostra claramente isso. Alguns dos diagramas de robustez foram representados de forma bastante incompleta, havendo casos onde, por exemplo, criam um objecto do tipo Controlador para controlar a admissão de novos utentes e, não ligam esse objecto a um outro objecto do tipo Entidade para armazenar os dados da admissão. 6.4 Percepção pessoal De uma forma geral, penso que o grupo não dedicou tempo suficiente à este projecto. O atraso sofrido nas férias mostra claramente uma posição bastante descurada e imatura por parte do grupo. Esta posição é visível não só pelo facto do grupo não ter entregue diagramas de sequência, mas também por não terem prestado a devida atenção a disciplina de Business Modeling, facto para o qual eu os alertei consecutivas vezes. O grupo deveria ter trabalhado mais intensamente e mais frequentemente. Encontrei-me bastante vezes a dar explicações não solicitadas

87 10 devido ao grupo nunca aparecer com dúvidas concretas e com pouco trabalho efectuado. Este tipo de questões surgiram, maioritariamente, nas semanas anteriores às entregas e, como tal, eram dúvidas concretas de representação de conteúdo a entregar, em vez de duvidas relacionadas com a modelação do sistema ou sobre decisões que poderiam eventualmente considerar. Embora a posição descuidada do grupo tenha sido, sem dúvida, o factor que mais influenciou a qualidade do projecto, não posso deixar de referir que o grupo se encontrava bastante mal preparado para esta última fase e, em adição a esta má preparação, a inclusão de diagramas de robustez fez com que a qualidade ficasse ainda mais baixa. Ao dedicarem-se a estes diagramas, o grupo perdeu tempo significativo que podia ter sido aproveitado para melhor caracterizar o negócio e, consecutivamente, melhor especificar a solução a desenvolver. A falta de documentação destes diagramas, a ambiguidade que geram, a falta de exemplos práticos da sua aplicação e a capacidade de abstracção que necessitam para serem bem representados, torna a sua inclusão nesta fase bastante complexa e difícil. Para os compreender devidamente e os representar, são necessários conhecimentos que, na minha opinião, maior parte dos alunos de 2º ano de licenciatura não possuem. Além deste facto, convém também salientar que o os diagramas de robustez fazem parte do processo ICONIX e não do processo RUP. 7 Conclusão O acompanhamento do grupo de trabalho de PMS não foi fácil. Foi extremamente complicado alertar os elementos do grupo para os impactos de alguns detalhes presentes no enunciado do projecto. De uma forma geral, os elementos não tinham a sensibilidade necessária para perceber o que lhes era pedido para além do que estava taxativamente explícito. Alguns conceitos como, por exemplo, o conceito de processo iterativo, não foram verdadeiramente compreendidos pelo grupo. Para além das dificuldades sentidas pelo grupo na utilização da metodologia RUP, convém também salientar a má preparação do mesmo para a fase de modelação em UML, conceitos tais como, por exemplo, generalização de actores, não foram verdadeiramente compreendidas. Quanto à experiência de acompanhamento, o autor considera-a como enriquecedora, complexa e desafiante, um verdadeiro alerta para o que poderá ser encontrado fora do contexto académico. As vicissitudes inerentes a este tipo de projectos são complexas e, se não existir consciência, por parte dos grupos de projecto, para a sua existência, os resultados podem ser comprometidos. A troca de papeis que existiu durante o decorrer do acompanhamento foi também positiva, permitiu um tipo de interacção com o grupo de trabalho diferente, mais pessoal, servindo como um alerta para o tipo de pressões que um gestor de projecto está sujeito.

88 11 8 Referencias [1] Fowler, M., and Scott, K. UML distilled: a brief guide to the standard object modeling language Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, [2] Rumbaugh, J., Jacobson, I., and Booch, G. Unified Modeling Language Reference Manual, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, [3] Kruchten, P. The rational unified process: an introduction Addison-Wesley Professional, [4] Kroll, P., and Kruchten, P. The rational unified process made easy: a practitioner's guide to the RUP Addison-Wesley Professional, [5] Rosenberg, D., Stephens, M., and Collins-Cope, M. Agile development with ICONIX process: people, process, and pragmatism Apress, 2005b. [6] Wikipedia, Wikimedia Foundation, Agile Software Development, disponivel em: acessado em 23/01/2011 [7] Iconix Process, disponivel em acessado em 23/01/2011 [8] Software Engineering Institute, Capability Maturiry Model Integration, disponivel em: acessado em: 23/01/2011 [9] Goldenson, D., and Gibson, D. "Demonstrating the impact and benefits of CMMI: An update and preliminary results," Special Report SEI. October) Bibliografia PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge PMBOK Guide 2000 Edition, Pennsylvania-USA 2000 SWEBOK. Guide to the Software Engineering Body of Knowledge Version. A project of the IEEE Computer Society Professional Practices Committee. Acetatos da disciplina de Analise e Concepção de Sistemas de Informção IBM Rational Unified Process

89 Interdependência em requisitos Carina Campos Análise e Concepção de Sistemas de Informação Mestrado em Engenharia e Gestão de Sistemas de Informação Universidade do Minho, Campus de Azurém, Guimarães Resumo: A maioria dos requisitos são interdependentes, pois, relacionam-se e afectam uns os outros. Alguns requisitos só podem ser implementados se outros requisitos forem implementados antes. Este artigo pretende abordar a interdependência em requisitos. Quando se fala em interdependência em requisitos tem-se dois conceitos associados á mesma, a rastreabilidade que é a base para intitular as interdependências em requisitos e a análise de impacto, pois, uma simples mudança num requisito pode implicar alterações noutros requisitos. Para gerir as interdependências existem tabelas de dependência e ainda alguns softwares específicos. Estes e outros aspectos serão descritos ao longo deste artigo. Palavras-chave: requisitos, interdependência de requisitos, rastreabilidade, análise de impacto, tabelas de dependência, softwares específicos. 1 Introdução Este artigo resultou de várias pesquisas efectuadas no âmbito da temática de interdependência em requisitos a decorrer ao abrigo do programa lectivo da unidade curricular de Análise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão de Sistemas de Informação da Universidade do Minho e pretende abordar alguns temas ligados à interdependência em requisitos. A maioria dos requisitos individuais desenvolvidos durante o processo de engenharia de requisitos relacionam-se e afectam uns os outros de complexas maneiras, não podendo assim, ser tratados isoladamente. (Carlshamre et al., 2001, Regnell et al., 2001). É importante notar que os requisitos não são independentes uns dos outros, pois, há requisitos que só podem ser implementados se outros requisitos forem implementados antes. Um estudo realizado mostra que apenas aproximadamente 1

90 um quinto dos requisitos em qualquer conjunto de requisitos são verdadeiramente singulares, isto é, não são influenciados ou relacionados com quaisquer outros requisitos (Carlshamre et al., 2001). Um requisito pode afectar outros requisitos quando ele (Dahlstedt and Persson, 2005): -forçar como outro requisito pode ser concebido ou implementado; -afectar o custo de implementação de outros requisitos; -aumentar ou diminuir a satisfação dos clientes de outros requisitos. As interdependências de requisitos são vistas como um tipo específico de rastreabilidade (Dahlstedt and Persson, 2005). A rastreabilidade permite identificar relacionamentos entre requisitos, identificar a origem dos requisitos e componentes que os implementam (Sayão and Do Prado Leite, 2005). A rastreabilidade de requisitos é a base para uma análise de impacto eficiente (Oliveira Filho et al., 2008). Através da análise de impacto é possível identificar consequências e fornecer estimativas em termos de prazos e custos, de uma mudança feita num requisito antes da mesma ser implementada. O facto de lidar com interdependências de requisitos pode enriquecer algumas actividades. As interdependências podem ser geridas através de tabelas de dependência e de softwares específicos, os quais, permitem tratar das interdependências de forma mais fácil e eficaz. Este artigo está organizado da seguinte forma: na secção 2 é descrito em que consiste a rastreabilidade de requisitos. A secção 3 apresenta o que é a interdependência de requisitos; as actividades que podem ser enriquecidas com o uso da mesma; e a analise de impacto de mudanças nos requisitos. A secção 4 descreve os tipos de interdependências. A secção 5 descreve os métodos para gerir as interdependências, onde são referidas as tabela de dependência e os softwares usados para gerir dependências em requisitos. A secção 6 apresenta um exemplo ilustrativo onde se pode observar as interdependências entre os requisitos e o impacto de mudanças feitas nos requisitos. E finalmente, a secção 7 corresponde á conclusão deste artigo 2

91 2 Rastreabilidade de Requisitos A rastreabilidade de requisitos tem sido reconhecida como uma parte importante do software e do desenvolvimento de sistemas de informação (Pohl, 1996, Gotel, 1995, Maciaszek, 2001). A rastreabilidade é considerada como uma base para intitular as interdependências de requisitos (Dahlstedt and Persson), sendo estas vistas como um tipo específico de rastreabilidade. A rastreabilidade vai auxiliar na compreensão dos relacionamentos existentes entre os requisitos. Existem diferentes definições do termo rastreabilidade de requisitos uma das definições é a capacidade para descrever e seguir a vida de um requisito, em ambas as direcções, de preferência através de todo o ciclo de vida do sistema ((Jarke, 1998), p.32, baseado no (Gotel and Finkelstein, 1994)). A rastreabilidade de requisitos apoia a compreensão de por que razão um determinado objecto foi criado, modificado e evoluído (Ramesh and Jarke, 2001). A rastreabilidade fornece também uma possibilidade para assegurar que todos os requisitos são cumpridos pelos componentes do sistema e que nenhum recurso foi adicionado (Ramesh and Edwards, 1993, Ramesh et al., 1997), uma vez que, todos os componentes ou recursos no sistema devem ser capazes de ligar-se a um ou vários requisitos (Dahlstedt and Persson, 2005). A rastreabilidade é mantida por elos que relacionam os requisitos a outros requisitos (elos de dependência), a artefatos que os atendem (elos de satisfação) e às suas fontes (Sayão and Do Prado Leite, 2005). Através da rastreabilidade é possível descobrir a fonte dos requisitos, qual a razão da existência do requisito, que requisitos se relacionam uns com os outros (dependência entre os requisitos) e ainda como os requisitos se relacionam com outras informações, tais como, concepção do sistema, implementações e documentação do utilizador (Cappelli and Santoro, 2006). Todas estas informações são utilizadas para identificar todos os requisitos que serão afectados por mudanças que sejam propostas. Uma boa prática sugerida é criar a rastreabilidade na medida em que os requisitos são desenvolvidos (Da Silva, 2007), o que ajudará a compreender melhor os requisitos. 3

92 3 Interdependência de requisitos As interdependências de requisitos não são um problema por si, mas influenciam o número de actividades de desenvolvimento e decisões feitas durante o processo de engenharia de software (Dahlstedt and Persson, 2005). A maior parte dos requisitos de um sistema de software relacionam-se entre si, não podendo ser tratados como requisitos independentes (Dahlstedt and Persson). Existem requisitos que só são implementados quando outros requisitos são implementados antes, como por exemplo, é impossível fazer um relatório de vendas sem que se registem as vendas previamente no sistema (Xexéo, 2007). Segundo (Carlshamre et al., 2001), ao avaliarem a interdependência em requisitos em diferentes tipos de projectos, mostraram que apenas uma pequena percentagem de requisitos são independentes. A identificação e o controlo das interdependências em requisitos, pode ser essencial para o projecto de software ser bem sucedido e para evitar erros potencialmente caros. Uma mudança feita num requisito pode mudar também vários outros requisitos (Kotonya and Sommerville, 1998, Pohl, 1996) o que provocará várias consequências no projecto. Quando avaliado o impacto de uma mudança ignorar as interdependências pode resultar em custos mais elevados (Dahlstedt and Persson, 2005). O propósito de sistematicamente lidar com interdependências de requisitos é para melhorar as decisões feitas durante o desenvolvimento de software e também para apoiar a detecção antecipada de potenciais problemas devido a interdependências de requisitos (Dahlstedt and Persson, 2005). Gerir interdependências de requisitos consiste em identificar, armazenar e manter informações sobre como os requisitos se relacionam e afectam uns os outros (Dahlstedt and Persson, 2005). Isto também envolve decidir qual a informação de interdependência em requisitos que é necessária nas várias situações no processo de desenvolvimento de software e como é que a informação deve ser apresentada (Dahlstedt and Persson, 2005). Quando um projecto entra em etapas como concepção, implementação e testes, uma falha na identificação das interdependências entre os requisitos pode ser extremamente dispendiosa de se corrigir e até mesmo significar o insucesso do projecto (Colares). 4

93 A forma de identificar as interdependências entre os requisitos deve ser bem definida, clara e não ambígua (Colares). Deve ainda cobrir todos os possíveis tipos de interdependências, todas as possíveis combinações entre os requisitos e ser automatizada. Caso a detecção de interdependências não seja automatizada, deve haver um procedimento claro e bem definido. Uma boa manutenção das interdependências em requisitos conduz a alguns benefícios a longo prazo, tais como, uma maior satisfação do cliente e custos de desenvolvimento mais baixos. 3.1 Actividades enriquecidas pelo uso de interdependências Dahlstedt e Persson (Dahlstedt and Persson) enumeram diversas actividades que podem ser enriquecidas com o uso de interdependências em requisitos. Algumas dessas actividades são: -Gestão de requisitos esta actividade preocupa-se com gerir uma grande quantidade de requisitos e informação extraída durante a engenharia de requisitos (Grehag, 2001). Apreender as interdependências em requisitos pode ser útil nesta fase, uma vez que fornece uma visão global de como os requisitos de alto nível são decompostos em requisitos mais detalhados (Ramesh and Jarke, 2001). -Gestão de mudanças No desenvolvimento de software os requisitos estão em constante evolução e mudança. As interdependências de requisitos são úteis nesta actividade, uma vez que mostram a evolução dos requisitos, ou seja, como um certo requisito foi mudado ao longo do tempo. As interdependências de requisitos têm ainda o beneficio de mostrar como os requisitos se relacionam e afectam uns os outros, o que facilita a análise de impacto das mudanças propostas (Kotonya and Sommerville, 1998, Pohl, 1996). -Planeamento de versões Preocupa-se com seleccionar uma ideal colecção de requisitos para implementação na próxima versão de um sistema de software. A selecção é usualmente baseada na prioridade dos requisitos. O conhecimento sobre como os requisitos interagem e condicionam uns os outros é, portanto, uma importante base para estas decisões (Dahlstedt and Persson). 5

94 -Reutilização de componentes Se semelhanças entre os requisitos são documentadas, essas interdependências podem ser usadas para identificar componentes reutilizáveis, por comparar os requisitos estabelecidos com os requisitos do sistema existente (Pohl, 1996). -Reutilização de requisitos Quando variantes de produtos de software são desenvolvidas, parte dos requisitos podem ser os mesmos, uma vez que os produtos são frequentemente construídos sobre a mesma funcionalidade básica (Dahlstedt and Persson, 2005). Os documentos de requisitos têm portanto muitas semelhanças. É importante assegurar que todos os requisitos relacionados com o requisito copiado são também incluídos no documento reciclado (Dahlstedt and Persson). O conhecimento sobre as interdependências entre os requisitos pode claramente apoiar esta tarefa de reciclar requisitos. -Concepção e Implementação A concepção de software preocupa-se com as tomadas de decisão. Muitas trocas são feitas, por exemplo, para decidir o alcance e as funcionalidades do sistema, bem como, a implementação entre os custos e os outros recursos (Ramesh and Jarke, 2001). As interdependências de requisitos podem apoiar este tipo de trocas e decisões, por exemplo, por revelar interacção entre os requisitos, os quais, podem interferir com a sua realização (Robinson et al., 1999). -Testes As interdependências de requisitos podem ser um aspecto relevante a ter em consideração na área de testes de software. Durante esta actividade, casos de teste são desenvolvidos com base nos requisitos, os quais a realização é suposta ser assegurada (Dahlstedt and Persson, 2005). Uma vez que, os requisitos estão relacionados, o conhecimento sobre interdependências de requisitos certamente afecta a capacidade para criar significativos e completos casos de teste. Os casos de teste estão relacionados a um ou a vários requisitos, significando que as interdependências entre os requisitos são úteis para decidir quais os requisitos que devem ser agrupados nos casos de teste (Dahlstedt and Persson, 2005). 6

95 Manutenção Poucos softwares e sistemas de informação são estáveis. A maioria dos sistemas continuamente evolui, devido a mudanças na organização ou nas necessidades do utilizador, ou devido a erros feitos durante o desenvolvimento (Pohl, 1996). As interdependências de requisitos são úteis neste contexto, uma vez que mostram como a mudança nos requisitos afecta outros requisitos já implementados no software (Dahlstedt and Persson). 3.2 Análise de impacto Ao longo do desenvolvimento de software ocorrem, normalmente, mudanças nos requisitos. Estas mudanças, na maioria das vezes, implicam uma renegociação dos prazos, dos custos e dos esforços para realizar o projecto (Mayer and Chiarello, 2009). A análise de impacto depende de informações de rastreabilidade para estimar as consequências de mudanças nos requisitos. A base para uma análise de impacto eficiente é a rastreabilidade. Tal como já foi referido anteriormente, a análise de impacto é realizada sobre uma rastreabilidade mantida por elos que relacionam os requisitos a outros requisitos (elos de dependência), a artefatos que os atendem (elos de satisfação) e às suas fontes (Ramesh and Jarke, 2001, Toranzo et al., 2002). Através dos elos de satisfação a análise de impacto pode identificar os artefatos afectados por uma mudança de requisitos. E os elos de dependência facilitam a identificação de requisitos interdependentes, que são candidatos naturais a sofrer algum impacto pela mudança (Oliveira Filho et al., 2008). Para cada mudança identificada é necessário que se estabeleça e identifique quais são os requisitos que foram afectados e que deverão ser renegociados, pois, muitas vezes uma simples mudança num requisito implica alterações noutros requisitos. É também necessário que sejam avaliados os impactos no projecto causados por essa mudança. Estes impactos podem ser em relação ao não atendimento de algum requisito, pelo custo associado aos requisitos alterados, pelos riscos identificados aos quais o projecto está exposto em consequência da mudança, entre outros. 7

96 4 Tipos de interdependências Como já foi mencionado anteriormente, os requisitos podem afectar e relacionarse uns com os outros de varias formas. No início das pesquisas de rastreabilidade, Pohl (Pohl, 1996) desenvolveu uma framework, na qual, incluiu um modelo de dependência definindo 18 tipos diferentes de possíveis ligações de dependência (Figura 1). O modelo de Pohl descreve os tipos de dependência que podem existir entre quaisquer tipo de objecto traçado usado no processo de engenharia de requisitos (Dahlstedt and Persson). Figura 1 Modelo dos tipos de dependência (Pohl, 1996) No modelo de dependência de Pohl há alguns tipos de dependências que claramente não existem entre requisitos, sendo então necessário adaptar e especializar o modelo de Pohl para as interdependências de requisitos. As categorias e os tipos de dependência apresentados no modelo de Pohl são também por vezes difíceis de distinguir claramente uns dos outros (Dahlstedt and Persson). E existem ainda tipos de interdependência de requisitos suplementares encontrados na literatura subsequente. Para poder desenvolver um modelo focado especialmente em interdependências de requisitos e também incorporar pesquisas recentes, é necessário adaptar e rever este modelo. 8

97 Com base na literatura existente e também em algumas pesquisas Åsa G. Dahlstedt e Anne Persson desenvolveram uma classificação dos tipos fundamentais de interdependência (Figura 2). Figura 2 Classificação dos tipos fundamentais de interdependência (Dahlstedt and Persson, 2005) Nesta classificação dos tipos fundamentais de interdependência foram identificadas três categorias de interdependências (Dahlstedt and Persson, 2005): 4.1 Interdependências estruturais (structural interdependencies) As interdependências estruturais estão preocupadas com o facto de que dado um conjunto específico de requisitos, eles podem ser organizados numa estrutura, onde as relações são de uma estrutura hierárquica, bem como, de uma estrutura de natureza transversal (Dahlstedt and Persson, 2005). Os requisitos de negócio de alto nível são gradualmente decompostos em requisitos de software mais detalhados, formando uma hierarquia. Além disso, pode haver relações estruturais entre requisitos em diferentes partes da hierarquia global. Pertencem a esta categoria os seguintes tipos de interdependência: Refined_to (refinado para) (Dahlstedt and Persson, 2005) um requisito de nível mais elevado é refinado por um número de requisitos mais específicos. Utiliza-se este tipo de dependência para descrever estruturas hierárquicas, onde requisitos mais detalhados estão relacionados com os seus requisitos de origem. 9

98 Estes requisitos fornecem mais explicações, detalhes ou esclarecimentos sobre os requisitos de origem. Os requisitos de origem podem, portanto, ser vistos como uma abstracção dos requisitos detalhados. Se um requisito detalhado é derivado de um requisito de nível mais elevado, mas não é um pré-requisito para esse requisito, então a relação é deste tipo de interdependência. Neste tipo de interdependência estão englobadas situações onde um requisito é elaborado por outro, onde um requisito mais detalhado é derivado de um requisito de nível superior, ou onde um ou vários requisitos são baseados num requisito de origem. Este tipo inclui também dependências em que um requisito foi dividido em várias partes, ou seja, vários requisitos mais simples são considerados como parte de um requisito fonte complexo. Outra situação que abrange é se um requisito formaliza outro ou se um requisito de nível superior é uma generalização de um ou vários requisitos mais detalhados. Todos estes tipos são utilizados para descrever algum tipo de relações hierárquicas, onde requisitos de nível superior são refinados em mais detalhe por vários requisitos mais detalhados. Exemplo:(Dahlstedt and Persson, 2005) Um requisito afirmando que O sistema deve suportar um acompanhamento dos pedidos do cliente depois da sua entrega (R1), poderia ser refinado pelos requisitos afirmando, por exemplo: -durante o acompanhamento deve ser possível comparar o custo de produção dos produtos relacionados com a encomenda fornecida ao cliente, com os orçamentos de produção para aqueles produtos (R2), e -o sistema deve facilitar a mudança do orçamento de produção quando está a fazer um acompanhamento dos produtos da encomenda do cliente (R3). Os dois requisitos (R2 e R3) são derivados do requisito (R1), pois, adicionam mais detalhes ás suas propriedades Change_to (Mudanças para) (Dahlstedt and Persson, 2005) se uma nova versão de um requisito é desenvolvida na qual substitui a antiga, então esse requisito muda para outro requisito, ou seja, para a sua nova versão. 10

99 Este tipo de interdependência descreve como um requisito evolui ao longo do tempo, uma vez que, permite relacionar as diferentes versões do requisito. Uma nova versão de um requisito pode ser desenvolvida por várias razões. Ela pode ser, por exemplo, o resultado de fazer o requisito mais compreensivo, mudar detalhes no requisito, ou expressa-lo mais formalmente. Exemplo: (Dahlstedt and Persson, 2005) O requisito Não deve demorar mais de 10 segundos a realizar uma pesquisa de informação de contacto pode ser mudado para uma nova versão Não deve demorar mais de 15 segundos a realizar uma pesquisa de informação de contacto. Na nova versão do requisito, pode-se verificar que foram mudados detalhes relativamente a primeira versão. Similar_ to (Similar a) (Dahlstedt and Persson, 2005) este tipo de interdependências descreve situações, em que um requisito é semelhante ou sobreposto com outro em termos de como ele é expressado ou em termos de uma ideia subjacente semelhante de que o sistema deverá ser capaz de executar. Pode ainda ser usada para descrever soluções semelhantes, das quais uma tem de ser seleccionada para ser parte do sistema. Este tipo pode portanto ser usado para descrever semelhanças tanto nos requisitos como nas suas possíveis soluções. Exemplo: (Dahlstedt and Persson, 2005) Os requisitos O sistema deverá suportar a gestão de itens de biblioteca e O sistema deverá fornecer meios para manusear livros e revistas na biblioteca são semelhantes, uma vez que, tanto os livros como as revistas podem ser considerados como itens de biblioteca. 4.2 Interdependências constritivas (constrain interdependencies) As interdependências constritivas descrevem como os requisitos podem constranger uns os outros (Dahlstedt and Persson, 2005), isto é, há requisitos que 11

100 apenas podem ser executados quando outros requisitos forem executados antes e requisitos em que a sua execução impede a execução de outros. Nesta categoria estão identificados 2 tipos de interdependências: Requires (Exigências) (Dahlstedt and Persson, 2005) a realização de um requisito depende da realização de outro requisito. Este tipo de interdependência descreve situações em que se um requisito esta a ser incluído no sistema, ele requer que outro requisito também seja incluído. Pode também ser usado para descrever relações hierárquicas entre dois requisitos de uma natureza mais forte que o tipo de interdependência Refined_to. O tipo Requires significa que um ou mais requisitos detalhados são necessários para realizar um requisito num nível mais elevado. O tipo Requires pode portanto ser visto como parte da categoria das Interdependências estruturais. Este tipo significa, que um requisito é um prérequisito ou uma pré-condição para outro. Assim sendo, os requisitos podem também ser usados para descrever uma interdependência temporal, onde um requisito necessita de ser implementado antes de outro requisito. Este tipo de interdependência pode então ser utilizado para descrever relações onde um requisito deve ser implementado a fim de executar outro requisito, mas também relações, onde um requisito tem um efeito positivo na realização de outro requisito. Exemplo:(Dahlstedt and Persson, 2005) Se o sistema deve ser capaz de incluir e acesso à web, uma conexão de rede é necessária. A realização do requisito 1 (o sistema deve ser capaz de incluir e acesso à Web) apenas acontece quando o requisito 2 (uma conexão de rede é necessária) for cumprido. Conflicts_with (Conflitos com) (Dahlstedt and Persson, 2005) um requisito está em conflito com outro requisito se aumentar a satisfação de um requisito diminui a satisfação de outro requisito, ou se eles não podem existir ao mesmo tempo. 12

101 Neste tipo de interdependência tanto são incluídas situações em que é impossível implementar ambos os requisitos como situações em que os requisitos têm uma influência negativa na realização uns dos outros. Exemplo: (Dahlstedt and Persson, 2005) Se um requisito declara que Todo o pessoal deve ser capaz de pesquisar informação sobre os produtos e clientes. e outro requisito declara que Apenas o pessoal com estado de segurança A deve ser capaz de pesquisar clientes classificados como militares. Estes dois requisitos contradizem-se um ao outro, e não podem ser satisfeitos simultaneamente. A realização de um requisito exclui a realização do outro. 4.3 Interdependências de custo/valor (cost/value interdependencies) As interdependências de custo/valor referem-se aos custos envolvidos na implementação de um requisito em relação ao valor que a realização desse requisito fornecerá ao cliente/utilizador afectado(dahlstedt and Persson, 2005). Nesta categoria temos dois tipos de interdependências: Increases/decreases_cost_of (Aumentar/diminuir o custo de) (Dahlstedt and Persson, 2005) se um requisito é escolhido para ser implementado então o custo de implementar outro requisito aumenta ou diminui. Esta interdependência é utilizada para referir requisitos que influenciam um pouco o custo de implementação de outros, por exemplo, fazendo mais cara ou mais barata a implementação de outros requisitos. Exemplo: (Dahlstedt and Persson, 2005) Se um requisito esta a declarar que nenhum tempo de resposta deve ser superior a 5 segundos, certamente aumentará o custo de implementar muitos outros requisitos. Increases/decreases_value_of (Aumentar/diminuir o valor de) se um requisito é escolhido para ser implementado então o valor para o cliente de outro 13

102 requisito aumenta ou diminui (Dahlstedt and Persson, 2005). Esta interdependência concentra-se no efeito que as relações entre os requisitos podem ter no valor do cliente afectado. Alguns requisitos podem influenciar positivamente no valor do cliente de outros requisitos, enquanto outros influenciam negativamente, por exemplo, por fazer funcionalidades mais complexas. Exemplo: (Dahlstedt and Persson, 2005) A satisfação do cliente de incluir uma agenda no telemóvel provavelmente aumentará, se for possível sincronizar essa agenda com a utilizada no PC. 5 Métodos para gerir as interdependência As interdependências de requisitos podem ser geridas através de tabelas de dependência e de softwares específicos para lidar com interdependências. Estes dois métodos facilitam a identificação das interdependências, assim como, a sua gestão. Com o uso destes métodos torna-se mais fácil e eficaz gerir as interdependências entre os requisitos. 5.1 Tabelas de dependência As tabelas de dependência mostram os relacionamentos entre os requisitos. As tabelas devem ser definidas com o número dos requisitos destacados nas linhas e nas colunas da tabela. Se um requisito for dependente de outro requisito, coloca-se um (X) nessa intersecção, indicando que esses requisitos dependem um do outro. Um exemplo simples para um sistema com 6 requisitos seria: Figura 3 Tabela de interdependência de requisitos (Kotonya and Sommerville, 1998) 14

103 No exemplo, R1 é dependente de R3 e R4; R2 é dependente de R5 e R6, etc. Se for proposta uma alteração no requisito R4, a leitura da coluna R4 aponta que R1 e R3 dependem de R4. Deve ser avaliado com isso o impacto em R1 e R3 com relação à alteração proposta a R4 (Kotonya and Sommerville, 1998). 5.2 Softwares para gerir dependências em requisitos Quando as diferentes relações entre os requisitos são identificadas é necessário ferramentas para ajudarem a armazenar e a gerir as interdependências. Existem alguns produtos no mercado especializados na gestão de requisitos. Estes produtos permitem gerir as interdependências entre os requisitos de forma automática tornando, assim o processo mais rápido e fácil. O Rational RequisitePro é uma ferramenta para gerir dependências que utiliza atributos de requisitos e rastreabilidade ( Rational Software Corporation). Permite criar e manter uma clara organização dos requisitos. Com esta ferramenta é possível agrupar os requisitos de acordo com os atributos definidos pelo utilizador como, por exemplo, função, prioridade, risco e custo. Além disso, é possível estabelecer relacionamentos hierárquicos que representam requisitos em grupos lógicos de pai-filho. Possibilita ainda criar um relacionamento de rastreabilidade entre dois requisitos que estabelece uma dependência entre eles. O software Almirante dá suporte ao processo de gestão de requisitos (Mayer and Chiarello, 2009). Esta ferramenta permite: o registo e a alteração dos requisitos levantados, mantendo o histórico das alterações; registar cada caso de uso relacionando-o aos respectivos requisitos, promovendo assim, a rastreabilidade dos requisitos; o registo e a alteração das iterações planeadas para o projecto; e rastreabilidade. O OSRMT Open Source Requirements Management Tool é uma ferramenta projectada para auxiliar na gestão de requisitos (Dourado, 2008). 15

104 As principais características desta ferramenta focam em permitir uma completa rastreabilidade do ciclo de vida de desenvolvimento de software em relação aos requisitos. Entre as funcionalidades da ferramenta, pode-se destacar: registo de autor, origem e motivo da necessidade de cada requisito; registo de casos de uso; registo do estado e origem de cada requisito, possibilitando a atribuição de categorias aos requisitos; definição de artefatos e entrada de dados (características, requisitos, código fonte, etc.); organização hierárquica e controlo de versão dos artefatos; rastreabilidade (através de gráficos que identificam todas as dependências entre requisitos); e geração de relatórios padronizados em formato PDF e HTML. O TRIC Tool for Requirements Inferencing and Consistency Checking é uma ferramenta para verificar consistências das relações entre os requisitos e para dedução de novas relações (Goknil et al., 2009). Suporta uma melhor compreensão das dependências entre os requisitos. A ferramenta possui entre outras, as seguintes características: gestão dos requisitos (permite acrescentar novos requisitos, actualizar e apagar os requisitos existentes); permite verificar resultados de inconsistências e deduzir novas relações; permite visualizar as relações entre os requisitos; analisar o impacto de mudanças nos requisitos; e importar/exportar mecanismos para outras ferramentas de gestão de requisitos. 6 Exemplo ilustrativo Nesta secção é apresentado um exemplo prático simples (Oliveira Filho et al., 2008), com três requisitos, que ilustra os passos utilizados pela gestão de requisitos para manter a rastreabilidade. Em seguida, perante uma solicitação de mudança nos requisitos, é discutido os passos necessários para realizar a análise de impacto. Ao longo deste exemplo será também focada a interdependência de requisitos. Os requisitos apresentados fazem parte da especificação de um sistema para administração de parques de diversões, que inclui emissão de bilhetes, controlo de acesso para cada brinquedo e distribuição de brindes, entre outras funcionalidades. 16

105 R1 O sistema deve emitir bilhetes de entrada para todos os brinquedos do parque. Em cada bilhete emitido devem ser impressos a idade do cliente, o brinquedo e o código de controlo do bilhete. A idade, o brinquedo e o código são obrigatórios; R2 O sistema liberta o acesso para cada brinquedo a partir do destravamento das suas respectivas alavancas. A alavanca não deve destravar, se a idade presente no bilhete for menor ou igual à idade mínima permitida para o brinquedo. Por exemplo, a montanha-russa tem a idade mínima fixada em 8 anos; R3 O sistema deve permitir promoções com entrega de brindes. O brinde deve ser entregue apenas a portadores de bilhetes cuja idade esteja entre 8 e 10 anos. Os requisitos R2 e o R3 dependem do R1, pois, estes dependem das informações contidas no bilhete (R1) para poderem ser executados. O requisito R2 utiliza idade e brinquedo, enquanto que o R3 utiliza apenas idade. A matriz de rastreabilidade deve tornar explícita esta dependência, relacionando estes requisitos. Para que a gestão de requisitos descubra esta relação de dependência de R2 e R3 sobre R1 (assumindo-se que R1 surgiu antes dos outros dois requisitos), é necessária a realização de uma investigação sobre a rastreabilidade dos requisitos. Se ocorrer a seguinte solicitação de mudança relacionada ao R1: Além da idade mínima de 8 anos, o sistema deveria considerar a idade máxima para acesso a alguns brinquedos, inclusive a montanha-russa. A idade máxima requerida deve ser de 80 anos. A gestão de requisitos precisa descobrir os requisitos afectados por esta solicitação de mudança. Para realizar esta análise, os requisitos R2 e R3 precisam de ser considerados, pois, eles dependem do R1. Uma vez que cada requisito dependente é facilmente encontrado na matriz de rastreabilidade, cada um deles deve ser investigado. Investigando assim, os demais artefatos que atendem cada requisito. A partir da análise, pode-se concluir que o requisito R2 será afectado, uma vez que, a idade máxima precisa ser considerada durante a libertação do acesso (e este não tem idade máxima). O requisito R3 não sofrerá impacto algum, pois, este já considera o limite máximo de 10 anos que está consistentemente dentro do limite máximo de 80 anos impostos pela restrição da emissão do bilhete. 17

106 Se for solicitada outra mudança para o mesmo requisito R1, que é: O brinquedo montanha-russa precisa de ter a sua idade mínima alterada para 11 anos. Tal como na primeira mudança, a gestão de requisitos deve seguir o processo de investigação sobre a rastreabilidade dos requisitos para descobrir se há impacto em algum requisito. Desta vez, o R3 será afectado, pois, como o limite máximo para entrega do brinde é de 10 anos e o novo limite mínimo para a montanharussa é de 11 anos, pessoas que comprarem bilhetes para este brinquedo não receberão brindes. Por outro lado, o R2 não sofre impacto algum, pois, este novo limite mínimo não inviabiliza o acesso ao brinquedo. Com este exemplo prático, é possível verificar que os requisitos não são independentes, pois, relacionam-se e dependem uns dos outros. Uma correcta identificação das interdependências entre os requisitos permite chegar a uma eficiente análise de impacto das mudanças que serão necessárias ter em conta. 7 Conclusão Este artigo apresentou diferentes aspectos relacionados com as interdependências em requisitos, procurando assim, apresentar uma visão das interdependências e das suas implicações para o processo de gestão de requisitos. Conclui-se com o mesmo que os requisitos não podem ser tratados como requisitos independentes, pois, eles relacionam-se e afectam uns os outros. As interdependências em requisitos são um aspecto muito importante e que deve ser bem gerido. As interdependências devem ser geridas de forma a identificar, armazenar e manter informações sobre como os requisitos se relacionam e afectam uns os outros. Ao longo dos projectos ocorrem mudanças nos requisitos, estas mudanças podem implicar varias alterações em outros requisitos através das interdependências pode-se identificar quais os requisitos que serão afectados por essas mudanças e que deverão ser renegociados. Assim sendo, as interdependências entre os requisitos devem ser identificadas correctamente num projecto, pois, uma falha na identificação das 18

107 interdependências pode provocar várias consequências, e até mesmo provocar o fracasso do projecto. Referências CAPPELLI, C. & SANTORO, F Modelagem de Processos e Engenharia de Requisitos - Gerência de Requisitos. CARLSHAMRE, P., SANDAHL, K., LINDVALL, M., REGNELL, B. & NATT OCH DAG, J An Industrial Survey of Requirements Interdependencies in Software Product Release Planning. Toronto, Canada: Proc. of the Fifth International Symposium on Requirements Engineering, August. COLARES, F. Requisitos para Detecção de Interdependência entre Requisitos de Software. DA SILVA, S. C Gerência de requisitos: A influência no ambiente de desenvolvimento de software. DAHLSTEDT, Å. G. & PERSSON, A. Requirements Interdependencies - Moulding the State of Research into a Research Agenda. Department of Computer Science, University of Skövde. DAHLSTEDT, Å. G. & PERSSON, A Requirements Interdependencies: State of the Art and Future Challenges. In: AURUM, A. & WOHLIN, C. (eds.) Engineering and Managing Software Requirements. Springer. DOURADO, A OSRMT Open Source Requirements Management Tool. GOKNIL, A., KURTEV, I., BERG, K. V. D. & VELDHUIS, J.-W Semantics of trace relations in requirements models for consistency checking and inferencing. Springer. GOTEL, O Contribution Structures for Requirements Traceability. University of London.: PhD Thesis, Department of Computing Imperial Collage of Science, Technology and Medicine. GOTEL, O. & FINKELSTEIN, A An Analysis of the Requirements Traceability Problem, Proc. of the 1st international Conference on Requirements Engineering. Colorado Springs, Colorado, USA. GREHAG, Å Requirements Management in a Life-Cycle Perspective - A Position Paper, Proc. of the Seventh International Workshop on Requirements Engineering: Foundation for Software Quality. Interlaken, Switzerland. JARKE, M Requirements Tracing, Communication of the ACM, 41(12). KOTONYA, G. & SOMMERVILLE, I Requirements Engineering Processes and Techniques. John Wiley & Sons. MACIASZEK, L. A Requirements Analysis and System Design Developing Information Systems with UML. Addison Wesley. MAYER, D. & CHIARELLO, M Guia para Gerenciamento de Requisitos-Metodologia CELEPAR. OLIVEIRA FILHO, A., MENDONÇA NETO, M. & CHAVEZ, C Em Busca de Agilidade na Análise de Impacto: O Artefato FIR. IEEE LATIN AMERICA TRANSACTIONS. POHL, K Process-Centered Requirements Engineering. John Wiley & Sons Inc. RAMESH, B Factors Influencing Requirements Traceability Practice, Communication of the ACM, 41(12). RAMESH, B. & EDWARDS, M Issues in the Development of a Requirements Traceability Model. San Diego, California, USA: Proc. of the IEEE International Symposium on Requirements Engineering. RAMESH, B. & JARKE, M Toward Reference Models for Requirements Traceability, IEEE Transactions on Software Engineering, 27(1). RAMESH, B., STUBBS, C., POWERS, T. & EDWARDS, M Requirements traceability: Theory and Practice, Annals of Software Engineering, 3. RATIONAL SOFTWARE CORPORATION. Mentor de Ferramentas: Gerenciamento de Dependências Usando o Rational RequisitePro [Online]. 19

108 REGNELL, B., PAECH, B., AURUM, A., WOHLIN, C., DUTOIT, A. & NATT OCH DAG, J Requirements Mean Decisions! Research issues for understanding and supporting decision-making in Requirements Engineering, First Swedish Conference on Software Engineering Research and Practice (SERP 01), October Ronneby, Sweden. ROBINSON, W. N., PAWLOWSKI, S. D. & VOLKOV, V Requirements Interaction Management, GSU CIS Working Paper 99-7, Department of Computer Information Systems, Georgia State of University, Atlanta. SAYÃO, M. & DO PRADO LEITE, J. C. S Rastreabilidade de requisitos. TORANZO, M., CASTRO, J. F. B. & MELLO, E Uma Proposta para Melhorar o Rastreamento de Requisitos. XEXÉO, G Modelagem de Sistemas de Informação: Da Análise de Requisitos ao Modelo de Interface. 20

109 Design Patterns: Creational Patterns Carlos Eduardo Ermida Santos Mestrado em Engenharia e Gestão de Sistemas de Informação, Universidade do Minho pg17282 Abstract: Este documento visa abordar o tópico de padrões Criacionais, pertencentes ao conjunto de Padrões de Design existentes. Contempla a forma como a utilização de padrões permite auxiliar no desenvolvimento de software para uma organização através da repetição de boas práticas anteriores, bem como apresentar os diversos tipos de padrões Criacionais e a forma como estes são compostos. Tenta-se ainda demonstrar como os diversos tipos de padrões Criacionais são utilizados para acelerar o desenvolvimento de um software bem como lhe aufere uma estrutura mais sólida do ponto de vista da sua concepção. São utilizados exemplos práticos, bem como alguns exemplos aplicados a problemas da vida real da autoria de Michael Duell. Tais questões são relevantes para a implementação mais eficaz e eficiente do software nas organizações, assim este tema assume um relevo importante na área das tecnologias de sistemas de informação. Keywords: Padrões de Design, Gang of Four, Padrão Criacional, Estruturação, Comportamento, Classes, Objectos, Abstract Factory Pattern, Factory Method Pattern, Builder Pattern, Prototype Pattern, Singleton Pattern Introdução Hoje em dia, é exigido aos programadores de software cada vez mais robustez, flexibilidade e eficácia no software. Para tal desenvolveram-se os Padrões de Software de modo a criar uma forma de desenvolver o Software que responda a essas exigências. Para tal reuniram-se as experiências similares e repetidas, que de facto pudessem estabelecer um padrão. (Gamma et al. 1998) 1

110 Assim, os padrões não são inventados: são extraídos do processo de design de sistemas existentes com a expectativa de encontrar formas de resolver problemas ocorridos em diferentes domínios. (Lauder et al. 1998) Devido às diferentes linguagens e abordagens relativas ao desenvolvimento de software, é de esperar que o número de padrões seja elevado em termos de quantidades. Portanto estes devem ser agrupados consoante as áreas em que se aplicam de modo a criar um catálogo, que possa servir como base para a identificação e resolução de problemas para o ciclo de vida do software. Conceitos Definição de padrão de Design no contexto de Sistemas de Informação Um padrão de design é uma forma de reutilizar designs e arquitecturas que obtiveram sucesso no desenvolvimento de software. Deste modo facilita-se o acesso de desenvolvedores a novos sistemas através da utilização de métodos eficazes. (Gamma et al. 1998) Os padrões tendem a seguir três dimensões de forma a situar qual o padrão a aplicar consoante a fase do projecto. Essas três dimensões são a Disciplina, a Etapa e o Nível, sendo a Disciplina relativa ao tipo de área de Concepção de um software, a Etapa relativa às etapas necessárias para elaborar um software e o Nível relativo ao nível no modelo do OMG (Object Management Group). Ilustração 1 - Modelo OMG de arquitectura (Group) 2

111 Os padrões de Design diferem dos demais dado que são aplicáveis a ambas as dimensões referidas anteriormente, dado serem utilizados tanto em diferentes etapas como disciplinas. (Azevedo et al.) Estrutura de um padrão Um padrão é constituído por quatro elementos: o seu nome, a problemática que abrange, a solução e as consequências que advém da implementação desta. O nome deve ser de apenas uma ou duas palavras por modo a ser facilmente identificável pelos utilizadores do padrão, servindo assim como forma de manter um vocabulário simples e eficaz. Deve assim ter em conta o problema, a solução e as consequências e efectuar a descrição geral destes elementos. O problema descreve os problemas em que o padrão se aplica bem como o seu contexto. Existe uma série de possibilidades em como este é descrito: pode incluir formas de como representar um algoritmo como um objecto e pode descrever estruturas de classe ou de objectos que são inflexíveis no design. Pode ainda exibir uma lista de condições que identifiquem se o padrão é aplicável no contexto. A solução não é tida como específica para o problema em concreto enfrentado pelo desenvolvedor, dado que este variará entre situações. Antes, apresenta-se de uma forma abstracta que pode servir de base em diversas situações e com um conjunto de elementos que permitem resolver as mesmas. As consequências são os resultados e escolhas que se esperam advir da aplicação do padrão. São críticas para se poder ter em conta soluções alternativas e a relação custo/benefícios resultante da aplicação à situação. Nas consequências incluem-se o impacto na flexibilidade, extensibilidade e portabilidade do sistema, dado que estas características são essenciais à necessidade de reutilização do padrão. (Gamma et al. 1998) Padrão Criacional Existem três tipos de propósitos para os padrões de design orientados a classes e objectos: Criação, Estruturação e Comportamento. Dentro destes são identificados 23 tipos de subpadrões pelo Gang of Four. Relativamente aos Criacionais temos cinco de acordo com o GoF: um de classe e quatro de objectos. O de classe é designado de Factory Method, enquanto os de 3

112 objectos são designados de Abstract Factory, Builder, Prototype e Singleton. (Gamma et al. 1998) Padrões Criacionais Os Padrões Criacionais abstraem o processo de instanciação, ou seja, ajudam a conceber o sistema de forma independente à criação, composição e representação dos objectos desse sistema. (Gamma et al. 1998) Estes padrões dão poder ao design do software, ao possibilitar que a instanciação possa afectar o comportamento de uma classe simultaneamente. Exemplos deste género, serão por exemplo a compatibilidade de aplicações Web com determinados browsers, através da criação de controlos compatíveis com esse browser. (Horner 2006) Michael Duell em colaboração com outros autores, apresenta exemplos da vida real para ilustrar a aplicação destes padrões assim inclui-se na descrição de cada padrão Criacional, um destes exemplos que o demonstram. (Duell et al.) Abstract Factory (Fábrica Abstracta) Ilustração 2 Padrão Abstract Factory (http://www.oodesign.com/) Este padrão fornece uma interface para construção de objectos com auxílio de métodos de classes de uma classe criadora. Funciona através do mecanismo de herança, permitindo que classes filhas decidam as operações a realizar com os métodos herdados da classe-mãe. (Herrmann et al. 2000) 4

113 Motivação A necessidade de ter um conjunto de ferramentas de interface do utilizador que permite um utilizador personalizar essa mesma interface. Assim, uma aplicação não deve ter um visual definido por default. O problema resolve-se com uma interface que possibilite a uma classe, a criação de cada tipo de elementos de uma forma abstracta. Os clientes podem utilizar estas interfaces para obter os elementos que desejam mas nunca terão noção das classes que utilizam para o efeito em si. (Gamma et al. 1998) Ilustração 3 Motivação para o Abstract Factory de acordo com o GoF Basicamente, este padrão define um Framework que produz objectos que seguem um padrão geral e ao correr esta fábrica é emparelhada com qualquer fábrica concreta para produzir objectos que seguem o padrão de um país específico. Assim, é uma fábrica cujos produtos são outras fábricas. (http://www.oodesign.com/) Utilização Este padrão é utilizado onde existe a necessidade de não ligar um cliente à implementação de uma classe que crie outras classes. Assim o cliente pode comprometer-se com uma interface e evitar ficar associado a uma implementação específica de uma classe. A razão para evitar essa associação é permitir que o cliente possa alternar entre classes. (Horner 2006) Exemplos na área do software: java.awt.toolkit, javax.swing.lookandfeel, java.sql.connection. (http://www.oodesign.com/) 5

114 Exemplo de Duell Uma máquina de autocolantes automóveis pode ser utilizada para colar vários autocolantes num veículo desde que esta não seja dedicada apenas a uma parte específica deste. (Duell) Ilustração 4 - Exemplo de Abstract Factory segundo Duell Factory Method (Método Fábrica) Ilustração 5 Padrão Factory Method (http://www.oodesign.com/) O Padrão Factory Method é utilizado para permitir um elo mais permissivo entre uma classe criadora e uma classe que a instancie. Permite ainda que a classe criadora defira a instanciação para uma subclasse, de forma a permitir a classe criadora trabalhar com novos tipos de subclasses. (Cinneide et al. 1999) 6

115 Este padrão não necessita ser inicializado porém necessita de ter subclasses. (http://sourcemaking.com/design_patterns/prototype) Motivação Os frameworks utilizam classes abstractas para definir e manter relações entre objectos. Estes são muitas vezes responsáveis pela própria criação desses objectos. Um framework para aplicações pode apresentar diversos documentos ao utilizador. As classes de Application e Document (Aplicação e Documento, respectivamente) são abstracções chave para esse Framework. Para criar uma aplicação de desenho, definem-se as classes DrawingApplication e DrawingDocument (desenhar aplicação e desenhar documento, respectivamente). A classe de Aplicação é responsável por gerir Documentos e criá-los conforme for necessário. Como a subclasse Documento a instanciar depende de uma aplicação específica, a classe Aplicação não consegue identificar correctamente a subclasse de Documento a instanciar pois apenas sabe quando um novo documento deve ser criado e não que tipo deve criar. Isto significa que este Framework deve instanciar classes mas não pode pois só tem conhecimento de classes abstractas. O padrão Factory Method resolve este problemas encapsulando o conhecimento de qual subclasse de Documento deve ser criada e transpõe o mesmo para fora do framework.(gamma et al. 1998) Ilustração 6 - Motivação para o Factory Method de acordo com o GoF 7

116 Este padrão define a interface para criar um objecto mas deixa a escolha do tipo desse objecto às subclasses com a criação a ocorrer durante o tempo que a aplicação corre. (http://www.oodesign.com/) Utilização Este padrão é utilizado quando o código que cria o objecto não consegue determinar a classe do novo objecto pois não recebe a informação de que classe deve criar. Em Java, este padrão é utilizado para implementar métodos estáticos ou objectos do padrão Abstract Factory. (Bucanek 2009a) Um bom exemplo é os XML.Parsers, dado que estes são componentes que permitem a interpretação de vários elementos do XML. (http://www.oodesign.com/) Exemplo de Duell A injecção num molde de um brinquedo plástico exemplifica este padrão. Os fabricantes destes brinquedos processam materiais para moldes de plástico e depois injectam o plástico nos moldes com as aparências desejadas. A classe resultante é determinada pelo molde. (Duell) Ilustração 7 - Exemplo de Factory Method segundo Duell 8

117 Builder (Construtor) Ilustração 8 - Padrão Builder (http://www.oodesign.com/) O Padrão Construtor separa a construção de um objecto complexo da sua representação, para que o processo de construção possa criar diferentes representações. (Chantarasathaporn et al. 2006) (Gamma et al. 1998) Motivação Um leitor de documentos RTF (Rich Text Format) deve ser capaz de converter esse formato em vários outros formatos de texto, por exemplo ASCII. Porém o número de conversões é open-ended, ou seja, não se limita a converter num formato sim, noutro não. Assim, deve ser possível adicionar uma nova conversão sem modificar o leitor. A solução passa por configurar a classe RTFReader (leitor RTF) com um objecto que converta RTF para outros formatos (TextConverter). Deste modo, cada vez que a classe RTFReader reconhecer que deve converter texto deve enviar um pedido a TextConverter para conversão desse texto. (Gamma et al. 1998) Ilustração 9 - Motivação para o Builder de acordo com o GoF 9

118 Este padrão permite assim a um objecto construir um objecto complexo através da especificação do seu conteúdo e tipo, sem nunca ter acesso a detalhes relativos à representação do objecto. (http://www.oodesign.com/) Utilização A classe Builder define uma operação cuja criação pode ser requisitada por um director pode requisitar, sendo que por defeito as operações não realizam nada. Uma subclasse Builder sobrepõe-se às operações para as componentes que tem de criar. (Gamma et al. 1998) Assim permite um maior controlo sobre o processo de construção de objectos. Um bom exemplo é os conversores de texto como demonstrado. (http://www.oodesign.com/) Exemplo de Duell A construção das refeições de crianças por parte de cadeias de fast food segue este padrão. Estas refeições são compostas por vários elementos (bebidas, batatas fritas, refeição principal e brinquedos, por exemplo). Estas refeições podem variar em conteúdo porém o seu processo de construção é o mesmo quando um cliente a pede. O empregado de balcão pede à equipa para montar o item principal, o secundário e o brinquedo. Estes itens são colocados num saco e a bebida é colocada num copo e mantida fora do saco. (Duell) Ilustração 10 - Exemplo de Builder segundo Duell 10

119 Prototype (Protótipo) Ilustração 11 - Padrão Prototype (http://www.oodesign.com/) Especifica os tipos de objectos a criar, utilizando instâncias, criando novos objectos através da replicação do protótipo. (Gamma et al. 1998) Este padrão não precisa de criar subclasses mas precisa de uma operação de inicialização. (http://sourcemaking.com/design_patterns/prototype) Motivação Para construir um editor de música através de editores gráficos e objectos que representam notas e afins, o framework desse editor deve ter uma palete de ferramentas para adicionar esses objectos à música. O framework deve ainda predefinir a subclasse que determina a ferramenta gráfica que cria as instâncias dos objectos gráficos e os adiciona ao documento. Porém essa ferramenta não sabe criar instâncias das classes da música para adicionar ao documento porque os objectos pertencem à aplicação e a ferramenta ao framework. A solução é fazer a ferramenta criar um novo gráfico copiando uma instância da subclasse Graphic (Gráfico). Este será o protótipo que definirá os parâmetros da ferramenta. (Gamma et al. 1998) 11

120 Ilustração 12 - Motivação para o Prototype de acordo com o GoF O padrão de Prototype permite que um objecto crie objectos de acordo com o necessário sem nunca ser necessário saber a classe destes ou como criá-los. Diferencia-se do Factory Method por nunca conter mais de um objecto. (http://www.oodesign.com/) Utilização O padrão de Protótipo é útil em linguagens estáticas como C++, onde as classes não são simultaneamente objectos. (Gamma et al. 1998) O padrão é utilizado para clonar processos de criação de objectos após especificar quais os tipos de objectos pretendidos. (http://www.oodesign.com/) Exemplo de Duell A divisão por mitose de uma célula, da qual resultam duas células idênticas é um exemplo de um protótipo que toma um papel activo na sua replicação. A divisão da célula representa uma clonagem da mesma. (Duell) Ilustração 13 - Exemplo de Prototype segundo Duell 12

121 Singleton Ilustração 14 - Padrão Singleton (http://www.oodesign.com/) O propósito do padrão Singleton é garantir que cada classe apenas possui uma instância ao mesmo tempo que essa instância é reutilizável. Tal é atingido através do armazenamento de uma variável estática nos atributos da classe. Assim, para se verificar que a implementação deste padrão é adequada, devemos ter em conta se as novas instâncias de classes apenas contém variáveis estáticas. (Stencel et al. 2008) Motivação É importante que algumas classes tenham apenas uma instância. Um exemplo é a existência de várias impressoras mas deve apenas existir um spooler para essas impressoras. Para tal, cria-se uma classe responsável por monitorizar a sua única instância. A classe deve assegurar que mais nenhuma instância é criada e deve fornecer um método de aceder à única instância. (Gamma et al. 1998) Este padrão envolve apenas uma classe, responsável pela sua própria instanciação ao mesmo tempo que assegura que apenas cria uma instância e fornece acesso global a essa instância sem a necessidade de utilizar o construtor da classe em cada uso. (http://www.oodesign.com/) Utilização O padrão Singleton deve ser utilizado para assegurar que apenas uma instância de uma classe é criada e quando esta está disponível por todo o código. Em ambientes multithread (tais como processadores com mais de um núcleo de 13

122 processamento), deve-se ter atenção ao facto de vários threads acederem aos mesmos recursos através do mesmo objecto Singleton. Assim este padrão é utilizado para classes Logger (de acesso a um sistema), classes de configuração e acesso a recursos em modo partilhado. (Bucanek 2009b) Porém o Singleton possui várias variações quanto à forma de implementação, podendo estas serem combinadas dando origem a novas variações: - Eager Instantiation: a instância é criada e atribuída a um atributo estático. - Lazy Instantiation: um método de acesso verifica se a instância está construída e em caso negativo, cria a instância. - Replaceable Instance: A instância deve poder ser substituída por outra instância. Por exemplo, um utilizador deve poder alterar a aparência de uma aplicação através da configuração desta. - Subclassed Singleton: Uma classe Singleton deve poder ter subclasses de forma a poder ser alterado o comportamento de um Singleton. - Delegated Construction: uma classe singleton pode delegar a contrução da sua instância a outro método ou classe. - Different Placeholder: A classe Singleton não deve estar dependente da localização da variável estática desta. - Different Access Point: Uma instância Singleton deve poder ser gerida e acessida via outra classe. - Limiton: tem como intenção assegurar que uma classe tem um número limitado de instâncias. Exemplo de Duell Um exemplo de uma classe Singleton é a da figura de um Presidente de um país: como não pode existir mais de um, a classe apenas deve possibilitar produzir um objecto Presidente. (Duell) Ilustração 15 - Exemplo de Singleton segundo Duell 14

123 Considerações finais É possível observar que as especificações de cada um dos padrões Criacionais tornam estes possíveis de se combinar para acelerar o desenvolvimento do software. Por exemplo a utilização de o padrão Prototype e o Abstract Factory permitem replicar classes que permitem criar subclasses para um desenvolvimento mais rápido de um sistema que utilize linguagens orientadas a objectos. Com os exemplos encontrados acerca da utilidade destes padrões é possível observar o seu valor para um desenvolvimento mais rápido e que evite erros básicos de programação, sendo esse valor essencial para as organizações que necessitem desenvolver diversos softwares para uma plenitude de clientes. Os padrões Criacionais são assim uma forma viável de agilizar o desenvolvimento de aplicações por parte de uma organização e desta viabilidade deve ser tirado proveito. Referências Bibliográficas Source Making, "SourceMaking." Azevedo, S., Machado, R.J., Bragança, A., and Ribeiro, H. "Systematic Use of Software Development Patterns through a Multilevel and Multistage Classification "). Bucanek, J. "Factory Pattern," in: Learn Objective-C for Java Developers, Apress, 2009a, pp Bucanek, J. "Singleton Pattern," in: Learn Objective-C for Java Developers, Apress, 2009b, pp Chantarasathaporn, K., and Srisa-an, C. "Energy conscious factory method design pattern for mobile devices with C\# and intermediate language," in: Proceedings of the 3rd international conference on Mobile technology, applications \& systems, ACM, Bangkok, Thailand, 2006, p. 29. Cinneide, M.O., and Nixon, P. "A methodology for the automated introduction of design patterns," Software Maintenance, (ICSM '99) Proceedings. IEEE International Conference on, 1999, pp Duell, M. "Non-Software Examples of Software Design Patterns." Duell, M., Goodsen, J., and Rising, L. "Non-Software Examples of Software Design Patterns." Gamma, E., Helm, R., Johnson, R., and Vlissides, J.M. "Design Patterns CD: Elements of Reusable Object-Oriented Software," Addison-Wesley Professional, Group, O.M. "http://www.omg.org." Herrmann, A., and Schöning, T. "Standard Telemetry Processing - an object oriented approach using Software Design Patterns," Aerospace Science and Technology (4:4) 2000, pp Horner, M. "Creational Patterns," in: Pro.NET 2.0 Code and Design Standards in C#, Apress, 2006, pp

124 "SourceMaking." O.-. "Design Patterns." Lauder, A., and Kent, S. "Precise visual specification of design patterns," in: ECOOP 98 Object-Oriented Programming, E. Jul (ed.), Springer Berlin / Heidelberg, 1998, pp Stencel, K., and Węgrzynowicz, P. "Implementation Variants of the Singleton Design Pattern," in: On the Move to Meaningful Internet Systems: OTM 2008 Workshops, R. Meersman, Z. Tari and P. Herrero (eds.), Springer Berlin / Heidelberg, 2008, pp

125 Ontologias Cristina Pereira Análise e Concepção de Sistemas de Informação Mestrado em Engenharia e Gestão de Sistemas de Informação Universidade do Minho, Campus de Azurém, Guimarães Abstract Ontology has become a very useful tool in Information Systems. The concept has been presented like a new category of new ways of seeing and facing new organizations and the way we are supposed to work and interact with them. In this article, there are some ontology definitions that, as time passes by, were growing in consistency, based in many referred authors. There is also described some ways of ontology construction, components and characteristics. Finally, there is also a small approach to the Emerging Ontology concept and how it works. Palavras-chave: Ontologias, Sistemas de Informação, Ontologias Emergentes,. 1 Introdução Este artigo apresenta um conjunto de ideias resultantes de pesquisas realizadas no âmbito da temática de Ontologias a decorrer ao abrigo do programa lectivo da unidade curricular de Análise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão de Sistemas de Informação da Universidade do Minho e pretende abordar alguns temas ligados às ontologias que tem sido um tema que se tem desenvolvido cada vez mais e tem feito parte dos Sistemas de Informação emergentes. Pelo artigo encontram-se inicialmente várias definições do conceito que se foram desenvolvendo e amadurecendo ao longo dos anos baseados sempre nos autores e mantendo as suas referências e citações. Foi também de levar em conta a forma como as ontologias são construídas, suas componentes de funcionamento e características que delas fazem parte e que as tornam úteis e funcionais para os sistemas em que são implementadas. Abrangendo também um 1

126 pouco as ontologias que estão em crescimento e numa perspectiva rápida de análise, tentou-se descrever o que são as ontologias emergentes e suas características, aceitando que são impulsionadoras de conhecimento futuro na área ontológica. 2 Definição de Ontologia Uma ontologia é a especificação da conceptualização ou um modelo abstracto para alguns fenómenos no mundo real (Kuzniarz and Staron). A própria palavra Ontologia foi retirada da Filosofia que se define como sendo a explicação sistemática do ser, embora nos últimos tempos tenha sido uma palavra muito importante para a Engenharia do Conhecimento. (Corcho et al., 2002) Uns tempos mais tarde, Heflin diz que a Ontologia define os termos usados para descrever e representar uma área do conhecimento, (Heflin 2003) e continua a definir ontologias dizendo que são utilizadas por pessoas, bases de dados e aplicações que lêem e partilham informação e que incluem definições utilizáveis por computadores. Um ano depois, surge a definição de que a criação de ontologias permite a definição de classes hierárquicas, propriedades de objectos e regras de relação. Utilizar este conhecimento é possível para representar a semântica de objectos, associá-los a documentos legais e também para fazer referencias sobre eles (Saias and Quaresma, 2004). Ramalho, no mesmo ano diz que as ontologias são novas categorias de instrumentos de representação que incorporam novas possibilidades aos processos de gestão de recursos (Ramalho, Ramalho, 2006) e desta forma possibilitam novas formas de representação facilitando a aplicação das ontologias em qualquer sistema tornando-o capaz de se modelar perante qualquer organização. Calero, acrescenta à definição de ontologia que a engenharia ontológica refere-se ao conjunto de actividades ligadas ao desenvolvimento de ontologias, ciclo de vida de uma ontologia, princípios, métodos e metodologias para a sua construção e o conjunto de linguagens que as suportam (Calero et al., 2006). Sanches-Quadrado, passado mais um ano, diz que existe também um esforço para adaptar a definição de ontologia aos sistemas já desenvolvidos anteriormente (Sanchez-Quadrado et al., 2007) o que leva a que as ontologias sejam bastante 2

127 abrangentes quando relacionados com as diferentes áreas de conhecimento. Já em 2008, Basso defende que as ontologias são uma forma de organização de informação em que se pode adicionar propriedades aos atributos e ajudam a definir diversos tipos de relacionamentos. Desta forma são então um conhecimento estruturado em que os seus componentes são modelados em forma de grafo ou rede (Basso, 2008).. Guizzardi profere ainda que desde o final dos anos sessenta, tem-se reconhecido ontologias como um instrumento conceitual bastante útil na Ciência da Computação, principalmente nas áreas de modelagem de dados e Inteligência Artificial. Outro conceito interessante do mesmo autor prende-se com as Ontologias de Fundamentação (Foundational ontologies) que são sistemas de categorias bem fundamentados e independentes do domínio para que foram utilizados melhorando a qualidade de linguagens e modelação de modelos conceituais (Guizzardi and Guizzardi, 2008). Também se diz que as ontologias consistem em formas de melhorar as possibilidades de inferência (Basso, 2008)para que permitam que um recurso seja colocado na Web no seu próprio contexto informacional de forma semiautomática através de relações semânticas sendo que o único problema que se coloca é a rigidez na criação de novas categorias (Basso, 2008). (Ramalho, 2006) refere ainda que uma ontologia é como um artefacto tecnológico que descreve um modelo conceitual de um determinado domínio numa linguagem lógica e formal. Ontologias são utilizadas para diferentes fins e aplicadas em diversos sistemas sendo uma ferramenta de trabalho com capacidade de intrusão e entrelaçamento de ideias e diferentes concepções nos sistemas. Para além de permitirem um vocabulário de fácil encaixe no processamento automático, são úteis para a troca de informação (Junior et al., 2009). Para o efeito, existem alguns mecanismos de interoperabilidade de ontologias: Combinação (Noy and Musen, 2003), Mapeamento (Silva, 2004), Alinhamento (Felicíssimo, 2004) e Integração (Farquhar et al., 1997). O mapeamento de ontologias é o resultado de uma estrutura formal, com expressões que ligam uma ontologia a outra. Este tipo de mapeamento poderá ser utilizado também para as transferências de instâncias de dados e esquemas de integração. O alinhamento 3

128 mantém as ontologias originais mas acresce ligações indicando quais os termos equivalentes, permitindo a sua interacção. A integração de ontologias possui três significados diferentes: o da Combinação anteriormente referido, o que se baseia na construção de uma aplicação a partir de uma ou mais ontologias e o que permite uma nova ontologia reutilizando conceitos descritos anteriormente através do cruzamento de outras ontologias (Junior et al., 2009). Mais recentemente, Ontologia é definida como existindo dois sentidos da palavra (Catarino and Baptista, 2010): Ontologia como campo de estudo da Filosofia e Ontologia como uma tecnologia para cientistas da computação e da informação. Uma Ontologia para as ciências da Computação e Informação é a especificação de uma conceitualização que é um conjunto de ideias, conceitos, relações ou outras abstracções que compõem o domínio de um modelo ou discurso. Uma Ontologia define um vocabulário representacional para a conceitualização, e especifica restrições no uso deste vocabulário de forma que os factos sobre um determinado domínio podem ser compartilhados, comunicados, debatidos. Ontologias têm vindo a ficar cada vez mais populares num cada vez maior alcance de aplicações e têm vindo a mudar-se do conhecimento académico para projectos comerciais. As ontologias iniciais eram primariamente utilizadas como suplementos de navegação (Yahoo, Lycos). Actualmente vemos ontologias muito mais complexas que são utilizadas em diversas aplicações desde mecanismos inteligentes a agentes inteligentes. O aumento destes esforços para o desenvolvimento de ontologias trouxe uma necessidade maior de standardização e a necessidade de fornecer interoperabilidade entre múltiplas ontologias distribuídas (Orgun et al.). 4

129 3 Ontologias: construção, componentes e características O termo Ontologia ainda não possui um significado consensualizado e o autor García-marco defende que a expansão de termos como ontologias e metadados na área da Ciência da Informação constitui a ponta do iceberg de um processo de reconfiguração disciplinar, como resultado da integração de diversas ciências (García-Marco, 2007), representado na figura seguinte: Figura 1- La ecología de las disciplinas ontológicas ((García-Marco, 2007)) Um pouco mais de perto, conseguimos identificar as ciências da linguística, filosofia, computação e ciência da informação. A ciência linguística está ligada à semântica e a computação à inteligência artificial. Ambas a filosofia e a linguística necessitam de ciências cognitivas e a computação e a filosofia dependem das matemáticas. A ciência da informação e a computação utilizam a teoria de sistemas. Consegue-se verificar que todas elas possuem em conjunto vários tipos de representações: linguística, filosófica e do conhecimento. 5

130 Para que precisamos de ontologias? (Ferreira, 2008) Ontologias promovem a partilha de conhecimento comum da informação estruturada entre os sistemas ou grupos de pessoas. Permitem também a separação clara do domínio do conhecimento. Nuno ferreira, defende ainda que as ontologias formais são criadas, porque quando escolhemos representar algo numa ontologia, estamos a tomar decisões de design. Ele mesmo propõe um conjunto de critérios para servirem de guia e avaliação de designs de ontologias sendo estes a claridade, coerência, extensibilidade, viés de codificação mínima e compromisso ontológico mínimo. Existem ainda alguns recursos que as ontologias proporcionam (Gašević et al., 2006): Vocabulary vocabulário controlado, relativo aos termos da área de negócio Taxonomy categorização hierárquica ou classificação das entidades consiante o seu domínio. Content theory as ontologias vão além da identificação das classes, relações e associações, proporcionando a informação de uma forma elaborada, utilizando linguagens de especificação ontológica. Partilha de conhecimento e reutilização para alem de proporcionar a descrição e relação entre conceitos, as ontologias promovem também a partilha sobre os agentes e as aplicações. Uma ontologia é constituída por duas partes independentes: a primeira parte inicial, contém informação sobre a estrutura do conhecimento e a segunda parte contém o verdadeiro conhecimento (Kuzniarz and Staron). Quando se pensa em construir uma ontologia, deve-se ter em atenção vários pontos relacionados com as metodologias que serão utilizadas para que esta se enquadro no sistema a ser implementada. (Corcho et al., 2002) defendem que essa atenção deve recair sobre as metodologias e métodos que se podem utilizar para a construção de ontologias, sendo elas: Construídas do zero ou reutilizando as que já existem; Que ferramenta apoia o desenvolvimento do processo de criação; Se a ferramenta possui algum mecanismo de inferência ou mesmo se possui algum tipo de tradutor para linguagens ontológicas de diferentes formatos; 6

131 Que linguagem deve ser utilizada para implementar uma ontologia; Que mecanismos de inferência estão ligados à ontologia; Existe alguma ferramenta de desenvolvimento de ontologias capaz de suportar a linguagem? Se a linguagem utilizada é compatível para a troca de informação entre diferentes aplicações; Se a linguagem é compatível com outras linguagens utilizadas para representar conhecimento e informação na Web? Estes e outros aspectos devem ser cuidadosamente analisados para que a ontologia a ser criada satisfaça todos os requisitos para que seja formalmente capaz de se encaixar no sistema. O professor Rogério Sá Ramalho (Ramalho) defende que uma característica das ontologias é o facto de possibilitarem a representação de informação genérica e também informação concreta. Perante estes dois aspectos pode descrever-se os seguintes componentes de uma ontologia: Classes agrupam determinados elementos consoante a sua similaridade para que formem subclasses; Propriedades características, adjectivos e/ou qualidades das classes; Relacionamentos relações entre classes da mesma hierarquia ou pertencentes a outra, que descrevem as relações existentes; Valores valores das propriedades; Instâncias classes que têm valores atribuídos; Regras enunciados lógicos que fornecem informações que podem não ter sido atribuídas inicialmente, mas que podem estar implícitas na estrutura da ontologia, dependendo do seu objectivo. Segundo o que Heflin defende (Heflin 2003), as ontologias têm sido utilizadas para a descrição de artefactos com diferentes níveis estruturais. Defende também que as ontologias normalmente expressam-se numa linguagem lógica para que quando detalhadas, precisas, consistentes e com sentido possam ser construídas entre classes, propriedades e relações. Representam a semântica de documentos e permitem que esta possa ser utilizada por aplicações Web e agentes inteligentes. Ontologias podem ser também utilizadas para melhorar aplicações baseadas na Web. Para a construção de ontologias, existem algumas ferramentas que conferem algumas propriedades gráficas, dispensando o conhecimento de linguagens 7

132 específicas (Catarino and Baptista, 2010): Protégé, WebODE, OntoEdit e Altova Semantic Works. Para a construção de Ontologias, Guarino (Guarino, 1998) defende que estas sejam construídas segundo o nível de generalidade tal como retrata a figura seguinte: Figura 2 - Tipos de Ontologias segundo o seu Nível de Dependência (Guarino, 1998) Embora tenham existido algumas propostas para diferentes formas de construção de ontologias, os modelos apresentados ainda não demonstravam um processo estruturado para que pudesse suportar a construção de ontologias perante uma visão de engenharia. Guarino (Guarino, 1998) apresenta algumas orientações para a sua realização: Identificação de propósito e especificação de requisitos identificar o seu propósito e os resultados esperados; Captura da Ontologia etapa fulcral em que o objectivo passa por identificar os conceitos e relações e organizá-los. Formalização da Ontologia nesta etapa será necessário identificar a linguagem a ser utilizada. Inicialmente qualquer linguagem se enquadrará, mas na prática apenas algumas se encaixam. Integração com ontologias Existentes durante os processos anteriormente referidos, poderá surgir a necessidade de integrar a ontologia em questão com outras já existentes. 8

133 Avaliação avaliar a ontologia para que se perceba se satisfaz todos os requisitos inicialmente estabelecidos. Documentação documentar toda a construção da ontologia e seu desenvolvimento. Figura 3 - Processo de Desenvolvimento de Ontologia (Falbo et al., 2002)) Ludwick e Miroslaw (Kuzniarz and Staron) defendem que a estrutura é definida pelas classes ontológicas que descrevem conceitos do mundo real, propriedades das classes, relações entre classes e informação semântica, que junta, descreve as instâncias das classes. As classes podem ter propriedades que são expressas por outra classe e propriedades simples, que são propriedades que podem ser referidas sem referir outras classes. São equivalentes a conceitos, atributos de conceitos e associações entre conceitos. As ontologias podem ser expressas em várias linguagens, embora o standard crescente seja o DAML+OIL, baseado XML. A linguagem foi desenhada para ser uma ferramenta independente e capaz de expressar todos os elementos que constituem a ontologia enquanto outros formatos baseados em XML são insuficientes na transmissão da informação contida nas ontologias. Tipicamente, o processo de constituição do Domain Model é feito manualmente. Várias técnicas são referidas no sentido de tentar ajudar na construção do Domain Model mas todas elas têm uma desvantagem por demorarem muito tempo e também por necessitar de alguém especializado. Uma alternativa poderia ser a procura de uma fonte que previamente classificada, estruturada e validada, poderá 9

134 ser automaticamente processada para obter a informação necessária ao Domain model. Um bom candidato será, então, a ontologia. O processo de construção do domain model de forma manual é representado na figura 3. Figura 4 - Manual domain model constructing from ontology ((Kuzniarz and Staron)) O system analyst investiga o mundo real e produz o Domain Model. Para que o possa analisar, tem de processar o conhecimento específico ou consultar um perito. Em muitos dos casos a descrição do domínio já se encontra sob a forma de uma ontologia. Para que este possa utilizar o conhecimento da ontologia, o system analyst terá também de conseguir entender a estrutura do conhecimento em ontologias e os elementos utilizados para as definir. Desta forma é necessária assistência para dispensar o system analyst de gerir a ontologia e o conhecimento contido na ontologia (figura 4). Figura 5 - Automatic initial domain model construction in the context of domain modeling ((Kuzniarz and Staron)) 10

135 A vantagem desta aquisição é que liberta o system analyst dos formatos de ontologias e ao mesmo tempo permite uma forma de criar uma nova versão do domain model, que será consistente com o conhecimento analisado pelos knowledge engineers (Kuzniarz and Staron). Relativamente aos tipos de ontologias, podemos classificá-las de diferentes formas. De acordo com Guarino (Guarino, 1998), ele considera que existem: High-level ontologies descrevem conceitos gerais (ex. espaço, tempo, material, objecto). Independentes do domínio específico ou problema. Domain ontologies descrevem o vocabulário relacionado com o domínio genérico (ex. sistemas de informação, medicina) Task ontologies descrevem o vocabulário relacionado com uma tarefa ou actividade genérica (ex. desenvolvimento ou vendas). Aplication ontologies descrevem conceitos pertencentes simultaneamente a um domínio e a uma tarefa. Fensel (Fensel, 2004) considera: Generic or common-sense ontologies capta o conhecimento geral do mundo. Proporcionam noções básicas e conceitos de espaço, tempo, estados, eventos e são validos para uma grande variedade de domínios. Representational ontologies não pertencem a um dominio específico. Oferecem entidades sim estabelecer o que poderão representar. Domain ontologies captam o conhecimento válido para um tipo especifico de domínio (ex. eletronica, mecânica, medicina, ) Method and task ontologies especifica para métodos de resolução de problemas. Segue-se a comparação de ambos sobre os tipos de ontologias dos autores, na figura 6. Figura 6 - Kinds of ontologies accordinf to the generality level ((Ferreira, 2008)) 11

136 4 Ontologias Emergentes O conceito de Ontologias Emergentes parte dos mapeamentos entre ontologias disponíveis num ambiente distribuído tendo por objectivo a criação de uma visão global. (Junior et al., 2009) Parte-se do princípio que perante este ambiente, existam iniciativas de construção de ontologias que atendam a contextos menores. Para um determinado domínio, pressupõe-se que existam também iniciativas de mapeamento entre as ontologias partindo de diferentes pontos do ambiente distribuído. Como resultado, temos ontologias distribuídas em que existe mapeamento entre os pontos, caracterizando-o como ambiente P2P (Junior et al., 2009). Para a criação de uma ontologia emergente, pretende-se primariamente criar uma arquitectura de suporte composta por cinco módulos e três bancos de dados como se pode verificar na figura 7. Figura 7 - Arquitectura de Abordagem de Ontologias Emergentes ((Junior et al., 2009)) Cada um dos pontos da rede P2P funciona de forma autónoma e representam cada um dos sectores. Os módulos representados acrescentam funcionalidades para atender às necessidades da Ontologia Emergente e são descritos de seguida: Módulo de mapeamento P2P faz o mapeamento entre duas ontologias distintas e armazena os pontos distribuídos no BD MAP. Módulo de Geração da OE analisa os mapeamentos e aplica heurísticas. 12

137 Módulo de Gerência faz a monitorização da quantidade de mapeamentos entre ontologias armazenadas no BD MAP anteriormente guardada pelo Módulo de Mapeamento P2P. Módulo de Navegação - instanciação proporciona instanciação com o utilizador para que possa ter acesso a informações sobre os pontos. Módulo de rastreamento realiza o log das actividades, status da ontologia emergente e outras informações relevantes. BD MAP contém os mapeamentos realizados entre os pontos. BD Ontologias contém a ontologia do ponto em questão. BD Instâncias contém as instâncias dos mapeamentos dispostos no BD MAP e no BD Ontologias. A considerar que neste sistema considera-se que cada ponto do ambiente distribuído tenha uma ou mais ontologia, com domínios diferentes, representando o conhecimento do ponto. O mapeamento é realizado quando um ponto requer a troca de informação a outro ponto. 5 Conclusões Neste artigo a metodologia de pesquisa e apresentação sobre Ontologias foi estruturada de forma a tentar apresentar algumas temáticas que fossem claras e que, de alguma forma, tivessem conhecimento de suporte bibliográfico referenciado para que a informação fosse fidedigna. Conclui-se que as ontologias são cada vez mais utilizadas em todos os sistemas pela rápida integração e pelas vantagens que delas advêm. São formas de conceptualização, representante das áreas do Conhecimento, proporciona organização hierárquica e estruturada, é constituída por partes independentes. O conceito não é constante visto que se adapta a diferentes ambientes organizacionais, consoante for as suas necessidades, logo, é um conceito em constante alteração e amadurecimento permitindo que acompanhe a evolução tecnológica, satisfazendo cada vez mais as necessidades. 13

138 Referências BASSO, C. A. M Uma Proposta para a Evolução de Ontologias a partir de Folksonomias. In: SILVA, S. R. P. D. (ed.). Brasilian Computer Society. CALERO, C., RUIZ, F. & PIATTINI, M Ontologies for Software Engineering and Software Technology, Ciudad Real, Spain, Springer. CATARINO, M. E. & BAPTISTA, A. A Ontologia STAP: Um Vocabulário de Termos de Metadados. XI Encontro Nacional de Pesquisa em Ciência da Informação Inovação e inclusão social: questões contemporâneas da informação. Rio de janeiro. CORCHO, O., FERNÁNDEZ-LOPEZ, M. & GÓMEZ-PÉREZ, A Methodologies, tools and languages for building ontologies. Where is their meeting point? Facultad de Informática, Universidad Politécnica de Madrid, Campus de Montegancedo s/n, Boadilla del Monte, Madrid 28660, Spain. FALBO, R. D. A., GUIZZARDI, G. & DUARTE, K. C An Ontological Approach to Domain Engineering. Vitória, Espírito Santo, Brasil. FARQUHAR, FIKES, R. & RICE, J Tools For Assembling Modular Ontologies in Ontolingua. FELICÍSSIMO, C. H Interoperabilidade Semântica na Web: Uma Estratégia para o Alinhamento Taxonômico de Ontologias. Universidade Católica Pontífica. FENSEL, D Ontologies: A Silver Bullet For Knowledge Management and Electronic Commerce, Springer. FERREIRA, N. A. C Multi-staged Domain Specific Modeling for Software Product Lines: An Insurance Ontology Analysis. GARCÍA-MARCO, F. J Ontologías y organización del conocimento: retos y oportunidades para el profesional de la información. GAŠEVIĆ, D., DJURIĆ, D. & DEVEDŢIĆ, V Model driven architecture and ontology development, Springer. GUARINO, N Formal Ontology in Information Systems, Van Diemenstraat CN Amsterdam Netherlands, IOS Press. GUIZZARDI, G. & GUIZZARDI, F. C. R. S. S A importância de Ontologias de Fundamentação para a engenharia de Ontologias de Domínio: o caso do domínio de Processos de Software. HEFLIN, J OWL Web Ontology Language Use Cases and Requirements. W3C Proposed Recommendation 15 December JUNIOR, H. C. D. S., MOURA, A. M. D. C. & CAVALCANTI, M. C Ontologias Emergentes: Uma Nova Abordagem para Integração de Ontologias. XXIII Simpósio Brasileiro de Banco de Dados. Brazil. KUZNIARZ, L. & STARON, M. Extracting Initial UML Domain Models from Daml+OIL Encoded Ontologies. Sweden. 14

139 NOY, N. F. & MUSEN, M. A The PROMPT suite: interactive tools for ontology merging and mapping. ORGUN, B., DRAS, M., NAYAK, A. & JAMES, G. Approaches for Semantic Interoperability between Domain Ontologies. Australia. RAMALHO, R. A. S. Representação do Conhecimento e Ontologias: reflexões interdisciplinares. RAMALHO, R. A. S Representação do Conhecimento e Ontologias: reflexões interdisciplinares. SAIAS, J. & QUARESMA, P A Methodology to Create Legal ontologies in a logic Programming information retrieval System. Évora, Portugal: Universidade de Évora. SANCHEZ-QUADRADO, S., MORATO-LARA, J., PALACIOS-MADRID, V., LLORENS- MORILLO, J. & MOREIRO-GONZÁLEZ, J. A De repente, todos hablamos de ontologías? SILVA, N. A. P Multi-Dimensional Service-Oriented Ontology Mapping. Universidade de Trás-os-Montes e Alto Douro. 15

140 Interacção ACSI com PMS Diogo Aarão Universidade do Minho Mestrado em Engenharia e Gestão de Sistemas de Informação Abstract. Este ensaio pretende ser uma amostra de como foi o funcionamento da parceria de entre a unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI) e a unidade curricular de Processos e Metodologias de Software (PMS) ao longo do semestre. O objectivo do trabalho era que os mestrandos de ACSI, fruto da sua maior experiencia ajudassem os alunos de PMS do 2ºano da licenciatura de LTSI no seu projecto final para a unidade curricular. Numa fase inicial os alunos de ACSI trabalharam como consultores dos alunos de PMS mas, devido ao mau fraca participação no processo por parte dos alunos de PMS, os professores das unidades curriculares viram-se forçados a alterar as funções, passando os alunos de ACSI a ser coordenadores dos alunos de PMS, dando-lhes para tal mais autoridade e consequentemente mais responsabilidade na interacção que vinham a ter com os alunos de PMS, tendo desde então ao alunos de ACSI a função de coordenar todo o trabalho executado por parte dos alunos de PMS durante o projecto. Palavras Chave: Processos e Metodologias de Software (PMS); Análise e Concepção de Sistemas de Informação (ACSI); coordenação; RUP; Requisitos; Misericórdia de Guimarães (MG); 1. Introdução Neste documento será abordado o processo de interacção entre os alunos de mestrado da unidade curricular Análise e Concepção de Sistemas de Informação (ACSI) e os alunos da licenciatura de Tecnologias de Sistemas de Informação (TSI) da unidade curricular de Processos e Metodologias de Software (PMS). Numa fase inicial é explicado o contexto em que o trabalho foi desenvolvido, dando a perceber todo o enquadramento do projecto e como decorreu o seu funcionamento. Assim, o documento está dividido em duas partes principais, uma em que os alunos de ACSI são consultores e outra em que os alunos de ACSI são coordenadores. Posteriormente é efectuada uma discussão sobre o funcionamento de todo o projecto abordando algumas das questões mais importantes no mesmo, 1

141 terminando o documento com uma conclusão onde é feito um balanço de toda a experiência. 2. Enquadramento do Projecto O conteúdo da unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI) tem como principal objectivo dar a conhecer aos alunos que existem problemas inerentes à execução das fases de análise e concepção de sistemas de informação, dar a conhecer alternativas para combater os problemas encontrados, saber executar tarefas de engenharia de requisitos e de transposição para modelos lógicos e arquitecturais e implementar repositórios de dados, através de técnicas avançadas de projecto em sistemas de informação(machado, 2010). Em conformidade com estes objectivos da disciplina, o professor apresentou dois métodos de avaliação, um no qual os alunos teriam que fazer um ensaio sobre um tema a acordar entre o aluno e o professor e outro método onde cada aluno de ACSI iria interagir com os alunos de Processos e Metodologias de Software (PMS) e é neste segundo método de avaliação que se vai focar o presente relatório. PMS é uma unidade curricular do segundo ano da licenciatura de Tecnologias e Sistemas de Informação (TSI) na qual os alunos têm uma primeira abordagem à engenharia de software e nomeadamente aos modelos de desenvolvimento, de qualidade e melhoria e de gestão de software, na qual o objectivo principal é a apresentação, discussão e clarificação dos conceitos básicos sobre a Gestão e Engenharia do Software(Abreu, 2007). Adicionalmente a estes conceitos este ano lectivo foi introduzida uma nova vertente na disciplina, onde pela primeira vez iria ser abordada a linguagem de modelação UML (Unified Modeling Language). Para a avaliação da unidade curricular os alunos tiveram que elaborar um conjunto de projectos tendo a nossa interacção com eles acontecido no último projecto, no qual houve a colaboração, de uma outra pessoa/entidade além dos alunos de ACSI, a Misericórdia de Guimarães (MG), esta entidade interagia como cliente em todo o processo. O objectivo principal do projecto era o planeamento e posterior execução da fase Inception do Rational Unified Process (RUP), tendo para isso o professor de PMS fornecido aos alunos um enunciado no qual era dada uma visão geral do funcionamento da MG e onde constavam os seus principais 2

142 processos. Terminada a fase de planeamento, houve uma apresentação efectuada por pela MG com o objectivo de fornecer mais informação sobre o seu funcionamento aos alunos para que depois eles fossem capazes de executar com mais qualidade a fase Inception, nomeadamente a Modelação de Negócio e os Requisitos. 3. Primeira Fase - Consultor A primeira fase deste desafio teve início no dia 11 de Novembro de 2010, dia em que foi atribuído o grupo de Processos e Metodologias de Software (PMS) do qual iria ser consultor. Como consultor era suposto eu ser um conselheiro; ou um perito em determinado assunto adstrito a algum organismo ou empresa, para proporcionar consultas sempre que se levante alguma dúvida sobre matéria da sua especialidade; (Editora), para tal e após uma breve reunião com o elemento que estava na aula e a troca de contactos, foi desde logo marcada uma reunião com o grupo para o dia 15 de Novembro de 2010 onde o objectivo era obter um maior conhecimento de todos os elementos e tentar perceber quais as suas principais dificuldades nesta fase do projecto. Tal objectivo saiu gorado visto que só um elemento do grupo apareceu à reunião e o trabalho efectuado para esta fase do projecto tinha sido pouco ou nenhum não permitindo então perceber quais as dificuldades sentidas. Como consultor, a minha orientação perante tal situação foi no sentido de incentivar o trabalho do grupo para que as dificuldades e dúvidas fossem surgindo, permitindo assim um melhor desempenho da minha função, marcando desde logo uma segunda reunião. Na segunda reunião e visto que nesta primeira fase o pretendido era a definição de quais das tarefas da disciplina de Modelação de Negócio, na qual são fornecidas orientações sobre diferentes técnicas de modelação que são utilizadas durante a engenharia do negócio (IBM, 2006) e da disciplina de Requisitos, onde por sua vez, são explicadas técnicas de como através dos pedidos vindos de todas as pessoas interessadas no sistema transformá-los em requisitos para o sistema (IBM, 2006), seria de esperar da parte do grupo um grande número de dúvidas e dificuldades, mas vi defraudadas as expectativas visto que mais uma vez apenas um elemento do grupo se apresentou à reunião, por sinal o mesmo que tinha ido à reunião anterior, mas desta vez já com dúvidas que foram esclarecidas de modo a permitir ao grupo continuar o seu trabalho. 3

143 Visto a relutância do grupo em aparecer às reuniões e porque a iniciativa devia partir da parte do grupo, decidi na semana a seguir a entrega do projecto não ter qualquer diligência no sentido de marcar uma reunião, esperando que partisse do grupo tal solicitação, algo que não aconteceu, não havendo mesmo qualquer tipo de contacto entre mim e o grupo durante essa semana. Conclui-se então que, qualquer iniciativa para os tentar ajudar os alunos no seu trabalho teria que partir da minha parte, sendo este cenário comum a todos os grupos. Nesse sentido houve uma mudança de funções para tentar combater de certa forma o desinteresse mostrado pelos alunos de PMS, e é essa nova função que será abordada no capítulo seguinte. 4. Segunda Fase Coordenadores Aquilo a que eu chamo a segunda parte tem a ver com a drástica mudança de funções que aconteceu para esta etapa. Nesta fase, devido aos factos relatados a cima, os consultores passaram a ser coordenadores ( pessoa que organiza e orienta um projecto ou actividade de grupo (Editora) ), tendo como responsabilidade agendar reuniões, que passaram a ter presença obrigatória, o planeamento e distribuição de tarefas e a supervisão da qualidade técnica dos artefactos produzidos. Com este aumento de responsabilidades e consequentemente de poder, o esperado aconteceu, houve outro tipo de postura e de envolvimento do lado dos alunos de Processos e Metodologias de Software (PMS). A partir desta mudança de funções, fiz questão de pedir ao único elemento que até agora tinha comparecido as reuniões os s dos restantes elementos, para que assim a comunicação fosse efectuada com todos. Enquanto consultor não tinha o de todos os elementos visto que tinha que partir dos elementos do grupo a iniciativa de comunicar comigo e efectuar todo o tipo de questões ou dúvidas relativas com o projecto. Aquando da atribuição dos grupos esse elemento era o único que estava presente na aula, tendo sido com ele que troquei contactos tendo-lhe então dado a responsabilidade de comunicar ao grupo o meu e de arranjar com o grupo um horário para as reuniões que fosse possível a presença de todos os elementos. O facto é que esse elemento do grupo não só não deu aos restantes elementos o meu contacto, como também não lhes comunicava o 4

144 agendamento das reuniões, marcando inclusive reuniões para horários em que alguns não podiam comparecer visto terem aulas. Só quando enviei o primeiro para todos os elementos a solicitar a marcação de uma reunião, é que me apercebi da situação, percebendo então o porquê de durante o tempo de funções como consultor só haver contactos por parte de um elemento e de só aparecer esse elemento as reuniões. Perante tal situação fiz questão de ir falar com o professor de PMS para que ele estivesse ao corrente do que se tinha passado. Tal como já foi referido, nesta fase houve uma maior interacção e envolvimento por parte dos alunos de PMS, no entanto, considero que não foi apenas devido ao facto de nesta segunda fase do projecto terem o meu que houve uma maior solicitação da minha ajuda, o aumento de solicitações deveu-se ao facto do aumento de complexidade do trabalho a desenvolver, mas também pela influência que como coordenadores passamos a ter na nota individual de cada elemento Distribuição de Tarefas Para execução da fase Inception e depois de terem efectuado o planeamento da mesma, era necessário elaborar o artefacto Vision do RUP e os diagramas de casos uso e diagramas de robustez e sequência referentes a cada um dos processos identificados no enunciado do projecto. Em conformidade com a vontade do grupo, e visto que a matéria relativa ao UML ainda não tinha sido abordada pelo professor de PMS, decidi que numa primeira fase eles deveriam elaborar o artefacto Vision. Assim, o artefacto foi dividido de forma igual por todos os elementos do grupo e foram estabelecidos prazos para que cada elemento terminasse a execução da tarefa a si atribuída. O processo de execução do artefacto Vision teve início no dia de distribuição das tarefas, dia 13 de Dezembro 2010, tendo-lhes sugerido que para a aula prática de PMS eles efectuassem pesquisa sobre a suas tarefas e assim, caso tivessem dúvidas elas seriam esclarecidas ou por mim ou pelo professor. Tal não se verificou, visto que nesse dia não houve aula e o grupo não mostrou disponibilidade para reunir noutra hora, sendo então solicitado por mim que caso houvessem dúvidas elas me fossem enviadas por , algo que só um elemento fez. Em seguida, houve o período de férias, no qual o grupo levou mesmo à letra o termo férias, tendo apenas só um 5

145 elemento me enviado, na data por mim solicitada, o trabalho que estava a realizar para que eu lhe pudesse dar uma orientação. Perante tal facto marquei para dia 3 de Janeiro de 2011 uma reunião onde todos os elementos me deveriam entregar as suas tarefas da Vision concluídas, nesse dia todos os elementos me entregaram o devido trabalho. Em alguns casos o trabalho apresentado era um trabalho com qualidade, apenas com algumas dúvidas pontuais, que viriam posteriormente a ser esclarecidas, mas em outros casos o trabalho estava longe de estar terminado e o que estava feito era em péssimas condições, tendo eu nesses casos estabelecido um novo prazo de entrega do trabalho devidamente executado. Depois de terminado o artefacto Vision e em função do que foi definido nesse artefacto relativamente a quais seriam os diagramas de casos de uso a ser mais detalhados, avançamos então para a execução dos mesmos, sendo o processo de escolha foi o seguinte: olhando para os 13 processos presentes no enunciado, o grupo decidiu executar aqueles que mais interagiam com o utente e que por consequência mais urgente seria a sua implementação. Posto isto, o processo de execução dos casos de uso foi oficialmente iniciado dia 9 de Janeiro de 2011, sendo o prazo limite de entrega dos casos de uso dia 11 de Janeiro de Nessa data apenas um elemento me entregou os devidos diagramas de casos de uso sendo que solicitei ao grupo para dia 14 de Janeiro de 2011 a entrega quer dos diagramas de casos de uso, quer dos diagramas de robustez e de sequência. À semelhança de situações anteriores, apenas um elemento entregou o devido trabalho, os restantes limitaram-se a entregar as suas tarefas dia 15 e/ou dia 16 de Janeiro de 2011, limitando assim muito a minha tarefa de supervisionar os diagramas por eles produzidos. A revisão de um trabalho como os diagramas de caso de uso, robustez e sequência não pode ser executada à pressa, é um trabalho minucioso, que necessita de ser executado com calma e ponderação. Houve inclusive diagramas aos quais não foi possível executar qualquer tipo de revisão, tal o adiantar da hora a que eles me foram enviados, visto que o prazo limite para entrega do relatório final da disciplina de PMS terminava dia 17 às 00:00h. 6

146 5. Discussão Nesta secção, gostava de abordar quais foram, na minha opinião, os pontos positivos e os pontos negativos durante a execução do trabalho. A ideia inicial, de consultoria aos alunos de Processos e Metodologias de Software (PMS) era boa, mas o seu resultado prático foi praticamente nulo, o que em grande parte se deve à fraca ou nenhuma participação dos que deveriam ser os principais interessados e os principais intervenientes, os alunos de PMS, sendo que desta fase, em termos de resultados de aprendizagem que justifiquem uma discussão não há muito a retirar, a não ser a falta de interesse e responsabilidade demonstrada pelos alunos e a dificuldade que é ser um consultor não solicitado, no fundo o consultor está mais preocupado em desenvolver um bom trabalho do que quem o contrata. Com a mudança de funções para coordenadores, os resultados já foram melhores, já houve mais interesse da parte dos alunos de PMS, em grande parte devido ao trabalho que era necessário desenvolver ser mais exaustivo. Desta fase retiro principalmente a dificuldade que é fazer a coordenação de uma equipa de trabalho, principalmente quando essa equipa não tem a motivação necessária para alcançar os melhores resultados. Aliada à falta de motivação do grupo para realizar um bom trabalho para tirar uma boa nota, estava o desinteresse, no trabalho, na disciplina, na matéria seleccionada e em alguns casos até no curso em si. Acho que grande parte desta relutância é demonstrada e é facilmente identificada pelas atitudes tomadas por alguns elementos relatadas anteriormente, como por exemplo a não entrega das tarefas nos prazos estipulados. É de lamentar que mesmo com a mudança de funções o grupo não tenha tido a motivação adequada para executar um trabalho que decorresse de forma tranquila e sem haver a necessidade de ter que executar tarefas em cima do prazo de entrega. Contudo, penso que da minha parte foram efectuados todos os possíveis para evitar tal facto, tentando motivar o grupo, alertando para o prazo de entrega e para o trabalho que ainda era necessário fazer até essa data, mostrando-me sempre disponível para os ajudar no que era necessário. Inserida na função de coordenadores estava a elaboração do artefacto Vision e dos diagramas de caso de uso, robustez e sequência. Os elementos do grupo, tal como seria de esperar, depararam-se com uma série de dúvidas, nomeadamente sobre os diversos diagramas e como os iam fazer, mas também com duvidas 7

147 relativas ao negocio. Sobre os diagramas em UML o grupo não tinha muito conhecimento sobre o que tinha que fazer e como tinha que fazer. Para muitos elementos o primeiro contacto que tiveram com a linguagem de modelação tinha sido durante as aulas, tendo sido a matéria dado muito próximo da fase de desenvolvimento dos diagramas para o projecto, não dando aos alunos um tempo para eles assimilarem a informação adquirida nas aulas. O grupo entrava também em contacto comigo para eu as esclarecer dúvidas relativamente ao negócio e o seu funcionamento, mas muitas das dúvidas eu também não conseguia responder e mesmo pedindo esclarecimentos ao professor de PMS, não ficavam totalmente elucidadas, devido ao facto de por vezes nem o professor ter o conhecimento necessário sobre o negócio. Era portanto notório que a informação disponibilizada não era suficiente para responder a algumas situações, sendo essencial mais informação sobre o funcionamento da MG. Mesmo efectuando pesquisas sobre o funcionamento de misericórdias a informação encontrada não podia ser aplicada a letra porque cada caso é um caso. Entre as varias tarefas do artefacto Vision incluía-se a identificação dos actores, sendo essa uma das dúvidas do grupo, quais as pessoas que iam interagir com o sistema e como o iam fazer. A resposta fácil seria dizer, são os funcionários da Misericórdia de Guimarães (MG) mas isso era muito vago, pois dentro do grupo de funcionários existem diferentes tipos e os diferentes tipos de funcionários executam diferentes acções e têm diferentes funções e consequentemente a sua forma de interacção com o sistema também será distinta. Mais uma vez considero que deveria ser dada mais informação aos alunos para poderem realizar a tarefa com a precisão necessária. Na minha opinião, a indefinição dos actores advêm de outra indefinição bastante mais grave, a indefinição dos requisitos. Os requisitos do sistema foram definidos muito alto nível, no enunciado do trabalho, estavam inseridos nos processos lá descritos e nem aquando da apresentação feita pela MG eles foram mais definidos. Esta indefinição entra na mitologia do cliente, onde este acha que Uma descrição genérica daquilo que eu pretendo é mais do que suficiente para que o meu fornecedor comece a bater umas linhas de código. Posso sempre completar a minha ideia mais tarde. (Machado, 2001). Esta indefinição levava a que muitas vezes os elementos do grupo perguntassem pormenores para realizar determinado caso de uso ou diagrama de robustez ou sequência, ao qual, mais 8

148 uma vez, nem eu nem o professor conseguíamos responder, com a exactidão necessária. Como requisito de software entende-se uma propriedade que um sistema deve ter de forma a resolver problemas do mundo real (IEEE, 2004). Por esta definição facilmente se percebe que olhando para o enunciado do trabalho (anexo 1), a definição de requisito não pode ser suportada pelo que lá tem. O que deveria ter sido feito, dando aos alunos essa oportunidade, através de uma maior interacção com o cliente, era através dos 13 processos presentes no enunciado, fazer um levantamento de requisitos, através de entrevistas com o grupo de stakeholders identificados ou através do fornecimento de mais documentos relativos ao funcionamento da MG, e depois de o grupo dar por determinado esse levantamento apresentar o resultado aos stakeholders para ver se os requisitos levantados estão de acordo com os que são esperados (IIBA, 2008). Esta actividade é bastante importante uma vez que, um mau levantamento de requisitos leva muitas vezes a um mau software. O levantamento de requisitos é a primeira etapa na percepção do problema de software que é necessário resolver (IEEE, 2004), portanto uma má percepção pode levar a concepção de software desnecessário ou não adequado. Outra dificuldade encontrada foi numa das tarefas do artefacto Vision, onde era pedido para estabelecer uma prioridade entre os requisitos, ora se os requisitos não estão bem definidos mais difícil se torna estabelecer uma prioridade entre eles. O processo de estabelecer prioridades entre requisitos ganha relevância porque os requisitos não são todos iguais e como é natural não tem todos a mesma importância e é através deste processo que é assegurado que nas fases de análise e implementação, o foco, são os requisitos definidos como críticos. As prioridades entre os requisitos devem ser estabelecidas segundo critérios como o valor, o risco, a dificuldade de implementação ou outro aspecto definido pelos stakeholders. Sendo através das prioridades definidos quais os requisitos que vão ser alvo de analises futuras na fase de design, construção e implementação. Assim era necessário novamente haver mais interacção entre a MG e os alunos para que houvesse um entendimento entre as duas partes para chegar aos requisitos prioritários (IIBA, 2008). Um aspecto que considero também ter sido um problema, foi o facto de ser pedida a elaboração de diagramas de robustez, a falta de consenso que estes 9

149 diagramas geram, nomeadamente entre os dois professores da disciplina, mas também pelo facto de ter sido algo que durante a meu o meu percurso académico não foi leccionado, isto levou a uma maior dificuldade da minha parte em supervisionar os diagramas de robustez efectuados pelo grupo. No sentido de combater essa ignorância da minha parte e para dar conta da supervisão que tinha que efectuar, vi-me forçado a ver a matéria seleccionada em PMS, onde percebi que os diagramas de robustez apareceram no sentido de tentar combater a falha existente entre a passagem dos diagramas de caso de uso para os diagramas de sequência(abreu, 2010). Além disto, no estudo efectuado fiquei a perceber que o principal objectivo dos diagramas de robustez é captar, para cada caso de utilização, os principais objectos e respectivas relações de comunicação estabelecidas entre os mesmos (Silva, 2010). Contudo, apesar das dificuldades sentidas, o facto de ter aprendido algo completamente novo, que nunca tinha sido estudado por mim foi um enriquecimento pessoal, que classifico de positivo. O último ponto que gostaria de abordar nesta secção era a apresentação efectuada pela MG. A apresentação focou-se muito no que levou a MG a se certificar na ISO 9001:2008 e não em dar uma visão aos alunos de como era o funcionamento dos processos indicados para estes trabalharem. 6. Conclusão Como conclusão acho que a ideia que deu origem a todo o processo foi bastante boa, mas a forma como o processo decorreu é que não foi a melhor. Devido a este facto, não sei, até que ponto é que aquilo que penso ser o objectivo do professor de Análise e Concepção de Sistemas de Informação (ACSI), a aplicação da matéria seleccionada na unidade curricular ao trabalho de Processos e Metodologias de Software (PMS), foi atingido. Na minha opinião tal objectivo não foi alcançado na sua plenitude fruto do desinteresse e alheamento dos alunos de PMS, mas também, pelos problemas por mim identificados ao nível da definição do próprio projecto em si. Contudo, penso que a experiência é positiva, uma vez que proporcionou a experiência de trabalho com pessoas totalmente desconhecidas, com personalidades diferentes do que estamos habituados. O principal ganho de toda esta experiência foi sem dúvida o ter dado conhecer muitos dos desafios encontrados pelos gestores quando comandam uma equipa de trabalho e a busca de técnicas para evitar e resolver esses problemas. 10

150 7. Referências Abreu, P. R. (12 de Outubro de 2007). part Introdução à Engenharia do Software. Abreu, P. R. (2010). part53.pms.pgr(1). Parte Diagrama de Robustez. Editora, P. (s.d.). Pesquisa global - Infopédia. Obtido em 27 de Dezembro de 2010, de Infopédia - Dicionários e Enciclopédia em língua portuguesa: Editora, P. (s.d.). Pesquisa Global - Infopédia. Obtido em 2010 de Dezembro de 27, de Infopédia - Dicionários e Enciclopédia em língua portuguesa: IBM. (2006). RUP. IEEE. (2004). SWEBOK. IIBA. (2008). The Guide to the Business Analysis Body of Knowledged. Machado, R. J. (26 de Setembro de 2010). ACSI_RMAC. Análise e Concepção de Sistemas de Informação (Resultados de Aprendizagem). Machado, R. J. (2001). RMAC_IntroducaoEngenhariaSoftware_X2001. Introdução à Engenharia do Software. Silva, A. (2010). 11-acsi-metodologia-iconix-jlb. Análise e Concepção de Sistemas de Informação - Metodologia ICONIX. 11

151 8. Bibliografia Machado, R. J. (2001). RMAC_IntroducaoEngenhariaSoftware_X2001. Introdução à Engenharia do Software. Machado, R. J. (2010). RMAC_IntroductionRequirementsEngineering_. Introduction to Requirements Engineering. Machado, R. J. (2010). RMAC_RequirementsElicitation_. Requirements Elicitation. Machado, R. J. (2010). RMAC_RequirementsPrioritization. Requirements Prioritization. 9. Anexos Anexo 1 1. [MG-GSQ] Gestão do Sistema de Qualidade tarefas relacionadas com a definição, acompanhamento e análise dos processos de qualidade. 2. [MG-RH] Recursos Humanos tratamento dos salários, férias, formação, objectivos, contratações, 3. [MG-AU] Admissão de Utentes processo partilhado pelas diversas unidades de apoio (lares, residências, apoio domiciliário, centros de dias). Trata da caracterização,contexto social e económico e enquadramento numa das unidades de apoio. Faz também a gestão das listas de espera. 4. [MG-GE] Gestão de Equipamentos procedimentos relacionados com os diversos tipos de manutenções em equipamentos, incluindo pequenas reparações nas instalações. 5. [MG-CSL] Cuidados de Saúde nos Lares gestão de consultas, medicamentos,cuidados de enfermagem, etc. 6. [MG-HIU] Higiene e Imagem do Utente tarefas relacionadas com limpezas dos diversos espaços da instituição (quartos, instalações, banhos, higiene, ). 7. [MG-SA] Serviços de Apoio processos relacionados com o apoio aos lares, por exemplo, gestão da frota e serviços de lavandaria. 8. [MG-QL] Quotidiano dos Lares Actividades sócio culturais (passeios, 12

152 trabalhos manuais, música, ginástica de manutenção, ). 9. [MG-CO] Compras processo centralizado que tratar de todas as compras relacionadas com a MG. 10. [MG-AL] Alimentar gestão das cozinhas, preparação e distribuição das refeições e elaboração das ementas (ementas específicas conforme as necessidades dos utentes). 11. [MG-AM] Análise de Melhoria tratamento das métricas obtidas através dos registos, quantificação de melhorias, análise de indicadores e auditorias internas e externas. 12. [MG-FI] Financeiro incluindo bancos, contabilidade, tesouraria, orçamentação e pagamento a fornecedores. 13. [MG-AD] Apoio Domiciliário gestão dos serviços ao domicílio (saúde, alimentação, higiene pessoal, lavandaria, ). 13

153 Ensaio sobre a Execução de Serviços do referencial ITIL v3 João Manuel de Campos Gonçalves (pg18368) Análise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão de Sistemas de Informação, Departamento de Sistemas de Informação, Escola de Engenharia, Universidade do Minho Resumo: A ITIL (Information Tecnology Infrastructure Library) é uma biblioteca de boas práticas e referencial na gestão de infra-estruturas de TI, tendo como objectivo a gestão do negócio assente em pessoas, processo e tecnologias. No âmbito da UC Análise e Concepção de Sistemas de Informação, pretende-se realizar um ensaio sobre a Execução de serviços do referencial ITIL v3, onde consta uma abordagem à ITIL em geral, com foco na execução de serviços em particular e, por último, a aplicação num caso concreto numa organização. Palavras-chave: TI, ITIL, Tecnologias da informação, Gestão de sistemas de informação Introdução Torna-se necessário, cada vez mais, reconhecer que a informação é o recurso estratégico mais importante que qualquer organização tem de gerir. A chave para a recolha, análise, produção e distribuição de informações dentro de uma organização é a qualidade dos serviços de TI prestados pela empresa. É essencial reconhecer que os serviços de TI são cruciais e estratégicos para as organizações e, estas devem investir, em níveis apropriados de recursos, na entrega, suporte e gestão desses serviços críticos que sustentam as TI. No entanto, esses aspectos são frequentemente ignorados ou apenas superficialmente abordados dentro de muitas organizações (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007). Se os processos e serviços de TI forem implementados, geridos e apoiados de forma adequada, a empresa será mais bem sucedida, sofrendo menores perturbações e perda de horas de produção, com a finalidade de reduzir custos, aumentar receitas, melhorar as relações públicas e atingir os objectivos comerciais. 1

154 O que é a framework ITIL A ITIL (Information Tecnology Infrastructure Library) é uma biblioteca de boas práticas e referencial na gestão de infra-estruturas de TI, tendo como objectivo a gestão do negócio assente em pessoas, processos e tecnologias (ITIL - Site Oficial OGC, 2007). O referencial ITIL descreve as melhores práticas e fornece uma estrutura de apoio à Gestão de Serviços de TI. Tendo como foco a melhoria contínua da qualidade dos serviços de TI entregues, numa perspectiva de cliente. Este foco é um factor importante no sucesso mundial do ITIL, que contribui de forma produtiva, as organizações que implantam as suas técnicas e processos (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007). Alguns dos benefícios que conduzem directamente para o sucesso da empresa, são: A satisfação do utilizador e do cliente com os serviços de TI; Melhor disponibilidade de serviços; Melhor tomada de decisões e riscos optimizados; Redução de custos resultantes da melhoria. Figura 1 Ciclo de vida do ITIL v3 (ITIL - Site Oficial OGC, 2007) 2

155 Principais fases do referencial ITIL são: Estratégia de Serviço: a realização de objectivos estratégicos requer o uso de activos estratégicos. O referencial mostra como transformar a gestão de serviços num activo estratégico (OCG, 2007). Desenho de Serviço: orientação para a concepção de serviços de TI, orientados pelas práticas, processos e políticas que regem a TI, com o objectivo de facilitar a introdução de serviços no ambiente da organização (OCG, 2007). Transição de Serviço: orientação para o desenvolvimento de recursos, na transição do Desenho de Serviços para a Execução de Serviços, com o objectivo de controlar os riscos de falhas e interrupções (OCG, 2007). Execução de Serviço: orientação na realização de eficácia e eficiência na entrega e suporte de serviços, com o objectivo de assegurar o valor ao cliente e ao prestador do serviço (OCG, 2007). Melhoria Continua de Serviço: orientação na criação e manutenção de valor para os clientes através de um melhor design, introdução e funcionamento dos serviços, a conjugação de esforços de melhoria e os resultados obtidos com Estratégia de Serviço, Design de Serviço, Transição de Serviço e Execução de Serviço (OCG, 2007). Abordagem Neste ensaio vai ser abordado um dos princípios fundamentais da gestão de serviços de TI, oferecendo-se uma visão de alto nível aplicada a um caso concreto de uma organização: Execução de Serviço: orientação na realização de eficácia e eficiência na entrega e suporte de serviços, com o objectivo de assegurar o valor ao cliente e ao prestador do serviço (OCG, 2007). Execução de serviço Introdução A Execução de Serviço explica-nos com detalhe as actividades de entrega e controlo, no sentido de alcançar a excelência operacional no dia-a-dia, devendo 3

156 para isso, manter o serviço em bom estado operacional, até que este deixe de ser útil e posteriormente retirado (OCG, 2007). As fases anteriores englobam processos mais voltados para a estratégia, mas neste ensaio veremos processos e funções operacionais. É importante reconhecer que o sucesso da Execução de Serviço dependerá de todas as fases anteriores do ciclo de vida do serviço. Se eventualmente o serviço for mal planeado durante a fase de estratégia, por consequência será incorrectamente desenhado. Consequentemente a transição irá implantar um serviço em execução que apresentará defeitos. Visto isto, durante todo o ciclo de vida, cada fase deve validar a informação gerada pela fase anterior para evitar que o serviço seja projectado com requisitos errados. Se nas fases anteriores tudo estiver bem pensado, planeado e coordenado, o serviço entrará em execução sem causar impactos negativos tanto para a equipa de TI como para a organização (OCG, 2007). Propósito O propósito da Execução de Serviço é coordenar e executar as actividades, processos e gestão contínua da infra-estrutura, para entregar e gerir serviços em níveis acordados com os utilizadores e clientes. Objectivos da Execução de Serviço: Entregar e garantir suporte dos serviços com eficiência e eficácia (OCG, 2007); Assegurar que o valor está a ser entregue aos clientes através dos serviços oferecidos (OCG, 2007); Executar a estratégia através da Execução de Serviço (OCG, 2007); Manter a estabilidade e adaptar-se às alterações no negócio e no ambiente tecnológico (OCG, 2007); Implantar processos que facilitem a execução do serviço no dia-a-dia (OCG, 2007). 4

157 Impacto, urgência e prioridade É importante avaliar o impacto e a urgência de incidentes 1, problemas 2 ou alterações nos processos, com vista a determinar a prioridade e, por sua vez, esta determina qual será a ordem de execução. Para determinar a prioridade utiliza-se, como boa prática, a combinação entre impacto e urgência. Para o impacto deve-se considerar quantas pessoas ou sistemas serão prejudicados pelo incidente, problema ou alteração. Já a urgência determina a velocidade em que o incidente precisa de ser resolvido (OCG, 2007). Exemplo: Numa sala de aula, um incidente com alto impacto pode ter uma baixa urgência se o impacto não afectar o regular funcionamento durante o horário das aulas. Se às 19:00h o servidor de imagens destinadas aos laboratórios de ensino avariar, é um incidente de alto impacto e média urgência, porque só no próximo dia às 08:00h deverá ser necessário para as aulas. Se no mesmo período, para o mesmo impacto a nível departamental, o servidor de que funciona 24 horas, deixar de funcionar, o incidente terá uma urgência maior. IMPACTO Alto Médio Baixo Alta Prioridade 1 Atendido < 1h Prioridade 2 Atendido < 2h Prioridade 3 Atendido < 4h URGÊNCIA Média Prioridade 3 Atendido < 4h Prioridade 4 Atendido < 8h Prioridade 5 Atendido < 16h Baixa Prioridade 4 Atendido < 8h Prioridade 6 Atendido < 24h Prioridade 8 Atendido < 48h Tabela 1 Impacto, urgência e prioridade no atendimento (OCG, 2007). A prioridade serve para classificar incidentes, problemas e alterações. Por exemplo, no Acordo de Nível de Serviço, pode estar escrito que incidentes com prioridade 3 precisem de ser resolvidos até 4 horas úteis. 1 É uma interrupção ou redução na qualidade do serviço. Exemplo: o utilizador contacta a Central de Serviços a pedir apoio na monitorização do sistema que está muito lento ou indisponível. 2 É a causa de um ou mais incidentes. Exemplo: o utilizador pede um determinado relatório e a sua monitorização bloqueia. Para este caso regista-se o incidente, se não se souber a origem, regista-se o problema. 5

158 Os processos da Execução de Serviço A fase de Execução de Serviço é composta pelos seguintes processos: Gestão de Eventos: processo que monitoriza todos os eventos que ocorrem através da infra-estrutura de TI para permitir o funcionamento normal e garantir elevado desempenho (OCG, 2007); Gestão de Incidentes: concentra-se em reparar o serviço o mais rapidamente possível para os utilizadores, a fim de minimizar o impacto no negócio (OCG, 2007); Gestão de Problemas: envolve a análise da origem da causa a determinar e resolver. Através de actividade pró-activa para detectar e prevenir futuros problemas/incidentes, estes registos ficam guardados como Erro Conhecido 3, para permitir rápido diagnóstico e resolução, caso novos incidentes acontecem (OCG, 2007). Pedido de Requisição: gere solicitações de clientes e utilizadores de todos os tipos de pedidos que incluem instalações, movimentos e empréstimos, bem como outros específicos para os serviços de TI (OCG, 2007). Gestão de Acesso: é o processo de concessão, a utilizadores autorizados, de direito de utilizar um serviço, ao restringir o acesso a utilizadores não autorizados. É com base nesse processo, que se é capaz de identificar com precisão os utilizadores autorizados e, em seguida, gerir a sua capacidade de aceder a serviços necessários durante as diferentes fases do ciclo de vida contratual dos seus recursos humanos (RH) (OCG, 2007). Ensaio Processo de Gestão de Evento Se for detectada uma ocorrência, através de um alerta 4, que seja significativa para a gestão da infra-estrutura ou para a entrega do serviço, deve ser tratado o evento 5, para que se deva avaliar o impacto que esse desvio pode causar aos serviços. 3 A origem da causa está documentada e uma Solução de Contorno identificada. 4 É um aviso ou advertência sobre uma meta, alteração ou falha que ocorreu. É criado e controlado por ferramentas de Gestão de Sistemas e pelo processo de Gestão de Evento. 5 É uma notificação criada por um serviço, originada pelo fraco desempenho da infraestrutura ou entrega do serviço. Pretende-se que os incidentes sejam registados e de imediato resolvidos pela equipa técnica de TI. 6

159 Para que a Execução de Serviço seja eficiente, depende da informação actualizada acerca da situação da infra-estrutura, onde se pretende detectar qualquer desvio da execução normal (esperada). Para isso, neste ensaio, é usado um sistema de monitorização e controlo, baseados numa ferramenta de monitorização que detecta e correlaciona alertas operacionais dos serviços de rede ou comunicações, geradas por itens de configuração: Nagios 6. A Gestão de Eventos pode ser aplicada à Gestão de Serviço TI que precise de ser controlada e que possa ser automatizada. Isto inclui: Itens de configuração: o Os switch de rede, servidores web, servidores e virtualização, devem permanecer sempre ligados: a ferramenta Nagios confirma isso, realizando pings de resposta; o Automatizar a actualização de um servidor de ficheiros. Condições de temperatura ideal no Datacenter 7 ; Monitorização de licenças de software atribuídas para assegurar que a política de licenciamento está a ser seguida; Segurança (detecção de intrusão); Gestão de cópias de segurança: Actividades específicas (por exemplo: monitorizar o uso de uma aplicação ou o desempenho de um servidor); Registar em logs a informação dos eventos. Funcionamento Quando ocorre um evento, lança de imediato uma notificação que será filtrada conforme a classificação: Se for informativo, apenas se regista o evento; Se for alerta, será efectuada uma: 6 Nagios é ferramenta de monitorização de rede, de código aberto e distribuída sob a licença GPL. Com esta aplicação, pode-se monitorizar hosts e serviços, alertando quando os problemas ocorrerem e também quando estes são resolvidos (www.nagios.com). 7 Datacenter é um local onde estão concentrados os equipamentos de processamento e armazenamento de dados de uma organização. 7

160 o Intervenção humana, como por exemplo, quando o espaço em disco está prestes a acabar, instala-se um novo com maior capacidade; o Resposta automática via sistema, quando o espaço da conta de e- mail está prestes a esgotar o limite. Se for excepção, por exemplo, o serviço ficar off-line, regista-se um incidente. Dependendo da situação, pode haver o envolvimento da Gestão de Problema para diagnosticar a origem da causa. Responsabilidades Não é necessário ter um Gestor de Evento, porque muitas actividades são delegadas às funções de TI como: Central de Serviço: comunica directamente ao técnico adequado a investigação e resolução do evento; Desenho de Serviço: classifica e define mecanismos de respostas automáticas. Processo de Gestão de Incidente Este processo vai lidar com os incidentes que possam ter falhas e dúvidas reportadas pelos utilizadores das TI. O objectivo da Gestão de Incidente é restaurar o funcionamento normal do serviço o mais rapidamente possível, garantindo os níveis de qualidade de serviço e de disponibilidade. O alvo do processo de Gestão de Incidente inclui qualquer evento que interrompa ou que possa interromper um serviço. Isto inclui eventos que são comunicados directamente pelos utilizadores, tanto através da Central de Serviços como por interfaces com ferramentas de monitorização de eventos (Nagios, neste caso!). Funcionamento O processo de Gestão de Incidente consiste nos seguintes passos (ver anexo, Figura 3): 1. Identificação do incidente quando este for detectado; 2. Registo dos incidentes (data, hora e informações relevantes); 8

161 3. Classificação do incidente, que será útil para a Gestão de Problema identificar quais são os mais frequentes; 4. Prioritização do incidente, classificando-o com um código de prioridade determinado pelo impacto e pela urgência (ver Tabela 1); 5. Diagnóstico do incidente é executado pela Central de Serviço, que tenta descobrir os possíveis sintomas; 6. Escalada do incidente que não puder ser resolvido pela Central de Serviços, deverá ser atribuído, dentro do tempo útil, a outro nível de suporte com maior capacidade; 7. Investigação e diagnóstico são feitos por cada grupo de suporte que investiga o sucedido e faz um diagnóstico; 8. Resolução e recuperação, mostra uma solução que deve ser aplicada e testada; 9. Fecho de incidente pela Central de Serviços que deverá classificar o motivo do incidente, documentá-lo, pedir para que o utilizador responda ao pedido de satisfação e fazer o fecho formal com a presença do utilizador. Responsabilidades O Gestor de Incidente deve: Procurar a eficiência e eficácia do processo; Produzir relatórios relativos ao tipo de incidentes; Gerir os incidentes graves; Gerir o trabalho das equipas de suporte (de 1º e 2º níveis): 1. O primeiro nível de suporte será feito pela Central de Serviços e inclui registo, classificação, escalada, resolução e fecho dos incidentes; 2. O segundo e terceiro níveis de suporte são responsáveis pela investigação, diagnóstico e recuperação dos incidentes: O grupo de segundo nível será formado por programadores e administradores de rede; O grupo de terceiro nível será ser formado pelos fornecedores de software ou hardware. 9

162 Processo de Gestão do problema A Gestão de Problema, tem como objectivo, encontrar erros conhecidos na infraestrutura de TI: Identificar qual é o erro conhecido através do diagnóstico; Identificar soluções alternativas para a remoção do erro conhecido; Emitir uma requisição de alteração para solicitar que a extinção ocorra; Depois ver que alteração foi feita e verificar se o erro conhecido foi removido. A Gestão de Problema como elemento pró-activo, que é identificar e facilitar a remoção de erros antes que eles se manifestem como reclamações pelos utilizadores. Este processo guarda informações sobre problemas, resoluções e soluções de contorno apropriadas para que a organização seja capaz de, ao longo do tempo, reduzir o número de incidentes. A Gestão de Problema e a Gestão de Incidente têm uma forte partilha de informação com a Base de Dados de Erros Conhecidos. As diferenças que existem entre a Gestão de Incidente e a Gestão de Problema: A Gestão de Incidente foca a recuperação rápida do serviço. Para isso, será necessário utilizar soluções de contorno disponíveis na Base de Dados de Erros Conhecidos 8 (OCG, 2007); A Gestão de Problema foca a identificação da origem da causa do problema e o desenvolvimento de uma proposta para remover definitivamente o erro da infra-estrutura (OCG, 2007). Os problemas são a causa de um ou mais incidentes. Um incidente nunca passa a problema, temos sempre dois registos separados, um para cada processo. Podemos ter 100 registos de incidentes referentes a um determinado sistema bloqueado e apenas um registo de problema. É importante separar o registo de incidente do registo de problema (OCG, 2007). Funcionamento As actividades da Gestão de Problema consistem (ver anexo, Figura 4): Identificação do problema quando este for detectado; Registo desse problema (data, hora e informações relevantes); 8 É um local onde se registam Erros Conhecidos. Estes registos serão utilizados pelo processo de Gestão de Incidente para resolver incidentes. 10

163 Categorização do problema a ser disponibilizado à Gestão de Incidentes; Prioritização do problema, classificando-o com um código de prioridade determinado pelo impacto e pela urgência (ver Tabela 1); Investigação e diagnóstico, consultando a Base de Dados Gestão de Configuração; Decisão sobre a solução de contorno, como uma forma temporária de resolver o problema. Por exemplo: reiniciar um servidor; Identificação de Erros Conhecidos, caso exista na Base de Dados de Erros Conhecidos, se não, cria novo registo; Resolução da alteração que foi necessária efectuar; Fecho do problema; Revisão de problema grave e/ou correcção de erros identificados. Responsabilidades O Gestor de Problema deve: Acompanhar a equipa de resolução de problemas para assegurar que estes os cumprem dentro das metas do Acordo do Nível de Serviço; Gestão e protecção da Base de Dados de Erros Conhecidos; Acompanhar o fecho formal de todos os registos de problemas; Organizar, conduzir, documentar e acompanhar todas as actividades de revisão. Processo de Cumprimento de requisição O Cumprimento de Requisição é usado como uma descrição genérica para os vários tipos de pedidos feitos ao departamento de TI pelos seus utilizadores. Muitos deles, são na verdade pequenas alterações de baixo risco, que ocorrem com frequência e baixo custo. Podem ser: uma requisição para mudar uma password, instalar um software num PC, configurar alguns itens do equipamento desktop ou apenas uma pergunta a requisitar uma informação. Devido à natureza de risco reduzido, este tipo de solicitação pode ser tratada por este processo, em vez de congestionar o processo da Gestão de Incidente. Este processo destina-se a: Ser atendido pela Central de Serviço, onde os utilizadores através de um canal web, podem requisitar serviços; 11

164 Fornecer aos utilizadores e clientes, informações sobre a disponibilidade e procedimento para obter esses serviços; Fornecer e registar as licenças de software; Fornecer suporte para ajuda automática, através de informações que podem ser publicadas na intranet. Funcionamento Neste ensaio, o Pedido de Requisição consiste nos seguintes métodos: Solicitações: os utilizadores podem submeter as suas solicitações, usando a ferramenta Request Tracker (RT) 9, que possui interface web, na qual o utilizador clica num link para solicitar o que pretende; Encaminhamento: normalmente a Central de Serviço está envolvida em solicitações da sua competência, as que estiverem fora desse âmbito, serão encaminhadas para grupos especialistas ou fornecedores; Conclusão: uma vez que a requisição de serviço 10 está completa, a Central de Serviço irá fechar o registo de requisição. Responsabilidades O Pedido de Requisição fica a cargo da Central de Serviço, que faz a monitorização, despacha e responde às requisições dos utilizadores: As equipas da Central de Serviço e da Gestão de Incidente irão lidar com as requisições de serviço; O preenchimento eventual de requisições é feito pelos utilizadores, recorrendo à aplicação open source RT. Processo de Gestão de Acesso A Gestão de Acesso concede ao utilizador o direito de usar um serviço, mas nega acessos a utilizadores não autorizados. O pedido de acesso é feito à Central de Serviço, a partir de uma requisição de serviço. 9 O Request Tracker é um sistema de tickets, que permite a Central de Serviços gerir requisições efectuadas pelos utilizadores de uma forma eficiente (www.bestpractical.com). 10 É atendida pela Central de Serviço, referente a um pedido de alteração de informação ou acesso a um serviço. Exemplos: efectuar reset a uma password, trocar um toner da impressora, dúvidas e informações. 12

165 Este processo irá ajudar a organização a manter a confidencialidade da informação de uma forma mais efectiva. Funcionamento A Gestão de Acesso consiste nas seguintes actividades: Verifica a legitimidade do pedido, através da requisição vê se é mesmo a pessoa que está a solicitar o acesso; Fornece os direitos de utilização de um serviço, que deve estar em conformidade com a política e as regras definidas; Monitoriza o estado, por exemplo, se alguém saiu definitivamente da organização, o seu login de acesso aos sistemas deve ser bloqueado imediatamente. Em caso de a pessoa ser promovida ou alteração das funções, o seu perfil deve ser alterado; Regista e monitoriza acessos, garante que os direitos foram dados correctamente, mas não responde às requisições de acesso; Remove e limita direitos de acesso, assim como dá o direito de acesso ao uso de um serviço. Responsabilidades Não é necessário ter um Gestor de Acesso, mas sim, políticas, práticas e procedimentos que precisam de ser definidas e comunicadas aos utilizadores. Os envolvidos nas actividades deste processo são: Central de Serviço: verifica a validade da requisição de acesso conforme as autorizações; Gestão de Acesso: na área de controlo, lida com os incidentes e problemas relacionados com os acessos. Funções da Execução de Serviços Vão ser introduzidas agora as funções que estão dentro da fase de Execução de Serviço. É importante recordar a diferença que existe entre função e processo: as funções são asseguradas pela Central de Serviços, com o objectivo de executar actividades nos processos da Execução de Serviço. 13

166 Central de Serviços A Central de Serviços é uma unidade funcional que está envolvida em vários eventos de serviço, como por exemplo atender as chamadas por telefone, atender pedidos via web, lidar com eventos da infra-estrutura que são reportados automaticamente, gerir problemas e incidentes verificados. A Central de Serviços tem como objectivo, prestar suporte aos utilizadores no dia-a-dia. O principal foco da Central de Serviços é restabelecer o funcionamento normal do serviço o mais rápido possível. Isto pode envolver a resolução de erros técnicos, preenchimento de requisição de serviço ou resposta a uma dúvida de algum utilizador. Existem quatro tipos de Central de Serviço: Local; Centralizada; Virtual; Seguir o sol (Follow the sun). Para este ensaio, está prevista somente a Central de Serviço Centralizada. Central de serviços centralizada Numa Central de Serviços Centralizada estão centralizadas todas as solicitações de suporte num único local. Este tipo de estrutura adequa-se à necessidade específica para este ensaio, onde o atendimento é assegurado no local. Qualificações do pessoal A equipa da Central de Serviços deverá ter as seguintes qualificações mínimas: Aptidões interpessoais; Competências para desempenhar os vários serviços; Conhecimento técnico necessário para fornecer o suporte. Para a decisão sobre o número de técnicos necessários para assegurar a estrutura da Central de Serviços deve-se considerar: Complexidade dos serviços de TI; Número de utilizadores que serão atendidos; Tipos de incidentes e requisições de serviço; Período para o atendimento; Tecnologias de suporte; Procedimentos e scripts para atendimento. 14

167 Responsabilidades Para esta função existem as seguintes: Gestor da Central de Serviços: gere todas as actividades e actua como supervisor, representando a direcção do departamento em questões onde há um impacto significativo no funcionamento (OCG, 2007); Supervisor da Central de Serviços: gere o atendimento no sentido de atribuir a outro nível de suporte, quando quem está a atender não consegue resolver os pedidos (OCG, 2007); Analista de Suporte: fornece o primeiro nível de suporte, atende os pedidos, lida com os incidentes e requisições de serviço (OCG, 2007). Gestão de Execução da infra-estrutura A Gestão de Execução é a função responsável pela gestão e manutenção da infraestrutura de TI, assegurando a entrega de serviço e consiste em: Controlo de Execução: É composto por uma equipa técnica que garante a execução e monitorização das actividades operacionais e eventos da infra-estrutura: o Gestão de consola; o Agendamento de jobs; o Backup e restauro; o Impressão. Gestão das instalações: Gere a parte física da infra-estrutura da TI: Datacenter Gestão de aplicações Na Gestão de Aplicações existe a responsabilidade de gerir aplicações durante o seu ciclo de vida. A responsabilidade é da equipa técnica envolvida na gestão e suporte de aplicações, com um papel a desempenhar em todas as aplicações, quer sejam compradas ou desenvolvidas na organização. Uma das decisões importantes da Gestão de Aplicações é a de comprar uma aplicação e gerir o fornecimento de licenças. Por outro lado, se as aplicações forem desenvolvidas na organização, tem que envolver toda a equipa técnica de Central de Serviços, para assegurar que os requisitos estão todos garantidos. 15

168 Conclusão Ao abordar um modelo de Gestão de Serviços de TI, baseado na ITIL v3 e, utilizá-la num caso real, como proposto neste trabalho, conclui-se que na organização em questão, só uma parte é que está implementada. Relativamente ao que já está implementado, como o Cumprimento de Requisição, a Gestão de Evento e a Gestão de Acesso, estão em funcionamento, só sofreram alguns ajustes. Os restantes processos, como a Gestão de Incidentes e Gestão de Problemas, já foram dados passo para se implementar com detalhe, no sentido de colocar em prática nos próximos tempos. Elaborar este trabalho, foi uma experiência enriquecedora, porque se conseguiu abordar uma parte da Framework ITIL, aplicando a Execução de Serviços a um caso real. Como trabalho futuro, fica o desafio de conhecer o referencial completo da ITIL e por fim a certificação. Bibliografia Cartlidge, A., Hanna, A., Rudd, C., Macfarlane, I., Windebank, J., & Rance, S. (2007). The IT Service Management Forum: an introductory overview of ITIL v3:. UK: itsmf. ITIL - Site Oficial OGC. (2007). Retrieved 12 17, 2010, from ITIL: Nagios. (n.d.). Retrieved 12 17, 2010, from OCG. (2007). ITIL v3 - Continual Service Improvement. London: TSO. OCG. (2007). ITIL v3 - Service Design. London: TSO. OCG. (2007). ITIL v3 - Service Operation. London: TSO. OCG. (2007). ITIL v3 - Service Strategy. London: TSO. OCG. (2007). ITIL v3 - Service Transition. London: TSO. Request tracker. (n.d.). Retrieved 12 17, 2010, from 16

169 Anexos Evento Notificação do evento (documento) Evento detectado Evento filtrado Significativo informativo Alerta Excepção Correlação do evento Trigger Evento registado Auto-resposta Alerta Incidente/Problema/Alterações Incidente Problema Mudança Intervenção humana Gestão de Incidente Gestão de Problema Gestão de Alterações Acções de revisão não Funcionou? sim Fecha evento Fim Figura 2 - Fluxo do processo de Gestão de Evento (adaptado: ITIL V3 Service Operation) 17

170 Gestão de Evento Interface WEB Chamada telefónica Identificação do incidente Registo do incidente Categorização do incidente Requisição? sim Pedido de requisição não Prioritização do incidente Procedimento de incidente grave (pré-definido) sim Incidente grave? não Diagnóstico inicial Necessário escalada? sim Escalada para 1º e 2º níveis de suporte não Investigação e diagnóstico Resolução e recuperação Fecho do incidente Fim Figura 3 - Fluxo do processo de Gestão de Incidente (adaptado: ITIL V3 Service Operation) 18

171 Gestão de Evento Gestão de Incidente Central de Serviços Gestão Pró-activa do Problema Fornecedor ou contratante Detecção do problema Registo do problema Categorização do incidente Prioritização do incidente Investigação e diagnóstico BD Gestão de Configuração Cria solução sim Solução de contorno? não Cria registo de erro identificado BD de Erros Conhecidos Gestão de Alterações Sim, cria RFC Alteração necessária? não Resolução Fecho do problema Revisão de problema grave (pré-definido sim Problema grave? não Fim Figura 4 - Fluxo do processo de Gestão de Problema (adaptado: ITIL V3 Service Operation) 19

172 Relatório de Acompanhamento e Coordenação de um Grupo de Processos e Metodologias de Software Jorge Aguiar Análise e Concepção de Sistemas de Informação MEGSI, Universidade do Minho, 2010 Abstract: No âmbito da unidade curricular da Análise e Concepção de Sistemas de Informação (ACSI), o objectivo deste relatório consiste na avaliação do meu desempenho como coordenador de um grupo da unidade curricular intitulada de PMS (Processos e Metodologias de Software), grupo esse, atribuído pelo professor Pedro Ribeiro. O papel de Coordenador não é fácil, uma vez que implica uma grande responsabilidade, tais como, a marcação de reuniões, o planeamento de tarefas, a distribuição de tarefas pelos vários membros do grupo de PMS, um supervisionamento acerca da qualidade técnica dos artefactos produzidos por cada membro do grupo e por fim reportar aos regentes das duas unidades curriculares (PMS e ACSI), como decorreu o desempenho de cada elemento do grupo. Neste relatório foi feito um enquadramento ao Projecto de PMS que consistia em desenvolver um produto que relacionasse as várias valências da organização da Santa Casa da Misericórdia de Guimarães, foi feita uma análise breve ao funcionamento da primeira fase (Consultor) e posteriormente á segunda fase (Coordenador), como também foi feita uma análise de como decorreu a execução do objectivo que me foi proposto de ser um coordenador de uma equipa de trabalho, seguindo em anexo os s mais relevantes tanto na fase de consultor, bem como a fase de coordenador. Keywords: Processos e Metodologias de Software (PMS), Análise e Concepção de Sistemas de Informação (ACSI), PMBOK, coordenador, RUP 1 Introdução Uma das mudanças mais significativas da nossa época, é a passagem da acção individual para o trabalho em grupo. Actualmente, podemos identificar vários tipos de grupos, que trabalham das mais variadas situações. Alguns conseguem tornar-se verdadeiras equipas, enquanto outros permanecem apenas como conjuntos de individualidades. Depois desta afirmação, uma questão se constata quais são os elementos fundamentais que marcam esta diferença e o 1

173 que devemos considerar para construirmos uma equipa de trabalho? O grupo essencialmente tem de conseguir vislumbrar vantagens do trabalho em equipa, complementaridade, interdependência relativamente ao trabalho individual; a necessidade de definir com clareza os objectivos e resultados individuais e do grupo a serem alcançados; a importância da existência de um coordenador que construa um plano de trabalho e que defina a responsabilização de cada membro do grupo, de forma a alcançarem os seus objectivos com sucesso; a necessidade de uma avaliação constante dos processos e dos resultados de cada elemento do grupo; a percepção de que o fracasso de um elemento, pode significar o fracasso de todos e que o sucesso de um elemento é fundamental para o êxito da equipa; a necessidade de aprimorar as relações interpessoais, de modo a que valorizem a comunicação entre os membros da equipa de trabalho; por fim, é fundamental que a relação entre um coordenador e a equipa de trabalho, seja uma troca de experiências e saberes, o que implica a existência de conflitos, de forma a valorizar a ideia de cada elemento. [5] Por estes motivos, dá para perceber, que o objectivo de ser um coordenador de um grupo de trabalhadores e a tentativa de transformá-los numa verdadeira equipa de trabalho, é realmente um grande desafio. [5] Se mais á frente deste relatório, surgirem críticas, elas devem ser vistas não só pelo seu conteúdo, mas também pela sua importância e relevância que deve ser dado a um trabalho em grupo, fundamental no mundo moderno de fortes exigências e competitividades. 2 Enquadramento do Projecto O projecto de PMS do ano lectivo 2010/2011 foi subdividido em duas entregas, como primeira entrega, planear a fase de Inception do projecto SIMG (Modelação de Negócios e Requisitos) e na segunda entrega analisar a fase do Inception segundo o modelo Rational Unified Process (RUP) [1]. A aplicação deste projecto tem como objectivo principal, produzir uma proposta para apresentar ao cliente (Santa Casa da Misericórdia de Guimarães), mais concretamente desenvolver um produto integrado que relacione as várias valências da organização, apoiando o funcionamento de cada uma delas. Sendo 2

174 importante na última fase do projecto efectuar a vision do projecto, bem como a realização de diagramas de casos de uso, de robustez e sequência que demonstram os detalhes de como o sistema iria funcionar. Uma vez que, a Misericórdia de Guimarães (MG) é uma instituição sem fins lucrativos [4], o projecto de PMS tem como objectivo optimizar os recursos da instituição para que estes possam melhorar e sobretudo para que haja uma melhor gestão de toda a instituição, persistindo numa melhoria continua correspondente á norma de qualidade adoptada (ISSO 9001). Embora seja pioneira na sua área, esta instituição carece de alguns meios para optimizar os diferentes departamentos existentes, sendo que, alguns destes departamentos já possuem meios informáticos, mas o objectivo essencial desta instituição seria poder interligar todos os departamentos em todas as valências e que o sistema cobrisse todos os requisitos necessários para o bom funcionamento dos respectivos departamentos. 3 Atribuição do Grupo 3.1 Primeira Fase Consultor Relativamente a esta primeira fase, o objectivo que nos foi proposto pelo regente Ricardo J. Machado da unidade curricular ACSI é que nos tornássemos consultores de um determinado grupo da unidade curricular PMS do 2ºAno regida pelo professor Pedro Ribeiro, promovendo a afectação dos alunos de ACSI aos respectivos grupos de PMS. Relativamente ao meu caso, fui atribuído ao grupo, cujo único elemento que cheguei a conhecer, foi o aluno Stefane na aula prática de PMS do dia 11 de Novembro. Posteriormente á atribuição, fiquei com o contacto ( e telefone) desse elemento, ao qual facultei os meus contactos, tendo ficado combinado futuramente reunirmo-nos de forma a tirares lhes as dúvidas iniciais nesta primeira fase do projecto de PMS. Como tinha ficado combinado, mandei lhe um no dia 16 de Novembro, pedindo lhe os respectivos s dos restantes elementos do grupo e que me informasse como estava a decorrer o trabalho deles até ao momento, que consistia na fase do planeamento (de modo a visualizar-se as fases principais do modelo, entregas e sua calendarização). Até a um determinado momento, não recebi qualquer mensagem ou qualquer informação de que me garanta que o grupo ainda existisse. Mandei diversos 3

175 s e mensagens para o telemóvel desse elemento, tendo recebido apenas uma mensagem a indicar o do outro elemento do grupo, que também nunca chegou a contactar me. Por todos estes motivos, infelizmente não pude aprofundar os meus conhecimentos e prover vantagens de ser um consultor de uma equipa de trabalho. 3.2 Segunda Fase Coordenador Assim sendo, após ter sido discutido na aula e posteriormente comunicado pelo professor da nossa unidade curricular ACSI da decisão em alterar o modelo de cooperação PMS/ACSI, decidi comunicar ao professor Pedro Ribeiro na aula em que decorreu a apresentação da Santa Casa da Misericórdia de Guimarães já depois da primeira entrega do trabalho ter decorrido, visto que, mais uma vez não houve sinal da presença do meu grupo nessa aula. Com o decorrer da conversa, apercebi de que o professor não tinha muito conhecimento desse grupo a que me foi atribuído, levando a querer consoante a conversa, que o meu grupo seria um dos dois grupos mais fracos do turno prático onde estavam inseridos e em risco de reprovar após a primeira entrega. Portanto, de modo a não continuar nesta situação para o bem do meu futuro relativamente aos objectivos que me foram propostos nesta unidade curricular, decidi propor a ideia ao professor Pedro Ribeiro de atribuir me um novo grupo, de modo a poder obter sucesso no objectivo de ser coordenador de uma equipa de trabalho. Ainda no próprio dia, fui informado pelo professor Pedro Ribeiro que tinha arranjando um grupo que estava algo desesperado em obter um coordenador para a sua respectiva equipa, tendo de imediato concordado em ser o coordenador desse grupo. O professor enviou me o contacto de um elemento do grupo, de modo a poder contactá-los o mais cedo possível, sendo que, mais uma vez não voltei a receber resposta aos s que lhes enviei. No dia 21 de Dezembro foi me atribuído pela terceira vez um novo grupo, tendo finalmente recebido feedback por parte de um elemento desse grupo. Logo tratei de obter os devidos contactos dos restantes elementos de grupo, de forma a todos serem comunicados das posteriores reuniões que marcasse, distribuição de tarefas e conseguir tirar na medida do possível todas as dúvidas que o grupo se deparasse acerca do projecto. Uma vez que, não participei na primeira entrega 4

176 deste grupo como Consultor, pedi-lhes que me enviassem o dito relatório que entregaram no dia 28 de Novembro, de modo a ter uma ideia de como funcionou a realização desse primeiro relatório. 4 Desenvolvimento do Projecto A partir de meados de Dezembro e início de Janeiro, finalmente comecei a usufruir do objectivo que me foi proposto, em ser um coordenador de uma equipa de trabalho do 2ºAno que compunha-se em quatro elementos (Fernando Alexandre, António Ferreira, Elizabeth Lima e Carlos Vasconcelos). Aquando deste novo papel que foi atribuído aos alunos de ACSI, no dia 27 de Dezembro enviei um ao grupo (no início apenas comunicava com apenas dois elementos Fernando e Alexandre, enquanto os outros dois elementos ainda não me tinham fornecido qualquer contacto a mim e nem ao grupo), contendo em anexo a distribuição de tarefas indicadas no artefacto Vision (que o professor Pedro Ribeiro sugeriu para seguir), por cada elemento do grupo de modo a que ainda aproveitassem a altura das férias para irem adiantando trabalho até a primeira aula do turno prático de 3ªFeira (4 de Janeiro das 16Horas ás 18Horas). Uma vez que, eu não podia comparecer nesse horário, pedi-lhes que aproveitassem essa aula para mostrarem o máximo possível de trabalho, de forma a tirarem todas as dúvidas com o professor. Por isso, devido á minha indisponibilidade relativamente às 3ªFeiras, decidi marcar uma reunião para 6ªFeira (dia 7 de Janeiro ás 16Horas) na Universidade do Minho em Guimarães com o objectivo de supervisionar a qualidade técnica dos artefactos produzidos por cada elemento do grupo e tirar lhes supostas dúvidas que tivessem relativamente ao projecto. Recebi feedback apenas de dois elementos (Fernando e António) via relativamente á marcação da reunião, sendo que os outros dois elementos só deram sinal de vida na aula de turno prático de 3ª Feira (dia 4 de Janeiro), na qual confirmaram a sua presença na reunião de 6ªFeira. Relativamente á primeira reunião que marquei, todos os elementos do grupo apareceram. Durante duas horas, tratei de recolher as tarefas que lhes foram destinadas e de saber quem trabalhou seriamente no projecto. Uma vez que, os elementos do Grupo deparam-se com algumas dúvidas relativamente á realização dos diagramas casos de uso, sequência e robustez, 5

177 tentei os ajudar através dos slides da unidade curricular do professor Pedro Ribeiro [3], bem como os slides da unidade curricular DAI (Desenvolvimento de aplicações informáticas) [2] dirigidos pelo mesmo. De modo a que ficassem o máximo possível esclarecidos, formulei um caso de exemplo acerca da criação dos ditos diagramas. No final da reunião, decidi dar um aviso aos elementos Carlos e Elizabeth, de que necessitavam de dar mais apoio aos restantes elementos do grupo (Fernando e António), visto que, estavam a prejudicar o bom funcionamento do grupo. Sendo assim, decidi fazer uma nova actualização da distribuição das tarefas, de modo aos elementos que trabalhavam menos, incluilos mais na realização do relatório (Vision), enquanto os outros dois elementos mais empenhados, incluí-los apenas na parte mais dura desta última fase, na criação dos diagramas casos de uso. Ainda nessa reunião, acordei com o grupo em marcarmos a próxima reunião na próxima 3ªFeira (dia 11 de Janeiro no turno prático das 16H ás 18H). Na aula do dia 11 de Janeiro, apareceram apenas á reunião os elementos Fernando, António e Elizabeth, enquanto o elemento Carlos não apareceu e nem sequer deu uma justificação, sabendo que tinha trabalho para me mostrar. Essa aula/reunião aproveitei mais uma vez para lhes tirar umas dúvidas acerca da realização dos diagramas e aproveitei também para corrigir (aconselhar) o elemento Elizabeth por forma, a melhorar as tarefas que lhe tinha incumbido. No decorrer da aula, em conversa com o professor Pedro Ribeiro, soube que havia uma forte possibilidade do adiamento da entrega final do projecto de PMS, o que me levou a pensar em dois planos, caso a data fosse alterada. Posteriormente á aula/reunião, mandei um ao grupo de modo a comunicar a minha ideia relativamente ao adiamento ou não da entrega final do projecto. No dia seguinte, o elemento Fernando comunicou me da decisão final do professor, a data de entrega não foi adiada. Assim, desde logo ficou combinado, que o grupo teria que me entregar as devidas tarefas que lhes foram incumbidas até ao dia 14 de Janeiro (dois dias antes da entrega final ao professor). Portanto, no dia da entrega final, devido ao interesse praticamente nulo de dois elementos do grupo que já falei anteriormente, os restantes elementos não conseguiram mandar me por completo o relatório final antes de entregarem ao Professor de modo a que eu pudesse supervisionar o relatório finalizado, devido ao acrescido trabalho que tiveram, por os outros dois elementos não terem dado o contributo necessário. 6

178 5 Discussão Ao longo deste relatório, são perceptíveis as vantagens e desvantagens que existem em ser um coordenador de uma equipa de trabalho do 2º Ano da Licenciatura de Tecnologias e Sistemas de Informação. Falando mais concretamente no caso dos grupos a que nos foram atribuídos, no início do semestre quando decidi escolher este regime de avaliação em vez de fazer um artigo científico, pensei que iria ser uma prova bastante proveitosa de forma a testar todos os meus conhecimentos que adquiri ao fim de três anos de licenciatura. Visto que, era uma iniciativa inovadora neste ano de mestrado na unidade curricular ACSI leccionada pelo professor Ricardo J. Machado, era natural que pudessem existir alguns problemas, tais como, na minha opinião achar que alguns alunos do 2º Ano não nos deram a devida importância, devido a alguma irresponsabilidade por parte deles, caso estivessem no primeiro ano da Universidade, ai fazia todo o sentido, em sentirmos alguma descrença por parte deles, uma vez que estavam num ambiente novo, completamente diferente das escolas secundárias. Assim sendo, felizmente a situação mudou, depois de o professor ter mudado o regime de avaliação baseado no projecto PMS para tornamos coordenadores formais das equipas de PMS, aumentando as nossas responsabilidades, obtemos assim uma atenção maior por parte dos alunos de PMS, visto que agora, tínhamos algum poder conjuntamente com o regente da cadeira de PMS na atribuição das notas aos projectos deles. Depois de todos os problemas que tive na atribuição de grupos sérios, dispostos a terem um consultor e posteriormente um coordenador, que falei já anteriormente, finalmente comecei a usufruir do objectivo a que me foi proposto. Este tipo de regime para além do aumento da responsabilidade, atenuou o manifesto desinteresse pelo papel que o consultor poderia desempenhar na execução do trabalho efectuado de uma equipa de PMS. 7

179 6 Conclusão Concluído o relatório relativamente ao acompanhamento de uma equipa de trabalho de PMS, na minha opinião interiorizei e adquiri competências ao longo desta experiência numa primeira instância como consultor e posteriormente como coordenador com optimismo, mas ao mesmo tempo com bastantes prudências, inquietudes e interrogações. Contudo, tinha essa consciência, que o papel de ser consultor não iria ser fácil proporcionar-se, visto que os alunos do 2º Ano não nos davam a devida importância, que foi o meu caso, só com a mudança do regime de avaliação facultada pelo professor é que pude finalmente cumprir na minha opinião com sucesso a tarefa de ser um coordenador de uma equipa de trabalho. Em jeito de conclusão, penso ter cumprido os principais requisitos estipulados pelo professor na unidade curricular de ACSI. 8

180 7 Referências 1. RUP Rational Unified Process (http://www.wthreex.com/rup/smallprojects/indez.htm) 2. Slides de Desenvolvimento de Aplicações Informáticas (DAI) do Professor Pedro Ribeiro (UML ) 3. Slides de Processo e Metodologias de Software (PMS) do Professor Pedro Ribeiro 4. (2010). "A Experiência da Santa Casa da Misericórdia de Guimarães (Slides)." 5. Carlos Haroldo Piancastelli, H. P. d. F., Marília Rezende da Silveira "O Trabalho em Equipe." 8 Bibliografia 1. (PMBOK). Edição do PMI (www.pmi.org) 2. SWEBOK_Guide_ Aurum, A. (2005). "Engineering and Managing Software Requirements." 4. Dr. Paula J. Hagan, W., The MITRE Corporation (2004). "EABOK - Guide to the (Envolving) Enterprise Architecture Body of Knowledge. 5. Lankhorst, M. (2005). "Enterprise Architecture at Work (Modelling, Communication, and Analysis." 6. Goldsmith, R. F. (2004). "Discovering Real Business Requirements for Software Project Success." 9

181 9 Anexos Primeira Fase Consultor ( s) 1 Segunda Fase Coordenador ( s) 2 10

182

183 Coordenação do projecto de PMS Mário Braga Departamento de Sistemas de Informação Universidade do Minho, Guimarães, Portugal Abstract. Este artigo tem como objectivo descrever o conjunto de actividades desenvolvidas na perspectiva de consultor e gestor, no processo de desenvolvimento de software. Ao longo do artigo são detalhadas as principais preocupações de forma a mitigar os riscos inerentes à realização do projecto. Porém nem todos os problemas podem ser contidos. Este documento providencia algumas formas de contornar os problemas de forma a não colocar o desenvolvimento do software em risco. Keywords: planeamento, consultadoria, gestão de projectos, análise e concepção de sistemas de informação, processos e metodologias de software. 1. Introdução No âmbito da disciplina curricular de Análise e Concepção de Sistemas de Informação, surge a possibilidade de realizar a articulação das aprendizagens teóricas com a componente prática. Esta articulação tem como objectivo uma maior consciência dos problemas abordados sobre a perspectiva teórica, bem como, a criação de um ambiente real no qual é necessário implementar as técnicas estudadas. A implementação deste sistema teórico/prático, passa pela envolvência de duas unidades curriculares distintas: Análise e Concepção de Sistemas de Informação (ACSI), unidade na qual se adquirem conhecimentos teóricos; Processos e Metodologias de Software (PMS), unidade na qual são postos em prática os conhecimentos adquiridos; Cada aluno proveniente da unidade de ACSI irá coordenar um grupo (4/5 elementos) proveniente da unidade de PMS. Este cenário é totalmente novo para ACSI e PMS, pelo que é necessário elaborar um estudo do seu desempenho. Este documento irá descrever detalhadamente todos os pontos fortes e fracos deste tipo de interacções entre unidades disciplinares. 1

184 2. Apresentação do tema analisado Este artigo encontra-se dividido em três fases distintas. Primeiramente, é realizado um levantamento de literatura que visa focar os fundamentos necessários para a realização deste artigo, bem como, os conceitos sobre as duas unidades curriculares ACSI e PMS e a actividade de gestão de projectos e métodos utilizados. De seguida, será realizado um confronto entre os conceitos basilares deste artigo com as experiências vividas durante o projecto. Serão abordados os problemas pelos quais o projecto passou e a forma como estes foram contornados. Por fim, a última etapa tem como objectivo realizar uma conclusão sobre o projecto e tecer possíveis melhoramentos em projectos futuros. 3. Interacção das unidades curriculares O projecto desenvolvido tem como cenário a envolvência de duas unidades disciplinares distintas, ACSI e PMS. ACSI tem como objectivo formar alunos de Mestrado de forma a prepará-los para coordenarem um projecto, PMS, por sua vez, cria projectos e atribui aos grupos de licenciatura. Os alunos de ACSI devem então interagir com um grupo vindo de PMS e gerir o projecto desse grupo. 3.1 Análise e concepção de sistemas de informação ACSI é a unidade principal, é através desta unidade que obtemos a formação teórica necessária para depois implementar em PMS. Esta unidade faz parte de um conjunto de unidades de primeiro ano do Mestrado em Engenharia e Gestão de Sistemas de Informação (MEGSI). Todos os alunos desta unidade têm formações (Licenciatura) na área dos sistemas de informação (SI) e/ou informática. Os resultados de aprendizagem propostos por esta unidade são: Identificar (saber que existe) os problemas inerentes à execução das fases de análise e de concepção de sistemas de informação. Discutir (saber como fazer) alternativas de resolução dos problemas inerentes à execução das fases de análise e de concepção de sistemas de informação. 2

185 Executar (saber fazer) as tarefas de engenharia de requisitos e de transposição para modelos lógicos e arquitecturais, em projectos de mediana complexidade de sistemas de informação. Implementar (fazer) repositórios de dados, recorrendo a técnicas avançadas de projecto de sistemas de informação [1] 3.2 Processos e Metodologias de Software Esta unidade é respectiva ao segundo ano da Licenciatura em Tecnologias e Sistemas de Informação (LTSI). Contrariamente aos alunos de MEGSI, os alunos de PMS não têm grande experiência, este factor torna-se decisivo e mais à frente será abordado. A unidade de PMS tem como objectivos os seguintes tópicos: Identificar as diferentes estratégias de avaliação e melhoria do processo de desenvolvimento de software; Identificar as áreas de conhecimento propostos pelo SWEBOK 2004; Compreender os modelos do processo de desenvolvimento de software; Discutir alternativas de aplicação das técnicas do PMBoK 2004 em projectos de desenvolvimento de software; Elaborar o plano de um projecto de desenvolvimento de software, seguindo as orientações do PMBoK [2] 4. Papeis desempenhados Durante o desenvolvimento do projecto os alunos de ACSI desempenharam dois papéis totalmente diferentes: consultor e gestor. O consultor é visto como uma entidade com papéis de auxiliar e resolver os problemas do seu cliente [3]. Grande parte das vezes, o consultor apenas é chamado a intervir quando surge determinando obstáculo/problema. Todavia a sua actividade é mais abrangente, o autor Milan Kubr [4], refere que o ciclo de vida de um consultor segue a seguinte distribuição: Tabela 1. Ciclo de vida da actividade de consultor. Etapa Início Actividades Primeiro contacto com clientes Diagnóstico preliminar dos problemas Atribuição da proposta ao cliente 3

186 Diagnóstico Plano de acção Implementação Fim Análise da proposta Análise do problema Procura de factos Análise dos factos Feedback para o cliente Desenvolvimento da solução Avaliação de alternativas Proposta ao cliente Planeamento da implementação Ajuda na implementação Ajuste de propostas Treino Avaliação Relatório final Assentar conhecimentos O gestor assume papéis totalmente diferentes do papel de consultor, o gestor está relacionado directamente com o projecto. Segundo o autor Francisco Duarte [5], as actividades principais que um gestor deve desenvolver são: A escrita de uma proposta, envolvendo uma descrição inicial dos objectivos e de como atingi-los. Pode incluir uma estimativa de custos e prazos; A orçamentação, onde se indicam o orçamento disponível e os custos estimados para as actividades do projecto; O planeamento e a calendarização do projecto, onde se especificam as actividades, pontos de controlo e resultados conjuntamente com a respectiva calendarização; A monitorização, que é uma actividade contínua ao longo de todo o processo e que permite ao gestor a comparação entre o que está feito na prática e o que estava planeado que estivesse disponível nessa mesma data; A selecção de recursos humanos, em que o gestor escolhe (normalmente dentro de algumas limitações) quais vão ser as pessoas atribuídas ao projecto; A produção de relatórios e apresentações aos clientes. Além das actividades o gestor deve lidar com três factores preponderantes para o desenvolvimento do projecto: as pessoas, o problema e o modelo [5]. 5. Técnicas de comunicação Um aspecto fundamental para uma boa gestão/consultadoria de projecto é a comunicação. Sem uma boa comunicação torna-se impossível elaborar o levantamento dos requisitos dos clientes, bem como, coordenar os elementos do projecto. 4

187 Segundo o autor Marc Lankhorst [6], existem sete técnicas de comunicação: Brown-paper session, Elicitation interview, Workshop, Validation interview, Committing review, Presentation e Mailing. Brown-paper session: técnica parecida com a de brainstorming, o objectivo é lançar palavras ou frases e depois ir categorizando até chegar a algum consenso. Elicitation interview: uma entidade (analista) conduz uma serie de questões a outra(s) entidade(s) (informador(es)). Workshop: criação de um projecto que utilize determinado modelo para que as pessoas que trabalham nesse projecto conheçam o modelo apresentado. Validation interview: segue o mesmo padrão da elicitation interview contudo, é mais restrita, as questões realizadas são mais rígidas não havendo muita flexibilidade na resposta. Committing review: reunião com os stakeholders com vista na validação de determinado modelo. Presentation: técnica que envolve um grupo de pessoas que apresenta determinado modelo para um outro grupo. O grupo que vê a apresentação relata o seu feedback relativo ao modelo apresentado. Mailing: forma de comunicar determinado modelo. Quanto ao feedback este pode ser requisitado ou não. 6. Processo unificado de desenvolvimento de software (RUP) A criação de software de forma eficiente é uma preocupação actual, existem vários processos que prometem um desenvolvimento rápido e de qualidade, um destes processos é Rational Unified Process (RUP). O RUP estrutura-se em quatro fases principais: inicio, elaboração, construção e transição [7]. A fase de início tem como principais objectivos a preparação do ambiente para um novo projecto, estimação dos riscos, projecção financeira, de tempo e descrição inicial do produto a desenvolver[7]. Na fase de elaboração retrata-se mais detalhadamente o domínio do problema. Nesta fase devem ser desenvolvidos cerca de 80% da modelação dos casos de uso [5], poderá ainda ser desenvolvido um protótipo e manuais de utilização. Na fase de construção finaliza-se o desenvolvimento do software e deve ser criada uma versão com qualidade e estabilidade que responda aos requisitos iniciais[5]. Por fim, a fase de transição trata das actividades referentes à disponibilização do software para os utilizadores. Esta fase final pode conter várias iterações [5], podem surgir várias versões até se atingir a versão final. Se todas estas fases forem implementadas no desenvolvimento do software, o RUP assegura as seguintes características: desenvolvimento iterativo, gestão de requisitos, arquitecturas baseadas em componentes, modelação visual do software, gestão da qualidade do software e controlo de alterações ao software [5]. 5

188 7. Unified Modeling Language (UML) O Unified Modeling Language (UML) é uma linguagem visual que tem como objectivo detalhar, construir e documentar artefactos de um sistema de software [8]. Esta linguagem tem a flexibilidade de ser usada com qualquer modelo de processo de engenharia de software e, pode abranger todo o ciclo de desenvolvimento [5]. Com a criação do UML, sintetizou-se as notações do método de Booch, a técnica de objecto de modelação (OMT) e a engenharia de software orientado aos objectos (OOSE) fundindo-os numa linguagem de modelação única, comum e amplamente utilizável. Uma vez que esta linguagem ainda se encontra em desenvolvimento, uma das principais falhas é a ausência de um processo de desenvolvimento step-by-step [8]. Quanto à forma como o UML está estruturado, pode-se dividir em três grandes áreas: estrutural, dinâmica e gestão do modelo [5]. Dentro de cada área temos a respectiva vista e diagrama. A tabela 2 apresenta um esquema que espelha a estrutura global do UML. Tabela 2. Estrutura do UML [5] Áreas Vistas Diagramas Estática Classes Casos de Uso Casos de Uso Estrutural Componentes Física Entrega Máquina de Estados Estados Actividades Actividades Dinâmica Sequência Interacção Colaboração Gestão do Modelo Gestão do Modelo Classes Segundo o processo ICONIX, existe uma falha entre os diagramas de casos de uso e sequência. O problema é que por vezes, o que era detalhado nos casos de uso não era bem entendido, o que resultava em incoerências que conduziam a um mau desenvolvimento dos diagramas de sequência. Para contornar este problema, a ICONIX desenvolveu um novo diagrama, o diagrama de robustez [9]. O papel desempenhado por este diagrama, é de criar uma ponte que reduza as incoerências da passagem dos diagramas de casos de uso, para os de sequência[10]. 6

189 8. Discussão 8.1 O projecto de PMS O caso de estudo para a criação deste artigo foi o projecto de PMS. Este projecto foi dividido em duas fases distintas: consultadoria e gestão de projecto. Durante a fase de consultadoria os elementos de PMS irão construir um plano tendo em conta as actividades referidas no RUP. Durante a realização deste plano teriam disponíveis consultores no caso de precisarem de ajuda. Na fase seguinte, os consultores passariam a gestores de projecto pelo que assumindo então a liderança do projecto, distribuindo tarefas pelos elementos de PMS e responsabilizando-se pelo cumprimento das mesmas. O início da coordenação deste projecto de PMS foi bastante atribulado. Fazia então o papel de consultor, e tomei o primeiro contacto com os elementos de PMS (clientes) numa reunião. Durante a reunião procedi à avaliação inicial do problema e à forma como iria abordá-lo de para resolvê-lo. O objectivo desta fase de consultadoria era desenvolver as cinco actividades de consultadoria: inicio, diagnostico, plano de acção, implementação e fim [4]. As duas primeiras actividades (início e diagnóstico) correram sem problemas, tudo se complicou na altura da criação do plano de acção e implementação. O plano de acção tratava do problema de uma forma muito técnica para o nível dos elementos de PMS, a diferença entre a maturidade foi sem dúvida um problema nesta fase bem como nas restantes. Quanto à etapa de implementação foi ainda pior, o grupo relaxou quanto às datas de entrega e, sendo assim não conseguiram implementar a solução proposta. Embora seja da responsabilidade do consultor auxiliar na implementação, é importante que haja receptibilidade por parte do cliente (elementos de PMS). Segundo o ciclo de vida da actividade de consultadoria [4], a última etapa é respectiva à avaliação da implementação da solução proposta. Pelo facto da etapa da implementação não ter sido concretizada com sucesso, não foi possível efectuar a avaliação. A causa principal para este erro foi a falta de interesse por parte dos alunos de PMS para com o projecto, como será possível verificar posteriormente, a falha na implementação da solução do problema irá atrasar em cerca de duas semanas o projecto total. A fase que se seguiu foi a de mudança de papel, assumi então o papel de gestor de projecto. Este papel atribui maior poder de decisão e consequentemente maior responsabilidade. O plano desenvolvido na fase anterior não correspondia ao plano necessário para o desenvolvimento do projecto e, embora como consultor tivesse planeado uma reformulação do plano os alunos não conseguiram implementá-lo. 7

190 Consequentemente, sentiu-se a necessidade de criar um novo plano para o desenvolvimento do projecto. O tempo despendido foi de cerca de duas semanas, esta actividade foi um abalo nos custos e no tempo do projecto. Com um atraso significativo no projecto, segue-se a actividade de distribuição de tarefas pelos recursos existentes, esta actividade exigiu grande articulação entre o gestor e os elementos de PMS, é de ressaltar que grande parte dos grupos eram de cinco elementos, o grupo que me fora atribuído era apenas constituído por quatro, o que reduz o número de recursos. A actividade de divisão de tarefas foi bastante complexa, o gestor deve ter conhecimento do tempo que cada tarefa necessita, bem como, de conhecer os horários de trabalho dos elementos e as suas características/vocações. Com a conclusão da distribuição das tarefas o trabalho realizado foi de acompanhamento e monitorização do projecto. Apesar de ter realizado uma monitorização bastante apertada, com controlos semanais, o projecto volta a atrasar no período de férias. Como gestor, foi muito difícil lidar com a situação, pois tinha a convicção que não seria possível realizar um bom trabalho com o tempo e recursos disponíveis, a solução passou por efectuar reuniões com maior frequência de forma a efectivar mais pontos de controlo pressionando os elementos a laborar. 8.2 Interacções com o grupo de trabalho Um factor preponderante neste projecto foi a forma de interagir com o grupo. Feliz ou infelizmente o grupo que me fora atribuído continha elementos que eu conhecia. Inicialmente, este factor tornou-se um pouco incómodo contudo, este sentimento não perdurou. No meu entender, o mais importante é realizar uma gestão do projecto transparente, se todos os elementos tiverem conhecimento de todas as actividades e decisões reduz-se o risco de criar um clima anti-produtivo. Duas técnicas de comunicação foram estabelecidas para garantir a estabilidade do grupo: Mailing e Validation interview. Em todas as reuniões semanais, era utilizada uma checklist para monitorizar o estado do projecto. Todos os elementos de PMS tinham que responder às mesmas questões e, consoante as respostas, media o esforço realizado para o projecto. Esta técnica permitiu realizar uma avaliação com métricas e em caso de dúvidas poderia disponibilizar a checklist para justificar a avaliação. Quanto ao mailing, era utilizado com a finalidade de distribuir tarefas, marcar reuniões e responder a questões. Com a utilização do podemos comprovar que respondemos a determinada questão e que informamos todo o grupo dessa mesma questão. Muita das vezes, a questão emitida pelo elemento A, traz consequências para o trabalho realizado pelo elemento B, se todo o grupo estiver a par de todo o processo, não se corre o risco de desenvolver duas visões distintas sobre o mesmo problema. 8

191 8.3 Conhecimentos técnicos O projecto desenvolvido não tinha grandes requisitos técnicos, os conhecimentos mínimos necessários foram: RUP e UML. No que diz respeito ao RUP, o projecto apenas contemplou a utilização da fase da inception, sendo que as três fases seguintes serão desenvolvidas numa unidade posterior. A inception é constituída por duas disciplinas principais: Business Modeling e Requirements[7]. Durante o planeamento é importante que se tenha um bom conhecimento sobre as disciplinas e as suas actividades. Os alunos de PMS não realizaram essa exploração e não sabiam utilizar o RUP. Como resultado, o desenvolvimento do primeiro plano do projecto foi descuidado. A maior lacuna no que diz respeito aos conhecimentos técnicos foi a modelação em UML, os alunos de PMS não tinham conhecimentos para o desenvolvimento da modelação. O resultado final foi a criação de diagramas de robustez e sequência ad hoc. 8.4 Objectivos atingidos É importante fazer uma diferenciação entre o trabalho desenvolvido entre os elementos de PMS e o papel de consultor/gestor. O consultor/gestor deve orientar os elementos de PMS no melhor caminho, facilitando as tarefas de gestão do projecto e monitorização [3, 5]. Por sua vez, os alunos de PMS devem desenvolver as actividades que lhes são atribuídas e reportar os problemas. A tabela 3 sintetiza o conjunto de objectivos atingidos durante o desempenho de actividade de consultor/gestor. Tabela 3. Cruzamento dos objectivos propostos com os atingidos Papel Objectivos principais Concretização Consultor Primeiro contacto com clientes; Diagnostico preliminar dos problemas; Atribuição da proposta ao cliente; Análise da proposta; Análise do problema; Procura de factos; Feedback para o cliente; Análise dos factos; Desenvolvimento da solução; Avaliação de alternativas; Proposta ao cliente; Planeamento da implementação; Ajuda na implementação; Sim Sim Sim Sim Sim Sim Sim Sim Sim Não Sim Não Não 9

192 Gestor Ajuste de propostas; Treino; Avaliação; Relatório final; Assentar conhecimentos; A escrita de uma proposta, envolvendo uma descrição inicial dos objectivos e de como atingi-los. Pode incluir uma estimativa de custos e prazos; A orçamentação, onde se indicam o orçamento disponível e os custos estimados para as actividades do projecto; O planeamento e a calendarização do projecto, onde se especificam as actividades, pontos de controlo e resultados conjuntamente com a respectiva calendarização; A monitorização, que é uma actividade contínua ao longo de todo o processo e que permite ao gestor a comparação entre o que está feito na prática e o que estava planeado que estivesse disponível nessa mesma data; A selecção de recursos humanos, em que o gestor escolhe (normalmente dentro de algumas limitações) quais vão ser as pessoas atribuídas ao projecto; A produção de relatórios e apresentações aos clientes. Não Não Não Não Não Não Sim Sim Sim Não Não 10

193 9 Conclusão Com a conclusão deste artigo, encerra-se o projecto que juntou os esforços das unidades de PMS e ACSI. Este projecto mostrou-se bastante positivo e os resultados finais são animadores. O ambiente criado pelas duas disciplinas forneceu um clima realista ao projecto, pelo que foram sentidos os problemas esperados no decorrer do processo de desenvolvimento de software. Os problemas de maior relevo foram: gestão de tempo, gestão dos recursos humanos, gestão das relações internas do grupo e a monitorização do projecto. Curiosamente, era espectável que surgissem problemas durante a tarefa de levantamento de requisitos, contudo, esta tarefa não foi desenvolvida devido à estrutura delineada na unidade de PMS. O maior contributo deste artigo é comprovar que é possível e aconselhável a interacção entre unidades disciplinares distintas para a criação de ambientes mais realistas. 10 Referencias [1] R. Machado, "Análise e Concepção de Sistemas de Informação - Apresentação," Universidade do Minho, [2] P. Ribeiro, "Processo e Metodologias de Software -Apresentação da Apresentação da Unidade," Universidade do Minho, [3] L. K. Stroh and H. H. Johnson, "The Basic Principles of Effective Consulting ": Loyola University Chicago, [4] M. Kubr, "Management Consulting: A Guide to the Profession," [5] F. Duarte, "Engenharia de software orientada aos processo," Universidade do Minho, [6] M. Lankhorst, "Enterprise architecture at work," [7] IMB, "Rational Unified Process," [8] J. Rumbaugh, et al., "The Unified Modeling Language Reference Manual," Addison Wesley,

194 [9] D. Borillo, "ROBUSTNESS ANALYSIS.", ering/ucdom_robustness.html, Acedido em Janeiro 2010 [10] J. A. Maia, "Construindo Softwares com Qualidade e Rapidez Usando ICONIX.", Com-Qualidade-e-Rapidez-Usando-ICONIX, Acedido em Janeiro 2010 Bibliografia P. Patanakul e S. S. Omar, Why Mega IS/IT Projects Fail: Major Problems and What We Learned from Them, School of Technology Management, NJ-USA, 2010; P.L Bannerman, Software Project Risk in the Public Sector, National ICT Australia Ltd, 2007; W. A. Cohen, how to make it big as a consultant, American Management Association, 2009; Project Management, A guide to the project management body of knowledge: PMBOK Guide: Project Management Institute Newtown Square PA, USA, A. Abran, J. W. Moore, P. Bourque et al., SWEBOK : Guide to the Software Engineering Body of Knowledge: IEEE Computer Society,

195 Gestão de projectos Marta Abreu Departamento de Sistemas de Informação, Escola de Engenharia, Universidade do Minho Azurém, Guimarães, Portugal Resumo. Este artigo aborda algumas das questões mais relevantes no contexto da liderança de uma equipa, tais como a motivação, a relação entre o líder e o seu grupo de trabalho e a distribuição de tarefas com vista a atingir um objectivo bem definido. Desta forma é relatado um caso de estudo onde todas estas questões foram vivenciadas, permitindo retirar conclusões directamente de um caso real. O caso real tratado foi a liderança de um grupo da disciplina de Processos e Metodologias de Software (PMS) do 2º ano da licenciatura em Sistemas de Informação. Esta liderança foi protagonizada por um líder da disciplina de Análise e Concepção de Sistemas de Informação do mestrado em Engenharia e Gestão de Sistemas de Informação. O objectivo do projecto consistia em planear a fase Inception do RUP, do projecto SIMG, modelação de negócios e requisitos. O processo de planeamento foi efectuado de acordo com o PMBOK Foi ainda abordada a descrição deste processo de planeamento. Palavras-chave: PMBOK, processo de planeamento, RUP, motivação, liderança, softkills 1 Introdução A liderança é o processo que permite conduzir uma equipa de pessoas capazes de em conjunto efectuarem várias tarefas com o objectivo de atingirem resultados previamente definidos (Maxwell, 2007). Neste contexto, a secção 2 retrata a relação entre o gestor e um grupo da disciplina de PMS nos seus trabalhos de planeamento da fase de Inception do projecto SIMG (Modelação de Negócios e Requisitos). Os vários problemas que apareceram ao longo do período de liderança foram expostos na secção 2 sendo conjugados com as teorias existentes em volta dos mesmos. Na secção 3 foram abordadas algumas metodologias no planeamento de processos de desenvolvimento de software. Esta secção deu especial ênfase ao PMBOK, sendo destacadas as suas áreas de conhecimento. 2 Caso de estudo: Orientação e liderança de um grupo de PMS O objectivo do grupo de trabalho da disciplina de PMS prendeu-se com o planeamento da fase de Inception do projecto SIMG de modo a produzir uma proposta para ser apresentada a um cliente.

196 A orientação do grupo na perspectiva de gestora e coordenadora teve como objectivo marcar reuniões, atribuir tarefas aos diferentes membros da equipa de trabalho, avaliar o seu desempenho nas tarefas atribuídas, motivar a equipa e prestar auxílio aquando do aparecimento de problemas mais complexos. Neste caso de estudo são abordados os problemas que surgiram ao longo do tempo no decorrer dos trabalhos de planeamento. É ainda discutido o impacto que a liderança e, principalmente, a motivação do grupo de trabalho têm nos resultados obtidos. São mencionadas algumas das características de um gestor tendo em conta os problemas encontrados e os dois factores anteriormente apresentados. Esta secção termina com a apresentação dos soft kills e com uma tabela com a agenda de reuniões e tarefas alocadas ao grupo ao longo do trabalho desenvolvido. (Collaborative Work Skills for the Beginning IS Professional, 2004) 2.1 Problemas que surgiram ao longo do desenvolvimento do projecto Ao longo do tempo que o grupo foi acompanhado surgiram vários problemas, sendo o mais relevante a desmotivação. Praticamente todos os elementos do grupo estavam desmotivados o que causou a perda de interesse pelo projecto e o incumprimento das tarefas que lhes eram atribuídas. Desta forma tornou-se extremamente difícil, como coordenadora do projecto, garantir que a equipa a executasse os trabalhos nos tempos previstos e com os resultados esperados. Um coordenador é como um guia e para além de distribuir tarefas e de auxiliar nos trabalhos deve motivar os elementos da equipa que lidera. A motivação é um pontochave que tem um impacto enorme no desempenho do grupo, sendo por assim dizer, o motor que permite executar as tarefas atempadamente e obter os resultados esperados. A motivação, genericamente, pode ser dividida em motivação intrínseca e extrínseca. A primeira define-se como sendo uma força capaz de permitir executar um conjunto de tarefas de modo a atingir os objectivos (Johnmarshall, 2009), sem intervenção de acções externas que directamente obriguem a tingir os objectivos. No caso do grupo de PMS, esta motivação deveria estar relacionada com a vontade de aprender a efectuar o planeamento de software, obtendo como ganho do trabalho efectuado o conhecimento. Nos elementos do grupo, esta motivação não foi encontrada. No entanto, a motivação extrínseca não depende directamente do indivíduo, mas sim dos factores externos que sobre ele têm impacto. Desta forma, o objectivo de obter uma boa classificação no trabalho por eles executado é um bom exemplo de motivação extrínseca. Contudo, mesmo essa motivação faltou na equipa de trabalho ao longo de todo o tempo. A falta de maturidade, em termos gerais, pois quase todos os elementos do grupo sofriam deste problema, levou a que a delegação de tarefas fosse encarada como um conjunto de funções que não tinham obrigatoriamente que cumprir. Com esse tipo de pensamento tornou-se difícil liderar, ou seja, tornou-se difícil conduzir o grupo ao encontro dos objectivos propostos. Numa fase final do projecto, um dos elementos acaba por abandonar a equipa e, muito provavelmente pela falta de motivação. Facto é que esta saída, algo muito comum em qualquer equipa de trabalho, pois pode sempre acontecer, pelas mais diversas razões, acabou por prejudicar ainda mais o grupo. Isto porque novas tarefas tiveram que ser definidas, passando a haver uma maior carga de trabalho para os

197 restantes membros da equipa levando a uma maior desmotivação e uma degradação do cumprimento dos tempos das tarefas e dos próprios resultados das mesmas. Por último torna-se necessário mencionar o tempo, como um factor fundamental no progresso dos trabalhos. Em certos casos não houve tempo suficiente para efectuar as tarefas porque este era demasiado curto, o que fez com que os elementos do grupo não conseguissem consolidar conhecimento suficiente para lhes permitir avançar. 2.2 Soft skills Esta secção aborda as soft skills, que são um conjunto de características humanas fundamentais que levam um indivíduo a interpretar e realizar um objectivo, de forma apropriada, numa determinada envolvente (Lynch, Kathy. 2004). A sua importância é óbvia no contexto do grupo e da sua liderança, tal como é no seio das organizações. Os soft kills básicos são: a orientação para resultados, o foco no cliente, o trabalho em equipa, a análise e resolução de problemas, a iniciativa, a flexibilidade e a comunicação pessoal. Todas estas competências podem, e devem, ser desenvolvidas a nível escolar a par da transmissão do conhecimento técnico, tal como deve acontecer nos trabalhos com o grupo de PMS e o seu líder. 2.3 A Liderança e a interacção entre o gestor de projecto e o grupo A liderança é um processo de influência exercida de forma intencional por parte do líder sobre a sua equipa de trabalho, tendo como desafios centrais a motivação, a inspiração, a sensibilização e o diálogo. Durante o tempo em que exerci funções de gestão, tive que desempenhar actividades de liderança, tive que desenvolver uma estratégia, dialogar e motivar o grupo, para que continuassem a desenvolver as suas tarefas. Os principais problemas de um líder são a responsabilidade, a autoridade, a delegação, o estabelecimento de objectivos, o controlo, a avaliação de desempenho, e a resolução de conflitos. Tanto o líder como a sua equipa têm objectivos mútuos. Uso de autoridade pelo líder Líder decide e anuncia a decisão Vende a decisão ao grupo Anuncia a decisão, permite questões Apresenta decisões provisórias, consulta o grupo e decide Apresenta o problema, pede ideias, decide Tabela 1 Liderança (Fleury, 2002). Área de liberdade do grupo Apresenta o problema e os seus limites, sendo o que grupo decide Dá ao grupo tanta liberdade quanta tiver para definir o problema e decidir O desempenho do grupo depende assim da combinação entre o estilo do líder na interacção com o grupo e o grau em que a situação dá controlo e influencia ao líder. Desta forma, a utilização da gestão de projectos em conjunto com a gestão da

198 qualidade pode ter vários benefícios como: maior qualidade do produto, clientes mais satisfeitos, redução das falhas internas e externas, Redução da quantidade de restos e manutenção do produto. Por outro lado, a utilização da gestão de projectos em conjunto com a gestão da mudança pode ter vários benefícios como: a capacidade de reagir com rapidez as mudanças exigidas pelos clientes, a redução do impacto da mudança e as boas relações com os clientes resultando em clientes mais satisfeitos 2.4 Características de um gestor A gestão de equipas não é uma tarefa fácil, porque os tempos dos projectos são muito dinâmicos, os membros do grupo estão em constante mudança. Se o gestor deseja ver a equipa motivada, devem se esforçar nesse sentido, isto é, através da condução das reuniões de uma forma muito produtiva, criação de um lugar e horas próprias para a reunião, divulgação dos resultados do grupo, reconhecimento dos esforços especiais por parte de algum elemento, comportamento vocacionado, para os elementos do grupo, quanto as responsabilidades de cada membro uma correcta estruturação. Um bom gestor de projecto deve conter uma série de atributos: Forte base tecnológica Maturidade individual Grande disponibilidade Bom relacionamento com toda a equipa/ cliente/ organização Elevado controlo emocional Capaz de manter a equipa motivada Flexibilidade e adaptabilidade Preferência por iniciativa Grande capacidade de liderança Agressividade Confiança Persuasão e fluência verbal Ambição e pró actividade Agilidade Flexibilidade Dinamismo Capacidade de comunicação e integrador Variedade de interesses pessoais Imaginação espontaneidade Apto para trabalhar sobre pressão do tempo, custo e factores humanos Organizado e disciplinado Ser generalista em vez de especialista Dedicar muito tempo a planear e a controlar Habilidade para identificar problemas Capacidade de tomada de decisão num curto espaço de tempo Foco no resultado

199 Carisma Possuir visão global Negociação e experiencia As características dos membros da equipa de projectos: Habilidades técnicas de alta qualidade Forte orientação á resolução de problemas Alta capacidade de auto-motivação (Meredith, et al., 1995) 2.5 Agenda das reuniões Data Descrição 09/11/2010 Integração no grupo constituído pelos elementos Daniel Garcia, Ismael Abreu, João Pereira, Jaime Oliveira e Paulo Soares. Análise do enunciado com os elementos do grupo. 16/11/2010 Divisão de tarefas por todos os elementos do grupo. 23/11/2010 Ajuda na primeira entrega Inception. Os alunos mostraram algumas dúvidas a trabalhar no Costar. Ajuda na elaboração do relatório, principalmente na WBS e OBS. 30/11/2010 Teste individual do Project. Os alunos tiveram uma apresentação do cliente onde foi descrito o projecto SIMG. Os alunos refizeram a WBS seguindo a Inception do RUP. O Professor Ricardo Machado resolveu fazer uma mudança de regras no envolvimento dos alunos de PMS com os de ACSI. O cargo dos alunos de ACSI passou de gestor/consultor para coordenador. A partir deste dia os alunos de ACSI passaram a 07/12/2010 desempenhar um papel de coordenadores formais das equipas de PMS no âmbito da execução da fase da inception. Os alunos passaram a ter responsabilidades como: agendar reuniões, planear tarefas e distribui-las por todos os membros da equipa de PMS, supervisionar a qualidade técnica dos artefactos, reportar todas as semanas aos regentes das unidades curriculares de PMS e ACSI o que se passou durante a reunião dos grupos. 14/12/2010 Os alunos analisaram os artefactos do RUP e refizeram a WBS, devido ao facto de não terem efectuado nenhuma tarefa durante a semana anterior. Como coordenadora do projecto distribui várias tarefas, a partir das quais os alunos tiveram de seguir os templates extraídos do RUP. 4/01/2011 Depois da vinda de férias, foi feita uma reunião, e nenhum elemento desenvolveu as tarefas planeadas, o que levou a um atraso no projecto. Voltei a dar as mesmas tarefas para a semana seguinte

200 11/01/2011 Nesta reunião, o grupo já tinham alguns templates dó RUP desenvolvido, eu aconselhei-os a começarem a desenvolver os diagramas UML, pois estavam muito atrasados. Um elemento do grupo, o Paulo, apareceu á ultima reunião/aula, antes da entrega do projecto na qual já não comparecia desde Novembro, eu avisei-o que ele não tinha ajudado o grupo e que não era justo ele aparecer na última semana de entrega do trabalho, na qual não tinha ajudado em nenhuma tarefa. Eu como gestora dei-lhe várias oportunidades de fazer as tarefas, mesmo que fosse em casa, não precisava de vir as reuniões, mas ele sempre ignorou os meus s. 13/01/2011 O grupo, nesta ultima semana de trabalho, ainda se encontravam bastante atrasados, tinham alguns diagramas de UML, feitos em papel, e tinham a ideia que o trabalho ia ser adiado, o que não aconteceu. Acho que o resultado final por parte da equipa não foi satisfatório. 3 Planeamento do processo de desenvolvimento de software: PMBOK Actualmente, devido ao elevado número de empresas existentes por todo o mundo cada vez é maior o número de projectos nas diversas áreas. A gestão de projecto é pois extremamente relevante neste contexto e define-se como sendo a arte de coordenar actividades com o objectivo de atingir as expectativas dos stakeholders. Um projecto é um empreendimento único, no entanto, temporário porque tem um início e um fim bem definidos. Para que este possa ser executado precisa de ser gerido, isto é, planeado e com controlo nas actividades da equipa de trabalho de modo a atingir os objectivos. Esta gestão passa pela aplicação de conhecimentos, habilidades e pela utilização de ferramentas e técnicas para atingir os requisitos do projecto. A gestão de projecto envolve assim o balanceamento do tempo, custo qualidade e bom relacionamento com o cliente. O sucesso da gestão do projecto depende do prazo do alcance dos objectivos, do desempenho adequado, da aceitação do cliente e do próprio gestor. Daí que o gestor tenha que ter algumas capacidades fundamentais, tais como a liderança, a comunicação, a negociação, a resolução de problemas e a influência na organização. Desta forma, gerar competências na formação de equipas de trabalho é uma grande preocupação, devido às diferentes funções e características de cada individuo (Frame, 1994). O gestor também tem várias actividades e responsabilidades, como definir e controlar objectivos e requisitos do produto, controlar os riscos, definir e avaliar os factores críticos de sucesso, os pontos fortes e os pontos fracos, definir e controlar a WBS, verificar esforço da equipa, definir prioridades, coordenar interacções com os envolvidos no projecto, assegurar que os custos e os prazos estão sendo cumpridos como planeados, assegurar que a qualidade do projecto está a ser alcançada de acordo com o estabelecido, optar por artefactos em discussão coma equipa. Elaborar relatórios e s com o desenrolar dos trabalhos e o acompanhamento do projecto com a respectiva avaliação. Participar em reuniões semanais é pois uma forma de

201 verificar o trabalho desenvolvido e a nova distribuição de tarefas por todos os elementos (Institute, 2001). 3.1 Estratégias e ferramentas de gestão Os diagramas de Gantt são uma ferramenta analítica importante para os gestores. Os diagramas de rede, chamados de gráficos de Pert (Program evaluation and review technique) e o método de caminho crítico (Critical Path Method- CPM), estabelecem aos gestores maior controlo dos projectos. O Process Management Institute (PMI) tem como principal objectivo difundir a gestão de projectos, promovendo e ampliando o conhecimento existente sobre a gestão de projectos. 3.2 Áreas de conhecimento do PMBOK As práticas de gestão de projectos do PMBOK contemplam as seguintes componentes: gestão de integração do projecto; gestão dos limites do projecto; gestão do tempo do projecto; gestão do custo do projecto; gestão da qualidade do projecto; gestão de recursos humanos do projecto; gestão da comunicação do projecto; gestão dos riscos do projecto; gestão da aquisição do projecto e gestão da contratação do projecto. A gestão dos limites do projecto descreve os processos necessários para assegurar o sucesso dos projectos, definir e controlar o que está no projecto e inclui processos de início, planeamento, detalhe, verificação e controlo. A gestão do tempo do projecto descreve processos necessários para assegurar que o projecto termine dentro dos prazos estabelecidos. Caso o projecto se atrase pode causar insatisfação, aumento dos custos e desmotivação. Este tempo é composto pelas reuniões, escrita de relatórios, resolução de conflitos, planeamento e comunicação com o cliente. Estimar a duração de cada actividade serve de suporte para prever os custos futuros. Para estabelecer as responsabilidades e tarefas a cada elemento, deve-se em primeiro lugar fazer uma lista de actividades, para definir uma ordem lógica do trabalho, de modo a atender os objectivos finais do projecto. Tudo isto é feito com a ajuda de algumas ferramentas como o MS Project, para fazer a WBS e diagramas de Gantt/ rede lógica PERT/CPM. A gestão do custo do projecto permite assegurar que o projecto termine com o custo esperado. Esta é composta pelos processos seguintes: planeamento de recursos, estimativa e controlo de custos. A estimativa de custos é realizada na fase da concepção após avaliação dos riscos e estimativa da duração do projecto, isso é conseguido através da ferramenta Costar, implementação do modelo COCOMO. É muito importante controlar e garantir a qualidade de um sistema durante o ciclo de vida do projecto. A gestão da qualidade do projecto existe para assegurar a satisfação dos objectivos do projecto, ou seja, que este está em conformidade com os requisitos e especificações satisfazendo as necessidades reais do cliente. É composto pelos processos: planeamento garantia e controlo de qualidade.

202 A gestão de recursos humanos do projecto é essencial para garantir a melhor utilização das pessoas envolvidas no projecto. Esta exige bastante sensibilidade e conhecimento do ser humano. É composta pelos processos: planeamento organizacional, selecção e desenvolvimento da equipa de trabalho. A gestão da comunicação do projecto assegura a geração, captura, distribuição e armazenamento. Esta gestão é composta pelos seguintes processos: planeamento de comunicações, distribuição de informação, descrição do desempenho da equipa. A gestão dos riscos do projecto descreve os processos de identificação, de análise e de resposta aos riscos sendo de extrema importância para o êxito dos projectos. É composta pelos seguintes processos: planeamento da gestão de riscos, identificação do risco, análise quantitativa dos riscos, desenvolvimento das respostas aos riscos e controlo e monitorização dos mesmos. Um risco é uma variável que pode gerar perigo e elimina o sucesso de um projecto (RUP, 2002). Desta forma o objectivo passa por aumentar o número de eventos positivos e diminuir o número de consequências negativas. Durante o planeamento é necessário identificar e avaliar os riscos. Quando estes são correctamente identificados no início podem ser apaziguados ou eliminados dando tempo para estudar outros riscos. Deve-se fazer uma lista de riscos e avaliá-los através da análise da probabilidade do risco acontecer e o impacto sobre o projecto na fase em que ele se encontra. Isto é importante porque quanto mais próximo do fim, mais crítico se torna o risco. Quando a lista estiver evidenciada deve-se desenvolver um plano para gerir cada risco, estabelecendo estratégias para evitar ou acalmar os mesmos. A gestão da aquisição do projecto descreve os processos necessários para aquisição de serviços e mercadorias fora da organização que desenvolve o projecto. Esta gestão é composta pelos seguintes processos: planeamento e preparação das aquisições, escolha dos fornecedores e administração dos contratos. A gestão da integração do projecto descreve os processos necessários para assegurar a coordenação dos diversos elementos constituintes do projecto e envolve a tomada de decisão, a escolha dos objectivos, dos processos das etapas de desenvolvimento, a execução do plano de projecto e o processo de controlo das alterações. É composto pelos seguintes processos: desenvolvimento do plano do projecto, execução do plano e controlo integrado de mudanças (Institute, 2000). A gestão de projecto utiliza cinco grupos de processos: iniciação, planeamento, execução, controlo e finalização (Institute, 2001). A iniciação corresponde à fase onde a equipa se compromete a executar o projecto. O planeamento corresponde à fase onde são definidos os objectivos e é feita a selecção das alternativas para alcançar os mesmos. Na fase de execução, coordenam-se as equipas de trabalho implementando o plano de projecto definido. A fase de controlo serve para assegurar que os objectivos estabelecidos estão a ser atingidos, através da monitorização e avaliação. A finalização é a fase final do projecto, onde se formaliza a aceitação formal do mesmo. Em suma, o ciclo de vida do projecto serve para definir o início e o fim de um projecto. Segundo o PMBOK, o gestor de projectos aprende a metodologia aplicada à maioria dos projectos, mas estas são alteráveis devido às diversas necessidades e utilizações. O gestor de projectos necessita de ter conhecimentos básicos e uso de técnicas e ferramentas de gestão (MS Project). O PMBOK tem como objectivo o sucesso dos projectos, através da gestão dos mesmos. É um documento que contém técnicas, métodos e processos relativos à gestão de projectos. A gestão de projectos

203 segundo o PMBOK corresponde à aplicação de conhecimentos, habilidades, ferramentas e técnicas às actividades do projecto a fim de alcançar os seus objectivos. A gestão de um projecto tem 4 pontos relevantes: custo, tempo, qualidade, limites e no geral um bom relacionamento com o cliente. A gestão é realizada através de processos, isto é, uma série de acções com o objectivo de alcançar um resultado definido inicialmente. 4 Conclusões Ao longo deste artigo foram expostos os vários problemas subjacentes à gestão e à liderança de uma equipa de trabalho. Conclui-se que os problemas enfrentados são clássicos, no sentido, em que são os problemas que todos os dias aparecem no seio empresarial no contexto da condução dos grupos de trabalho com a finalidade de atingir um objectivo. Deste modo, a gestão de projectos não deve ser praticada de uma forma abusiva, mas com aplicação de conhecimentos, habilidades, ferramentas e técnicas e com o uso de metodologias, para atender da melhor forma as necessidades da organização. Gerir projectos é, actualmente, um grande desafio, contudo é fulcral para a sobrevivência das empresas. Gerir projectos com eficiência constitui um grande esforço de percepção das empresas em adoptar metodologias de gestão de projectos e formar a sua equipa. Um gestor tem de ser formado para usar as metodologias e aplicá-las de forma eficiente. Para que um gestor possa desempenhar bem o seu papel, deve ser dado apoio visível por parte dos seus superiores, resultando no sucesso do projecto. O modelo de gestão adoptado, baseado no RUP, completa as necessidades encontradas em projectos de curto prazo. 5 Referências Boehm, B Software Cost Estimation with COCOMO II. s.l. : Prentice Hall, Collaborative Work Skills for the Beginning IS Professional. Lynch, Kathy Australia : s.n., Corporation, Rational Software Rational Solutions for Windows Rational Unified Process Fleury, Maria As Pessoas na Organização. s.l. : Gente, Frame, J. D The New Project Management Tools for an Age of Rapid Change, Corporate Reengineering, and Other Business Realities. San Francisco : Jossey-Bass Publishers, Harold, Kerzner Gestão de Projectos: Melhores Práticas Institute, Project Management A Guide to the Project Management Body of Knowledge. s.l. : PMI Publishing Division, Project Management Box of Knowledge Institute, Project Managment A Guide to the Project Management Body of Knowledge. Maryland : Project Management Institute Inc., 2001.

204 Johnmarshall, Reeve Understanding Motivation and Emotion. s.l. : John Wiley & Sons, Inc., Kruchten, P The Rational Unified Process: An Introduction. s.l. : Addison- Wesley, Maxwell, John C The 21 Irrefutable Laws of Leadership: Follow Them and People Will Follow You. s.l. : Thomas Nelson, Meredith, J. R. e Mantel, Jr Project Management: A Managerial Approach. New York : John Wiley & Sons, PMI - The World's Leading Professional Association for Project Managment. [Online] [Citação: 20 de Janeiro de 2011.] RUP RUP - Rational Unified Process. s.l. : Rational Software, 2002.

205 A Interacção com uma Equipa de Trabalho Ser Consultor vs. Ser Coordenador de Projecto Henriques, Micael Ribeiro Universidade do Minho Abstract: Um projecto de desenvolvimento de Software exige a participação de várias entidades especializadas em diversas áreas. Ao longo do projecto realizado no âmbito da unidade curricular de Análise e Concepção de Sistemas de Informação, foi possível vivenciar o papel de duas dessas entidades: o consultor e o coordenador de projecto. Dessa forma, pôde-se perceber tanto o modo como cada um desses intervenientes age, as diferenças existentes entre ambos, bem como as dificuldades que possam surgir na realização das tarefas adequadas a cada uma das funções. Palavras-chave: consultor, coordenador de projecto, interacção, equipa 1. Introdução No mundo das empresas, a realização de um projecto exige a participação de várias entidades diferentes para a sua concretização. E, claro está, um projecto de desenvolvimento de Software não é excepção. Desde os analistas até aos responsáveis pelos testes, passando pelos arquitectos, programadores, entre outros, muitos são os intervenientes ao longo do ciclo de vida de um Software. O projecto realizado no âmbito da unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI) permitiu compreender melhor o modo de actuação de dois diferentes tipos de intervenientes: o consultor e o coordenador. 1.1 Contexto do Projecto Um dos métodos de avaliação propostos no âmbito da unidade curricular de ACSI consistia na colaboração com um grupo de trabalho constituído por alunos de licenciatura a fim de desenvolver um projecto apresentado na unidade curricular de licenciatura Processos e Metodologias de Software (PMS). Este método de avaliação foi o escolhido por ter sido considerado bastante interessante, uma vez que nunca se experienciou tal prática, e importante por permitir obter-se uma 1

206 percepção daquilo que se poderá vir a encontrar aquando da entrada no mercado de trabalho. 1.2 Escolha do Tema O motivo da escolha do tema A Interacção com uma Equipa de Trabalho Ser Consultor vs. Ser Coordenador de Projecto tem muito a ver com a oportunidade oferecida com a realização deste projecto. Muitos estudantes universitários em fase final da sua formação ainda não têm ideias concretas acerca do papel que querem desempenhar na sua área. Na área em que o mestrado de MEGSI se insere, muitas são as opções disponibilizadas para uma futura carreira profissional. Através desta experiência, pôde-se experienciar e perceber como funcionam duas dessas opções. Os vários aspectos técnicos presentes ao longo do projecto, como a oportunidade para relembrar diferentes tipos de diagramas, contactar na prática com o RUP, que foram realmente outros aspectos positivos que resultaram da experiência vivida, podem ser considerados temas em falta ao longo do relatório. Mas enquanto que estes aspectos foram abordados ao longo da licenciatura, o contacto directo com uma equipa de trabalho, desempenhando um papel específico no meio do grupo, com os prós e contras que se obteve, foi muito mais enriquecedor no aspecto da preparação para aquilo que se encontrará no mercado de trabalho, já não sendo surpresa se algum dos problemas aqui encontrados virem também a surgir futuramente nessa nova realidade. Daí advém o grande interesse encontrado no tema escolhido. 2. Consultor vs. Coordenador Ao longo deste capítulo, irão ser comparadas as vivências como consultor com as vivências como coordenador. O modo como cada um desses papéis interage com uma equipa de trabalho, os problemas ocorridos em cada situação, as soluções para os mesmos e a comparação com o que se pode encontrar no mundo empresarial são alguns dos temas analisados nos pontos 2.1 e A Relação Consultor Equipa de Trabalho Na primeira parte da experiência vivida, coincidente com a parte de planeamento da fase de Inception do projecto de PMS, a função desempenhada na relação 2

207 com a equipa de trabalho foi a de consultor. Esse papel, tal como qualquer outro, tem características e funções bem particulares. Neste caso, o consultor procura actuar como um apoio para quem recorre aos seus serviços. O significado de ser consultor, a forma como se agiu ao desempenhar esse papel, bem como os resultados advindos da relação com a equipa de trabalho, são alguns dos pontos que irão ser focados de seguida Ser Consultor Para um aluno universitário que frequenta um curso académico relacionado com as actividades desenvolvidas nas empresas, torna-se normal o facto de já ter um conhecimento no mínimo básico da existência de profissionais em consultoria e do papel dos mesmos no mundo empresarial. Apesar dessa provável ideia já feita, a realização deste projecto levou à necessidade de se ter uma maior certeza acerca do que é ser consultor e daquilo que são as suas funções e modos de agir, de forma a tornar a experiência mais realista e séria. De acordo com a definição apresentada no Glossário de Fulgencio [1], consultor é aquele que dá pareceres acerca de assuntos de sua especialidade. É o profissional designado para actuar numa área especializada. Ainda segundo Larry Greiner e Robert Metzger, a consultoria de gestão é um serviço de consultoria proporcionado às organizações por pessoas especialmente treinadas e qualificadas que ajudam, de forma objectiva e independente, a organização do cliente para identificar problemas de gestão, analisar os mesmos, recomendar soluções e ajudar, quando solicitado, na implementação destas [2]. Um indicador da importância atribuída ao papel do consultor é um artigo publicado em 2008 pela revista americana U.S. News and World Report [3], que considerou a profissão de Consultor como sendo uma das melhores profissões para o ano de Compreendidas as funções atribuídas ao consultor e a sua importância, procurouse actuar da forma mais correcta de acordo com o referido papel junto da equipa de trabalho Modo de Actuação Uma vez entendidas as funções a serem desempenhadas por um consultor, procurou-se aplicar a teoria à prática junto do grupo de trabalho. 3

208 Na fase inicial, o objectivo consistiu em contextuar-se no tema e finalidade do projecto, com o intuito de, quando posteriormente questionado pela equipa de trabalho, poder aconselhar os seus elementos da forma mais adequada possível. A contextualização foi realizada tanto através de pesquisa acerca do tema geral (funcionamento de uma misericórdia) como do contacto directo com o cliente. Essa fase que antecede o contacto directo com a equipa de trabalho é fundamental para que a interacção futura com a mesma seja produtiva, uma vez que permite desde logo poder antecipar possíveis dúvidas que possam surgir e também minimizar o tempo de resposta quando solicitado. Após a fase de compreensão do projecto, actuou-se junto do grupo de trabalho. Em 2001, Block propôs o estabelecer uma relação de colaboração com os seus clientes como uma das metas a serem atingidas por um consultor [4]. E assim se procurou fazer na primeira abordagem com a equipa de trabalho, informando-os do porquê da presença de um consultor, quais as funções do mesmo e fazendo-os ver de que era mais um para ajudar e não para mandar, ao contrário do que poderiam pensar. Para além disso, forneceu-se-lhes material extra que podia ajudá-los na realização do projecto. Toda essa abordagem inicial tinha como objectivo aproximar ambas as partes para que a interacção funcionasse da melhor maneira. A partir daí, sempre procurando actuar como se de um verdadeiro consultor se tratasse, aguardou-se que a equipa acorresse aos serviços disponibilizados. Isto porque, se se imaginar um profissional em consultoria, este não adivinha as necessidades das empresas, tendo de ser estas a procurarem os seus serviços quando necessitam. O contacto pessoal com a equipa de trabalho ocorreu inicialmente apenas durante as aulas práticas de PMS por indicação do grupo de trabalho. Nesses contactos directos, e relembrando o modo como um consultor deve agir, aquilo que se procurou fazer foi aconselhar a equipa, mostrar as várias possibilidades existentes, indicar os prós e contras de cada um; não era objectivo impor ideias e exigências pessoais, nem fazer o trabalho por eles, procurando que a última palavra fosse sempre a da equipa de trabalho. 4

209 2.1.3 Problemas Encontrados Tal como o próprio nome indica, um consultor é um profissional que é consultado, i.e., não é seu papel procurar empresas que necessitem de ajuda; são sim as empresas necessitadas que devem procurar os seus serviços, tal como já mencionado anteriormente. E essa característica resultou no primeiro obstáculo na interacção com a equipa de trabalho: não houve procura por parte da mesma relativamente ao consultor. Os momentos de contacto directo eram pouco ou mesmo nada produtivos, uma vez que os elementos do grupo de trabalho não expunham dúvidas nem questionavam o modo de procedimento, desaproveitando por completo a possibilidade de recorrerem ao consultor, sendo este visto como um corpo estranho. Nem o facto de se ter fornecido diversos meios de contacto à distância, como número de telemóvel ou , fez com que utilizassem esses mesmos meios para encetarem contacto. E mesmo quando questionados acerca de possíveis dúvidas ou problemas encontrados, deparou-se na maioria das vezes com respostas de negação, o que minimizou a margem de intervenção por parte do consultor. Não se pode, obviamente, obrigar ninguém a falar, e isso não facilita uma interacção que havia de ser baseada na troca de ideias. Toda essa falta de interacção trouxe incertezas ao consultor por este não saber como aconselhar quem não quer ser aconselhado Por outro lado, constatou-se que a própria equipa apresentava muito pouco trabalho feito, o que mostrava ser a causa da escassez de dúvidas. Esse problema nem era benéfico para a equipa de trabalho, uma vez que isso apenas iria obrigá-la a um esforço extra aquando da aproximação do prazo final de entrega; mas também não o era para o próprio consultor, visto não estar a actuar de acordo com as suas funções, desaproveitando a oportunidade concedida Medidas Tomadas para a Resolução dos Problemas Uma vez percebidos os problemas existentes, foram tomadas certas medidas como forma de solucioná-los. De acordo com informações obtida em conversa durante as aulas de ACSI, certas empresas de consultoria queixam-se por serem contratadas por empresas clientes e depois de não serem consultadas pelos seus serviços. Isso acaba por levar os colaboradores das primeiras a actuarem quase como coordenadores junto das segundas. E essa foi também a atitude a ser tomada na realização deste projecto 5

210 universitário, mas sem nunca esquecer que a verdadeira função continuava a ser a de consultor. Block considera que um consultor é uma pessoa que está em posição de exercer alguma influência sobre um indivíduo, grupo ou organização, mas que não tem o direito de produzir mudanças ou programas de implementação [4]. Foi com essa ideia que se passou a abordar o grupo de trabalho de forma diferente da inicial. Em vez de esperar que fosse a equipa de trabalho a entrar em contacto, passou-se a querer ir ao seu encontro por iniciativa própria. Para isso, sugeriram-se, e não se impuseram, marcações de reuniões fora da aula, de modo a poder haver uma maior interacção entre ambas as partes. A abordagem para tal foi realizada sempre sem esquecer o verdadeiro papel que se estava a desempenhar, utilizando frases do género talvez fosse melhor marcar-se uma reunião em vez de frases indicadas para coordenadores vamos marcar uma reunião. A própria atitude na interacção com a equipa de trabalho alterou-se. Em vez de uma abordagem mais pacífica, estando na expectativa, procurou-se, digamos, espicaçá-los com perguntas e sugestões constantes, sem que nada fosse perguntado por eles. Essa atitude mais empreendedora tinha como intuito apegarse-lhes de forma a motivá-los. A alteração de atitude na abordagem ao grupo de trabalho solucionou alguns dos problemas identificados anteriormente, sendo o mais visível o problema relacionado com a falta de interacção entre o consultor e a equipa de trabalho. Com a mudança ocorrida, a interacção foi maior e melhor. Mas outros foram os problemas que continuaram a existir mesmo após a mudança no modo de interagir, sendo que o mais preocupante foi o continuar da não apresentação de trabalho feito. Apesar da atitude indirectamente mais exigente, o papel do consultor é apenas opinar e aconselhar o segundo, não podendo desse modo exigir trabalho feito, e assim persistiu um pensamento algo geral entre os vários elementos da equipa de trabalho de ainda há muito tempo para fazer Uma conclusão retirada deste aspecto ocorrido é que, sem a auto-motivação por parte do grupo de trabalho na realização do projecto, um consultor pouco é necessário 6

211 2.1.5 Diferenças e Parecenças entre a Experiência Vivida e a Realidade nas Empresas As motivações existentes no ceio de uma equipa de trabalho constituída por alunos universitários são, compreensivelmente mas também infelizmente, diferentes das que existem numa equipa de profissionais de uma empresa, muito devido ao diferente nível das obrigações associadas a cada um desses tipos de entidade. Enquanto que, generalizando os casos, um aluno ainda em fase inicial da sua formação universitária sente ter obrigações somente para consigo próprio, não necessitando de se justificar perante os docentes, e despreocupando-se se a sua formação demora mais um ano, um colaborador de uma empresa tem obrigações perante os seus superiores no que toca ao trabalho feito, ao cumprimento de prazos; tem a pressão do seu trabalho poder atingir proporções importantes para a empresa; e tem a motivação gerada pela realização pessoal e pelo recebimento do salário. Essas diferenças existentes entre os dois ambientes abordados fazem com que a própria forma como um consultor actua junto de cada um seja diferente. Num ambiente empresarial espera-se que haja uma grande procura em relação a um consultor devido à sua importância no desenvolvimento de projectos. Esse facto leva a querer que essa entidade esteja em constante actividade junto da equipa de trabalho, fazendo praticamente parte dela. Essa é uma cumplicidade que não se verificou ao longo da experiência pessoal. A equipa de trabalho não deu a devida importância ao papel do consultor, acreditando ser possível, com mais ou menos dificuldade, finalizar correctamente o projecto. Não que isso seja impossível, mas a experiência de uma pessoa que já passou por essa fase traria certamente um apoio importante. Esse é um facto que no mundo empresarial já se percebeu. Mas também existem algumas semelhanças entre a experiência vivida e aquilo que é a realidade entre profissionais. Apesar de se esperar uma atitude séria por parte duma equipa de trabalho constituída por profissionais, por vezes também ocorrem falhas. Desde o faltar a reuniões até à mostra de desinteresse, passando pelo não cumprimento das ideias previstas, tudo são atitudes que foram verificadas junto da equipa universitária e que também o podem ser em equipas de profissionais. 7

212 2.2 A Relação Coordenador de Projecto Equipa de Trabalho Após a primeira fase do projecto em que se actuou como consultor na interacção com a equipa de desenvolvimento, esta segunda fase, em que se procedeu ao desenvolvimento da fase de Inception para o projecto da Misericórdia de Guimarães, representou uma mudança de papel, passando a actuar-se como coordenador de projecto. Uma vez que a maneira como esta entidade actua é diferente da realizada pelo consultor, foi necessário perceber as novas funções a desempenhar e a forma como se passaria a interagir com o grupo de trabalho. Todos esses aspectos foram desenvolvidos e estão referidos nos subtemas seguintes Ser Coordenador de Projecto Tal como acontece com consultor, também o termo coordenador indica desde logo uma ideia daquilo que é o seu papel e as suas funções junto de uma equipa de trabalho. Como ideia pessoal inicial, o coordenador é a entidade que coordena os elementos de uma equipa de trabalho, distribui tarefas por cada um deles, marca reuniões e indica prazos, ajuda na realização das tarefas e supervisiona o trabalho desenvolvido. Segundo uma primeira descrição dada em [5], um coordenador de projecto é uma entidade que combina várias responsabilidades, incluindo comunicação, gestão da agenda, coordenar materiais das reuniões e assistir os membros da equipa do projecto. Mas numa análise mais aprofundada feita por Lock [6], o nível de responsabilidade e autoridade dadas a um gestor de projecto varia consideravelmente de uma organização para outra. Em alguns casos, o gestor de projecto age unicamente como planeador ou coordenador, com o mínimo de poder e autoridade. Em outros negócios, o gestor de projecto terá total autoridade sobre todos os responsáveis pelo alcançar dos objectivos do projecto. Foi com base nas várias ideias obtidas através da pesquisa realizada que se procurou agir da maneira mais correcta Modo de Actuação Desde o primeiro momento em que foi assumido o papel de coordenador, em substituição do de consultor, procurou-se adaptar a interacção com a equipa de 8

213 trabalho de acordo com a nova função desempenhada. Esta alteração veio melhorar vários aspectos que estavam a ser obstáculos na primeira abordagem como consultor. A primeira e principal decisão tomada foi a de começarem a ser marcadas semanalmente uma ou mais reuniões de modo a que o trabalho desenvolvido pela equipa fosse acompanhado mais de perto e de forma mais eficaz. Para além de proporcionarem uma conversa aberta entre os diversos elementos de trabalho, incluindo o coordenador, sobre diversos assuntos, tais como dúvidas que pudessem ter surgido, modos de procedimento, entre outros, essas reuniões também serviam para avaliar o trabalho desenvolvido, identificar as tarefas a serem realizadas na semana seguinte e proceder à distribuição das mesmas pelos diversos elementos de trabalho. Para além das reuniões, um envio mais constante de s foi outra maneira utilizada para se obter um maior contacto com os elementos da equipa de trabalho. Este meio permitiu um acompanhamento à distância do modo como estava a correr o desenvolvimento do trabalho planeado. Também tinha como objectivo funcionar como pressão para que as tarefas planeadas não caíssem no esquecimento. Como forma extra para supervisionar o trabalho desenvolvido semanalmente, de modo a verificar a realização ou não das tarefas planeadas, foi criada uma ficha de preenchimento individual para cada elemento da equipa de trabalho. Nela eram indicadas, entre outros parâmetros secundários, as tarefas desenvolvidas e o tempo gasto para cada uma delas, bem como possíveis dúvidas encontradas. No contacto pessoal com os elementos da equipa de trabalho, a interacção conseguida foi saudável, procurando-se ser mais um elemento do grupo em vez de ser visto como sendo aquele que manda. Essa opção pessoal teve como objectivo permitir um melhor ambiente no ceio do grupo, como forma de transmitir um suficiente, mas não em excesso, à vontade Problemas Encontrados A alteração de estatutos ocorrida trouxe algumas melhorias no funcionamento da interacção com a equipa de trabalho. Mas a verdade é que também se mantiveram alguns dos problemas já identificados na primeira fase do projecto, para além do surgimento de outros novos. 9

214 Um exemplo dos problemas ocorridos foi o facto da marcação de reuniões nem sempre ter surtido o efeito desejado. Tendo estas como objectivo reunir o grupo todo de maneira a debaterem-se em conjunto assuntos relacionados com o projecto, o mesmo não foi atingido uma vez que, quando marcadas fora do horário de aulas da UC de PMS, dificilmente compareciam todos os elementos da equipa. E é ligado a essa falta de comparecimento que está parte de uma preocupação surgida: o desinteresse demonstrado. Neste aspecto em concreto, o desinteresse foi verificável através da não existência de uma justificação viável para tal sucedido, o que comprova a preocupação referida. A explicação dada previamente da importância das reuniões marcadas não obteve uma reacção positiva como era de esperar. Outra parte que comprova o desinteresse apresentado está relacionada com a comunicação por s. Este método de interacção não foi bem sucedido uma vez que a maioria dos s enviados não obtiveram resposta por parte dos elementos visados. Isso acabou por complicar ainda mais tanto o relacionamento mútuo, como a própria viabilidade do projecto a ser realizado no âmbito de PMS. Por muito que se é coordenador, é impossível obrigar alguém a ter a atitude certa se ele próprio não demonstra querer tê-la Medidas Tomadas para a Resolução dos Problemas Talvez por falta de experiência, não se soube muito bem o que se deveria fazer para resolver os problemas encontrados A verdade é que, como coordenador, já era o próprio a tomar todas as decisões para que a interacção com a equipa de trabalho funcionasse da melhor maneira: marcavam-se as reuniões consideradas necessárias, enviavam-se s constantemente, as tarefas eram divididas consoante a decisão do próprio, bem como a data limite para as suas realizações E se nem assim funcionava, lamenta-se a expressão mas só mesmo de chicote na mão é que poderia funcionar correctamente E a verdade é que, não no sentido físico da expressão obviamente, a partir daí esteve-se autenticamente de chicote na mão, com uma atitude mais séria comparativamente com a anterior. Isto é, antes, como foi referido acima, procurou-se ter um ambiente mais amigável, tentando ser mais um elemento do grupo de maneira a deixar os outro elementos mais à vontade para trabalharem; 10

215 mas visto que essa opção não teve o efeito desejado, passou-se a infringir uma interacção mais típica de coordenador-equipa de trabalho. A primeira atitude tomada a partir daí foi reunir a equipa para transmitir os aspectos que não estavam a correr bem e o modo como iria passar a ser a interacção. Procurou-se atingir a consciência de cada elemento fazendo-os perceber que um bom ou mau trabalho só iria ser, respectivamente, benéfico ou prejudicial para eles próprios. Outra atitude tomada foi a de pressionar regularmente via telemóvel e s a realização das tarefas. Com isso procurou-se obter uma reacção qualquer que fosse por parte dos elementos do grupo. Visto que até então não tinha havido nenhuma, qualquer tipo de reacção que surgisse seria positivo, nem que fosse a realização das tarefas só para que não os chateassem mais. Não se achou necessário marcar mais reuniões pelo simples motivo de que o problema não estava na falta das mesmas, mas sim na falta de comparação dos elementos da equipa de trabalho. O que mudou em relação às reuniões foi o modo como decorriam. Em vez de seguir uma linha mais de conversa aberta, visto que essa não tinha resultado anteriormente, continuou-se a ouvir as opiniões de cada elemento mas as decisões quanto às tarefas e prazos eram única e exclusivamente tomadas pelo coordenador em mais uma demonstração da diferenciação dos papéis como forma de pressão. Foi durante as reuniões que surgiu então a lembrança de uma ideia defendida por um docente aquando da licenciatura, que acreditava que a melhor maneira para ter um aluno motivado era através de reforços positivos. Esta ideia defendida baseava-se num simples modo de actuar: em vez de afirmar está mal, dizer está bem, mas. O factor psicológico é sem dúvida um aspecto muito importante a ter em conta quando se quer motivar alguém. O objectivo das alterações ocorridas após a identificação dos problemas era mexer com a equipa de trabalho em termos psicológicos, e não tanto dar-lhes ainda mais trabalho como que a despachar o papel de coordenador e deixar o grupo entregue a si mesmo. E analisando os resultados de tais alterações, conclui-se que acabaram por se verificar várias melhorias na interacção. Houve empenho coordenado com a divisão de tarefas e prazos estabelecidos pela entidade coordenadora, o que acabou por tornar a interacção mais rentável e agradável. Este aspecto vem comprovar que, fosse nesta experiência ou numa empresa, o coordenador não 11

216 deve abandonar a equipa de trabalho, mas sim procurar a melhor maneira para obter o melhor funcionamento do grupo Diferenças e Parecenças entre a Experiência Vivida e a Realidade nas Empresas A experiência como coordenador num ambiente universitário permitiu viver algumas práticas semelhantes àquelas que profissionais com essa mesma função vivem no dia-a-dia nas empresas. O coordenador é sempre uma entidade com maior responsabilidade visto ter poder de decisão em determinados aspectos. Mas o aspecto que mais marcou esta experiência como coordenador está relacionado com a maneira como se deve abordar a interacção com uma equipa de trabalho. Este aspecto levou a errar inicialmente, o que certamente aconteceria também num ambiente profissional de uma empresa. Isto porque, ao querer desde o primeiro instante transmitir ao grupo de trabalho que, apesar da compreensão pessoal das diferentes funções adjacentes a um coordenador, se era mais um entre eles para deixá-los mais à vontade, sem antes fazê-los perceber as diferenças existentes e a importância de um coordenador numa equipa, levou a um maior relaxamento devido ao excesso de confiança criado. O que por arrastamento começou por prejudicar a realização do projecto. E este aspecto poderia muito bem acontecer num ambiente profissional, onde a entidade coordenadora poderia não ser levada a sério caso não mostrasse confiança e delineasse as funções de cada um. Seja para uma situação ou outra, percebeu-se que a abordagem inicial é fundamental para o sucesso da interacção. E essa primeira abordagem deve ter como objectivo transmitir a perfeita percepção por parte de todos os elementos de uma equipa acerca dos papéis de cada um e das suas respectivas funções e obrigações. Esta experiência como coordenador possibilitou errar agora, evitando o mesmo erro um dia, numa empresa, se se vier a desempenhar a mesma função. 3. Conclusão e Análise Crítica Aquilo que inicialmente parecia ser uma complicação na interacção com a equipa de trabalho veio a ser na realidade uma experiência rica em termos dum maior e melhor conhecimento de dois diferentes papéis importantes no desenvolvimento de um projecto. 12

217 O papel de consultor mostrou poder ser algo ingrato caso a entidade que supostamente deveria utilizar os seus serviços não mostre interesse nesse sentido, o que pode realmente acontecer no mundo profissional e veio a observar-se na experiência vivida. O consultor necessita de se adaptar a cada situação consoante a mentalidade da equipa de trabalho com quem interage. Com algumas equipas, certamente que será abordado constantemente para exercer as suas funções; mas com outras, mais pacíficas, ele terá de encontrar soluções para incentivar os elementos da equipa para exercerem uma melhor interacção. Por outro lado, o consultor tem uma relação com a equipa de trabalho mais estreita, o que lhe permite tomar as decisões adequadas quando algo não corre como deveria. O seu maior obstáculo será obter por parte da equipa de trabalho uma total compreensão dos deveres que têm perante a entidade coordenadora sem que percam o sentido de responsabilidade fornecido a essa entidade. No que diz respeito a ambas as entidades, existe um ponto em comum que sobressai: necessitam de estar sempre um passo mais à frente da restante equipa em termos de conhecimento. Se, caso contrário, mostrar que o seu conhecimento não é tão elevado quanto os restantes elementos, poderá arriscar-se a perder a confiança depositada em si. Isso obriga-o a um esforço redobrado para ter sucesso nas suas funções e ganhar o reconhecimento por parte da restante equipa, seja aplicado ao consultor ou ao coordenador. Numa das últimas aulas de ACSI, colocou-se a questão de se a forma como foi realizada a interacção com a equipa de trabalho, começando por agir como consultor e passando posteriormente a agir como coordenador, tinha sido a mais correcta ou se seria preferível ter começado desde o início como coordenador. A grande maioria das opiniões foi peremptória em considerar a segunda opção como a mais correcta. Mas durante a realização deste relatório, que funcionou como forma de organizar toda a informação acumulada ao longo da experiência vivida, pôde-se concluir que várias foram as aprendizagens positivas assimiladas, desde as diferentes percepções sobre o mesmo projecto até à compreensão do possível surgimento de problemas na interacção com uma equipa de trabalho, passando pelo conhecimento necessário, o tipo de comunicação adequado, a melhor forma de dar apoio, a importância da experiência pré-adquirida, entre muitas outras. Todos os aspectos mencionados levam a uma única conclusão: se a mesma questão da aula fosse colocada agora, a resposta seria com certeza diferente. 13

218 4. Referências Bibliográficas [1] Fulgencio, Paulo César, Glossário Vade Mecum, Mauad Editora, 2007, pág. 151 [2] Kubr, Milan, Nature and Purpose of Management Consulting in Management Consulting: a Guide to the Profession, 4ª edição, International Labour Organization, 2002, pág. 3 [3] Marty Nemko, 11 de Dezembro de 2008, Best Careers 2009: Management Consultant, acedido em 10 de Janeiro de 2011 [4] Block, Peter, Consultoria: o desafio da liberdade, 2. ed. São Paulo: Pearson Education do Brasil, 2001 [5] Melanson, G., What Is a Project Coordinator, acedido a 23 de Janeiro 2011 [6] Lock, Dennis, Key People in the Organization in Project Management, 9ª edição, Gower Publishing, 2007, pág

219 Dificuldades e decisões de Consultadoria & Gestão de Projectos Ricardo Sousa Cardoso (A52379) Analise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão de Sistemas de Informação, Departamento de Sistemas de Informação, Universidade do Minho Abstract Este artigo refere os vários aspectos e acontecimentos ao longo da unidade curricular Análise e Concepção de Sistemas de Informação (ACSI), mais propriamente no que diz respeito à minha participação na orientação e gestão de um grupo de trabalho da unidade curricular de Processos e Metodologias de Software (PMS). Este artigo tem como objectivo mostrar o que foi realizado, como foi realizado, as dificuldades e objectivos alcançados. Palavras-chave UML, Gestão de projectos, Casos de Uso, Coordenação de projectos, Tomada de decisão, Análise de Negócio, Modelação de Negócio, Consultor, Tomada de decisão. 1. Introdução A Gestão a cada dia que passa, torna-se mais importante nas nossas vidas e nas nossas empresas, mais concretamente na gestão de projectos da mesma [1]. Actualmente uma empresa que não crie os seus projectos através das várias regras que foram implementadas ao longo destes vários anos, dificilmente terá sucesso. Mas para isso esses projectos terão que ter um gestor, gestor esse que estará encarregue de coordenar todo o projecto para que este corra da melhor forma e com o mínimo de percalços possíveis. O gestor do projecto será também o responsável por tomar grande parte das decisões, decisões que podem levar o projecto a alcançar os objectivos propostos. De uma forma geral um gestor pode decidir o sucesso ou o insucesso de uma operação ou mesmo de um projecto. O que irá ser apresentado ao longo deste artigo é um relato de uma experiencia como consultor e coordenador de uma equipa de projecto. Este relato deve-se aos 1

220 termos de avaliação da unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI) do Mestrado em Engenharia e Gestão de Sistemas de Informação. Este artigo pretende mostrar o trabalho realizado ao longo do semestre, assim como os problemas e dificuldades que obtive no seu decorrer e que decisões a tomar na resolução dessas situações. 2. O Projecto Como referi a cima, este trabalho teve como objectivo apoiar um grupo de projecto da Licenciatura em Tecnologias e Sistemas de Informação. Mais concretamente, desempenhei dois papéis neste projecto, o de consultor e o de coordenador, ambos tiveram as suas dificuldades e a sua importância na minha formação, são dois papéis diferentes e que me deram a conhecer as duas faces de interacção num projecto. A seguir irei falar dos pontos mais importantes para que se perceba as várias etapas deste trabalho O problema O problema pode ser dividido em duas partes distintas, a de consultor e a de coordenador. Como o nome indica, coordenador ou gestor é uma pessoa que está responsável por orientar algo ou alguém de forma a atingir certos objectivos, ao gestor/coordenador está também implícita a tarefa de tomar decisões [2]. Em relação ao consultor, este apenas tem como função dar pareceres, a respeito de assuntos ou matéria dentro da sua especialidade [3]. Estes são os dois papéis que tive que desempenhar no decorrer deste semestre e que levam a dois problemas distintos, o primeiro, o de consultor que decorreu durante a terceira entrega da unidade curricular de Processos e Metodologias de Software (PMS) e que teve como principal objectivo apoiar o grupo no desenvolvimento do seu trabalho. Contudo o resultado não foi bem o esperado e por isso foi-nos atribuído um papel mais preponderante e activo no grupo e no projecto. Este novo papel incidiu sobre a quarta e ultima entrega onde executei funções de coordenador/gestor, em que o principal objectivo era gerir todo o desenrolar desta etapa do trabalho, incluído esclarecer as duvidas e apoiar o seu desenvolvimento O Grupo Este talvez seja um dos pontos mais importantes na gestão de um projecto, pois o sucesso do mesmo despende em grande parte do trabalho desempenho pelo grupo de trabalho. E este caso não era excepção, pois eu sabia que muito provavelmente 2

221 iria encontrar pela frente um grupo inexperiente na realização de projectos deste tipo. E não me enganei, o grupo que me foi atribuído pelo professor da unidade curricular de Processos e Metodologias de Software, era constituído apenas por três elementos e logo ai surgiu o primeiro problema, pois o trabalho estava projectado para grupos com cinco ou seis elementos. O grupo iria estar sujeito a um maior esforço para cumprir com as tarefas que o trabalho exigia, mas no decorrer da semana seguinte foram acrescentados ao grupo mais três elementos, perfazendo assim um grupo de seis elementos, solucionando assim o problema. Apesar de não ser muito relevante para este artigo, a seguir apresento uma tabela com os elementos do Grupo 2 do turno PL2. Tabela 1 Elementos do grupo de trabalho Número Nome José Pedro Coutinho Jean Pierre Matos Pedro Miguel Costa Luís Filipe Veloso Ricardo Manuel Brioso João Pedro Ferreira À primeira vista não me pareceu um grupo com muita disposição para trabalhar de forma coesa e colaborativa e o mesmo foi demonstrando ao longo da primeira fase do projecto, pouca união e espírito de equipa, e para além de tudo isto o interesse demonstrado também nunca foi soberbo, longe disso, o interesse dos vários elementos foi sempre superficial e eu diria ainda que na primeira fase onde desempenhava o papel de consultor o interesse do grupo era nulo, pois nunca demonstraram preocupação de esclarecer o que quer que seja e o relatório entregue na primeira fase é resultado disso mesmo As Reuniões As reuniões tiveram uma grande importância no decorrer do projecto, já que foi nas mesmas onde muitos assuntos foram debatidos, onde foram consolidadas ideias, onde verdadeiramente surgiram dúvidas e se fazia evoluir o que era verdadeiramente importante, o trabalho. Inicialmente as reuniões decorriam durante as aulas práticas de PMS, pois foi o que ficou previamente estabelecido no primeiro contacto com o grupo. Entretanto, as reuniões que foram surgindo fora do horário da aula foram sempre requeridas por mim, pois nunca recebi solicitações para isso, mas com o decorrer do projecto e com as minhas novas funções de coordenador, essa situação foi-se alterando, até que me foi solicitada ajuda mais frequentemente. Foi nestas reuniões que realmente o trabalho levou o rumo certo e onde tomei decisões importantes para o desenrolar do trabalho. Mas estas reuniões nem sempre foram fáceis, pois o grupo não estava preparado para um projecto destes e pelo que o grupo me transmitiu as aulas teóricas andaram sempre um pouco atrasadas em relação às etapas dos trabalhos, o 3

222 que nem sempre ajudou. Tudo isto junto fez com que o grupo tivesse dificuldades acrescidas no desenrolar dos trabalhos Consultor de projecto Neste ponto vou descrever a minha função de consultor de projecto, basicamente o que foi feito, as dificuldades e decisões que tive que tomar. Como já referi antes esta foi a função que me foi imposta na primeira fase deste projecto e que foi referente à terceira entrega da unidade curricular de PMS, logo a minha função era apoiar e esclarecer dúvidas que o grupo coloca-se sobre essa mesma etapa do projecto. A verdade é que a minha participação nesta fase foi um pouco estranha, pois nunca me foi solicitada ajuda ou esclarecimentos e se chegou haver comunicação entre o consultor e o grupo, foi sempre devido à minha preocupação em saber o que estavam a fazer e de que necessitavam. Em relação ao apoio aqui realizado, que não foi o esperado, baseou-se no aconselhamento de algumas referências importantes, como por exemplo o Rational Unified Process (RUP) onde aconselhei a estudarem as varias fases e artefactos da Inception. Penso que neste ponto até correu de forma favorável pois o grupo consultou o mesmo e durante uma das sessões praticas foram-me colocadas algumas questões relacionadas com o mesmo e ao qual eu tentei responder da forma mais explicita possível. Nesta fase do projecto em que foi necessário recorrer ao RUP consegui desenvolver as minhas aptidões em relação ao mesmo, pois, as dúvidas deles levaram-me a que tivesse que aprofundar mais os meus conhecimentos sobre a matéria e isso fez com que o meu conhecimento hoje seja mais completo em relação ao RUP. Mas os meus conselhos não ficaram por aqui, pois para algumas dúvidas pontuais que surgiram sobre a gestão de projectos, aconselhei-os a analisar o PMBOK, mas ai as coisas não correram tão bem, pelo que fui percebendo na realização do trabalho do grupo eles não se guiaram pelo mesmo e nem sequer colocaram mais nenhuma questão sobre o assunto. Em conclusão a minha experiência como consultor foi um pouco superficial, o grupo nunca colocou questões nem grande vontade de solicitar a minha ajuda, muito do que foi feito teve que ser forçado por mim. Mas no conto geral teve alguns aspectos positivos como referi a cima, e serviu para perceber de que forma o consultor tem de actuar perante uma equipa de trabalho e o que nos espera lá fora Coordenador de projecto Após a primeira entrega do grupo (PMS) foram debatidas as nossas funções como consultor, pois as coisas não correram como desejado e nem sempre foi fácil perceber o que o grupo precisava e por isso foi-nos sugerido a função de coordenador/gestores de projecto. Penso que de modo geral a opção foi bem aceite por todos, apesar de algumas dúvidas de como as coisas iriam correr. 4

223 Na minha nova função de coordenador comecei por comunicar ao grupo o meu novo papel, o grupo ficou surpreendido pois não estavam a par do sucedido, após falar um pouco com o grupo sobre as minhas novas funções, coloquei mãos ao trabalho e comecei por definir as fases da gestão de projectos. Imagem 1 Fases da gestão de projectos [2]. Após a definição das fases do projecto, decidi analisar o relatório que foi realizado na entrega 3. Este não estava muito famoso, notava-se falta de empenho desde a organização do trabalho até à concepção dos diagramas, passando pelo texto explicativo. Comecei por realizar um novo planeamento, pois o realizado na fase anterior não se encontrava de acordo com a minha nova função, reformulei alguns pontos da Inception, nomeadamente da visão e da linguagem de modelação Unified Modeling Language (UML), pois estes dois pontos eram fulcrais nesta fase do projecto, mas não só. Também propus ao grupo a reformulação de alguns pontos da entrega anterior que estavam no meu entender muito fracos e incoerentes. No novo planeamento estipulei alguns pontos de monotorização e controlo que passam por entregas intermédias, entregas essas que teriam que ser enviadas para mim nas datas estipuladas. Após isto entreguei o novo planeamento ao grupo e apresentei a primeira fase a desenvolver, o grupo cumpriu e até mostrou algum trabalho do meu agrado, apesar de alguma falta de brio notou-se que foi feito um esforço para realizar um bom trabalho, a partir daqui as coisas começaram a correr melhor, as entregas foram sempre realizadas a tempo e quando não era possível era-me pedido mais algum tempo. De forma geral as coisas foram decorrendo bem, a comunicação com o grupo já não se baseava num monólogo onde eu dizia alguma coisa e não obtinha resposta. Entretanto chegaram as férias do Natal e como eu sou da opinião que as férias são para descansar um pouco, (caso contrario não faria sentido existirem), mas férias também marcam a recta final do semestre, por isso no planeamento marquei algum trabalho para as férias, mas mais reduzido, que incluía apenas a realização de uma entrega. Posso dizer que pensei que essa entrega seria um fracasso e que nem sequer ia chegar até mim, mas a verdade é que fui surpreendido, o grupo trabalhou como tinha vindo a trabalhar e fez a entrega como pedido. 5

224 Até aqui nada a dizer, esta nova fase estava a correr bem melhor que a anterior e as minhas novas funções estavam a ser bem-sucedidas, ao ponto do grupo pedir ajuda frequentemente e até pedir reuniões para além das aulas praticas, para esclarecer dúvidas e colocar problemas. E como eu disse tudo estava a corre de feição até que surgiu a ultima semana antes da entrega 4 de PMS, posso dizer que não previ esta semana, pois como aluno da Universidade do Minho há três anos e alguns meses, esqueci-me que o final de semestre é sempre um dos momentos mais complicados do ano, com trabalhos e testes uns em cima dos outros. Nesta fase ainda faltava realizar oitenta porcento da última fase de UML, pois o conhecimento do grupo sobre esta matéria era nulo e as aulas teóricas sobre o assunto apenas foram leccionadas na primeira semana de Janeiro deste ano, a menos de duas semanas da entrega. Isto tudo junto complicou de que maneira a última semana de trabalho, e toda esta pressão fez com que a inexperiência do grupo se fizesse sentir e complicar esta ultima fase do projecto. O rendimento do grupo baixou drasticamente, desde a qualidade à quantidade do trabalho, passando pela interacção comigo. E com uma semana tão complicada para o grupo o trabalho ficou um pouco atrasado, pois o que ficou planeado é que este ficaria pronto no dia anterior à entrega para que eu pudesse fazer uma revisão antes de ser submetido, e assim se a revisão fosse realizada com alguma antecedência daria tempo para corrigir alguns aspectos que fossem necessários. A verdade é que isso não aconteceu e uma grande parte do trabalho ficou para o dia antes da entrega, e como já é sabido isso normalmente não é bom sinal. O grupo teve que trabalhar a duzentos porcento nesses dois dias e quando o terminaram faltava 20min para a data limite de submissão, portanto não foi possível rever o trabalho, o que estava feito era definitivo pois não havia tempo para efectuar alterações. Isto deixou-me muito desiludido com o grupo (apesar de saber que foi uma semana complicada), pois o trabalho final não ficou totalmente como eu desejava, principalmente a parte de UML que está longe de estar convincente. De uma forma geral o papel de coordenador foi muito produtivo e vantajoso para mim e para o grupo, mas as coisas podiam ter corrido muito melhor. Penso que é também uma lição para mim e para o grupo, os imprevistos podem sempre ocorrer e a semana da entrega devia ter sido tomada em conta e até considerada um risco para o projecto. Mas no conto geral esta primeira experiência como coordenador/gestor, para além de diferente dos comuns trabalhos realizados noutras unidades curriculares, foi muito boa para a minha experiencia pessoal e fez-me ver o que me espera o mundo do trabalho As Decisões Aqui vou falar um pouco sobre as decisões que tive de tomar, para isso consultei alguma bibliográfica para me apoiar em tais decisões. "Tomada de decisões é o processo pelo qual são escolhidas algumas ou apenas uma entre muitas alternativas para as acções a serem realizadas [4]. Quando trazemos a tomada de decisão para o meio empresarial, a dificuldade e importância aumenta, pois pode-se perder um grande negócio apenas por uma 6

225 decisão mal tomada. E tão grave que pode mesmo influenciar todo o curso do projecto, de forma a ele deixar de ser viável [5] [6] [7]. São inúmeras as implicações da tomada de decisão, e a maior parte das consequências está normalmente fora do nosso alcance visual. Por isso é preciso ter cuidado aquando da decisão, por isso devemos considerar não só as opções mas também as pessoas e o meio onde se insere a mesma. Principalmente porque essa decisão na maior parte das vezes numa organização, não diz respeito apenas a nós próprio mas sim a todo um grupo de trabalho que está dependente dessas e de outras decisões. A complexidade dos inúmeros contextos criados pelo quotidiano de um grupo de trabalho requer competências multidisciplinares para ser propriamente analisada [5] [8]. Por isso é importante tentar, de alguma forma, sistematizar o contexto do problema, criar cenários pelo menos próximos da realidade onde as possibilidades de decisão possam ser analisadas sob todas as perspectivas. A capacidade de tomar decisões firmes, claras e no tempo certo é uma importante característica de liderança e de gestão coesa. O tipo de decisão, porém, varia conforme as circunstâncias. Por isso, é preciso sempre fazer uma análise da situação e de possíveis implicações, porque depois de uma má decisão pode não haver mais nada a fazer [5] [6]. Imagem 2 Elementos intervenientes na tomada de decisão [5]. Na imagem a cima podemos ver os principais elementos que intervêm na tomada de decisão. Dos cinco elementos contido na imagem, penso que o conhecimento é o elemento mais importante na tomada de decisão, pois esse mesmo conhecimento pode trazer as soluções necessárias para o problema em questão. A comunicação também será um elemento importantíssimo, pois por vezes podemos pedir a opinião de outras pessoas, para observar outros pontos de vista que não estão visíveis para nós. Basicamente foi isto que tentei sempre fazer neste projecto, a interacção com o grupo foi muito importante, principalmente na segunda fase do projecto e ai sim tivemos de tomar muitas decisões. E como gestor do projecto a palavra final dependia sempre de mim e uma má decisão poderia deitar tudo a perder, pois o 7

226 tempo era apertado, a experiencia do grupo era pouca e afinal de contas quem realmente poderia ser prejudicado com isto era o grupo Opinião Neste ponto vou fazer uma pequena reflexão sobre as funções que desempenhei, sobre as unidades curriculares de ACSI e PMS. A minha opinião sobre o trabalho desenvolvido neste projecto é bastante positiva, numa fase inicial foi um pouco complicado pois o grupo também não contribuiu, na segunda fase e com as novas funções de coordenador as coisas melhoraram. Penso que de modo geral a conciliação das duas funções e a passagem de função é importante pois passamos a ter duas perspectivas diferentes de actuação num projecto. Em relação à unidade curricular de PMS e da colaboração do professor Pedro Ribeiro, não tenho muito a dizer, ele sempre esteve presente para esclarecer as minhas dúvidas e sempre me apoiou no que foi necessário. No que diz respeito às aulas praticas também não há nada a referir pois sempre decorreram de forma tranquila e normal, deixo no entanto aqui uma ponto que penso que teve influência directa no trabalho realizado, que foi as aulas teóricas de PMS que estiveram sempre um pouco atrasadas em relação ao desenvolvimento do projecto, nomeadamente no que diz respeito à modelação em UML, que surgiu um pouco tarde e com isso o grupo teve que começar a modelar sem ter conhecimento da linguagem. Por fim na unidade curricular de ACSI, tudo se desenrolou de forma normal, de referir que a hora que dispensávamos de quinze em quinze dias para discutirmos sobre o decorrer dos acontecimentos, foi importante, pois expusemos as nossas dúvidas e problemas que foram surgindo e com isso tentamos corrigir alguns aspectos, como por exemplo, a mudança de funções. Por isso de uma forma geral estou muito satisfeito com o que realizei e foi realizado no âmbito da unidade curricular de ACSI e penso ainda que esta actividade fez com que eu mudasse a minha forma de ver o mundo do trabalho numa organização. 3. Conclusão No final da realização deste projecto, existem algumas conclusões importantes a retirar. Em primeiro lugar, todo este projecto, desenvolvido ao longo do semestre teve como objectivo o acompanhamento de um grupo de trabalho da unidade curricular de PMS. Devido à sua complexidade, que se veio a revelar bastante elevada, criou alguns obstáculos no seu desenvolvimento. Desde logo o facto de ter que lidar com um grupo totalmente desconhecido e que apresentava bastantes dificuldades na matéria e trabalho em grupo. Para além disto, outro aspecto bastante importante, e que dificultou a realização deste trabalho, está relacionado com a mudança de papéis de consultor 8

227 para coordenador, o que obrigou a rectificar o planeamento e a mudar a atitude perante o grupo, mas de forma geral valeu a pena, pois a nossa intervenção tornou-se muito mais incisiva e importante. Para terminar, espero com este trabalho ter contribuído, de alguma forma, para um melhor entendimento e compreensão desta área, sendo que no que me diz respeito, com este trabalho alcancei um conjunto de competências ao nível de gestão de projectos e relacionamento com pessoas, que anteriormente não possuía. Referencias 1. GAREIS, R. COMPETENCIES IN THE PROJECT-ORIENTED ORGANIZATION PROJEKTMANAGEMENT GROUP. 2. (2010). "Project management." from 3. (2007). "Consultor." from 4. (2006). Tomada de decisão. from 5. Angeloni, M. T. (2003). "Elementos intervenientes na tomada de decisão." from 6. Calado, A. M. F., J. F. F. Marques, et al. (2007). TOMADA DE DECISÃO. ALGUNS DOS ERROS MAIS COMUNS NA TOMADA DE DECISÃO. 7. PEREIRA, M. J. L. B.; FONSECA, J. G. M. (1997) Faces da decisão: as mudanças de paradigmas e o poder da decisão. 8. MALHOTRA, Y. (1993). What is knowledge management?. 9

228 Consultor de Projecto Processos e Metodologias de Software PG17828, Rui Manuel Fernandes Correia 2011, Universidade do Minho Abstract. A actividade de consultoria é praticada em diversas áreas e competências profissionais que têm como principal objectivo intrínseco a formulação e o diagnóstico de soluções acerca de uma determinada especialidade. Aos profissionais desta área atribui-se o nome de consultores. Neste artigo científico demonstrar-se quais as principais competências/características que um consultor deverá interiorizar e posteriormente desempenhar, quais os tipos de consultoria que se pode aplicar e sobretudo quais as melhores formas e modelos de comunicação. Através de um exemplo prático, ou seja, com um apoio sustentado e constante num projecto de planeamento da fase de inception do projecto SIMG (Modelação de Negócios e Requisitos), revela-se a quantificação do objectivo previamente estabelecido e formas de abordagem ao problema com vista à apresentação de uma solução credível ao cliente. Keywords: rational unified process, project management body of knowledge, consultor, modelos de comunicação, processos, requisitos, processos e metodologias de software, análise e concepção de sistemas de informação, unified module language, artefactos, vision. 1

229 Introdução O desenvolvimento/elaboração deste artigo científico insere-se na unidade curricular de Análise e Concepção de Sistemas de Informação presente no plano de curso do primeiro ano do Mestrado em Engenharia e Gestão de Sistemas de Informação (2ºciclo). O principal objectivo deste artigo é relatar todos os factos, casos e medidas que os alunos de ACSI, denominados de consultores, se depararam com o constante auxílio aos alunos da licenciatura em Tecnologias e Sistemas de Informação (1ºciclo), no projecto prático da unidade curricular de Processos e Metodologias de Software, leccionada na Universidade do Minho. O fundamento e o propósito pela qual se pretende incutir a actividade de consultoria, passa por uma cooperação/interligação entre estas duas unidades curriculares contemplando/englobando alunos com competências e graus académicos completamente distintos, activando capacidades e aptidões que posteriormente serão aplicadas no mercado de trabalho. O projecto na qual a actividade de consultor é aplicada em toda a sua plenitude tem como principal objectivo planear a fase da inception do projecto SIMG (Modelação de Negócios e Requisitos), sendo no final produzida uma proposta para posterior entrega ao cliente abrangendo desde logo diagramas UML (casos de uso, sequência e por fim robustez) para posteriormente arquitectar o sistema informático que se desenvolverá posteriormente. Projecto Clarificação de Linhas Orientadoras Fundamentos O processo de planeamento a ser adoptado é baseado numa perspectiva top-down de acordo com o PMBOK O planeamento de um projecto segundo o PMBOK (2004) segue um conjunto de processos apresentados na figura [1]. 2

230 Figura 1 - Processo de Planeamento segundo o PMBOK 2004 Condições de Execução e Ferramentas Para a execução deste projecto prático algumas nuances e condições prévias têm que obrigatoriamente ser consideradas. O projecto será realizado nas aulas práticas (unidade curricular de PMS), complementando com trabalho extra, sendo que, este será realizado em grupos de trabalho de 4/5 alunos, todos pertencentes ao mesmo turno prático e sem alteração de membros durante o projecto. O tamanho do relatório terá no máximo 20 páginas. Além de um editor de texto ferramentas como o COSTAR (implementação do modelo COCOMO), o MS Project (implementação das técnicas WBS, CPM e Resource Leveling) e por fim IBM RUP (processo de desenvolvimento) não devem ser descuradas. Objectivo de Implementação A empresa sw-ltsi dedica-se ao desenvolvimento de software. Entre os seus clientes encontra-se uma Instituição de Solidariedade Social (IPSS), denominada MG (Misericórdia de Guimarães). A MG está sediada em Guimarães e é uma instituição sem fins lucrativos, vocacionada para ajudar as pessoas mais carenciadas. A sw-ltsi vai desenvolver um sistema informático integrado para apoiar o funcionamento da MG. 3

231 Embora a MG tenha alguns subsistemas informatizados, a recente certificação ISO 9001:2008 trouxe novos desafios e a Direcção da MG coloca a possibilidade de adquirir um novo sistema integrado, alinhado com o sistema de qualidade. O projecto global (SIMG) será constituído por dois subprojectos. O subprojecto Inception, cobrindo as actividades de Modelação de Negócio e Requisitos decorrerá entre Dezembro de 2010 e Janeiro de O subprojecto Desenvolvimento dependerá da aprovação do subprojecto inicial e nesse caso está previsto decorrer entre Fevereiro de 2011 e Junho de Nesta fase de definição de requisitos, ou seja, segundo Ricardo J. Machado, uma condição ou uma capacidade que alguém necessita para resolver um problema ou atingir um objectivo (Machado 2001), deverá satisfazer o cliente em toda a sua plenitude e possuir capacidade de resposta às suas necessidades. Posteriormente verificar-se-á uma interligação desta fase de requisitos, através dos diagramas de UML, com os requisitos de software patenteadas pelo cliente. Segundo Ricardo Machado em Introduction Requirements Engineering, um requisito descreve como um produto de software deverá ser executado sendo esse requisito uma circunstância ou uma capacidade necessária a um utilizador com o intuito de solucionar um problema ou objectivo. (Machado 2010) A MG tem as suas actividades espalhadas por diversas localizações físicas, nomeadamente: sede, unidade de apoio à saúde, lares, residenciais, recolhimentos e centros de dia. Na figura [2] apresenta-se o organigrama simplificado da instituição. 4

232 MG Administração Corpor Directivo Dpt Administrativo, Contabilidade e Tesouraria Dpt. Transportes Dpt. Recursos Humanos Dpt. Acção Social Serviços de Saúde Serviço de Culto e Assistência Religiosa Aprovisionamento e Armazéns Asistência Humanitária e Social Unidade de Apoio à Saúde Património Figura 2 - Organigrama da Misericórdia de Guimarães; Definição de Processos Na recente certificação de qualidade foram definidos 13 processos, cada um descrito num manual de procedimentos. Os manuais de procedimentos são detalhados em instruções de trabalho e toda a informação é armazenada em registos, que permitem comprovar a execução dos processos, analisar métricas e propor acções de melhoria. Os 13 processos definidos são: 1. [MG-GSQ] Gestão do Sistema de Qualidade tarefas relacionadas com a definição, acompanhamento e análise dos processos de qualidade. 2. [MG-RH] Recursos Humanos tratamento dos salários, férias, formação, objectivos, contratações, [MG-AU] Admissão de Utentes processo partilhado pelas diversas unidades de apoio (lares, residências, apoio domiciliário, centros de dias). Trata da caracterização, contexto social e económico e enquadramento numa das unidades de apoio. Faz também a gestão das listas de espera. 4. [MG-GE] Gestão de Equipamentos procedimentos relacionados com os diversos tipos de manutenções em equipamentos, incluindo pequenas reparações nas instalações. 5. [MG-CSL] Cuidados de Saúde nos Lares gestão de consultas, medicamentos, cuidados de enfermagem, etc. 5

233 6. [MG-HIU] Higiene e Imagem do Utente tarefas relacionadas com limpezas dos diversos espaços da instituição (quartos, instalações, banhos, higiene,...). 7. [MG-SA] Serviços de Apoio processos relacionados com o apoio aos lares, por exemplo, gestão da frota e serviços de lavandaria. 8. [MG-QL] Quotidiano dos Lares Actividades sócio culturais (passeios, trabalhos manuais, música, ginástica de manutenção,...). 9. [MG-CO] Compras processo centralizado que tratar de todas as compras relacionadas com a MG. 10. [MG-AL] Alimentar gestão das cozinhas, preparação e distribuição das refeições e elaboração das ementas (ementas específicas conforme as necessidades dos utentes). 11. [MG-AM] Análise de Melhoria tratamento das métricas obtidas através dos registos, quantificação de melhorias, análise de indicadores e auditorias internas e externas. 12. [MG-FI] Financeiro incluindo bancos, contabilidade, tesouraria, orçamentação e pagamento a fornecedores. 13. [MG-AD] Apoio Domiciliário gestão dos serviços ao domicílio (saúde, alimentação, higiene pessoal, lavandaria,...). A MG considera ainda a hipótese de acrescentar um novo processo denominado Gestão de Contratos Externos, dedicado à definição, acompanhamento e verificação dos contratos de aluguer dos espaços da MG. Estes contratos referem-se a entidades externas, nomeadamente, os serviços de hemodiálise, tomografia, fisioterapia e medicina nuclear. Por outro lado, os serviços de endoscopia e cuidados continuados, são explorados pela própria MG. A instituição pretende analisar a viabilidade de incluir este subsistema nos processos actuais (definidos pela qualidade) ou autonomizar estes serviços avançando para uma certificação específica na área da saúde. A sw-ltsi é uma empresa CMMI nível 2 e usa um processo de desenvolvimento de software baseado no Rational Unified Process (RUP). 6

234 Consultoria Competências de um consultor A interacção cliente/consultor é o factor mais importante para o sucesso da consultoria em projectos e, consequentemente, para a sobrevivência de cada empresa de consultoria. (Nikolova, Reihlen and Schlapfner 2009). Os consultores são vistos como especialistas que têm acesso à base de conhecimento de uma determinada área prática e sejam capazes de desenvolver soluções para os problemas nessa área. Este conhecimento não está disponível, ou pelo menos não inteiramente, ou seja, ele é adquirido com a experiência implicando que os consultores possuam um monopólio interpretativo no que toca aos seus conhecimentos e respectivas áreas de actuação. (Nikolova et al. 2009) Características de um consultor Um cliente espera que o consultor a partir da experiência e conhecimentos específicos adquirida no trabalho com outros clientes ou em desafios semelhantes, uma diversidade de características. (Jang and Lee 1998). De facto, para que se assegure de antemão alguma linha de orientação e sucesso no desempenho do papel de consultor, é extremamente imperativo possuir características bastante vincadas, únicas que não se incrementam temporalmente. Existem certas medidas e critérios de personalidade que advém da própria natureza do ser humano, sendo por vezes uma tarefa difícil alterar certas ideologias sobre um determinado panorama real. Os consultores são chamados a desempenhar uma variedade de papéis quando utilizam os seus conhecimentos e técnicas. Com base nos modelos reportados pelo artigo escrito por Young Jang e Jinjoo Lee ( Factors influencing the sucess of manegement consulting projects ), os consultores devem assumir cinco funções básicas: especialista, gestor, pesquisador, conselheiro e político. Em primeiro lugar, o papel do consultor como um especialista é fundamental no processo de consultoria. O consultor é o provedor de habilidades e conhecimentos. Os clientes esperam que os consultores possam argumentar com teorias reportadas à sua área de especialização.(jang and Lee 1998) Em segundo lugar, o papel de gestor requer habilidades especiais para gerir ou controlar as condicionantes ou proporções para que o projecto possa rumar. 7

235 Em terceiro lugar, no papel de um pesquisador, o consultor deve ser capaz de aceitar a responsabilidade para a obtenção, análise e interpretação de dados objectivos de uma forma científica. (Jang and Lee 1998) Em quarto lugar, o papel orientador auxilia os clientes na aprendizagem e na transmissão de conhecimento através de métodos formais e posteriormente assume a responsabilidade pelo processo de aprendizagem do cliente. Por fim como última característica de um consultor, o papel de político. Este papel é promulgado pelo entendimento das fontes de energia nos sistemas sociais e ganhando o apoio daqueles que têm o poder e influência para facilitar ou dificultar a mudança. O consultor deve tornar-se politicamente mais sofisticado e activo a fim de aumentar o sucesso dos projectos de consultoria de gestão. (Jang and Lee 1998) Para que a perícia do consultor não seja meramente instrumental na resolução de problema do cliente, necessita de se mobilizar várias habilidades ou competências. Isso requer que o consultor detenha a combinação adequada de competências aliadas as suas características psíquicas. (Jang and Lee 1998) Conhecimento e Formação do Grupo de Trabalho Após uma apresentação/estruturação de ideias quanto ao enquadramento e contextualização do projecto na qual os alunos de ACSI teriam que cooperar/coordenar com os alunos de LTSI bem como os tipos e características que um consultor deve interiorizar face a um projecto desta envergadura, nesta secção do artigo científico relata-se a estratégia adoptada para a associação das equipas de trabalho. Esta associação foi elaborada no dia 11-Novembro-2010 na sala LAP1 pelas 11:00 horas localizada no complexo da Escola de Engenharia na Universidade do Minho (Pólo de Azurém), com a coordenação do professor e regente da unidade curricular de PMSoftware (Teórico-Práticas) Pedro Ribeiro. A actividade de consultoria que desenvolverei tem como principal foco o grupo número seis composto por cinco elementos tabela[1]. 8

236 Grupo Número 6 Processos e Metodologias de Software Nome Número Mecanográfico Eva Luzia Gonçalves Dias Paulo Manuel Araújo Pires Paulo Ricardo da Costa Grilo Sílvia Manuela Pires Sofia Marlene Ribeiro da Silva Tabela 1 - Identificação dos elementos do grupo de trabalho de PMS (Grupo 6); Após a afectação dos grupos de trabalho aos respectivos consultores de projecto, procedeu-se a uma breve troca de ideias sobre o projecto a desencadear bem como à troca de contactos de e telemóvel para posterior marcação de reuniões e prestação de todas as dúvidas inerentes ao projecto estabelecendo aqui uma sintonia e método de trabalho. Este foi o primeiro contacto visual entre ambas as partes. Definição de Objectivos do Grupo de Trabalho Posteriormente ao primeiro contacto entre as partes envolventes, procedeu-se a uma clarificação de objectivos intragrupo, ou seja, que linhas orientadoras e objectivos o grupo se propõe a atingir face a este projecto. Este planeamento de objectivos incute no grupo uma melhor visão e missão do trabalho que se terá que desenvolver tendo algo como objectivo primordial. Numa reunião realizada no dia 18-Novembro-2010 o grupo estabeleceu como principal foco o canalizar de todos os esforços e fluxos de trabalho com o objectivo de obter uma classificação final de projecto de 15 valores. Para alcançar tal objectivo o grupo propõe um plano de trabalho semanal de 20 horas, ou seja, cada elemento terá que realizar um trabalho extra (horas de aulas não englobadas) de 5 horas/semana. 9

237 Metodologia Adoptada Comunicação Quanto à metodologia adoptada no seio da nossa cooperação em grupo, ou seja, a fomentação do elo de ligação consultor/grupo PMS e vice-versa, foi estabelecida através das tradicionais plataformas tecnológicas como o e a dropbox. Distribuição de Tarefas No que toca à distribuição de tarefas, foi elaborado por mim um template na ferramenta excel, na qual semanalmente é devidamente preenchido pelo consultor e posteriormente enviada e visualizada pelo vários elementos do grupo de trabalho de PMS através duma das plataformas de comunicação estabelecidas, o . De seguida apresento um template que demonstrará qual a nomenclatura e interpretação da distribuição das tarefas reportadas semanalmente. Objecto de Interesse ACSInformação - Projecto de PMS Semana do Data de Elementos Tarefas Verificação Projecto Marcação Distribuição de Tarefas Paulo Grilo Eva Dias Paulo Pires Sílvia Pires Sofia Silva Tabela 2 - Template semanal da distribuição das tarefas; Planeamento Semanal No que toca ao planeamento semanal do projecto, ou seja, a comunicação encontrada para a marcação das reuniões onde são debatidas e esclarecidas todas as dúvidas acerca de pormenores ou das tarefas distribuídas para os vários elementos do grupo de trabalho passa por um template vocacionado unicamente para tal efeito. Nesse template destaca-se campos como a data de marcação, a data da reunião, local posteriormente a verificação das presenças de todos os elementos. 10

238 Objecto de Interesse ACSInformação - Projecto de PMS Data de Data da Marcação Reunião Elementos Presenças Paulo Grilo Reuniões Eva Dias Paulo Pires Sílvia Pires Sofia Silva Tabela 3 - Template do planeamento semanal do projecto; Avaliação do Desempenho A avaliação é algo crucial para se tirar ilações sobre a rendibilidade de todo o trabalho desenvolvido pelo grupo de trabalho. Obviamente, nem sempre a classificação final que o corpo docente atribui à equipa de trabalho corresponde às expectativas por eles delineadas/depositadas não existindo por vezes equidade quanto à prestação qualitativa de cada elemento em proporção com a classificação individual que advém da nota final, provocando por vezes uma demagogia emergente e transparente a todo o corpo docente. Nesta secção do artigo, tudo ficará mais claro pois como das principais tarefas incumbidas a um consultor de projecto (ou coordenador) passa pela constante monitorização ou rastreio constante de todo o trabalho desenvolvido. Com esse acompanhamento, é natural que com as minhas apreciações semanais exista informação mais precisa acerca do trabalho desenvolvido por cada elemento da equipa de trabalho ficando assim com uma percepção prévia do que se poderá esperar relativamente ao produto final. Grupo de Trabalho Na perspectiva da avaliação do grupo de trabalho e segundo a óptica de coordenador/consultor do projecto desempenhada por mim, considero que grande parte dos elementos canalizaram todos os seus esforços e competências, pré e pós adquiridas com o fluxo de trabalho, com o intuito de obterem a melhor classificação possível interligando todas as opções tomadas a um projecto final exequível explorando as áreas e os objectivos na qual o cliente (misericórdia de Guimarães) pré- 11

239 estabeleceu. Poderá não corresponder à realidade no contexto da própria execução do projecto, mas aquando da observação do desempenho individual dos vários elementos que constituem o grupo de trabalho, denoto algumas lacunas e uma abordagem muito superficial sobre algumas temáticas que considero fundamentais que alicerçam os resultados de aprendizagem ou os objectivos previamente delineados para a realização deste projecto. A deficiente gestão do tempo no que toca à elaboração do artefacto Vision da metodologia RUP, condicionaram posteriormente a pré-arquitectura dos diagramas UML que são peça fulcral no que toca à implementação ou desenvolvimento do sistema informático que posteriormente será entregue ao cliente e decorrerá no próximo semestre. O fornecimento de material de apoio no que toca aos diagramas UML (J. Machado 2010), nomeadamente no que toca à nomenclatura específica de cada diagrama, facilitou a elaboração dos mesmos conferindo um resultado final bastante apreciável. Porém, faço uma apreciação positiva do trabalho desenvolvido por todos esperando que a classificação final obtida no projecto bem como da satisfação por parte do cliente se coadunem com as suas expectativas/objectivos delineadas, ou seja, que a classificação final ronde os 15 valores. Equipa Docente Neste momento a equipa docente ainda não promulgou o veredicto final no que toca a esta primeira etapa do projecto. Este tinha como deadline o dia 16 de Janeiro de 2011 até às 23:55 horas, pelo que, provavelmente só daqui a duas semanas os professores revelarão as respectivas classificações finais do projecto. Findo esta fase do projecto, obtive junto da equipa docente uma apreciação positiva do grupo na qual desempenhei as minhas tarefas de consultor e posteriormente de coordenador de projecto. Interesse, capacidade de comunicação aliado à enorme vontade de realizar o melhor projecto possível, aprofundando e detalhando o artefacto Vision bem como os diagramas UML, foram elogios e palavras proferidas pelo professor regente da unidade curricular Pedro Ribeiro. Dai provocar quer no seio do grupo de trabalho quer em mim, pelas tarefas e coordenação que desenvolvi junto deles, enormes expectativas quanto à classificação final do projecto salientando o trabalho desenvolvido por ambos os intervenientes, ficando estes com um sentimento de dever cumprido esperando uma boa classificação final. 12

240 Discussão/Reflexão Crítica Inicialmente todo este processo de conjugação das unidades curriculares de análise e concepção de sistemas de informação, inserida no plano do mestrado em engenharia e gestão de sistemas de informação regida pelo professor Ricardo Machado, com processos e metodologias de software inserida na licenciatura em tecnologias e sistemas de informação regida pelo professor Pedro Ribeiro, leccionadas ambas na Universidade do Minho, não foi deveras fácil. Denotou-se uma falta de transparência informacional do que de facto se perspectivava com esta interligação de UCs, ocorrendo durante algumas semanas alguns factores impróprios e surpreendentes que causaram alguma inquietude, perca do sentido de orientação e alguma exequibilidade no que toca à realização deste projecto de ambos os intervenientes (equipa de PMS+consultor ACSI). Previamente à demonstração do regime de avaliação que foi exposto aos alunos de ACSI, todas as partes envolvidas de PMS, corpo docente e alunos, possuíam total conhecimento dos procedimentos e regras que ambas as partes se deveriam reger. Conhecimento sobre a mecânica do acompanhamento do projecto por parte dos alunos de ACSI foi escrupulosamente e detalhadamente transmitida aos alunos de PMS, pelo que, após a afectação dos vários consultores pelos respectivos grupos de trabalho, estavam reunidas as condições para que o projecto arrancasse sem sobressaltos, dúvidas ou qualquer espécie de desleixo pré-inicial. Tal situação não se verificou. Numa fase prematura, e logo após o conhecimento de todos os elementos na qual tinha sobre minha responsabilidade, verificou-se ao longo de semanas um grande afastamento amenizando esta situação com o reforço do papel que me estava incumbido, ou seja, através da plataforma de demonstrei sempre a minha disponibilidade total para o esclarecimento de qualquer dúvida relativa ao projecto. Acontece, que nunca fui solicitado para quaisquer dúvidas bem como do agendamento de uma reunião para posterior conhecimento interpessoal e acompanhamento presencial do trabalho desenvolvido por cada elemento no projecto. Sendo que esta situação se arrastou durante semanas, foi comunicado ao professor Ricardo Machado sobre os recentes factos que estavam a decorrer e após uma reflexão conjunta, alunos e docente de ACSI, instauraram-se novas regras e procedimentos para a execução do projecto. 13

241 Algumas nuances foram reformuladas e invertidas, ou seja, até então os alunos de PMS eram incumbidos de tomar o comando das operações no que toca ao agendamento de reuniões e distribuição de tarefas. Com os actos sucedidos na fase inicial do projecto, e após uma reformulação de alguns procedimentos e regras, estas responsabilidades inverteram-se, ou seja, os consultores eram agora responsáveis por tais tarefas e sobretudo pelo supervisionamento do trabalho semanalmente realizado pelos elementos da equipa de trabalho. Posteriormente a esse acto, era disponibilizado ao corpo docente de ambas as unidades curriculares, um feedback semanal, através de um pequeno documento, no que toca ao trabalho desenvolvido pelos mesmos em prol do projecto. Após esta mudança e reformulação de responsabilidades, denotou-se uma elevada melhoria e um comutar de situações que até aqui não se tinham verificado. O agendamento de reuniões imposta por mim, facilitou a interacção e o posterior conhecimento da realeza do projecto bem como do actual panorama em que se encontrava o trabalho, ou seja, possuía total conhecimento sobre o trabalho que se encontrava finalizado e o que de facto ainda se encontrava por finalizar. Esta situação paulatinamente ficou sanada com a distribuição de tarefas que semanalmente lhes era incumbido realizarem, ficando previamente acordado que na reunião seguinte era verificado todo o trabalho elaborado e devidamente finalizado por os respectivos elementos. Para além deste facto, denotei um aumento substantivo no que toca ao interesse na execução do projecto, explanando quer através das reuniões quer através da plataforma de , todas as dúvidas que estes se deparavam que os inibia de prosseguir com a realização do projecto, dúvidas as quais me prontifiquei a tirar indicando sempre qual o caminho que deveriam seguir. De facto nesta unidade curricular de ACSI, foi proporcionado um conjunto de situações e problemas que diariamente são sentidas por todos os consultores de projecto. Sendo que o principal objectivo deste método de avaliação prendia-se com o facto de proporcionar um hipotético mundo do trabalho a todos os alunos de ACSI, agora atingido o seu final, penso que foi bastante enriquecedor e um adicionar de competências, quer em termos humanísticos quer em termos profissionais que futuramente quando estiver inserido nesta realidade, me levarão a contornar/resolver certos problemas de forma diferente, sabendo de antemão, após ter passado por esta experiência, qual os meus limites psíquicos e profissionais. 14

242 Conclusão Com um projecto desta envergadura, penso que o resultado que conjuntamente foi produzido pelos intervenientes no projecto de PMS (consultor ACSI + Alunos de PMS), projecto esse que consistia apara além do apoio/melhoramento do funcionamento da misericórdia de Guimarães [MG] (cliente) a elaboração da fase da Inception cobrindo as actividades de modelação de negócio e requisitos, foi deveras excelente e surpreendendo as minhas expectativas, cimentando esse trabalho com um relatório bem fundamentado, pormenorizado todas as tarefas da Vision proveniente da metodologia RUP. No que toca ao desempenho do papel de consultor, penso que prestei um bom trabalho e que todas as minhas competências adquiridas com a conclusão da licenciatura em tecnologias e sistemas de informação foram postas à prova. Após o ultrapassar de um ciclo inicial algo conturbado, toda a coordenação e o verdadeiro papel de um consultor de projecto foi exposto em toda a sua plenitude, permitindo-me adquirir novos conhecimentos de gestão de projecto e sobretudo de situações adversas que me esperam no mercado de trabalho. Referências Bibliográficas J. Machado, R UML 2.0 Synthesis and Meta-Modeling Capabiities. Jang, Y. & J. Lee (1998) Factors influencing the sucess of management consulting projects. Internacional Journal Of Project Management, 16. Machado, R Análise, Requisitos e Especificação. Machado, R. J Introduction Requirements Engineering. Nikolova, N., M. Reihlen & J.-F. Schlapfner (2009) Client-Consultant Interaction: Capturing Social Practices of Professional Service Production. Scandinavian Journal Of Management, 25. Bibliografia Ribeiro, P. & A. Rodrigues. 2007/2008. Gestão de Projectos de Software - Parte 4. Ribeiro, P. G. 2007/2008. Qualidade de Software. Ribeiro, P. M. 2007/2008. Introdução à Engenharia de Software. Ribeiro, P. M. G. 2007/2008. Modelos e Metodologias de Software. 15

243 Anexos Anexo 1 Adicionei esta secção para expor todos os s que enviei para o grupo de trabalho de PMS. 16

244 17

245 18

246 19

247 Anexo 2 Neste secção adiciono toda a informação relativa ao planeamento das reuniões e distribuição das tarefas. Legenda 1 Não Apareceu (Sem justificação) 2 Não Apareceu (Com Justificação) 3 Presente 20

248 Legenda 1 Péssimo - Não realizou 2 Satisfaz - Realizou 1/3 3 Razoável - 1/2 4 SBastante - Realizou Satisfatoriamente 5 Excelente 21

249 Information Technology Infrastructure Library Sandra Antunes 1 1 Aluna de Análise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão de Sistemas de Informação, Universidade do Minho Guimarães, Portugal Resumo: O ITIL, conjunto de orientações, já é uma realidade no contexto universitário e empresarial nomeadamente nos EUA e Reino Unido, praticando assim as boas práticas ao nível de melhoria de serviços. Este artigo reflecte sobre a sua contextualização no mundo actual e explica as suas cinco fases, tendo estas incluídas vinte e sete processos que reflectem o ciclo de vida completo de um serviço. Palavras-chave: ITIL, ITIL V3, Service Strategy, Service Transition, Service Design, Service Transition, Continual Service Improvement 1 Introdução O ITIL, acrónimo para Information Technology Infrastructure Library, é um conjunto de orientações. A sua estrutura, publicada numa série de livros, descreve-o como um processo integrado baseado em abordagem de melhores práticas a serem aplicadas na infra-estrutura, operação e manutenção de serviços de TI (tecnologias de informação). O ITIL encontra-se envolto em algum mistério quanto à sua origem. Foi desenvolvido em 1980 pelo CCTA (Central Compute rand Telecommunications Agency), actualmente poderá se dizer que se encontra delegado à OGC (Office for Government Commerce) de Inglaterra. O ITIL dá-mos uma série de boas práticas de TI com uma checklist de tarefas e procedimentos que uma organização ITIL pode adoptar para as suas necessidades. A ITIL lida com as estruturas de processos para a gestão de uma organização de TI apresentando um conjunto abrangente de processos e procedimentos organizados em disciplinas, com as quais uma organização pode fazer a sua gestão operacional e táctica com vista ao alcance do alinhamento estratégico dos negócios. O ITIL aborda os seguintes aspectos chaves: Estratégia dos serviços, serviços de Design; transição de serviços; operação do serviço e a melhoria continua dos serviços.

250 2 Contextualização Como transcrito na introdução, o ITIL foi desenvolvido pelo ano de 1980 em Inglaterra. Desde então passou por duas mudanças, depois da entrada no novo milénio acontece a primeira mudança entre os anos de 2000 e 2002 passa da versão ITIL V1 para a versão ITIL V2 tendo ficado com 15 processos a documentar o ciclo de vida. Em 2007 ocorre a segunda alteração, passando para a versão ITIL V3 sendo adicionado aos 15 processos mais 12 novos processos estando actualmente com 27 processos. Segundo dados da University ITSM 2010, existem 18 universidades com implementações de processos ITIL nos Estados Unidos da América. Em Portugal a situação é diferente, até ao inicio de 2010 não existiam muitos movimentos relativamente a este conjunto de orientações sendo a FCCN (Fundação para a Computação Científica Nacional) a dar os primeiros passos reunindo alguns interessados e reunindo com eles. O ISCTE é uma das instituições que visa à aplicação do ITIL V3 na sua estrutura já tendo promovido formações do ITIL V3 Foundations a alguns dos seus colaboradores, assim como envolvido os seus estudantes em trabalhos de Mestrado. 3 As Cinco Fases do ITIL 3.1 Estratégia de Serviços (Service Strategy) Uma Estratégia de Serviço de qualquer prestador de serviços tem que ser efectuada com base em conhecimento. Os seus clientes não compram produtos, mas sim satisfação para as suas necessidades (Cartlidge, Hanna et al. 2007). Para conseguir perceber essas necessidades, é necessário entender quando e o porquê de elas ocorrerem em determinadas circunstâncias. Para isso a Estratégia de Serviço não pode ser criada isoladamente, tem de ser criada de acordo com o funcionamento da empresa cliente. O prestador de serviços pode existir de várias formas: (Cartlidge, Hanna et al. 2007) Efectuar a prestação de serviço para uma única unidade de negócio; Efectuar a prestação de serviço para múltiplas unidades de negócio; Efectuar a prestação de serviço, a nível externo da organização, para múltiplas unidades de negócio; Depois da Estratégia de Serviço estar alinhada com o ITIL V3, é necessário que todos os envolvidos percebam os seguintes aspectos: (Cartlidge, Hanna et al. 2007) Que serviço está a ser oferecido; Para quem é direccionado o serviço; 2

251 Como devemos programar o serviço no mercado interno e externo; Potenciais concorrentes existentes no mercado e os objectivo que diferem o valor do nosso serviço; Como é que os clientes e interessados vão avaliar o valor do serviço e como cria-lo; Como os clientes vão tomar as decisões quanto aos prestadores de serviço existentes, qual é que escolhem e porquê; Como é que se irá controlar a nível financeiro a criação deste serviço; Casos de estudo que exprimam robustez de negócio ao qual o serviço será inserido; Como irão ser distribuídos os recursos para este serviço, não diminuindo o desempenho nos restantes serviços; Como é que o desempenho do serviço será medido. Existem vários tipos de conceitos chave, ao nível do ITIL V3, para a Estratégia de Serviços. De seguida serão mencionados: The Four P s of Strategy (Figura 1) (Cartlidge, Hanna et al. 2007) Perspectiva Posição Planeamento Padrão 3

252 Figura 1 - Os Quatro P s da Estratégia de Serviços (OGC) Competition and Market Space (Cartlidge, Hanna et al. 2007) Todos os Serviços (novos ou existentes) são sujeitos às forças de mercado; Todos os prestadores de serviço operam nos mercados internos ou externos; Service Value (Cartlidge, Hanna et al. 2007) Utilidade do Serviço prestado; Garantia do Serviço prestado; Service Provider Types (Cartlidge, Hanna et al. 2007) Existe para prestar o serviço a uma única unidade de negócio (Tipo I); Existem para prestar serviço a múltiplas unidades de negócio (Tipo II); Operam como prestadores de serviços externos servindo múltiplas unidades de negócio externas (Tipo III); Service Management A gestão da estratégia é fundamentalmente focada nas capacidades e recursos que o prestador de serviços tem a nível de infra-estruturas, pessoas, controlo coordenação, entre outras. 4

253 Factores críticos de sucesso: Identificar e analisar periodicamente estes factores para uma melhor prestação de viços e com elevada taxa de sucesso. Figura 2 - Factores Críticos de Sucesso (CSF) (OGC) Service Oriented Estabelece a ponte entre a gestão de serviços e a gestão financeira. Service Provisioning Models Caracterizar e seleccionar vários modelos de serviço que podem ser escolhidos pelos clientes. Para isso terá de se ter em atenção a Gestão de Serviços, a partilha entre serviços e a utilidade desses mesmos serviços. Organization Design and Development Desenhar a organização onde está inserido o prestador de serviços para permite que a estratégia de negócios seja fácil de analisar. Perante estes conceitos chaves, temos processos e actividades chave que são mencionadas de seguida: Financial Management Esta gestão controla os serviços de TI e também as contas e valores que serão gastos pelo prestador de serviços. Verifica-se assim a nível financeiro se a prestação de serviços pode ser aplicável ou não e se iremos ter rentabilização a curto, médio ou longo prazo dos investimentos feitos nesta estratégia. 5

254 Service Portfólio Management (SPM) O SPM contém todos os serviços prestados pela organização detalhando o seu ciclo de vida, mas também aqueles que já entraram em queda e mesmo os que deixam de ser fornecidos. Demand Management Esta gestão é muito crítica na criação da estratégia. É com esta gestão que se consegue tirar ilações respeitantes à procura de serviços que os clientes querem e como chegar a essa mesma procura. Existe o SLP e é concebido para identificar o nível de utilidade de determinado serviço e a sua concepção para responder as necessidades de um determinado negócio. 3.2 Design de Serviços (Service Design) O Design de Serviços é uma importante fase do ciclo de vida de um serviço e também um elemento importante da mudança de um processo de negócio (Cartlidge, Hanna et al. 2007). Existe uma regra importante para esta mudança e que deve ser realçada: O Design de Serviços, adequados e inovadores de TI incluindo as arquitecturas, processos, politicas e documentação, servem para cumprir os actuais e futuros requisitos do negócio (Cartlidge, Hanna et al. 2007). 6

255 Figura 3 - Service Design (OGC 2007) Os objectivos deste Serviço são: (Cartlidge, Hanna et al. 2007) Desenhar os serviços mediante o negócio em questão; Desenhar os processos para suportar o ciclo de vida de um serviço; Identificar e gerir riscos; Desenhar o mapa de segurança das infra-estruturas, ambiente, aplicações e da informação dos recursos e suas capacidades; Desenhar métodos de medição e métricas; Produzir e manter planos, processos, politicas, normas, arquitecturas, Framework e documentos para suporte de soluções TI; Desenvolver aptidões e capacidades dentro das Tecnologias de Informação; Contribuir para a melhoria global da qualidade dos serviços de TI. 7

256 O Design de Serviços começa com alguns requisitos de negócio, e acaba com o desenvolvimento de uma solução concebida para documentar esses mesmos, e é incluída num Service Design Package (SDP) para ser divulgada pelo Serviço de Transições (Cartlidge, Hanna et al. 2007). Assim podemos verificar que existem vários tipos de conceitos chave: (Cartlidge, Hanna et al. 2007) Solução nova, ou alteração de uma existente; Ferramentas e Sistemas de Gestão de Serviços, especialmente o Portfólio; Gestão de Sistemas e arquitecturas tecnológicas; Regras, processos e capacidades; Métodos de análise e métricas. Um bom Design de Serviço depende de uma efectiva e eficiência utilização dos quatro P s, pessoas, produtos, processos, parcerias (Figura 4). Figura 4 - Os quatro P s do Design de Serviço (OGC 2007) Esta utilização leva a uma consistente e integração de todas as actividades e processos fornecendo assim uma relação com o negócio funcional e qualificada (Cartlidge, Hanna et al. 2007). Service Design Package (SDP) Este package define tudo o que um serviço e os seus requisitos usam ao longo do ciclo de vida do mesmo serviço. É produzido para novos serviços, alterações em larga escala e para abandono de algum serviço existente (Cartlidge, Hanna et al. 2007). 8

257 Service Catalog Management (SCM) O SCM fornece para a organização, informação importante e relevante relativamente aos serviços de TI incidentes no negócio, garantido uma imagem fiável e ilustrativa de todos os serviços de TI disponíveis existentes na mesma bem como os seus detalhes e o seu estado actual. A informação importante para o SCM está contida dentro do Serviço Catálogo. Essa informação é proveniente do Serviço Portfólio e do negócio em si. Service Level Management (SLM) O SLM negoceia e acorda objectivos correspondentes ao negócio, monitoriza e produz relatórios das entregas acordadas (Cartlidge, Hanna et al. 2007). O objectivo principal do SLM é garantir a avaliação correcta de todos os profissionais das TI s na organização, e garantir inclusive que todos os serviços e relatórios vão de encontro ao negócio pretendido e os clientes da organização. Capacity Management Esta gestão é efectuada ao longo do ciclo de vida de um serviço. A chave do sucesso desta gestão passa por ser efectuada ao longo do Design. Esta gestão tem como objectivo fornecer um ponto da gestão ao nível das capacidades e performances dos serviços e seus recursos bem como cruzar os requisitos do negócio com as capacidades das tecnologias. Availability Management Tem como objectivo avaliar e fornecer um ponto de gestão ao nível das questões relacionadas com a disponibilidade e distribui-las pelos serviços, componentes e recursos existentes, assegurando que todos os objectivos das diversas áreas não são afectados e são atingíveis. Existem dois níveis para esta gestão: (Cartlidge, Hanna et al. 2007) Actividades activas - efectuar análises e medições, monitorizar e gerir eventos. Incidentes e problemas envolvendo serviços não disponíveis; Actividades proactivas - planear, desenhar e melhoria da disponibilidade dos serviços. IT Service Continuity Management (ITSCM) Tem como objectivo ligar os serviços de TI com as necessidades, requisitos e prazos do negócio. É distribuído pelo ciclo de vida para garantir que, quando são desenvolvidos planos de recuperação e de continuidade, são mantidos alinhados com o negócio e suas prioridades (Cartlidge, Hanna et al. 2007). Information Security Management (ISM) 9

258 O Objectivo do ISM é alinhar a seguranças das tecnologias com a segurança que o negócio necessita, e assegurar a segurança da informação para toda a organização e seus serviços. Esta informação deve ser assegurada desta forma: A informação deve estar disponível assim que solicitada (Disponibilidade); A informação deve ser visualizada só por quem tem autorização para tal (Confidencialidade); A informação tem de estar protegida contra uma não autorizada alteração da mesma (Integridade); Transacções de negócio e troca de informação podem ser autorizadas (Autenticação). Supplier Management Garante que os fornecedores e os serviços que eles fornecem, apoiam e vão coincidir com os objectivos e metas do negócio envolvente. O objectivo é obter valor do capital dos fornecedores bem como assegurar o cumprimento das metas e contratos estabelecidos estão de acordo com os termos e regras neles contidos. 3.3 Transição de Serviços (Service Transition) O Objectivo da transição de serviços é enviar serviços que são requisitados pelo negócio (Cartlidge, Hanna et al. 2007). Se por eventual circunstância existirem alterações ao nível do negócio depois do design, essas mesmas modificações serão solicitadas ao longo desta transição. Assim, esta é focada em toda a sua implementação, não só na aplicação, mas também na sua utilização. Requer: (Cartlidge, Hanna et al. 2007) Valor potencial de negócio e a quem será entregue; Identificação de todos os interessados nos clientes ou fornecedores; Aplicação e adaptação dos serviços de design, incluindo as modificações ocorridas no mesmo ao longo da transição. Esta transição é suportada pela utilização eficiente e eficaz das modificações ou dos novos serviços. Para isso existem alguns conceitos chave: Compreender a utilização e garantias de todos os serviços existentes Estabelecer um padrão para as alterações necessários dos serviços Apoiar a transferência dos conhecimentos, as decisões a serem executadas e a reutilização dos processos: Gestão e antecipação das correcções em curso: 10

259 Garantir a participação da transição de serviços ao longo do ciclo de vida dos mesmos De seguida são enumerados e explicados outros processos e actividades chave para a Transição de Serviços: Change Management Esta gestão garante que as alterações são autorizadas, avaliadas, planeadas, testadas e implementadas através de um gestor de controlo (Cartlidge, Hanna et al. 2007). O objectivo passa pela garantia, pela utilização de métodos eficientes, e todas as situações são configuradas no sistema de gestão de configurações que tem em atenção essas alterações em relação ao negócio propriamente dito. Um serviço de mudança é a adição, modificação ou remoção de uma autorização, planeamento ou serviço de suporte e a documentação a ele associada (Cartlidge, Hanna et al. 2007). Figura 5 - Gestão ou Modificação dos Serviços (OGC 2007) Service Asset and configuration Management (SACM) O SACM suporta o negócio fornecendo informação e controlando todas as relações que a organização mantém (Cartlidge, Hanna et al. 2007). 11

260 O Objectivo passa por identificar e controlar as relações, e mais propriamente os CI (Configuration Items) assegurando que estes passam todo o ciclo de vida do serviço. Para gerir infra-estruturas com elevada complexidade de serviços TI, é necessário um apoio do CMS (Configuration Management System). Knowledge Management O objectivo é garantir que o funcionário correspondente a determinado suporte de serviços, tenha as competências necessárias, bem como a eficiência, para exercer essas funções. Essas funções têm de incidir em: Efectuar um serviço eficiente com qualidade; Compreender claramente e concisamente o valor dos serviços que presta; Disponibilizar sempre a informação relevante. O principal para esta gestão é a Informação, conhecimento, estrutura e utilidade dos dados. Transaction Planning and Support Os objectivos deste planeamento e suporte são: (Cartlidge, Hanna et al. 2007) Planear e coordenar os recursos de modo a assegurar que os requisitos da Estratégia de Serviços estão a ser seguidos pelo Serviço de Design e realizados pelo Serviço de Operações; Gerir e identificar os riscos de falhas resolvendo-as ao longo das actividades de transição; Release and Deploy management Os objectivos deste processo passam por alocar todos os serviços para a produção e moldar a utilização desses ou de novos serviços (Cartlidge, Hanna et al. 2007). Este processo cobre toda a implementação de novos ou existentes serviços para uso operacional. Service Validation and Testing O sucesso dos Testes depende de como os processos foram construídos e se os esses são apropriados, proporcionando a validação correcta de acordo com o negócio a que se destina e os riscos a ele associados. O objectivo principal para este processo é verificar se o processo que está a ser testado ou validado efectivamente suporta os requisitos do negócio e os seus SLA s. Os testes são efectuados através de ferramentas específicas e acontece no SDP. 12

261 Evaluation Processo que assegura que o serviço é adequado ao negócio e continuará a ser relevante, através de técnicas de medições apropriadas. Service Transaction Operation Activities Este é também utilizado para actividades operacionais tais como: Gestão de comunicações ao longo da Gestão de serviços TI; Gestão das modificações na organização; Gestão dos Stakeholders; Organização dos serviços de transição e suas regras (Cartlidge, Hanna et al. 2007). 3.4 Operação de serviços (Service Operation) O objectivo deste Serviço passa pela disponibilização dos serviços aos utilizadores e clientes, bem como a gestão das aplicações, infra-estrutura e suporte inerentes a esses mesmos serviços. É só nesta fase do ciclo de vida de um serviço, que é mostrado o valor do serviço do negócio ao cliente, e passa a ser da responsabilidade dos colaboradores do Serviço de Operações o assegurar deste mesmo ideal. É importante para o Serviço de Operações terem em atenção, para gerir objectivos conflituosos, estas quatro situações: Visualização interna das TI s Vs Visualização externa do negócio Estabilidade Vs Responsabilidade Qualidade do serviço Vs Custo do Serviço Actividades reactivas Vs Actividades Pró-activas É extremamente relevante que os colaboradores mantenham o equilíbrio, qualquer foco excessivo leva a que seja prestado um mau serviço (Cartlidge, Hanna et al. 2007). Como principais pontos chaves do Serviço de Operações temos: Event Management Process Um evento é uma alteração de um estado que tem significado para a gestão da configuração de um serviço de TI (Cartlidge, Hanna et al. 2007). Um evento torna-se importante pois poderá indicar que algo na organização não está a funcionar correctamente e tem de ser verificada, a demora da verificação poderá levar o evento a passar a um incidente. É também de salientar que um evento pode também indicar actividades normais ou rotinas dentro da organização, a sua gestão depende da sua monitorização. No entanto, esta gestão 13

262 gera notificações monitorizando o estado das mesmas, mesmo que não exista nenhum evento a correr. Depois de um evento ser detectado pelo CI ou por alguma ferramenta de gestão poderá passar a ser um incidente ou alteração, bem como informação que pode ser extraída por quem de direito. A resposta a um evento tem duas versões: a automática ou a manual. Incident Management Process Um incidente é uma interrupção inesperada de um serviço de TI, ou uma redução de qualidade desse mesmo serviço. Falha numa configuração que ainda não teve impacto num serviço é considerada também um incidente (Cartlidge, Hanna et al. 2007). O objectivo desta gestão é restabelecer a normalidade dos serviços o mais rápido possível tentando minimizar ao máximo a sua influência negativa nas operações do negócio envolvente. Como dito acima, estes são detectados pela gestão de eventos ou por utilizadores que reportam o mesmo ao Service Desk. A caracterização dos incidentes, do menos grave para o mais grave, é efectuada de acordo com o impacto que cada um tem no negócio envolvente. Se for muito grave, passa a ter prioridade sobre algum que exista que tenha menos gravidade. Se o incidente não for resolvido rapidamente é denominada outra pessoa para resolvê-lo. (escala-se o incidente). Assim o incidente é passado para um técnico da equipa de suporte que tem as skills apropriadas para resolvê-lo. Depois de o incidente ser investigado, diagnosticado, resolvido e a solução testada, o Service Desk tem que se assegurar que o utilizador que identificou o incidente está satisfeito com a solução para depois encerrar o dito incidente. Numa organização, é extremamente necessária uma ferramenta de gestão de incidentes, para efectuar a gestão da informação de cada incidente bem como ter a consulta ao mesmo sempre que necessário. Request Fulfillment Process Um pedido de um serviço é um pedido de um utilizador por informação, aconselhamento, para uma alteração do padrão ou um acesso a um serviço TI (Cartlidge, Hanna et al. 2007). O objectivo deste tipo de pedidos é capacitar os utilizadores de pedirem e solicitarem serviços padrão; para fornecer informação aos utilizadores e clientes sobre os serviços e processos e como obtê-los; e para assistir com informação geral (Cartlidge, Hanna et al. 2007). Todos os pedidos devem ser registados e monitorizados através dum software apropriado para o efeito. O processo terá que ter uma pessoa, ou várias que aprovem o mesmo antes de se executar o que foi pedido. Access Management Process O objective desta gestão passa pelo fornecimento do acesso aos utilizadores, aos serviços bem como a grupos dos mesmos, precavendo assim acessos não autorizados. Com esta gestão consegue-se precaver a gestão de conflitos, 14

263 disponibilidade e integridade dos dados bem como as suas propriedades (Cartlidge, Hanna et al. 2007). Este acesso é fornecido com uma identidade única por cada utilizador e com permissões de acesso que permite a esses aceder aos dados. Este processo inclui a verificação da identidade do utilizador, login do mesmo, controlo do seu acesso e remoção ou modificação do mesmo acesso caso exista alguma alteração ao nível das regras. Problem Management Process O problema é a causa de um ou mais incidentes. A causa deste, normalmente é desconhecida no momento em que ocorre, e o problema management process é responsável pela investigação ao mesmo (Cartlidge, Hanna et al. 2007). O objectivo desta gestão passa por prever os problemas que podem ser resultado dos incidentes existentes, bem como eliminar incidentes e minimizar o impacto daqueles que não podem ser detectados a tempo (Cartlidge, Hanna et al. 2007). Esta gestão inclui os diagnósticos efectuados para descobrirem-se as causas dos incidentes, determinando assim a sua resolução e assegurando que essa seja cumprida. Os problemas são caracterizados de uma forma similar aos incidentes, no entanto o objectivo dessa caracterização é diferente. Passa por entender as causa, documentando-as e pedindo as alterações necessárias de modo a ficarem resolvidos. A documentação é guardada numa Base de dados que pode ser acedida por outros técnicos que tenham o mesmo problema para resolver algures no tempo, proporcionando assim uma maior rapidez na resolução do problema. Common Service Operation Os Serviços de Operações incluem algumas actividades que não estão enquadradas nas 5 anteriores explicadas. Essas actividades são as seguintes: Monitorizar e controlar; Gestão / Ponte para as operações; Gestão das infra-estruturas (Bases de dados, directorias, data Center, etc.); Aspectos Operacionais que estão incluídos em outros processos ao longo do ciclo de vida do serviço (Cartlidge, Hanna et al. 2007). Tendo em conta os pontos-chave acima transcritos podemos verificar alguns tipos de funções importantes: Service Desk Function O Service Desk é uma função extremamente importante, fornece um contacto único com todos os utilizadores dos serviços de TI. É pelo serviço prestado pelo Service Desk que são registados os incidentes e pedidos de acesso providenciando uma interface com todos os utilizadores da Organização. As principais responsabilidades desta função são: 15

264 Registar todos os incidentes e pedidos, estabelecendo uma caracterização e prioridade entre eles; Investigação e diagnóstico inicial; Gerir o ciclo de vida de um incidente ou pedido, escalando os mesmos e fechando-os sempre que esses tiverem resolvidos e quando o utilizador está satisfeito; Manter os utilizadores informados sobre os seus pedidos ou incidentes (Cartlidge, Hanna et al. 2007). Como estrutura, o Service Desk insere-se nos seguintes tipos (Cartlidge, Hanna et al. 2007): Service Desk local - próximo dos utilizadores; Service Desk - centralizado, permite que com poucos colaboradores lidem com um maior número de chamadas; Service Desk Virtual - para o utilizador parece que os colaboradores pertencem a uma única equipa e na verdade pertencem a várias equipas; Follow the Sun - service desk com fusos horários diferentes, passam as chamadas a colaboradores que estão a trabalhar no momento. Technical Management Function Inclui todos os colaboradores que são técnicos especializados em TI. Estes profissionais ajudam a planear, programar e manter estáveis as infraestruturas de TI. As actividades que são efectuadas são: (Cartlidge, Hanna et al. 2007) Identificação das necessidades e competências; Definição da arquitectura padrão; Envolvimento no design e construção de novos serviços; Contribuem para o Serviço de Design, Serviço de transição e ou projectos de melhoria; Interagem com a gestão de processos, ajudando a definir os padrões e as ferramentas a utilizar; Interagem com a gestão de contractos e fornecedores. Application Management Function Esta função contém os colaboradores que possuem a especialização técnica e gestão de aplicações (Cartlidge, Hanna et al. 2007). É muito parecida com a função anterior, contudo tem uma diferença, foca-se mais no software das aplicações do que nas infra-estruturas da tecnologia. Cada aplicação existente na organização pode suportar mais do que um serviço de TI, 16

265 e cada serviço pode usar muitas aplicações distintas. Como exemplo tem-se os shared services baseados em arquitecturas service-oriented. Trabalham muito próximos do Development, mas tem funções e regras próprias e distintas. As actividades inerentes a esta função são um tanto similares as que foram descritas na função anterior. Estes profissionais são distribuídos pelas áreas de negócio que a organização abrange formando assim equipas de suporte para diferentes áreas. IT Operations Management Function Esta função tem como responsabilidade gerir as infra-estruturas de TI necessárias para a prestação de um bom serviço ao cliente por parte da organização. Existem dentro desta função, duas sub funções: Controle de Operações de TI - normalmente é dividido em turnos pelos seus colaboradores. Eles centralizam monitorizando e controlando, normalmente de um centro de controlo ou Centro de Operações em Rede; Gestores de Instalações - são responsáveis pela gestão dos Data Center, sala de computadores e locais de recuperação de dados. São também coordenadores dos projectos para alterações na data Centers e servidores (Cartlidge, Hanna et al. 2007). 3.5 Melhoria Contínua dos Serviços (Continual Service Improvement) Continual Service Improvement (CSI) foca-se na manutenção do valor dos serviços para os clientes, através de uma continuada evolução dos serviços prestados bem como a maturidade global do ciclo de vida do ITSM (Cartlidge, Hanna et al. 2007). Combina essencialmente princípios, praticas e métodos da gestão de qualidade com os da gestão de mudança e a melhoria da capacidade. Sendo assim, trabalha para a melhoria do ciclo de vida do serviço bem como dos serviços actuais, processos e actividades relativas às TI. CSI não é um novo conceito. Para muitas organizações, este tornou-se um projecto quando algo falha e causa severo impacto no negócio. Quando este é resolvido, é prontamente esquecido até a próxima falha (Cartlidge, Hanna et al. 2007). 17

266 Figura 6 - Continual Service Improvement (Addy 2007) De seguida serão mencionados os processos e actividades chaves deste serviço: 7-Step Improvement Process (Cartlidge, Hanna et al. 2007) Passo um: Define-se o que se deve medir Passo dois: Definir-se o que se consegue medir Passo três: Reunir os dados Passo quatro: Processar os dados Passo cinco: Analisar os dados Passo seis: Apresentar e utilizar as informações Passo sete: Implementar medidas correctivas Service Measurement Existem quarto razões base para monitorizar e medir: (Cartlidge, Hanna et al. 2007) Primeira Validar decisões anteriores que tenham sido efectuadas Segunda Actividades Directas para ir de encontra aos objectivos propostos; 18

267 Terceira Justificar que um acção é necessário, com a evidência ou prova; Quarta Intervir no momento certo implementando decisões correctivas; Métricas para tecnologias: é associado frequentemente com componentes tecnológicas e aplicações, com base no desempenho e disponibilidade; Métricas para processos: é conseguido através dos Factores Críticos e Sucesso, Indicadores de Desempenho e actividades métricas; Métricas para serviços: Componentes / Tecnologias são usadas para computorizar as métricas de serviço. É necessária uma plataforma integrada de medição para alocar os dados necessários e apoiar a sua apresentação. Service Reports São guardados muitos dados que são monitorizados pelas TI e posteriormente enviados pelo serviço de qualidade para o negócio, mas no entanto, só uma pequena porção desses dados é que interessam realmente ao negócio. A organização gosta de ter um histórico para verificar como evolui ao longo do tempo e como colmatou algumas das lacunas que foram aparecendo, sendo que tem uma particular atenção aos acontecimentos passados que continuam a ser uma ameaça para a empresa, e como irão atenuar essas mesmas ameaças. TI necessita construir uma aproximação ao reporting tendo como base: o que aconteceu, o que fez, como o TI assegurará que não voltará a acontecer determinada ameaça e como estão a agira para melhorar a prestação de serviços na generalidade. Um relatório que incide no futuro da mesma forma que incide no passado proporciona meios para que as TI consigam oferecer os seus serviços alinhados com o que de positivo e negativo se retira das experiencias anteriores nesse determinado negócio. 4 Conclusão Verificamos no nível da contextualização a força que este conjunto de orientações tem exercido ultimamente a nível académico, sendo aplicadas em diversas universidades nos EUA e estando a ser implementadas em Universidades Portuguesas, como ISCTE, neste momento. Tanto as instituições de ensino superior privado ou público, bem como do sector empresariais, têm o dever de gerir da melhor forma (eficaz), e utiliza-los racionalmente (eficiência), os seus activos e recursos ao nível das TI s e não só, estes conceitos efectivamente ajudam nessa gestão. Este trabalho reflecte sobre essa mesma contextualização, e explica detalhadamente as suas cinco fases bem como onde essas incidem e de que modo 19

268 podem as instituições aplica-los de forma correcta, ganhando na melhoria dos seus processos. Não nos podemos esquecer que estes conceitos são teóricos e têm que ser perceptíveis a quem vai implementar estas orientações de modo a ter um uso total das mesmas. 5 Referências Addy, R. (2007). Effective IT Service Management To ITIL and Beyond!, Springer. Cartlidge, A., A. Hanna, et al. (2007). The IT Infrastructure Library An Introductory Overview of ITIL V3, The UK Chapter of the itsmf. OGC "ITIL V3 Service Strategy." OGC (2007). ITIL- Service Design, The Stationery Office. OGC (2007). ITIL - Service Transition, The Stationery Office. 6 Bibliografia Dugmore, J. and S. Taylor (2008). "ITIL V3 and ISO/IEC " OGC "ITIL V3 Service Improvement." OGC ITIL V3 Service Operation. Perks, C. and T. Beveridge (2001). Guide to enterprise IT architecture, springer. (OGC ; OGC ; Perks and Beveridge 2001; Dugmore and Taylor 2008) 20

269 Consultor e Coordenador de Projecto Académico: Planear, Coordenar, Controlar e Avaliar Sérgio António Ramos da Costa (PG17378) Análise e Concepção de Sistemas de Informação, Mestrado em Engenharia e Gestão de Sistemas de Informação, Departamento de Sistemas de Informação, Universidade do Minho Abstract O presente artigo tem como objectivo descrever as experiências pessoais ocorridas na forma de ensino, em ambiente académico, pelo qual eu passei, enquanto consultor e coordenador de uma equipa de trabalho, composta por quatro alunos que frequentam unidade curricular de Processos e Metodologias de Software, da Licenciatura em Tecnologias e Sistemas de Informação da Universidade do Minho. O projecto consiste num caso prático de modelação de negócio e requisitos de uma Instituição Publica de Serviços Sociais, a Santa Casa da Misericórdia de Guimarães. Inicialmente a equipa realiza o planeamento da fase Inception, da metodologia de desenvolvimento RUP e posteriormente a sua execução. O artigo descreve o meu papel como consultor de projecto e posteriormente a forma de como todo projecto foi coordenado, controlado e avaliado enquanto coordenador. Palavras-chave Consultor, Coordenador, Gestão de Projecto, Projecto, RUP, Inception, Competências, Planear, Coordenar, Controlar, Avaliar. 1. Introdução Este artigo apresenta o relato da experiência vivida enquanto consultor e coordenador de um projecto académico. O projecto surge no âmbito da unidade curricular de Processos e Metodologias de Software (PMS) da Licenciatura em 1

270 Tecnologias e Sistemas de Informação (LTSI) da Universidade do Minho (UM). A participação neste projecto deve-se ao facto de me encontrar a frequentar a unidade curricular de Análise e Concepção de Sistemas de Informação (ACSI) do Mestrado em Engenharia e Gestão de Sistemas de Informação (MEGSI) da UM. Nesta unidade curricular foram propostas duas formas de avaliação, uma das quais em parceria com unidade curricular de PMS. A minha opção de escolha foi participar no projecto de PMS, como consultor e coordenador da equipa de trabalho, composta por quatro alunos, que frequentam o mesmo turno prático da unidade curricular de PMS. O projecto é designado como projecto SIMG (Sistema Informático para a Misericórdia de Guimarães) e é constituído por dois subprojectos. O subprojecto planeamento e o subprojecto Inception. A participação no projecto SIMG resume-se a duas funções, a de consultor e coordenador. Consultor durante o subprojecto planeamento e coordenador durante o subprojecto Inception. Com base na definição, de Turner (2006), de um projecto como uma organização temporária com recursos dedicados, o projecto torna-se um instrumento de mudança organizacional, de recursos e gestão de riscos [1], sendo necessária a gestão do mesmo. A gestão e coordenação de projectos é a aplicação dos conhecimentos, das competências, ferramentas e técnicas às actividades do projecto para atender aos requisitos do mesmo. Esta é realizada através da aplicação e integração dos processos de gestão de iniciação, planeamento, execução, monitoramento, controle e encerramento [2] [3]. A gestão de um projecto aborda o planeamento e a coordenação desde o seu começo até ao seu fim, identificando as exigências do cliente e cumprindo os tempos estabelecidos, os custos e os padrões de qualidade [2]. O objectivo deste artigo é apresentar o relato da experiência vivida ao longo do projecto, enquanto consultor e coordenador, expondo a forma de como este foi gerido, coordenado, controlado e avaliado. O artigo é constituído por 6 secções, e estão organizadas da seguinte forma: (2) O Projecto, onde refiro o âmbito do projecto e o envolvimento no mesmo, a descrição da equipa de trabalho, do cliente e o resultado esperado. (3) Consultor do Projecto SIMG, onde exponho a minha experiência enquanto consultor, fazendo referência às competências de um consultor (4) Coordenador do Projecto 2

271 SIMG expondo a minha experiência enquanto gestor/coordenador do projecto, a forma como todo ele foi coordenado, controlado e avaliado. (5) Consultor vs Coordenador, onde menciono as diferenças entre as funções e o desempenho da equipa de trabalho perante as duas. Por último, (6) Discussão e Conclusão onde são abordadas as conclusões que extraí com a experiência vivida ao longo deste projecto. 2. O Projecto O projecto SIMG (Sistema Informático para a Misericórdia de Guimarães) surge no âmbito da unidade curricular de PMS sendo constituído por dois subprojectos. O subprojecto Planeamento e o subprojecto Inception. O subprojecto planeamento tem como objectivo planear a fase Inception do projecto SIMG, baseado numa perspectiva top-down de acordo com o PMBOK 1 [2]. O subprojecto Inception, a primeira das quatro fases da metodologia Rational Unified Process (RUP), tem como objectivo desenvolver as actividades de modelação de negócio e requisitos [4] [5]. É um projecto que foi solicitado por um cliente com características específicas, uma Instituição Publica de Serviços Sociais (IPSS), a Santa Casa de Misericórdia de Guimarães (MG). A MG pretende melhorar a sua actividade e para tal este projecto poderá beneficiar o funcionamento da mesma, resultando numa maior informatização do sistema da MG, que irá permitir uma melhor gestão de todos os seus recursos. O projecto SIMG, na sua totalidade decorreu entre Novembro de 2010 e Janeiro de Metodologia Adoptada Como referido anteriormente, a metodologia utilizada foi o RUP, pois parte especifica desta pode ser adoptada para a realização de levantamento de requisitos para projectos de software. O RUP é um processo iterativo e incremental, composto por quatro fases (Inception, Elaboration, Construction e Transition) 1 Project Management Body of Knowledge é um guia do conjunto de conhecimentos em gestão de projectos (http://www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbok.pdf). 3

272 numa perspectiva temporal, onde cada fase consiste em uma ou mais iterações [4] [5]. O projecto SIMG foca-se na fase inicial, a Inception, onde o esforço atribuído é em grande percentagem, mais concretamente nas disciplinas de modelação de negócio e requisitos. É nesta fase que a equipa de PMS assegura a viabilidade do projecto definindo os objectivos e documenta essas informações no documento Visão. A disciplina modelação de negócio vai ajudar a equipa a entender a estrutura e a dinâmica da organização. Por outro lado, a disciplina de requisitos permite à equipa de PMS realizar o levantamento dos pedidos das partes interessadas e proceder à transformação destes num conjunto de requisitos, admitindo assim, um conjunto de requisitos detalhados sobre o que o sistema deve fazer, proporcionando desta forma um conjunto de casos de uso [5]. Como consultor e coordenador da equipa de PMS é importante ter conhecimento da metodologia adoptada para a realização do projecto, especificamente nas disciplinas referidas A Equipa de Trabalho Para a realização do projecto SIMG considera-se uma equipa composta por quatro alunos, pertencentes ao mesmo turno prático. Tabela 1 - Alunos pertencentes à equipa de trabalho. Nome do Aluno Número de Aluno Fabiano Rodrigues Graciano Filipe Luís Ramos Marta Isabel O conceito de equipa de trabalho é visto como um conjunto de pessoas organizadas, trabalhando em diferentes tarefas, mas com o mesmo objectivo, sendo necessário coordená-la e acompanhá-la ao longo do projecto. 4

273 2.3. Resultado Esperado Num contexto mais tecnológico o que se pretende do projecto SIMG será aumentar a qualidade da MG, combatendo lacunas nomeadamente na área de informação da IPSS. Espera-se que com este novo sistema informático a MG seja capaz de controlar todos os seus recursos com a máxima qualidade e eficiência exigida. Por outro lado, num contexto académico pretende-se desenvolver as competências dos alunos envolvidos (consultor/coordenador e equipa de trabalho) quer ao nível de planeamento e gestão de projectos de engenharia de software, quer ao nível de modelação de negócio e análise de requisitos. 3. Consultor do Projecto Durante a fase de planeamento, da fase Inception, a minha função foi a de consultor do projecto, com o objectivo de apoiar, orientar e aconselhar a equipa de PMS no seu desenvolvimento. Inicialmente mostrava-me um pouco confuso em relação ao meu papel perante o projecto, na realidade não sabia muito bem o que fazer, se tinha eu que efectuar o trabalho, se teria de coordenar os alunos, se ficaria quieto à espera que surgissem dúvidas e que fosse contactado, etc.. Todas essas dificuldades foram superadas devido a um esforço da minha parte, em compreender realmente o que teria de fazer enquanto consultor. O consultor é a pessoa que está em posição de ter influência sobre um individuo, grupo ou organização [6], utilizando os seus conhecimentos, a sua experiência pessoal e profissional e competências de relacionamento [7], mas que no entanto não têm autoridade formal, ou seja, não dispõe de poder directo para influenciar e produzir mudança perante o projecto [6] [7], logo todo o trabalho do consultor depende da atitude da equipa de trabalho [7]. A conjugação de um conjunto de competências são essenciais e de extrema importância a um consultor para a realização do projecto. Segundo Peter Block 5

274 existem três competências essenciais a um consultor: (1) competências técnicas, (2) competências interpessoais e (3) competências de consultoria [6] [7] [8]. Imagem 1 - Conjunto de competências de um consultor [9]. As competências técnicas estão inteiramente relacionadas com as capacidades do consultor em saber responder a questões que lhe são colocadas, ou seja, é importante ter conhecimento sobre o assunto que se está a tratar de forma a conseguir perceber o que o individuo, grupo ou organização está a dizer [6] [7] [8]. As competências interpessoais também são essenciais para lidar com as pessoas envolvidas, é necessário ter capacidade de transformar ideias em palavras, saber ouvir, saber dar apoio e até mesmo saber discordar de forma razoável para manter um relacionamento [6] [7] [8]. As competências de consultoria implica ser competente num conjunto de cinco fases sequenciais [6] [7] [8]: (1) entrada e contacto (2) colecção dos dados e diagnóstico, (3) feedback e a decisão de agir, (4) implementação e (5) extensão. No meu caso, apesar de não ter considerado as cinco fases, implicitamente estive envolvido nelas, pois numa primeira fase foi necessário o primeiro contacto com os alunos da equipa de PMS onde foram estabelecidas algumas questões relacionadas com o projecto, como marcação de reuniões e especificação do problema. Numa segunda fase, como consultor do projecto foi necessário realizar uma investigação inicial sobre o cliente e sobre as matérias a serem desenvolvidas, obtendo dados relevantes para a realização do projecto, dando o meu ponto de vista em relação ao mesmo, ou seja, ajudar a equipa a compreender como este deveria ser resolvido. Posteriormente, na terceira e quarta fase, foi necessário ajudar a equipa a resolver as dúvidas que apresentavam, actuando em 6

275 conjunto nas reuniões, que foram inicialmente estabelecidas, dando o feedback sobre o que estava sendo realizado e o que teria de ser melhorado de forma a atingir os objectivos propostos. Na última fase enquanto consultor, foi realizada uma revisão e avaliação ao que foi desenvolvido para que a equipa possa dar por encerrado o subprojecto planeamento do projecto SIMG. Como consultor de projecto as competências foram postas em acção, a vários níveis, sendo que houve necessidade de conseguir melhorar essas mesmas competências realizando um estudo mais pormenorizado dos conceitos, de forma a compreender o domínio do problema, bem como toda a funcionalidade e comportamentos esperados da organização cliente, como também fazer revisão de literatura sobre as técnicas a ser utilizadas para a fase de planeamento, de forma a poder ajudar, orientar e aconselhar a equipa de PMS na realização do projecto. De forma geral, e considerando o que é dito em [6] a consultoria é um novo recurso que contribui para melhorar a qualidade de vida e de trabalho das equipas. 4. Coordenador do Projecto Devido a alguns problemas que se fizeram sentir com as equipas de trabalho, o modelo de avaliação foi alterado, e por consequente, de consultor passei a coordenador da equipa de PMS. Esta alteração fez com que me fossem atribuídas mais responsabilidades, quer ao nível do controlo, da avaliação e da coordenação, como o planeamento e atribuição de tarefas pelos vários membros da equipa, e supervisionar a qualidade técnica dos artefactos produzidos, reportando periodicamente o desempenho da equipa aos docentes das duas unidades curriculares, de PMS e ACSI. Numa abordagem de engenharia de software, um processo de software, neste caso o RUP, envolve actividades de desenvolvimento, actividades de gestão e actividades de garantia de qualidade [10]. As actividades de desenvolvimento (Modelação do Negócio, Análise de Requisitos, Implementação, ) estão relacionadas com o desenvolvimento do produto de software a ser entregue ao cliente. As actividades de gestão estão relacionadas com planeamento e acompanhamento do projecto (distribuição de tarefas, estimativas de tempos e custos, elaboração de cronogramas, etc.). As 7

276 actividades garantia de qualidade estão relacionadas com a qualidade do produto em desenvolvimento e do processo utilizado, como por exemplo, a revisão e avaliação, quer sejam intermédias ou finais [10]. No entanto as actividades de gestão e qualidade são actividades de apoio às actividades de desenvolvimento visto que não se encontram directamente ligadas à construção do produto final [10], como se pode ver na figura 2. Figura 2 - Actividades do Processo de Software [10]. O projecto SIMG envolve as três actividades referidas, e enquanto coordenador de equipa estive envolvido nas actividades de gestão e de garantia de qualidade, sendo a equipa de trabalho de PMS responsável por as actividades de desenvolvimento. Assim, de forma a participar nas actividades mencionadas o gestor de projecto precisa de um vasto conjunto de capacidades e competências. As competências são descritas como os conhecimentos específicos do projecto, a competência para resolver problemas, liderança e competência social [1] têm que ser complementadas com competências empresariais e de gestão do projecto. Dependendo do tipo e objectivo do projecto, as competências variam em sua profundidade e amplitude [1]. Como coordenador as competências foram adquiridas ou aperfeiçoadas ao longo do desenvolvimento do projecto SIMG, pois esta fase do projecto implicou grande esforço, sendo necessário inicialmente replanear todo o projecto, realizando um novo plano, onde consta um cronograma que permite identificar as tarefas a executar por cada elemento da equipa, as datas de entrega e as reuniões. Posteriormente com o desenrolar do projecto foi necessário coordenar e controlar a equipa, diariamente, para ver se as tarefas estavam a ser cumpridas, 8

277 sendo necessário avaliar a qualidade de todos os artefactos que vinham a ser produzidos, dando o feedback ao grupo Replanear Como coordenador de projecto seria necessário realizar um plano de projecto de forma a conseguir uma estrutura que possibilita-se fazer estimativas relacionadas aos recursos, aos prazos relacionados com marcação de reuniões, entregas e realização de tarefas, isto tendo em consideração, o processo de desenvolvimento, ou seja, os artefactos que o RUP sugere em relação à fase Inception. Tabela 2 Artefactos planeados e desenvolvidos. Artefactos Planeados Business Case Business Vision Vision Diagramas de Caso de Uso Diagramas de Robustez Diagramas de Sequência Os artefactos produzidos, pela equipa, foram estabelecidos como críticos para a gestão do projecto, de forma a poder controlar e avaliar todo o trabalho que vinha sendo desenvolvido Coordenar, Controlar e Avaliar o Projecto A coordenação trata-se de uma actividade de gestão do projecto cuja função está relacionada com coordenação e gestão do projecto, distribuição e validação de tarefas, agendar reuniões e entregas, estabelecer prazos, resolver problemas e aconselhar. É então necessário saber lidar com as pessoas envolvidas no projecto, conseguir motiva-las para a realização do trabalho e obtenção dos objectivos propostos. 9

278 Como referido em [11] e [12] as motivações, os incentivos e as emoções das pessoas são muitas vezes extremamente complexas, e compreendê-las é geralmente uma parte importante de coordenação. Um projecto sem recursos humanos não será possível, logo é importante o envolvimento de pessoas que apoiem, que entreguem e que facilitem [10]. É importante identificar os recursos humanos e posteriormente prepara-los e orientalos para ajudar a cumprir o tempo de conclusão para os projectos [2] [10]. A gestão dos recursos humanos é uma das áreas de conhecimento, do PMBOK, mais importante quando se pensa na execução dos projectos. No projecto SIMG foi necessário coordenar uma equipa composta por quatro pessoas, foi um aspecto muito delicado e que exige algumas competências para tal. A forma como é realizada a comunicação é essencial e cuidada, conseguir transmitir informações de maneira clara e conseguir dar e receber feedback é bastante importante para a realização do projecto. Segundo [13] uma comunicação eficaz deve estar em mente do gestor, pois durante todo o ciclo de vida do projecto um líder deve estar disposto a comunicar com todos os interessados e membros da equipa do projecto. Durante o projecto, todos devem estar comprometidos a comunicar adequadamente - quer se trate de reuniões, de conversas de um para um, ou via e- mail. A comunicação eficaz deve ser incentivada em toda a organização até que se torne prática corrente, iniciando-se a partir da fase de planeamento do projecto [13]. Outro aspecto importante foi a gestão do tempo do projecto, sendo um factor crucial, devido aos prazos definidos. O tempo de projecto foi estabelecido no plano, com a elaboração de um cronograma onde constam as tarefas e os seus responsáveis, as entregas dos artefactos e as reuniões. Estas foram agendadas tendo em conta o tempo estabelecido para a realização do projecto, permitindo também controlar e avaliar o que estava a ser desenvolvido, pois como coordenador da equipa de trabalho também seria a pessoa responsável pelo sucesso do projecto. Seria então importante controlar e avaliar o que estava a ser feito, existindo a preocupação em assegurar que os objectivos do projecto estavam a ser atingidos, através do 10

279 controlo/monitorização e da avaliação do seu progresso, e quando necessário considerar acções que permitissem melhorar o que estava a ser realizado. O controlo foi conseguido através das entregas dos artefactos que foram estabelecidas no plano realizado. Uma entrega corresponde, de certa forma, a uma Milestone, onde seria realizada a avaliação do que estava a ser desenvolvido e se era necessário melhorar ou não, caso não fosse o grupo poderia avançar para a realização da próxima etapa (entrega), e assim sucessivamente. As reuniões com a equipa de trabalho ajudaram a perceber o que cada elemento estava a realizar, verificando o seu contributo para o projecto, sendo estas necessárias para a resolução de problemas que a equipa apresenta, ajudar a perceber alguns conceitos que não estão presentes e dúvidas técnicas como manuseamento de ferramentas e metodologias de modelação, neste caso específico, o UML. Através do plano foi mais fácil coordenar, controlar e avaliar o projecto. A forma de controlar e avaliar foi bem-sucedida, conseguindo o grupo atingir os objectivos propostos, realizando as tarefas dentro dos prazos estabelecidos, com a qualidade prevista. 5. Consultor de Projecto vs Coordenador de Projecto É possível agora fazer uma breve diferenciação das duas funções que me foram atribuídas para a realização do projecto: A função de consultor numa primeira fase e a função de coordenador numa segunda fase. Como consultor eu não poderia gerir o grupo, não poderia atribuir tarefas, marcar reuniões, estabelecer prazos, controlar e avaliar o que estava a ser realizado, apenas participava no projecto quando a equipa precisava. Enquanto consultor e como referido em [6] todo o trabalho depende da atitude da equipa de trabalho não tendo possibilidade de controlo sobre a mesma. Por outro lado a função de coordenador, uma função muito mais motivante na medida em que já era possível ter algum controlo sobre a equipa, com definição e atribuição das tarefas, agendamentos de reuniões e entregas, entre outros. A função de coordenador requeriu mais trabalho do que a função de consultor, sendo a minha participação no projecto de forma mais activa, ajudando o grupo a 11

280 perceber o que realmente têm de fazer e como fazer, sempre com a preocupação de motivar a equipa para a realização do mesmo. Relativamente à percentagem de trabalho por função pode-se verificar que enquanto consultor a percentagem é muito inferior em comparação com a função de coordenador de projecto, como podemos ver no gráfico 1. Coordenador Consultor Gráfico 1 Percentagem de trabalho por função. Os projectos são idealizados, planeados e executados por pessoas, o que torna os factores comportamentais e de personalidade do coordenador do projecto o elemento fundamental para a integração de uma equipa [14]. No entanto, no projecto SIMG o coordenador acaba também por ser um consultor, pois para além de coordenar o grupo era necessário ajuda-los naquilo que eles precisavam, de forma a atingir os objectivos. 6. Discussão e Conclusão Analisando tudo o que foi realizado durante o projecto e a minha participação, considero que foi uma experiência muito positiva na minha formação académica. Esta experiência proporcionou-me aprendizagem tanto na parte prática como na teórica, ao nível de análise e concepção de sistemas de informação, participando numa situação real, com prazos curtos e ao mesmo tempo com exigência de resultados. Tanto para a equipa como para mim esta foi a primeira participação em um projecto cujas funções estavam definidas da forma que foram apresentadas, havendo desta forma um grande interesse por parte de todos os elementos envolvidos. 12

281 A grande experiência desta convivência de três meses é sem dúvida a aprendizagem obtida, pois aprendemos a trabalhar como equipa, a respeitar a opinião do próximo, de dar opiniões e aconselhar, de saber dar e receber, etc. É possível concluir que para ser um bom coordenador de projecto, deve-se percorrer um longo caminho, começando pela procura do conhecimento, das áreas que realmente interessam, passando pela prática (competências técnicas) e concluindo com as competências interpessoais. Referências 1. Dr. N. Ehsan, K. Z. W., U. Asghar, M. T. Nawaz, E. Mirza, S. Z. Sarwar (2010). "Effects of Project Manager s Competency on Project Success." IEEE. 2. Project Management Institute (2008). A Guide to the Project Management Body of Knowledge PMBOK Guide 2008 Edition, Pennsylvania, USA. 3. Zhang, W. (2009). "The Relationship between Project Manager Leadership Style and Project Sucess." University of Wisconsin-Platteville. 4. IBM Corp, Rational Unified Process Version 7.1. The RUP. 5. Mocanu, V. (2010). "Requirements for Security Enhancements to Legacy Software with RUP." Information Security Journal: A Global Perspective 19: Wandick., K. A actuação do consultor e da consultoria em uma organização. Core RH. 7. Block, P. (1999). Flawless Consulting: A Guide to Getting Your Expertise Used 2nd Edition. 8. Consultant, I. (2011). "3 Skills a Consultant Must Have." from 9. Rees, A. (2009). "What is Consulting?". 10. Falbo, R. d. A. (2005). "Engenharia de Software." (UFES - Universidade Federal do Espírito Santo). 11. Hölzle, K. (2010). "Designing and implementing a career path for project managers." International Journal of Project Management, Crowston, T. M. a. K. (1993) The Interdisciplinary Study of Coordination. 13. Balogun, M. (2008). Leadership in Project Management: Exploring Roles & Behaviours. Software Magazine, Standish: Project Success Rates Improved Over 10 Years. 14. Carina Careli de Almeida, L. A. d. P. C., José Rodrigues de Farias Filho (2008). "Em busca do perfil ideal de Gerente para alcançar o sucesso dos projectos IV Congresso Nacional de Excelência em Gestão. 13

282 ITIL vs ISO/IEC ABSTRACT Têm vindo a aumentar o reconhecimento que a informação é o recurso estratégico mais importante que uma organização tem de gerir. A chave para o armazenamento, análise, produção e distribuição da informação no seio da organização é a qualidade dos serviços de tecnologias da informação posto ao dispor do negócio. É essencial que reconheçamos que os serviços de IT são recursos cruciais e estratégicos. Como tal, as organizações devem investir em um nível apropriado de recursos no suporte, disponibilização e gestão de serviços críticos de IT e nos sistemas de informação que os suportam. No entanto, estes aspectos de TI são geralmente negligenciados ou apenas abordados superficialmente dentro das organizações. Abílio Casanova 2010/2011 Análise e Concepção de Sistemas da Informação Mestrado em Sistemas da Informação Universidade do Minho

283 Índice Keywords...3 Introdução...4 O que é a gestão de serviços de TI?...5 O porquê da adopção de boas práticas?...6 O que é o ITIL?...9 Framework ITIL Versões do ITIL Porquê adoptar o ITIL? O que é o ISO/IEC 20000? Benefícios da certificação ISO ISO e ITIL ISO/IEC vs ITIL Papel do ITIL para atingir a certificação em ISO A Importância da Melhoria Contínua Conclusão Bibliografia

284 Keywords Tecnologia da Informação (TI); International Organization for Standardization (ISO); International Electrotechnical Commission (IEC); Information Technology Infrastructure Library (ITIL); Central Computer and Telecommunications Agency (CCTA); Office for Government Commerce (OGF); British Standard Institute (BSI); 3

285 Introdução A gestão de serviços de IT tornou-se numa questão de sobrevivência das empresas. Alinhar e integrar a tecnologia da informação com o negócio, em conjunto com as melhores práticas e metodologias, transformaram a gestão de TI numa das melhores ferramentas para mostrar o real valor da TI. É necessário ter em atenção dois pontos : 1. A TI não é uma parte desconectada do negócio; 2. A área de TI não pode ser considerada apenas de suporte. O aumento da complexidade de gestão de TI é um problema para qualquer organização na medida em que não está próximo do fim, bem pelo contrário, novas tecnologias, plataformas, maior velocidade da inovação, e outras tendências tecnológicas tendem a transformar a gestão de TI numa complexa área de actuação. Apesar de existirem várias metodologias e ferramentas para apoiar a gestão e controle dos activos, estas ferramentas apenas auxiliam, na verdade, nenhuma possui uma fórmula mágica que resolva os problemas. Isto porque as ferramentas focam diversos pilares, entre eles processos, pessoas, métricas entre outros. Tendo em conta estes dois pressupostos, este trabalho tem como objectivo fazer a ligação entre o guia de boas práticas ITIL e o standard ISO/IEC São eles modelos concorrentes ou complementares? 4

286 O que é a gestão de serviços de TI? Para melhor entendermos o que é a gestão de serviços, temos em primeira mão que perceber o que são serviços, e como a gestão de serviços pode ajudar aos fornecedores de serviços a disponibilizar e gerir esses mesmos serviços. Podemos definir um serviço como uma forma de disponibilizar valor aos clientes através de processos e ferramentas que melhorem os resultados do negócio. Um exemplo simples de uma mais-valia para um cliente que pode ser facilitada por um serviço de IT é, por exemplo, o facto de um vendedor, em que o auxílio de uma ferramenta informática tenha agilizado a parte burocrática no negócio resultando desta forma no aumento do tempo disponível para interagir com os clientes. Os proveitos que os clientes querem atingir são a razão do porquê de terem comprado ou usado determinado serviço. O valor do serviço para o cliente está directamente dependente de como este é capaz de facilitar esses proveitos. A gestão dos serviços é o que faz com que o fornecedor de serviço perceba os serviços que está a disponibilizar, que assegure que os serviços sejam factores facilitadores para os resultados que os seus clientes pretendem atingir, que perceba o valor desses serviços para os clientes, e para perceber e gerir todos os custos e riscos associados a esses serviços. A Gestão de Serviços é um conjunto de capacidades organizacionais que potenciam valor para os clientes na forma de serviços. 5

287 O porquê da adopção de boas práticas? O crescer da adopção das melhores práticas de IT é o resultado da necessidade da indústria das tecnologias da informação gerir, da melhor forma, a qualidade e a fiabilidade dos sistemas de IT no negócio e responder ao crescimento do número de regulamentações e requisitos contratuais. No entanto, existe o perigo de que a implementação destas boas práticas sejam dispendiosas e isentas de conteúdo se forem tratadas como puros guias técnicos. Para serem mais eficazes, as melhores práticas, devem ser aplicadas dentro do contexto do negócio, focando-se no ponto onde o seu uso irá trazer o maior benefício para a organização. Gestão de topo, gestão dos negócios, auditores, administrativos e profissionais de IT devem trabalhar em conjunto para se certificarem que as melhores práticas de IT levam à eficácia de custos dos serviços de IT. Podemos apontar que as boas práticas de IT são importante pois: A gestão das Tecnologias da Informação é crítica para o sucesso da estratégia da organização; Ajudam a atingir a gestão das actividades de IT. Um sistema de gestão é necessário para que toda a gente saiba quais os seus objectivos e o que fazer (politicas, controlos internos e regras definidas). Geram bastantes benefícios, incluindo ganhos de eficiência, menos erros, aumento da confiança dos parceiros de negócio e respeito pelas entidades reguladoras. A implementação das melhores práticas deve ser consistente com a gestão de risco da organização e com o sistema de controlo e integrada com outros métodos e práticas que estejam a ser usados. As normas e as boas práticas não são remédios, e a sua eficácia depende da forma como foram implementadas e se se 6

288 encontram actualizadas. São mais úteis quando são aplicadas como um conjunto de princípios e um ponto de partida para delinear procedimentos específicos. Para evitar que essas práticas fiquem com um vazio de conteúdo, os quadros superiores e os funcionários devem perceber o que fazer, como o fazer e o porquê de elas serem importantes. A implementação deve ser delineada, prioritizada e planeada de forma a atingir eficiência pretendida. As boas práticas podem surgir de diferentes fontes, incluindo sistemas públicos (tal como ITIL, COBIT e CMMI), normas (como a ISO/IEC e ISSO 9000), e conhecimento proprietário das pessoas e das organizações. Devido a sua natureza técnica, as normas e boas práticas de IT são mais conhecidas pelos elementos da área, os profissionais de IT, gestores e consultores, os quais adoptam e fazem uso delas com boas intenções mas potencialmente sem uma focalização no negócio em causa ou sem o envolvimento e apoio do cliente. Mesmo em organizações onde as práticas como o ITIL foram implementadas, alguns gestores de negócio têm uma percepção diminuta acerca do seu propósito real e são incapazes de influenciar a sua adopção. Para terem a percepção do seu valor total, os clientes dos serviços de TI necessitam de serem envolvidos no processo, já que a eficaz utilização das TI deve ser uma experiência colaborativa entre o cliente e os fornecedores de serviços internos e externos, com o cliente a definir os requisitos. Outras partes interessadas, tais como os elementos da administração, executivos, auditores e reguladores, também devem ter noção do investimento em TI e de como essa situação vai trazer mais-valias à organização. São diversos os pontos chaves que os gestores de topo e os gestores de IT têm de enfrentar: TI e planeamento da gestão estratégica; Integração e alinhamento da TI e dos objectivos do negócio; Implementação de melhoria continua; Medição da organização da TI em termos de eficácia e eficiência; Optimização de custos e do custo total de posse (TCO Total Cost of Ownership); 7

289 Atingir e demonstrar o retorno do Investimento (ROI) Demonstrar o valor das TI no negócio; Desenvolver negócios, sociedades e relações de TI; Utilização das TI para ganharem vantagem competitiva; Gerir a mudança nas TI; Os desafios para os gestores de TI são o coordenar e trabalhar em conjunto com o negócio de forma a fornecerem serviços de TI de alta qualidade. O principal objectivo da Gestão dos Serviços é de assegurar que os serviços de IT estão alinhados às necessidades do negócio e que de forma activa as suportem. É imperativo que os serviços de IT suportem os processos do negócio, mas também é de extrema importância que as TI actuem como agentes facilitadores na transformação do negócio. Todas as organizações que usam TI dependem delas para serem bem sucedidas. Se os processos de IT e os serviços de IT forem implementados, geridos e suportados de forma apropriada, o negócio será melhor sucedido, irá sofrer menores perturbações e irá sofrer menor perda de horas produtivas, irá reduzir custos, aumentar os ganhos, melhorar as relações públicas e atingirá os objectivos do negócio. 8

290 O que é o ITIL? A Gestão de Serviços de Tecnologias de Informação é hoje uma área central nas organizações, tendo em conta o crescente nível de informatização dos processos e serviços de uma instituição. Neste âmbito, surge a certificação ITIL, reconhecida internacionalmente como padrão na Gestão de Serviços em TI, adoptada por instituições de todo o mundo como estratégia para redução de custos e aproveitamento de recursos, gerando maior satisfação junto dos clientes. Information Technology Infrastructure Library (ITIL) é um conjunto de boas práticas a serem aplicadas na infra-estrutura, operação e manutenção de serviços de tecnologia da informação (TI). Foi desenvolvido no final dos anos 1980 pela CCTA (Central Computer and Telecommunications Agency) e actualmente está sob custódia da OGC (Office for Government Commerce) da Inglaterra. Os seus benefícios incluem: Aumento da satisfação do utilizador e do cliente em relação aos serviços de IT; Aumento da disponibilidade do serviço, levando ao aumento dos proveitos e ganhos do negócio; Poupança resultado da diminuição/eliminação de tempos perdidos, aumento da gestão e uso dos recursos; Aumento do tempo para a pesquisa de novos produtos e serviços; Melhorias na tomada de decisão e optimização do risco; Maior transparência e profissionalismo nas decisões envolvendo TI e negócio; 9

291 Framework ITIL O IT Infrastructure Library (ITIL) é um conjunto de práticas para disponibilizar serviços eficientes e efectivos de TI, além da gestão da infraestrutura de TI. O desenvolvimento do ITIL foi motivado pelo facto das organizações estarem cada vez mais dependentes de TI para alcançarem os objectivos corporativos delineados. Essa dependência levou a necessidade de serviços de TI com qualidade correspondendo aos objectivos de negócio de cada organização e atingindo os requisitos e expectativas dos seus clientes. Paulatinamente, a ênfase da TI tem mudado do desenvolvimento de aplicações para a gestão de serviços. Os serviços de TI devem ser confiáveis, consistentes, de alta qualidade e com um custo aceitável. Considerando-se o ciclo de vida dos produtos de TI, estima-se que a fase operacional represente 70 a 80% do custo e tempo empregados. Isto demonstra a necessidade de uma gestão de serviços eficiente para garantir o sucesso da área de TI. A gestão de serviços de TI aborda a provisão e suporte do serviço de TI personalizado às necessidades de cada organização. O ITIL foi desenvolvido para disseminar as melhores práticas em gestão de serviços de TI de forma sistemática e coesa. A abordagem baseia-se na qualidade do serviço e no desenvolvimento de processos eficazes e eficientes. O ITIL oferece um framework comum para todas as actividades do departamento de TI, como parte do serviço, sendo baseado na infra-estrutura de TI. Estas actividades são divididas em processos, os quais criam um framework efectivo para tornar mais madura a gestão dos serviços de TI. Cada um dos processos cobre uma ou mais actividades pertinentes ao departamento de TI. Esta abordagem de processos permite descrever as melhores práticas de TI de forma independente da estrutura organizacional do departamento de TI. Muitas destas melhores práticas são claramente identificadas e utilizadas por grande parte das organizações de TI. O ITIL apresenta essas práticas de forma coerente. Os livros do ITIL descrevem como estes processos, algumas vezes 10

292 identificáveis, podem ser optimizados e como a interacção entre os processos pode ser melhorada. Além disso, explicam como os processos podem ser formalizados dentro da organização. Os livros do ITIL ainda disponibilizam um quadro de referência para a organização com terminologias relevantes, as quais ajudam a definir os objectivos e determinar o esforço requerido para alcançá-los. Usando a abordagem de processos, o ITIL primariamente descreve o que deve ser incluído na gestão da TI para dotar os serviços de TI com a qualidade requerida. O ITIL surge num contexto, onde as tendências de mercado apontam dificuldades crescentes no sector das TI, tais como: Custo crescente da prestação de serviços de TI; Aumento do nível de exigência quanto a qualidade dos serviços de TI; Complexidade crescente da infra-estrutura e constantes mudanças na sua composição; Dependência de várias áreas do negócio quanto aos serviços prestados pela TI. As organizações actuais estão cada vez mais dependentes das TI, e estas necessitam de ter os seus objectivos incorporados às necessidades do negócio. 11

293 Versões do ITIL A primeira versão do ITIL foi denominada Government Information Technology Infrastructure Management (GITIM), sendo mantida em 40 livros. Entretanto, a versão 2.0 lançada em 2001 possui apenas 10 livros, com uma visão mais global das práticas de prestação de serviços de TI. Já em 2007, foi lançada a versão 3.0 da biblioteca a qual é composta por 5 livros : Service Strategy; Service Design; Service Transition; Service Operation; Continuous Service Improvement; Esta versão reúne o melhor do ITIL V1 e V2, incorporando as melhores práticas de serviços de TI. A tabela seguinte ilustra as principais diferenças entre a versão V2 e a V3. ITIL V2 Alinhamento com o negócio; Foco nos processos de Suporte aos Serviço e Entrega dos Serviços; Catálogo de Serviço Linear; ITIL V3 Integração com o Negócio; Foco no ciclo de vida dos Serviços; Dinamic Service Protfolios; Definição da Preposição de Valor da Gestão de Serviço; Alinhamento com padrões e frameworks; Definição da Estratégia e Gestão de Serviços; 12

294 Os 5 livros, anteriormente referidos, cobrem cada fase do ciclo de vida do serviço, desde a definição inicial e análise dos requisitos dentro do Service Strategy e Service Design, até à migração para o ambiente dentro do Service Transition, até a operação ao vivo e melhoria no Service Operation e Continual Service Improvement. Figura 1- Ciclo de vida de um serviço. Porquê adoptar o ITIL? O ITIL estabelece importantes passos para que a tecnologia saía da classificação de complexa e cara para algo potenciador do negócio. Na verdade, podemos referir que a percepção das Organizações sobre a área de TI são: Provisão de serviços inadequada; 13

295 Falta de comunicação e entendimento com os utilizadores; Gastos excessivos com infra-estrutura (sentimento de se tratar de uma parcela demasiado elevada nos gastos totais do negócio); As justificações dadas para os custos dos serviços são insuficientes ou pouco fundamentadas; Falta de sintonia entre as mudanças na infra-estrutura e os objectivos de negócio; Entrega de projectos com atrasos e derrapagens no orçamento. No entanto, a adopção das boas práticas do ITIL dão resposta aos pontos anteriores na medida em que apresentam como resultado: Fortalecimento dos controlos e da gestão dos ambientes de TI; Orientação a processos com significativa redução nos tempos de execução e distribuição de serviços; Diminuição gradativa da indisponibilidade dos recursos e sistemas de tecnologia da informação, causados por falhas no planeamento das mudanças e implantações em TI; Elevação dos níveis de satisfação dos utilizadores internos e clientes com relação à disponibilidade e qualidade dos serviços de TI; Redução dos custos operacionais de TI; Reconhecimento da capacidade de gestão pelos accionistas, colaboradores e clientes; Adesão às instruções normativas das entidades reguladoras e criticadoras. 14

296 O que é o ISO/IEC 20000? Como vimos anteriormente, podemos considerar o ITIL como um guia de boas práticas que devem ser seguidas de forma a oferecer aos utilizadores serviços adequados de IT para suportar os seus processos de negócio. As certificações ITIL estão disponíveis para indivíduos, no entanto, até bem recentemente, não havia forma de uma organização comprovar que estava a trabalhar alinhada com as recomendações do ITIL. A norma ISO foi concebida para preencher esta necessidade. Iniciada pelas organizações itsmf e BSI (British Standard Institute), foi modelada com base nos princípios de ITIL e assim, pela primeira vez, oferece às organizações a possibilidade de certificar o seu serviço de gestão de TI. A norma ISO tem como objectivo certificar as empresas e não os produtos, isto é importante salientar, a norma certifica o processo e não a qualidade do produto ou serviço prestado, mas sim se o mesmo é gerido seguindo as melhores práticas. O novo standard de gestão de serviços de tecnologias de informação, ISO/IEC 20000, foi publicado para endereçar o fornecimento destes serviços e a sua contribuição para o sucesso do negócio. Este novo standard veio para substituir o standard britânico reconhecido mundialmente, BS O ISO/IEC foi desenvolvido para responder às necessidades de uma audiência global e fornecer um entendimento comum da gestão de serviços de tecnologias de informação em todo o mundo. Cobre os aspectos responsáveis por 80% do investimento total em tecnologias de informação da grande maioria das organizações. À semelhança do que acontecia com o BS 15000, este standard é publicado em duas partes e permitirá aos prestadores de serviços compreender como poderão alcançar a qualidade no serviço prestado aos seus clientes, internos e externos. As organizações que procurem ser certificadas com a norma ISO 20000, necessitam de preencher requisitos específicos, requisitos esses que estão 15

297 especificados na primeira parte da norma ISO/IEC 20000, ou seja na Specification. A segunda parte da norma (ISO/IEC 20000, Part 2 : Code of Practice), contém sugestões para as organizações que pretendem ser certificadas. No entanto, as linhas de orientação desta segunda parte não são estritamente mandatórias. Em modo de resumo, os dois requerimentos centrais da norma ISO podem ser descritos como: 1. Utilização de uma abordagem de gestão que está em conformidade com os standards de gestão ISO9001:2000, baseados nos princípios da Gestão dos Processos de Negócio e apontados para uma continua melhoria da qualidade. 2. Alinhamento dos processos de TI com o requisitos do standard ISO 20000, que na generalidade corresponde às boas práticas de ITIL. Benefícios da certificação ISO O ITIL oferece alguns tipos de certificação para os indivíduos com o objectivo de certificar que aquela pessoa conhece e/ou sabe aplicar ITIL. ISO 20000, como é um padrão internacional, pode e deve ser auditado. Com isso, a própria norma oferece direcções de como auditar o cumprimento da mesma. Isso ajudou a remover um dos maiores problemas de ITIL: comprometimento e reconhecimento da alta Direcção. Com a ISO ficou mais fácil ganhar apoio da alta direcção. Mas porque é importante a certificação na ISO 20000? É importante pois transmite a confiança aos clientes e investidores que os serviços de TI são planeados, geridos e revistos constantemente de forma coerente, contínua e segura. Porque é isso tão importante? Porque a obtenção da certificação ISO pode contribuir para que as empresas alcancem uma vantagem competitiva relativamente às outras que não cumprem essa norma. 16

298 A existência de um certificado ISO numa organização é prova que essa organização é: Orientada aos seus clientes; Capaz de apresentar serviços que atingem níveis de qualidade bem definidos; Faz uso dos recursos de forma económica e produtiva. Como tal, o certificado e o correspondente logótipo representa uma crescente vantagem competitiva no mercado. São muitos os clientes que consideram a certificação em ISO uma condição essencial para celebrar contractos/parcerias com empresas de serviços da área de TI. É claro que, uma empresa que trabalhe alinhada com os princípios da ISO (e ITIL) também oferece vantagens internas para a organização, afinal o standard é sobre o suportar os processos de negócio com os serviços de TI adequados, fazendo com que esses serviços funcionem da forma mais eficiente possível. O estatuto internacional do standard ISO/IEC é fundamental para a sua adopção a nível mundial. Torna-se claro que atingir a certificação, medindo o nível de serviço face ao standard, tem um valor acrescentado real para as organizações não só porque demonstra a qualidade dos serviços internos como lhes permite seleccionar parceiros externos adequados. Em resumo, a certificação ISO passa pela demonstração de confiança aos stakeholders, principalmente aos accionistas, clientes e investidores. 17

299 ISO e ITIL A norma ISO não oferece conselhos ou guias de como definir os processos. É sim, um conjunto de requisitos que devem ser atingidos de forma a demonstrar a qualidade necessária para atingir a certificação. É neste ponto que o ITIL entra em jogo : A ITIL (especialmente a nova versão, a 3) está fortemente alinhada com a ISO e oferece uma colecção detalhada de boas práticas, as quais são um método de partida para o desenvolvimento de processos alinhados à ISO A introdução ao ITIL, pode ser, desta forma, considerada a melhor forma de preparar uma organização para a certificação em ISO A tabela seguinte sumariza a forma como os processos da norma ISO estão relacionados com a ITIL V3. Requisitos da ISO Planning and Implementing New or Changed Services Processos de ITIL relacionados Os requisitos são preenchidos pelos processos de ITIL Service Strategy e Service Level Management Service Delivery Service Level Management Service Reporting Service Continuity and Availability Management Budgeting and Accounting for IT Services Capacity Management Information Security Management Os requisitos são preenchidos pelo processo de ITIL Service Level Management Os requisitos são preenchidos pelo processo de ITIL Service Level Management Os requisitos são preenchidos pelos processos de ITIL IT Service Continuity Management e Availability Management Os requisitos são preenchidos pelo processo de ITIL Financial Management Os requisitos são preenchidos pelo processo de ITIL Capacity Management Os requisitos são preenchidos pelo processo de ITIL IT Security 18

300 Relationship Processes Business Relationship Management Supplier Management Resolution Incident Management Problem Management Control Configuration Management Change Management Release Release Management Management Os requisitos são preenchidos por vários processos do ITIL : Service Portfolio Management, Service Level Management ; e Continual Service Improvement Os requisitos são preenchidos pelo processo de ITIL Supplier Management Os requisitos são preenchidos pelo processo de ITIL Incident Management Os requisitos são preenchidos pelo processo de ITIL Problem Management Os requisitos são preenchidos pelo processo de ITIL Service Asset and Configuration and Asset Management Os requisitos são preenchidos pelo processo de ITIL Change Management Os requisitos são preenchidos pelo processo de ITIL Release and Deployment Management 19

301 ISO/IEC vs ITIL O ITIL e o ISO/IEC estão alinhados. O ITIL não é baseado no ISO/IEC 20000, ISO/IEC não é baseado em ITIL 1 A tabela seguinte apresenta uma comparação directa entre a norma ISO e o Framework ITIL. ISO ITIL v3 Standard global que descreve requisitos Biblioteca de boas práticas Certificação para fornecedores de Certificação para indivíduos. serviços Independente da estrutura Define funções, papeis e organizacional responsabilidades 13 Processos; sem funções 26 Processos e 4 funções Baseado em processos Documentado em 5 fases de um ciclo de vida norma ITIL. Em resumo, a pirâmide seguinte ilustra a relação da ISO com a 1 Lynda Cooper, Forum ISO20000 Portugal,

302 ISO Parte 1 Requisitos a Serem cumpridos ISO Parte 2 ITIL (IT Infraestructure Library) Orientações para o alcance dos requisitos Guia de Boas Práticas Procedimentos Internos Solução particular da organização Figura 2 Relação ISO/IEC e ITIL Papel do ITIL para atingir a certificação em ISO A coisa mais importante no inicio de um grande projecto como uma certificação na norma ISO é saber exactamente o que é necessário atingir, ou seja, no onde queremos estar no fim do projecto. Infelizmente, a norma em si apenas define um número de requisitos que a empresa necessita preencher de forma a atingir a certificação. A ISO estabelece que é necessário desenvolver e implementar um número de processos que devem atingir determinados requisitos, mas não descreve a forma de os atingir, ou seja a forma de como o processo deve ser feito. Sendo assim, não existe uma resposta curta e directa para a questão: o que deve ser atingido?. Como resultado, é frequente o seguinte problema no inicio de uma iniciativa como a certificação em ISO 20000: Não são claros como é que os hábitos de trabalho da organização devem ser de forma a estarem em conformidade com a ISO 20000, sendo então complicado de determinar qual o sentido a apontar e quanta mudança é necessária. No entanto, desde que a as boas práticas ITIL e a norma ISO estão alinhadas, é possível utilizar o ITIL como forma de aconselhamento. 21

303 A Importância da Melhoria Contínua Todas as organizações deverão ter a noção que o aspecto chave da ITIL e, consequentemente, da ISO 20000, é a validação da melhoria contínua da qualidade do nível de gestão de serviços de TI. O modelo de melhoria contínua da qualidade é baseado no PDCA (Plan-Do-Check-Act), de Ewards Deming, inicialmente estabelecido para a indústria de transformação. Nenhum modelo nem forma de trabalho é estático. O mundo transformase, e cada vez de forma mais rápida. A ideia de um processo de avaliação e melhoria contínua é a ideia-chave para manter os processos e procedimentos baseados no ITIL v3 e na ISO sempre actualizados e úteis. 22

304 Conclusão Neste trabalho foram apresentados os principais conceitos do Framework IIL e da norma ISO/IEC Enquanto a ITIL é um conjunto das melhores práticas para a gestão dos serviços de tecnologia de informação, a ISO é uma norma internacional que tem como objectivo regulamentar, no âmbito mundial, o padrão para a gestão de serviços de tecnologia de informação. O ITIL é flexível enquanto a norma ISO tem uma série de exigências que devem ser seguidas para que a organização possa ser certificada. Ambos têm em comum a meta de fornecer um conjunto de processos estruturados e com qualidade para gerir os serviços de TI. A conclusão que podemos chegar, é que o ITIL é uma excelente opção de modelo de referência para melhorar e controlar os processos de TI numa organização, e a norma ISO/IEC visa certificar que essa mesma organização cumpre os requisitos necessários para uma correcta, eficaz e eficiente Gestão de Serviços de TI. Aliás, no mercado já há consenso que a implementação das melhores práticas ITIL e a certificação dos profissionais nos fundamentos ITIL auxilia na obtenção da certificação ISO pela organização. 23

305 Bibliografia APMG-International. (s.d.). ISO/IEC Certification & Qualification Schemes. Obtido em 2 de Fevereiro de 2011, de Bon, J. V., Jong, A. d., Kolthoft, A., Piper, M., Tjassing, R., Veen, A. v., et al. (2007). Foundations of IT Service Management based on ITIL v3. Zaltbommel, Netherlands: Van Haren Publishing. Cartlidge, A., Hanna, A., Rudd, C., Macfarlane, I., Windebank, J., & Rance, S. (2007). An Introductory Overview of ITIL V3. The UK Chapter of the itsmf. Integral, V. (s.d.). Workshop : Construir valor com a gestão de sistemas integrados. Obtido em 12 de Janeiro de 2011, de ISO/IEC. (s.d.). ISO/IEC Obtido em 15 de Janeiro de 2011, de ISO/IEC 20000: itsmf. (s.d.). itsmf International - IT Service Management, ITIL and complimentary Best Practices. Obtido em 5 de Janeiro de 2011, de 24

306 1 íveis de maturidade do Processo de Software Mestrado em Sistemas de Informação Fábio Miguel Carneiro Castro Cosme Resumo O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI foi baseado nas melhores práticas para o desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto na engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção. Este presente artigo tem como objectivo descrever e analisar os níveis de maturidade do processo de software do modelo CMMi (Capability Maturity Model Integration). Introdução De acordo com o modelo CMMi, os níveis foram criados para indicar a capacidade de uma organização e representam um caminho evolucionário para uma organização aprimorar os processos com base nas melhores práticas do modelo do CMMI. Os níveis indicam uma sequência lógica para que os processos evoluam na medida em que estes satisfaçam as exigências do modelo. Por um outro lado, do ponto de vista de quem compra o serviço destas organizações, os níveis permitem que comparações sejam feitas entre diversos fornecedores, avaliando em qual nível (ou níveis) as empresas opera. Agora, o modelo do CMMI apresenta dois caminhos a serem seguidos: Contínuo: permite que a organização evolua incrementalmente os processos correspondentes a uma área de processo (PA) individualmente, ou um grupo de área de processos seleccionado pela empresa. Estágios: a evolução é feita num grupo de processos relacionados que são dirigidos ao implementar-se grupos de áreas de processo (PA) prédeterminados sucessivos. Estes caminhos (também chamados de representações do modelo) são importantes porque são eles que vão determinar o tipo de nível que será usado na organização.

307 2 Para a representação contínua, usa-se o termo nível de capacidade ou ainda capacidade da área de processo. Ou seja, um nível de capacidade está relacionado a apenas uma área de processo. Exemplo: nível de capacidade 3 na área de planeamento de projectos. Para a representação por estágios usa-se o termo nível de maturidade ou ainda a maturidade da organização. Ou seja, um nível de maturidade está relacionado a um grupo de áreas de processo. Exemplo: nível de maturidade 2 significa que a empresa implementou as práticas das áreas de processo. Este artigo baseia-se nos níveis de maturidade do modelo CMMi, estando este dividido em primeiro lugar pelos cinco níveis de maturidade dos processos de software e dentro deste tópico existem outros sub-tópicos importantes para os níveis de maturidade do processo sendo eles: Caracterização do comportamento dos íveis de Maturidade, Analise dos íveis de Maturidade, Visibilidade Interna do desenvolvimento do Projecto de Software, Capacidade do Projecto e a Previsão do Desempenho, Saltar entre íveis de Maturidade 1 - Os Cinco íveis da Maturidade do Processo de Software A melhoria contínua de processos é assente em muitas etapas evoluídas ao invés de fundamentar-se em inovações revolucionárias [Imai86]. O CMM fornece uma estrutura para organizar essas etapas evoluídas em cinco níveis de maturidade que estabelecem fundamentos sucessivos para a contínua melhoria do processo. Estes cinco níveis de maturidade definem uma escala ordinal para medir a maturidade de um processo de software da organização e para avaliar a sua capacidade de processo de software. Os níveis também ajudam a organização a escolher de forma prioritária as tentativas de melhorias. ível de maturidade é um estágio evolutivo bem definido que procura um processo de software maduro. Cada nível de maturidade fornece uma gama de fundamentos para a melhoria contínua do processo. Cada nível compreende um conjunto de objectivos de processos que, quando satisfeitos, estabilizam uma componente importante do processo de software. Cada nível alcança uma estrutura de maturidade, estabelece diferentes componentes no processo de software, resultando num crescimento na capacidade de processo da organização. O CMM está organizado em cinco níveis ilustrados na Figura 1, a prioridade está de acordo com as acções de melhoria para o crescimento da maturidade do processo de software. As setas classificadas na Figura 1 indicam o tipo de capacidade que cada processo está a ser referenciado pela organização e cada etapa da estrutura de maturidade.

308 3 As caracterizações dos cinco níveis de maturidade são descritas a seguir: 1) Inicial O processo de software é caracterizado como ad hoc. Poucos processos são definidos e o sucesso depende de esforço individual. 2) Repetível Os processos básicos de gestão do projecto são estabelecidos para acompanhar os custos, cronogramas e funcionalidades. 3) Definido O processo de software para as actividades de gestão e engenharia é fundamentado, com um padrão e integrado num processo de software padrão para a organização. Todos os projectos utilizam uma versão aprovada do processo de software padrão para desenvolver software. 4) Gestão São efectuadas medidas detalhadas do processo de software e da qualidade do produto. O processo e os produtos de software são quantitativamente compreendidos e controlados. 5) Optimizado A melhoria contínua do processo é proporcionada pelo feedback quantitativo do processo e pelas ideias e tecnologias inovadoras. Figura1-5 níveis de maturidade do processo de maturidade 1.1 Caracterização do comportamento dos íveis de Maturidade Os níveis de maturidade de 2 a 5 podem ser caracterizados pelas actividades executadas pela organização para estabelecer ou melhorar o processo de software, pelas actividades realizadas em cada projecto e pela capacidade dos processos proveniente dos projectos. A caracterização do comportamento do Nível 1 também é descrita para estabelecer uma base de comparação com as melhorias de processos alcançadas nos níveis mais elevados de maturidade.

309 ível 1 O ível Inicial No Nível Inicial, a organização, de um modo geral, não fornece um ambiente estável para desenvolvimento e manutenção de software. Quando uma organização não dispõe de práticas de gestão bem estabelecidas, os benefícios das boas práticas de desenvolvimento de software são minados por um planeamento ineficiente e por um contexto onde os compromissos são sempre reactivos. Entende-se por compromissos reactivos aqueles que são firmados como reacção a algum acontecimento não previsto no planeamento. No meio de uma crise, os projectos tipicamente abandonam os procedimentos que foram planeados e partem para a codificação e testes. O sucesso depende inteiramente de ter um gestor de projectos excepcional e uma equipa de desenvolvimento de software madura e eficiente. Ocasionalmente, os gestores de software eficientes, que dispõem de poder, podem resistir às pressões de recorrer a atalhos no processo de software; contudo, quando deixam o projecto, a influência desaparece. Mesmo um forte processo de desenvolvimento não pode superar a instabilidade criada pela ausência de práticas sólidas de gestão. A capacidade do processo de software em organizações de Nível 1 é imprevisível porque o processo de software é constantemente alterado à medida que o trabalho progride (ou seja, o processo é ad hoc ). Cronogramas, orçamentos, funcionalidades e qualidade do produto são geralmente imprevisíveis. O desempenho depende da capacidade dos indivíduos e varia com as suas habilidades, conhecimentos e motivações. Raros são os processos de software que são estáveis e o desempenho só pode ser previsto através de habilidades individuais e não por meio da capacidade da organização ível 2 O ível Repetível No Nível Repetível, as políticas de gestão de projecto de software e os procedimentos para implementá-las são estáveis. O planeamento e a gestão de novos projectos são baseados na experiência adquirida em projectos similares. Um dos objectivos alcançados no nível 2 é a institucionalização dos processos para os projectos de software, possibilitando que as organizações repitam as práticas bem sucedidas desenvolvidas em projectos anteriores, apesar dos processos específicos implementados pelos projectos serem diferentes. Um processo efectivo pode ser caracterizado como hábil, documentado, robusto, treinado, medido e com capacidade de poder ser melhorado. Os projectos nas organizações de nível 2 possuem controlos básicos de gestão de software. Os compromissos realistas do projecto são baseados em resultados observados em projectos anteriores e nos requisitos do projecto actual. Os gestores de software do projecto acompanham custos, cronogramas e funcionalidades do

310 5 software; os problemas com compromissos são identificados quando surgem. Os requisitos e os produtos de trabalho de software desenvolvidos para satisfazê-los são armazenados de forma criteriosa e a integridade dos mesmos é controlada. Os padrões do projecto de software são definidos e a organização garante que eles sejam seguidos fielmente. Quando existem subcontratos, o projecto de software trabalha em conjunto com os mesmos, visando fortalecer a relação cliente - fornecedor. A capacidade do processo de software das organizações de nível 2 pode ser resumida como sendo disciplinada, uma vez que o planeamento e o acompanhamento de projecto de software são estáveis e os sucessos mais recentes podem ser repetidos. Os processos estão sob um controle efectivo de um sistema de gestão de projecto, seguindo planos realistas baseados no desempenho de projectos anteriores ível 3 O ível Definido No Nível Definido, o processo padrão de desenvolvimento e manutenção de software global da organização é documentado, inclusive o desenvolvimento de software e a gestão de processos, estando estes todos integrados num só. Este processo padrão é referido em todo o modelo CMM como processo de software padrão da organização. Os processos no nível 3 são utilizados (e alterados, quando apropriado) para apoiar os gestores de software e o pessoal técnico, contribuindo para que possam actuar de forma mais efectiva. Ao padronizar os seus processos de software, a organização exercita práticas de engenharia de software efectivas. Existe uma equipa responsável pelas actividades de processo de software da organização, por exemplo, a equipe de processo de engenharia de software, ou SEPG (Software Engineering Process Group) [Fowler90]. Um programa de treino é implementado em toda a organização para garantir que os gestores e funcionários tenham os conhecimentos e as habilidades necessárias ao cumprimento de suas funções. Os projectos adaptam o processo de software padrão da organização para desenvolver os seus próprios processos de software definidos, que consideram as características únicas de cada projecto. Este processo concebido é referido no modelo CMM como processo de software definido do projecto. O processo de software contem uma integração coerente do desenvolvimento de software com os processos de gestão bem definidos. O processo bem definido pode ser caracterizado como possuidor de critérios de disponibilidade, entradas, padrões e procedimentos para realização do trabalho, mecanismos de verificação (tais como revisões por pares), saídas e critérios de finalização. Como o processo de software é bem definido, a gestão tem uma boa percepção do progresso técnico em todos os projectos.

311 6 A capacidade do processo de software das organizações de nível 3 pode ser resumida como sendo um padrão consistente porque tanto as actividades de gestão como a engenharia de software são estáveis e repetíveis. Nas linhas de produtos estabelecidas, a qualidade de software é acompanhada, além do custo, cronograma e funcionalidades estarem sob controlo. Esta capacidade do projecto é baseada num entendimento global da organização com relação às actividades, regras e responsabilidades decorrentes do processo de software definido ível 4 O ível Gestão No Nível de gestão, a organização estabelece metas quantitativas de qual idade para os produtos e processos de software. A produtividade e a qualidade são medidas nas actividades importantes de processo de software em todos os projectos, como parte de um programa organizacional de medições. Um banco de dados de processo de software, que abrange a organização toda, é utilizado para colectar e analisar os dados disponíveis dos processos de software definidos nos projectos. No nível 4, os processos de software são instrumentalizados com medições consistentes e bem definidas. Essas medições estabelecem as bases para avaliar os processos e os produtos de software do projecto. Os projectos possuem controlos sobre os seus produtos e processos, reduzindo a variação no desempenho desses últimos, para atingir limites quantitativos e aceitáveis. As variações significativas no desempenho dos processos podem ser distinguidas das variações aleatórias (ruídos), particularmente dentro de linhas de produtos estabelecidas. Os riscos decorrentes da introdução de um novo domínio de aplicação são conhecidos e cuidadosamente geridos. A capacidade de processo de software das organizações de Nível 4 pode ser resumida como sendo previsível porque o processo é medido e opera dentro de limites apreciáveis. A capacidade do processo desse nível permite que a organização preveja as tendências na qualidade dos produtos e dos processos dentro das fronteiras quantitativas desses limites. Quando esses limites são excedidos, são tomadas providências para corrigir a situação ível 5 O ível de Optimização No Nível de Optimização, toda a organização está voltada para a melhoria contínua do processo. A organização tem meios de identificar as oportunidades de melhoria e fortalecer o processo de maneira pró-activa, com o objectivo de prevenir a ocorrência de falhas. Os dados sobre a efectividade de processo de software são utilizados para realizar análises de custo benefício das novas tecnologias e das mudanças propostas

312 7 no processo de software da organização. As inovações decorrentes das melhores práticas de engenharia de software são identificadas e transferidas para a organização toda. As equipas de projecto de software das organizações de Nível 5 analisam as falhas para determinar as suas causas. Os processos de software são revistos para prevenir tipo de falhas já conhecidos que normalmente se repetem e as lições retiradas são divulgadas para outros projectos. A capacidade de processo de software das organizações de Nível 5 pode ser resumida como sendo de melhoria contínua porque estas estão continuamente a fazer um esforço para melhorar a abrangência de sua capacidade de processo, melhorando desta forma o desempenho dos processos dos seus projectos. As melhorias ocorrem através de avanços incrementais nos processos já existentes e através de inovações que utilizam novos métodos e tecnologias. 1.2 Analise dos íveis de Maturidade O CMM é um modelo descritivo, no sentido de descrever atributos essenciais (ou chave) que seriam esperados para caracterizar uma organização num nível particular de maturidade. É um modelo normativo, no sentido de que as práticas detalhadas caracterizam os tipos normais de comportamento que seriam esperados numa organização que desenvolve projectos em larga escala. A intenção é que o CMM tenha um nível suficiente de abstracção que não restrinja desnecessariamente a maneira que o processo de software é implementado pela organização; ele simplesmente descreve o que normalmente seria esperado dos atributos essenciais do processo de software. Em qualquer contexto em que o CMM for aplicado, deveria ser utilizada uma interpretação razoável das práticas. O CMM deve ser interpretado apropriadamente, utilizando-se o conhecimento de peritos quando o ambiente comercial da organização difere significativamente de uma grande organização fornecedora. O CMM não é prescritivo; ele não diz à organização como melhorar. O CMM descreve a organização em cada nível de maturidade sem determinar os meios específicos para consegui-lo. Pode levar vários anos para se passar do Nível 1 para o nível 2; a movimentação entre os outros níveis geralmente leva cerca de dois anos. A melhoria de processo de software ocorre dentro do contexto dos planos estratégicos e dos objectivos de negócio da organização, da sua estrutura organizacional, das tecnologias utilizadas, da sua cultura social e do sistema de gestão. O CMM está voltado para os aspectos de processo da Gestão da Qualidade Total; a melhoria de processo bem sucedida implica que os aspectos fora do alvo de processo de software também sejam encaminhados (por exemplo: as questões pessoais envolvidas nas mudanças da cultura organizacional que possibilitem a implementação e a institucionalização das melhorias de processo).

313 Análise do ível Inicial Embora as organizações de Nível 1 sejam frequentemente caracterizadas como tendo processos ad hoc, elas desenvolvem produtos que funcionam, apesar de poderem estar com o orçamento e com o cronograma mal elaborado. O sucesso das organizações de Nível 1 depende da competência e heroísmo das pessoas que actuam na organização. A selecção, contratação, desenvolvimento e a retenção de pessoas competentes são questões significativas para as organizações de todos os níveis de maturidade, mas estão fora do escopo do CMM Análise dos íveis Repetível e Definido À medida que os projectos crescem em tamanho e complexidade, a atenção desloca-se das questões técnicas para as questões organizacionais e administrativas o foco da maturidade do processo [Siegel90, DoD87, GAO-92-48]. O processo possibilita que as pessoas trabalhem mais na organização, no sentido de incorporar aos processos formais (documentados) as lições aprendidas pelo melhor grupo de trabalho. Desta forma, as habilidades necessárias para executar eficientemente os processos são construídas (geralmente através de treino) e melhoradas continuamente, aprendendo-se com as pessoas que estão a realizar o trabalho. Para alcançar o Nível 2, a gestão deve se concentrar nos seus próprios processos a fim de conseguir um processo de software disciplinado. O Nível 2 fornece as bases necessárias para o Nível 3 porque o objectivo é actuar na melhoria dos seus processos, antes de cuidar das questões técnicas e organizacionais do Nível 3. A gestão estabelece uma posição de liderança ao alcançar o Nível 2 através da documentação e do acompanhamento dos processos de gestão do projecto. Os processos podem diferir entre os projectos das organizações de Nível 2; os requisitos organizacionais para alcançar o Nível 2. Os procedimentos formais (documentados) fornecem a base para os processos consistentes que podem ser institucionalizados na organização, através de treino e de garantia da qualidade de software. Sobre essa base de gestão de projecto, o Nível 3 se estabelece, definindo, integrando e documentando o processo de software completo. Integração, neste caso, significa que a saída de uma tarefa flui suavemente para a entrada da próxima. Não existindo ligação entre as tarefas, essas são identificadas e tratadas ainda nas etapas de planeamento do processo de software, ao invés de só serem detectadas na execução do processo. Um dos desafios do Nível 3 é a elaboração de processos que autorizem as pessoas a realizar o trabalho sem serem excessivamente rígidos [Humphrey 91b].

314 Análise dos íveis de gestão e Optimização Os Níveis de maturidade 4 e 5 são relativamente desconhecidos para a indústria de software. Poucos são os exemplos de projectos e organizações de software de Nível 4 e 5; existindo, portanto, poucos exemplos para se extrair conclusões gerais sobre as características dessas organizações. As características desses níveis têm sido definidas por analogia a outro tipo de indústrias e existem poucos exemplos na indústria de software que possuem este nível de capacidade de processo. Muitas características dos Níveis 4 e 5 são baseadas em conceitos de controlo de processo estatístico, como exemplificado na Figura 2. O Diagrama da Trilogia Juran [Juran88] ilustra os objectivos básicos da gestão de processos. Figura 2 Diagrama da Trilogia de Juran: Planeamento, Controlo e Melhoria da Qualidade Juran divide a gestão da qualidade em três processos de gestão básicos [Juran88]. O propósito do planeamento da qualidade é fornecer às forças operacionais, isto é, aos produtores de software, condições de desenvolver produtos que vão de encontro às necessidades do cliente. As forças operacionais desenvolvem o produto mas existe a necessidade de algum trabalho devido às deficiências de qualidade. Este custo é permanente porque o processo foi planeado desta forma; o controlo de qualidade é realizado para prevenir e evitar que as coisas fiquem ainda pior. Os picos esporádicos dentro do processo, como mostrado na Figura 2, representam actividades conhecidas como apagar incêndios. O custo permanente fornece a oportunidade de melhoria; aproveitar essa oportunidade é entendido como melhoria da qualidade. A primeira responsabilidade, e o foco do Nível 4, é o controlo do processo. O processo de software é gerido, operando de forma estável dentro da zona de controlo de qualidade. Há inevitavelmente algum custo permanente e pode haver picos nos resultados medidos que precisam ser controlados, mas o sistema como um todo geralmente é estável. Este é o ponto onde o conceito de controlo de causas especiais de desvios se aplica. Uma vez que o processo é estável e medido, quando ocorre alguma circunstância excepcional, a causa especial do desvio pode ser identificada e tratada. A segunda responsabilidade, e foco do Nível 5, é a melhoria contínua do processo.

315 10 O processo de software é alterado para melhorar a qualidade e, em consequência, a zona de controlo de qualidade se move. Um novo padrão de referência para desempenho é estabelecido, reduzindo o custo permanente. Os conhecimentos adquiridos com a melhoria de processos são aplicados no planeamento de processos futuros. Este é o ponto onde o conceito de tratamento de causas comuns de desvios se apresenta. Existe um custo permanente em qualquer sistema, na forma de trabalho, simplesmente devido aos desvios aleatórios. Custo adicional é inaceitável; os esforços organizados para eliminá-los resultam na alteração do sistema, isto é, na melhoria do processo através de alteração das causas comuns de ineficiência, com o objectivo de prevenir a ocorrência de custos imprevistos. É previsto que as organizações que alcançam os níveis de maturidade mais elevados do CMM possuam um processo capaz de produzir software extremamente confiável dentro dos limites do custo e dos cronogramas previsíveis. À medida que cresce o entendimento dos níveis de maturidade mais elevados, as áreas-chave de processo existentes vão sendo redefinidas e outras ainda podem ser adicionadas ao modelo. O CMM é derivado de ideias sobre processos inspirados na produção. Contudo, os processos de software não são caracterizados pela fabricação de réplicas como os processos da produção. O processo de software é caracterizado pela geração de projectos, sendo uma actividade de conhecimento intensivo [Curtis88]. 1.3 Visibilidade Interna do desenvolvimento do Projecto de Software Os engenheiros de software possuem uma visão detalhada da situação interna do projecto porque possuem as informações, em primeira mão, sobre a situação e o desempenho do mesmo. Entretanto, os projectos grandes, as percepções geralmente são extraídos apenas de experiências pessoais das suas áreas de actuação. Aqueles que não participam do projecto e que não têm contacto como os gerentes superiores não possuem a visibilidade interna dos processos e contam com as revisões periódicas para obter as informações de que necessitam para monitorar o progresso. A Figura 3 ilustra o nível de visibilidade interna da situação e do desempenho do projecto alcançado em cada nível de maturidade do processo. Cada nível de maturidade sucessivo fornece melhor visibilidade interna do processo de software.

316 11 Figura 3 - Visibilidade da Gestão Dentro dos Processos de Software em cada Nível de Maturidade No Nível 1, o processo de software é uma entidade indiferente uma caixa preta e a visibilidade interna dos processos do projecto é limitada. Uma vez que a preparação das actividades é definida de forma precária, os gestores passam por fases extremamente difíceis para estabelecer a situação do progresso e das actividades do projecto. Os requisitos fluem no interior do processo de uma forma descontrolada e surge o produto. No Nível 2, os requisitos do cliente e os produtos de trabalho são controlados, sendo que as práticas básicas de gestão de projecto estão estabelecidas. Estes controlos da gestão possibilitam a visibilidade interna do projecto num momento definido. O processo de construção de software pode ser visualizado como uma sucessão de caixas pretas, permitindo a visibilidade da gestão nos pontos de transição como fluxos de actividades entre as caixas (marcos do projecto). Mesmo que a gestão não conheça detalhes do que está a acontecer dentro da caixa, os produtos e os pontos de verificação dos processos são identificados e conhecidos, através dos quais pode-se confirmar que o processo está a funcionar. A gestão reage aos problemas quando os mesmos ocorrem. No Nível 3, a estrutura interna das caixas, isto é, as tarefas dentro do processo de software definido, é visível. A estrutura interna representa a maneira que o processo de software padrão é aplicado aos projectos específicos. Tanto os gestores como os engenheiros compreendem os seus papéis e responsabilidades dentro do processo e entendem como é que as suas actividades interagem, num nível apropriado de detalhes. A gestão prepara-se de maneira pró-activa para os riscos que possam surgir. As pessoas que não participam directamente no projecto podem obter uma actualização rápida e precisa sobre a situação do mesmo porque os processos definidos permitem grande visibilidade dentro das actividades do projecto. No Nível 4, os processos de software definidos são instrumentalizados e controlados quantitativamente. Os gestores são capazes de medir os progressos e os problemas. Eles possuem bases objectivas e quantitativas para a tomada de decisões.

317 12 Suas habilidades de prever resultados crescem constantemente, tornando-se mais precisas à medida que a variação no processo diminui. No Nível 5, maneiras novas e aprimoradas de construir software são continuamente experimentadas, de uma forma controlada, para melhorar a produtividade e a qualidade. A mudança disciplinada é o comportamento habitual quando as actividades ineficientes ou que tendem a apresentar defeitos são identificadas. Elas são substituídas ou revistas. A percepção estende-se além dos processos existentes, chegando aos efeitos potenciais das mudanças nos processos. Os gestores são capazes de estimar e acompanhar quantitativamente o impacto e a eficiência da mudança. 1.4 Capacidade do Projecto e a Previsão do Desempenho A maturidade do processo de software de uma organização ajuda a prever a habilidade do projecto em atingir as metas. Os projectos nas organizações de Nível 1 apresentam grandes desvios em relação às metas de custo, cronograma, funcionalidade e qualidade. Como pode ser visto na Figura 4, três melhorias relacionadas ao alcance de metas são observadas à medida que o processo de software da organização vai se tornando mais maduro. Primeiro, à medida que a maturidade cresce, a diferença entre os resultados esperados e os resultados reais diminui nos projectos. Por exemplo, se dez projectos do mesmo tamanho fossem programados para serem entregues em 1 de Março, então a data média de cada entrega estaria mais próxima de 1 de Março, tanto quanto mais madura fosse a organização. As organizações de Nível 1 frequentemente atrasam muito as suas datas de entrega originalmente previstas, enquanto as organizações de Nível 5 seriam capazes de prever essas datas com considerável precisão. Isso acontece porque as organizações de Nível 5 utilizam um processo operacional de software cuidadosamente elaborado dentro de parâmetros conhecidos, sendo a escolha da data de entrega baseada no grande volume de dados que possuem sobre os processos e as suas habilidades de tirar proveito do mesmo. (Isso é ilustrado na Figura 4 através da parte da área sob a curva que se encontra à direita da data de entrega.)

318 13 Figura 4 - A capacidade do processo indicado pelo nível de maturidade À medida que a maturidade cresce, a variação dos resultados reais em torno dos resultados esperados diminui. Por exemplo, as datas de entrega nas organizações de Nível 1, em projectos de tamanhos similares, são imprevisíveis e muito variáveis. Projectos similares em organizações de Nível 5 vão ser entregues dentro de um intervalo de tempo muito menor. Isso ocorre nos níveis de maturidade mais elevados porque, na prática, todos os projectos são executados dentro de parâmetros controlados, aproximando-se da capacidade do processo para custo, cronograma, funcionalidade e qualidade. (Isto é ilustrado na Figura 4 através da parte da área sob a curva concentrada próxima à linha alvo). Os resultados esperados melhoram à medida que a maturidade da organização aumenta. Isto é, à medida que a organização de software amadurece, os custos diminuem, o tempo de desenvolvimento torna-se menor, e a produtividade e a qualidade aumentam. Numa organização de Nível 1, o tempo de desenvolvimento pode ser muito longo devido ao volume de trabalho necessário para correcção de erros. Em contraste, as organizações de Nível 5 utilizam melhoria contínua de processo e técnicas de prevenção de defeitos para aumentar a eficiência do processo e eliminar trabalhos dispendiosos, permitindo que o tempo de desenvolvimento seja reduzido. (Isto é ilustrado na Figura 2.4 através do deslocamento horizontal da linha alvo em relação à origem). Os aperfeiçoamentos na previsão dos resultados do projecto representados na Figura 4 assumem que os resultados do projecto de software tornam-se mais previsíveis à medida que a interferência, na forma de trabalho, é eliminada. Sistemas

319 14 sem precedentes complicam o quadro, uma vez que as novas tecnologias e as novas aplicações reduzem a capacidade do processo através do aumento da variabilidade. Mesmo no caso de sistemas sem precedentes, as características das práticas de gestão e de engenharia de muitas organizações maduras ajudam a identificar e a encaminhar os problemas no ciclo de desenvolvimento antes mesmo de serem detectados em organizações menos maduras. A detecção antecipada de defeitos contribui para a estabilidade e desempenho do projecto, eliminando o trabalho durante as fases posteriores. A gestão de riscos é uma parte integrante da gestão do projecto num processo maduro. Em alguns casos, um processo maduro pode significar que os projectos destinados ao fracasso sejam identificados mais cedo no ciclo de vida de software e o investimento numa causa perdida seja minimizado. 1.5 Saltar entre íveis de Maturidade Os níveis de maturidade no CMM descrevem as características de uma organização num determinado nível de maturidade. Cada nível constrói a base para os níveis seguintes alavancarem a implementação de processos de forma efectiva e eficiente. As organizações podem, entretanto, usar proveitosamente os processos descritos num nível de maturidade mais elevado que aquele em que se encontram. A engenharia de processos, tal como a análise de requisitos, projecto, codificação e teste, não é discutida até o nível 3, ainda que até mesmo as organizações de Nível1 devam realizar essas actividades. As organizações de Nível 1 ou Nível 2 podem ser capazes de realizar revisões por pares (Nível 3), fazer análise de Pareto (Nível 4) ou experimentar novas tecnologias (Nível 5) proveitosamente. Ao prescrever os passos que uma organização deveria calcar para passar do Nível 1 para o Nível 2, frequentemente uma das recomendações é estabelecer um conjunto de processos de desenvolvimento de software; isso é um atributo das organizações de Nível 3. Embora seja o foco do Nível 4, avaliação também é parte integrante dos níveis de maturidade. Entretanto, esses processos não podem ficar completos antes que uma base adequada seja estabelecida. As revisões por pares não podem ser totalmente efectivas, por exemplo, a menos que sejam implementadas de forma consistente, mesmo quando os problemas colocam o projecto em risco. Os níveis de maturidade descrevem os problemas que predominam em cada nível. Os problemas predominantes nas organizações de Nível 1 são problemas de gestão; os outros problemas tendem a ser encobertos pelas dificuldades de planeamento e gestão dos projectos de software. Saltar níveis de maturidade é prejudicial porque cada nível constitui a base necessária a partir da qual se alcança o próximo nível. O CMM identifica os níveis através dos quais uma organização deve se desenvolver para estabelecer uma cultura de excelência em desenvolvimento de software. Os processos sem as bases adequadas

320 falham no ponto extremo onde estão mais carentes sob stress e não fornecem bases para as melhorias futuras. Uma organização de Nível 1 que está a tentar implementar o processo definido (Nível 3), antes de ter estabelecido o processo repetível (Nível 2), geralmente é mal sucedida porque os gestores de projecto estão subjugados com as pressões de custo e cronograma temporal. Esta é a razão fundamental para se focar na gestão de projectos antes de se implementar engenharia de processo. Pode parecer que a definição e a implementação da engenharia de processo acontecem antes da gestão de processo (especialmente aos olhos do pessoal técnico), mas, sem a disciplina gestora, a engenharia de processo fica prejudicada pelas pressões do cronograma e do custo [Humphrey88]. Uma organização que está a tentar implementar o processo de gestão (Nível 4), sem os fundamentos do processo definido (Nível 3), geralmente é mal sucedida porque não há bases comuns para a interpretação das medidas sem os processos definidos. Se, por um lado, os dados podem ser colectados individualmente pelos projectos, por outro, poucas medidas são significativas no âmbito de todos os projectos, não tendo condições de fazer crescer substancialmente o entendimento do processo de software. Uma organização que está a tentar implementar um processo optimizado (Nível 5), sem as bases do processo de gestão (Nível 4), provavelmente está destinada ao fracasso devido a falta de entendimento do impacto das mudanças no processo. Sem controlar o processo dentro de fronteiras estatisticamente estreitas (pequenas variações nas medidas dos processos), existe muita interferência nos dados para que se possa determinar objectivamente se uma dada melhoria de processo tem algum efeito. As decisões podem se degenerar em conflitos subjectivos porque existe pouco fundamento quantitativo para se tomar decisões racionais. O esforço na melhoria de processo deveria se concentrar nas necessidades da organização com relação ao contexto do seu ambiente de negócio. A habilidade de implementar processos de altos níveis de maturidade não implica que os níveis de maturidade inferiores possam ser ignorados. 15

321 16 Conclusão A melhoria contínua aplica-se ao modelo de maturidade e às práticas, assim como ao processo de software. O impacto potencial das mudanças do CMM na comunidade de software será cuidadosamente considerado, mas o CMM, a questão da maturidade, a avaliação de processo de software e os métodos de determinação da capacidade do software continuarão a evoluir à medida que se ganha experiência no processo de software. O CMM fornece uma estrutura conceptual para a melhoria da gestão e desde o envolvimento de produtos de software de uma forma consistente e disciplinada. Ele não garante que os produtos de software serão construídos com sucesso ou que todos os problemas de desenvolvimento de software serão resolvidos adequadamente. O CMM identifica práticas para um processo de software maduro e fornece exemplos do estado da prática (e, em alguns casos, do estado da arte), mas não tem a intenção de ser exaustivo nem ditatorial. O CMM identifica as características de um processo de software efectivo, mas a organização madura trata de todas as questões essenciais para um projecto bem sucedido, incluindo pessoas e tecnologia.

322 17 Referencias bibliográficas Figura1- Figura2- Figura 3 e figura 4- Brooks87 F.P. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer,vol.20 No.4,April1987,pp Crosby79 P.B.Crosby, Quality is Free, McGraw-Hill, New York,NY,1979. Curtis90 B.Curtis, Managing the Real Leverage in Software Productivity and Quality, American Programmer,Vol.3, No.July1990,pp Deming86 W. Edwards Deming, Out of the Crisis, MIT Center for Advanced Engineering Study, Cambridge,MA,1986. DoD87 Report of the Defense Science Board Task Force on Military Sof tware, Office of the Under Secretary of Defense for Acquisition, Washington,D.C. September Fagan86 M.E. Fagan, Advances in Software Inspections, IEEE Transaction on Software Engineering, Vol.12, No. 7, July 1986, pp Fowler90 P.Fowler and S.Rifkin, Software Engineering Process Group Guide, Software Engineering Institute, CMU/SEI90-TR-24,ADA235784, September,1990. Freedman90 D.P Freedman and G.M. Weinberg, Handbook of Walktroughs, Inspections, and Technical Reviews, Third Edition, Dorset House, New York, NY, Gabor90 A. Gabor, The Man Who Discovered Quality, Random House, New York, NY, GAO Embedded Computer Systems: Significant Software Problems on C-17 Must be Addresses, GAO/IMTEC May Humphreys87a W.S. Humphrey, Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/SEI-87-TR-11, ADA182895, June Humphreys87b W.S. Humphrey and W.L. Sweet, A method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, CMU/SEI-87-TR-23,ADA September Humphrey88 W.S. Humphrey, Characterizing the Software Process, IEEE Software, Vol.5,No.2,March,1988, pp Humphrey89 W.S. Humphrey, Managing in the Software Process, Addison - Wesley, Reading, MA, Humphrey91a W.S. Humphrey, D.H. Kitson, and J. Gale, A Comparison of U.S. and Japanese Software Process Maturity, Proceedings of the 13 th International Conference on Software Engineering, Austin, TX,13-17 May 1991, pp

323 Humphrey91b W.S. Humphrey, Process Fitness and Fidelity, Proceedings of the Seventh International Software Process Workshop, October IEEE-STD-610 ANSI/IEEE Std , IEEE Standard Glossary of Software Engineering Terminology, February, Imai86 M.Imai, Kaizen: The Key to Japan s Competitive Success, McGraw- Hill, New York, NY, Juran88 J.M. Juran, Juran on Planning for Quality, Macmillan New York, NY,1988. Juran89 J.M. Juran, Juran on Leadership for Quality, the Free Press, New York, NY, Kitson92 D.H. Kitson and S. Masters, An Analysis of SEI Software Process Assessment results: , Software Engineering Institute, CMU/SEI-92-tr 24, July1992. Paulk91 M.C. Paulk,B. Curtis, M.B. Chrissis, et al, Capability Maturity Modelfor Software, Software Engineering Institute, CMU/SEI-91-TR- 24,ADA240603,Agust Paulk93a M.C. Paulk, B. Curtis, M.B. Chrissis, and C.V. Weber, Capability Maturity Model for Software, version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24 February Paulk93b M.C. Paulk, C.V. Weber, S. Garcia, M.B. Chrissis and M. Bush, Key Practices of the Capability Model, Version 1.1, Software Engineering Institute, CMU/SEI-93TR-25,February

324 Redes de Petri Coloridas Uma Abordagem Prática Nuno Costa Departamento de Sistemas de Informação, Escola de Engenharia, Universidade do Minho, Guimarães, Portugal Resumo. Este artigo funciona como uma documentação dos passos e procedimentos realizados na modelação de um cenário prático (sugerido pela BOSCH Portugal) utilizando Redes de Petri Coloridas. O cenário prático consiste nos processos produtivos de auto-rádios que a BOSCH tem na sua fábrica de Braga. Neste documento, são esquematizados todos os momentos passados na realização deste estudo académico, começando pela análise aos processos produtivos da BOSCH, continuando com a análise de requisitos a serem modelados, a utilização do UML 2.0 para a percepção das actividades, agentes e workflow do Sistema, a transposição da modelação em UML para as Redes de Petri e, por fim, a solução encontrada para conseguir modelar o Sistema em Redes de Petri Coloridas. No final é feita também uma análise crítica a toda a abordagem, apontando estado da arte da ferramenta analisada que sugere o trabalho futuro que, no entender do autor, era susceptível de conferir mais realismo ao modelo criado. Palavras-Chave: Redes de Petri, Redes de Petri Coloridas, BOSCH, UML, processos, workflow. 1. Introdução No âmbito da cadeira de Análise e Concepção dos Sistemas de Informação, foi pedido aos alunos que escolhessem uma temática para estudar e analisar que se enquadrasse no referencial da disciplina. Assim, o foco escolhido estende-se pela Concepção de um Sistema. Dentro desta problemática, foi a maneira de como se podem modelar sistemas que mais despertou a curiosidade. Depois de analisar várias técnicas de representação diferentes (como o 1

325 UML 2.0 ou vários variantes das Redes de Petri), optou-se por analisar as Redes de Petri Coloridas (do Inglês, Coloured Petri Nets). Ao aprofundar a temática, e depois de inquirido o regente da cadeira sobre a possibilidade de integrar este estudo com um caso prático, foi sugerido a integração deste estudo com um problema determinado pela BOSCH Portugal em Braga (encarregue da produção de auto-rádios), integração essa que vai ser o plano principal deste relatório. 2. O Problema da BOSCH De maneira a conhecer a realidade da organização e perceber o negocio da BOSCH Portugal, foi combinada uma reunião na sua sede em Braga, que serviu para se fazer uma introdução ao tipo de produção existente. Ciente do campo de acção da empresa, foi mais tarde realizada outra reunião que tinha como intuito descrever o workflow a modelar, introduzir os elementos do ambiente e explicar a dinâmica da produção dos auto-rádios pelos diversos postos da linha de montagem. Este encontro pode ser considerado como uma negociação de requisitos a serem incluídos no modelo a ser criado. Processo de produção da BOSCH Em traços gerais, vai-se descrever o processo de produção de auto-rádios da BOSCH de Braga, tendo como suporte a figura 1. Todo o processo começa com a chegada de matéria prima à BOSCH. Depois de descarregada (e uma amostra passada pelo controlo de qualidade), é etiquetada com todas as suas informações e guardadas no Armazém. As posições onde a matéria prima recém chegada é armazenada é calculada através de um algoritmo de minmax, com o intuito de minimizar todas as perdas temporais e de espaço disponível neste processo. 2

326 .Figura 1 Overview do processo produtivo da BOSCH A produção propriamente dita começa no passo seguinte. A linha de montagem 1 (que a partir deste momento vai ser designada de MOE1) é a responsável pelo fabrico de componentes para os auto-rádios. Recebe os inputs necessários que vêm do Armazém, transportados pelo Milk-Run0 (MR0), que circula em loop transportando o material desde o Armazém até à linha que necessita dele. Os parâmetros das viagens do MR0 (tempo de viagem, capacidade disponível para transporte, frequência da viagem, etc) podem ser alterados no modelo a qualquer momento. 3

327 O output do MOE1 (componentes para auto-rádios), é agrupado em caixas de x elementos cada, e colocado à saída do MOE1. O Milk-Run1 (MR1), à semelhança do MR0, circula em loop, pegando nas caixas que estão à saída do MOE1 e colocando-as à entrada do Supermercado. O Supermercado é um armazém intermediário que guarda caixas de componentes agrupados e outras peças necessárias para a assemblagem dos auto-rádios. Possui um (ou mais) Gestor, que tem como uma das tarefas armazenar as caixas que o MR1 deixa à entrada do Supermercado. Para essa tarefa é utilizado um processo semelhante ao do Armazém principal: é calculada uma posição algoritmicamente e armazenado. Outra das responsabilidades do Gestor é dar seguimento aos Pedidos provenientes da linha de montagem 2 (MOE2). Esses pedidos, gerados automaticamente ou manualmente, são criados quando o número de peças disponíveis de um determinado material numa determinada linha é mais baixo que um limite definido. Ao receber os Pedidos, o Gestor consulta o Sistema de Informação e determina a posição onde a matéria prima requerida está armazenada no Supermercado. Depois de calcular, transporta a referida caixa para a saída do Supermercado. Para transportar as caixas desde o Supermercado até à MOE2, existe um Milk-Run (semelhante aos MR0 e MR1), denominado de MR2. Transporta as caixas colocadas à saída do Supermercado para a linha que a pediu. POSTO INPUT OUTPUT Armazém Caixas de material Caixas de material MOE1 Caixas de material Caixas de componentes Supermercado Caixas de componentes Caixas de componentes Pedidos de material MOE2 Caixas de componentes Pedidos de material Auto-Rádios Tabela 1 Relação entre os outputs e os inputs de cada posto da fábrica 4

328 O processo de produção de auto-rádios é terminado na MOE2. Pegando em componentes previamente fabricados na MOE1, constrói o auto-rádio final. De seguida os auto-rádios são agrupados e embalados estando prontos para continuarem o seu caminho até ao consumidor final. 2.1 O desafio dos Milk-Runs O objectivo da BOSCH, como de qualquer outra indústria, é poder produzir o máximo utilizando o menor número de recursos possíveis (financeiros, temporais, recursos humanos, entre outros). Assim, um dos principais desafios numa organização tão complexa como esta, é encontrar uma maneira de maximizar a produtividade das linhas de montagem. Para isso, o papel dos Milk-Runs é fundamental: são eles que, ao transportar eficientemente o material, asseguram que as linhas de montagem têm sempre o material necessário para continuar o seu trabalho. O trabalho dos Milk-Run não é simples, têm de gerir o transporte de uma grande variedade de diferentes materiais, de maneira a assegurar a presença dos mesmos sempre que forem necessários. Esse desafio é ainda maior e mais relevante quando se trata da passagem de material de umas linhas de montagem para as outras. Assim, a BOSCH colocou o desafio: construir um modelo que representasse as linhas de montagem da sua fábrica, de maneira a poder simular o transporte de material entre a MOE1 e a MOE2. Ao conseguir um protótipo fiel, a BOSCH pode testar a maneira de maximizar a produtividade dos Milk-Runs, conseguindo simular o que aconteceria caso modificasse os parâmetros do MR1 e do MR2 (tempo de espera em cada sítio, periodicidade do transporte, número de carruagens em cada comboio, entre outros). Os agentes directamente relacionados com a funcionalidade de transporte de material entre a MOE1, o Supermercado e o MOE2 estão assinalados a vermelho na figura Abordagem ao desafio com as Redes de Petri Coloridas De maneira a solucionar o desafio entregue pela BOSCH, foram estudadas algumas técnicas de representação de Sistemas capazes de servir como ferramenta para resolver o problema em questão. UML 2.0, Redes de Petri direcionadas a processos e 5

329 Redes de Petri Coloridas foram algumas das técnicas pensadas para ajudar na resolução da questão. Depois de alguma análise às limitações e virtualidades de cada abordagem, foi decidido o uso das Rede de Petri coloridas devido à sua possibilidade de poder integrar estruturas de dados complexas (com o correspondente aumento de capacidade que essa funcionalidade proporciona), ao invés de utilizar outro tipo de Redes de Petri cuja a única informação que pode ser transitada de uns lugares para os outros é o seu token unitário. 3.1 Modelação dos Requisitos com UML O primeiro passo para começar a modelar o sistema seria retratar graficamente uma representação da sequência de actividades que cada elemento do Sistema executa para cumprir o seu objecto. Seguindo a abordagem utilizada pelo Professor regente da cadeira, Ricardo Machado (em Machado et. al, 2007), decidiu-se começar por especificar quais as funcionalidades (mapeadas depois em Casos de Uso) que cada agente do sistema tem a responsabilidade de desempenhar. Essa descrição terminou no diagrama da figura 2. Fig. 2 Diagrama de Casos de Uso correspondente ao sistema a modelar 6

330 Neste diagrama estão relacionados as principais actividades cumpridas na passagem de material entre o MOE1, o Supermercado e o MOE2. Nota apenas para as actividades Agrupar Material e Gerir Pedidos que, como são realizadas nas linhas de montagem 1 e 2, não estão modeladas na Rede de Petri criada. Para especificar a cadeia de acontecimentos em cada uma das actividades, para cada Caso de Uso foi construído um diagrama de actividades que expõe o workflow de cada um. A figura 3 possui alguns desses diagramas, embora os mesmos não estejam detalhados exaustivamente. Fig. 3 Diagramas de actividades de alguns dos casos de uso do Sistema 3.2 Transposição para as Redes de Petri Coloridas Partindo dos diagramas de casos de uso e de actividades, o passo seguinte foi a elaboração de um rascunho que contivesse a modelação do sistema através de Redes de Petri. Rapidamente chegou-se à conclusão que um diagrama geral era difícil de ler, confuso e facilmente sujeito a erros. 7

331 Fig. 4 Rede de Petri correspondente a todo o Sistema Assim, foi decidida a utilização de uma abordagem Top-Down, onde se criou uma Rede de Petri de topo, com os lugares comuns e as actividades principais, que depois se individualizavam em sub-redes mais específicas. A maneira mais lógica que se achou para conseguir esta divisão foi recorrendo, mais uma vez, aos casos de uso modelados anteriormente. A amálgama de lugares e transições deu lugar a uma Rede de Petri mais limpa, onde se destacam as actividades MOE1 <> SUP, SUP <> MOE2, Responder Pedido e Responder Material. Cada transição dessas é depois individualizada numa rede de petri própria, com o mesmo nome, onde existem lugares de entrada e de saída, para conseguir relacionar as sub-redes com a rede principal. 8

332 Fig. 5 Rede de Petri de topo Nesta rede de topo, além das transições/actividades principais do Sistema, aparecem apenas os lugares que são comuns, ou seja, são necessário para o desenrolar de mais do que uma transição. 4. A simulação com o CPN Tools Depois de pensada e estruturada todas as redes, foi altura de potenciar uma das melhores capacidades das Redes de Petri Coloridas: a sua capacidade de poder transmitir informação complexa de uns lugares para outros, utilizando a linguagem de Standard ML. 4.1 As Redes de Petri Nesta versão da Simulação, por não possuir conhecimento do tipo de informação relevante que é transportado entre as linhas de montagem, foi feito apenas uma 9

333 simulação onde os tokens existentes são especificados apenas por uma String, caracterizando o nome do componente que faz o percurso MOE1->Supermercado- >MOE O transporte de material entre MOE1 -> SUP -> MOE2 Considerada como a actividade principal a modelar, o transporte de material entre as diversas estações proporcionou as maiores dificuldades na modelação e originou as sub-redes mais complexas. Nesta actividade, é necessário simular duas realidades completamente diferentes: a presença dos Milk-Runs em cada estação (MOE1, SUP ou MOE2) e a presença das caixas a transportar entre os postos. Dado que o transporte entre MOE1 - SUP e SUP MOE2 ser autónomo (possuindo os seus próprios Milk-Runs, a sua própria periodicidade, etc), foram modeladas sub-redes diferentes para os dois casos (embora sejam muito idênticas). Fig. 6 Rede de Petri correspondente à actividade MOE1 < > SUP 10

334 Como é possível verificar na Figura 6, existem 3 tipos de lugares diferentes a representar. Os lugares/transições a vermelho correspondem ao processo de movimentação do MR1 entre o Supermercado e o MOE1. A única informação que circula nesses arcos, é o próprio token correspondente à presença do comboio em cada um desses lugares. Representado a azul estão os procedimentos de carga/descarga do MR1. É fácil de perceber que a carga de MR1 apenas é possível quando existem caixas disponíveis à saída de MOE1 e o comboio encontra-se estacionado nessa linha (visível através do lugar MR1 em MOE1 ). Depois de carregar, o token de presença regressa ao lugar MR1 em MOE1 e surge o sinal que o MR1 está pronto para seguir viagem. Concorrentemente a estas últimas transições, encontra-se o lugar MR1 carregado (lugares sublinhados a roxo), que fica com os tokens que correspondem ao material que está a circular. Esta solução de recurso foi implementada com o intuito de impedir que o comboio faça viagens sem estar carregado e devido à difícil integração de estruturas de controlo (ciclos If) de StandarML na simulação. Após a chegada de MR1 ao Supermercado, os tokens correspondentes ao material que estão no lugar MR1 Carregado seguem através da transição Descarregar MR1 para a entrada do Supermercado (representado pelo lugar Caixa Pronta ). A rede de petri correspondente à circulação de material entre o Supermercado e o MOE2 é em tudo idêntica a esta, com a diferença que o carregamento do MOE2 é concretizado quando o material referente a um pedido (tratado na transição global Responder Pedido ) é disponibilizado pelo Gestor de Supermercado A recepção e armazenamento de material no Supermercado Concluído que está a movimentação de caixas de material entre MOE1 e o Supermercado, as mesmas estão prontas para armazenamento. É o Gestor de Supermercado o responsável por essa actividade (modelada no sistema com o nome Receber Material ), dado que tem como missão receber o material proveniente de MOE1 e colocar à saída do armazém o material para MOE2. 11

335 Depois de pegar na caixa à entrada do Supermercado, o Gestor tem que inquirir o sistema para obter a posição onde essa caixa vai ser armazenada. Idealmente, a transição Calcular Posição deveria chamar um método que calculasse uma posição, posição essa que circularia juntamente com a informação correspondente à caixa, até à transição Armazenar onde guardaria a informação numa Base de Dados. A dificuldade de introduzir linhas de código de StandardML muito complexas, a fraca interacção providenciada pelo CPNTools e o pouco apoio existente nas comunidades online, fez com que essa possibilidade fosse adiada para uma fase posterior do trabalho. Assim, a única informação retida no lugar Caixa Armazenada, é o número de tokens (e o nome da caixa) que lá chega. Esta perspectiva pode ser verificada através da Figura 7. Fig. 7 Rede de Petri correspondente à actividade Receber Material 12

336 4.1.3 A resposta aos pedidos de material pela MOE2 Assim que uma das linhas de montagem de MOE2 começa a ficar sem um determinado componente/material, é enviado um pedido para o Supermercado. O Gestor, quando está disponível, existe material armazenado e recebe um pedido de MOE2, está apto para iniciar o processo de resposta ao pedido. Para a resposta aos pedidos, foi pensada a utilização de um sistema de Fila FIFO, onde os pedidos mais antigos fossem os primeiros a ser tratados. Caso não existisse o material para um determinado pedido, o mesmo era colocado de novo no final da fila. Essa solução não conseguiu ser implementada devido à sua complexidade (não no entendimento do conceito de fila, mas na sua integração com o CPN Tools). A primeira tarefa a desempenhar é aceder à suposta base de dados e procurar o lugar onde o material pretendido se encontra. A partir do momento em que o material é resgatado do armazém, é colocado à saída do Supermercado com a indicação do número de linha que o pediu para ser transportada pelo MOE2. Após a conclusão desta tarefa, o gestor fica novamente disponível para executar outras actividades. Esta modelação é representada na Figura 8. Fig. 8 Rede de Petri correspondente à actividade Responder Pedido 13

337 5. Análise crítica - problemas vividos Os verdadeiros contornos dos assuntos relacionados com uma técnica de representação de um Sistema, idealmente, devem ser estudados tendo em conta um cenário real. Essa possibilidade foi potenciada pelo regente da cadeira, no entanto, a integração de um cenário real com um trabalho académico é dificultada devido aos limites temporais inerentes a uma cadeira semestral. Uma organização complexa e capaz como a BOSCH não para, por isso, o acesso aos responsáveis da organização nem sempre foi conseguida nos timings ideais. O facto do processo de negocio ter sido disponibilizado no início das férias de Natal, teve como consequência que apenas existiu um mês para modelação da rede e integração com a interface do CPN Tools, interface essa que não é das mais amigáveis no ramo de programas de modelação de sistemas. Outro dos problemas vividos foi a própria escassez de informações referentes ao CPN Tools. Tirando a documentação online e pouca bibliografia (a maioria da bibliografia cobre os conceitos das Redes de Petri Coloridas e não a sua modelação com o CPN Tools), existe muitos poucos recursos que possam ser consultados referentes a este programa. Esse problema potenciou uma deficiente utilização das capacidades do Standard ML, dado que foi sempre muito difícil perceber as origens dos erros que apareciam em muitos procedimentos escritos em Standard ML. 5. State of the art Trabalho futuro Embora o trabalho esteja terminado no âmbito da disciplina de ACSI, a verdade é que muito mais pode ser feito para enriquecer o modelo criado. Depois da leitura de algumas publicações e literatura sobre as Redes de Petri coloridas (Bibliografia no final do artigo), concluiu-se que existem técnicas utilizadas actualmente que permitem aproximar os sistemas que se modelam dos modelos desenvolvidos em Redes de Petri Coloridas. 14

338 No âmbito de outra cadeira da faculdade ou mesmo por interesse expresso da BOSCH, existe trabalho idealizado para que seja desenvolvido um protótipo funcional que permita testar o sistema até extrair todas as conclusões. A saber: Integração com uma interface de animação (ex: Britney) o Existem frameworks desenvolvidas que conseguem tornar a simulação mais agradável e perceptível. É necessário um contacto próximo e permanente com alguém com experiência na área, dado que a informação disponível sobre esta integração é escassa. Exploração do uso do StandardML o Existem alguns lugares e transições que poderiam ser substituídas por código funcional. Mais uma vez é recomendável o contacto com alguém com experiência na área. Integrar a dimensão temporal na simulação o De maneira a automatizar a simulação e torna-la mais real, pode ser aplicado tempos para algumas acções, nomeadamente o tempo de transporte entre várias estações. Para este objectivo, é necessário um estudo aprofundado das actividades que decorrem na linha de montagem, sugerindo-se uma visita à mesma. Conseguir interligar a simulação com uma Base de Dados o Seria mais uma maneira de aproximar a simulação do cenário real, caso se conseguisse inserir numa BD todos os materiais armazenados no Supermercado. Assim, ao responder aos pedidos vindos da MOE2, poderia testar-se com sucesso o que acontecia ao Sistema caso o material não estivesse disponível. Expansão da simulação para o resto das actividades o Como é perceptível na Figura 1, apenas uma parte do Sistema de produção de auto-rádios está modelado. Caso se modelasse o resto das actividades, a Simulação ficaria mais rica e potenciaria a qualidade das conclusões a retirar pelos elementos da BOSCH. 15

339 A possibilidade de ocorrer eventos concorrentes o Nesta versão do modelo, apenas é permitido uma transição de cada vez. Enquanto que o MR1 está a transportar material para o Supermercado, o Gestor poderia estar a despachar pedidos vindos de MOE2 ou mesmo o MR2 estar a transportar mais material para MOE2. Este passo é muito importante pois representaria mais fielmente o que se passa nas linhas de montagem de auto-rádios da BOSCH. 6. Conclusão No final deste trabalho, foi concluído que as Redes de Petri (nomeadamente as coloridas) são uma técnica de representação muito poderosa para Simular e Modelar actividades e processos industriais (mas não só). A sintaxe das Redes é relativamente simples e o facto de poderem transportar informação complexa entre os lugares valoriza bastante o método. Pelo lado negativo, concluiu-se que existe ainda alguma falta de aprimoramento dos programas e interfaces gráficas que permitem modelar sistemas recorrendo a Redes de Petri. A interacção entre o programador e a interface é fraca e nem sempre o suporte online é útil. Mais uma vez concluiu-se que é necessário um cenário real e prático para se poder testar e retirar conclusões válidas deste tipo de estudos. Aos esforços evidenciados pelos Engenheiros da BOSCH e pelo Professor Ricardo Machado para que tal cenário fosse possível, o autor do artigo está muito grato. Apesar disso, frisa-se outra vez que nem sempre é possível avançar mais nos trabalhos quando se trabalha com organizações industriais, pois nem sempre existe a disponibilidade para o acompanhamento que um estudo académico o exige. 16

340 7. Referências / Bibliografia Machado, R., Lassen, K., Oliveira, S., Couto, M., Pinto, P.: Requirements Validation: Execution on UML Models with CPN Tools, Springer (2007) Machado, R., Fernandes, J., Santos, H.: Modelling Industrial Embbeded Systems with UML, ACM Press(2000) Jensen, K., Kristensen, L., Wells, L.: Coloured Petri Nets and CPN Tools for Modelling and Validation of Concurrent Systems. International Journal on Software Tools for Technology Transfer (STTT), Springer (2007) Jensen, K.: Coloured Petri Nets, Basic Concetps Analysis Methods and Practical Use Volume 1 (2nd edition). Springer (1997) Jensen, K.: Coloured Petri Nets, Basic Concetps Analysis Methods and Practical Use Volume 2 (2nd edition). Springer (1997) Jensen, K.: Coloured Petri Nets, Basic Concetps Analysis Methods and Practical Use Volume 3 (2nd edition). Springer (1997) van der Aalst, W., van Hee, K.: Gestão de Workflows Modelos, métodos e sistemas (Tradução: Jorge Cardoso). Imprensa da Universidade de Coimbra (2009) 17

341 Uso de artefatos PMBoK para Engenharia de Requisitos em gerenciamento de projetos de software V. Lima 1 1 Departamento de Sistemas de Informação, Escola de Engenharia, Universidade do Minho Azurém, Guimarães, Portugal Abstract. Atualmente, devido às grandes dificuldades encontradas em gerenciar os projetos, as organizações buscam apoio em vários recursos tecnológicos e metodologias, visando garantir a qualidade no desenvolvimento de seus produtos e serviços. Apresentam-se, neste trabalho, as principais preocupações relacionadas aos requisitos de software, bem como a importância de que se exerça o gerenciamento de requisitos. Destacam-se os principais fatores que levam às mudanças dos requisitos e os impactos que estas podem trazer para um projeto. Apresentam-se ainda, conceitos e a relevância da disciplina de gerenciamento de projetos. Destaca-se o guia PMBoK, as suas áreas de conhecimento, o apoio que este guia oferece para o bom andamento do projeto durante todo o seu ciclo de vida e os principais artefatos elaborados, de acordo com este mesmo guia, para o monitoramento e controle de um projeto. Keywords: Requisitos, Gerenciamento de requisitos, Gerenciamento de Projetos e PMBOK. 1 Introdução Com o aumento da concorrência e clientes cada vez mais exigentes, as empresas têm procurado constantemente aperfeiçoar seus conhecimentos para garantir a qualidade de seus produtos e serviços. Vários projetos não chegam ao fim devido à falta de controle ou um controle realizado de forma inadequada. A falta de efetividade em processo de requisitos tem como resultado produtos que não atendem às necessidades do cliente ou de qualidade duvidosa. Conforme [20] nos faz lembrar, todas as etapas do processo de desenvolvimento de software cumprem uma importante tarefa, mas podemos considerar a fase de identificação de requisitos uma das fases mais críticas, porque os erros que forem detectados nesta fase não deverão passar para as fases seguintes. Gerenciar o documento de requisitos é a base para estimar tamanho, esforço, cronograma e custo de um projeto, portanto, é fundamental que as informações contidas neste documento, sejam produzidas de forma que não venha a prejudicar o bom andamento do projeto durante a sua execução. O gerenciamento de requisitos acompanha os requisitos durante todas as fases, pois todos os projetos são passíveis a alterações e estas podem ocorrer durante todo o

342 desenvolvimento. Para tanto, o gerenciamento de projetos torna-se peça fundamental para o sucesso do projeto. Porém, esta gerência necessita do auxílio de diversos documentos para realização de acompanhamentos os quais fornecerão conhecimento atempadamente das mudanças e evoluções e assim, caso haja necessidade, o gerente de projetos venha a proceder com ações corretivas de forma fundamentada. É neste contexto que surge a importância da utilização de boas práticas tais como as apresentadas no guia PMBOK. O PMBOK é um guia que tem como objetivo fornecer uma visão geral de cada subconjunto do conjunto de conhecimento do gerenciamento de projetos, tornando-o partes menores, mas ao mesmo tempo interligadas entre si. É um guia onde usa um vocabulário padronizado, comum a todos os profissionais da área, elemento essencial a qualquer profissão [9]. Este presta um apoio considerável ao gerenciamento do projeto desde a fase de iniciação até o seu encerramento. Diante deste contexto, a Seção 2 apresenta conceitos acerca de requisitos de software, bem como os artefatos do fluxo de requisitos. A Seção 3 aborda o gerenciamento de requisitos ressaltando as principais dificuldades encontradas por esta área, os diversos fatores que levam as mudanças dos requisitos e as atividades inerentes ao processo de gerência de requisitos. A Seção 4 apresenta conceitos relacionados a projetos, destacando o guia PMBOK e suas áreas de conhecimento. A seção 5 trata da importância do tratamento do escopo/ requisitos em desenvolvimento de softwares, apresentando estatísticas acerca de insucessos em projetos. A seção trata dos artefatos PMBoK para gerenciamento de requisitos, tais como: Termo de Abertura do Projeto, Declaração do Escopo do Projeto, Plano de Gerenciamento do Projeto, Declaração do trabalho e Estrutura Analítica do Projeto. Por fim, na Seção 7, extraem algumas conclusões relevantes acerca do estudo realizado. 2 Requisitos de Software Uma tarefa muito difícil de ser realizada é a de estabelecer as funcionalidades de um sistema. Isto ocorre devido à dificuldade em se entender os problemas de uma organização, e os quais as empresas esperam que sejam resolvidos com a implantação de um software ou serviço. As descrições das funções e restrições são os requisitos para os sistemas e o processo que envolve a descoberta dos requisitos, sua análise e documentação é chamada análise de requisitos ou engenharia de requisitos [2]. É a composição das necessidades do sistema que definirá suas funcionalidades, ou seja, sua estrutura e comportamentos serão os requisitos do software. Trata-se de itens de um requisito: os dados, processos, restrições de acordo com o negócio, as pessoas envolvidas e o relacionamento entre todos esses elementos [2]. Espera-se que os requisitos forneçam as premissas para que o software seja desenvolvido de forma que venha permitir que o usuário resolva problemas inerentes ao negócio e atenda às necessidades ou restrições da organização, ou, se for o caso, de outros componentes de um sistema já existente.

343 Os requisitos podem ser definidos como funcionais: representando as funções do sistema, o que este deverá fazer; e não-funcionais: representando os atributos do sistema, as qualidades gerais do software (segurança, manutenção, disponibilidade, performance e outros). Os principais artefatos do fluxo de requisitos deverão conter os seguintes elementos [1]: Descrição do problema: Para fornecer ao leitor uma visão geral do problema que será resolvido e suas funções básicas; Glossário: Para apresentar a introdução e os termos que serão utilizados; Atributos dos requisitos: Descreve um repositório de dependências, atributos e requisitos de projeto; Matriz de rastreabilidade: Apresenta os relacionamentos entre o levantamento de requisitos e a representação destes requisitos em um método particular da engenharia de software. Especificações dos casos de uso: Apresenta uma breve descrição, ator, prioridade, interfaces gráficas associadas (opcional), entradas e précondições, saídas e pós-condições, fluxo de eventos principal, fluxos secundários: alternativos e de exceção (opcional); e Especificações suplementares: Apresenta os requisitos não- funcionais, tais como: Confiabilidade, performance, segurança, distribuição, adequação a padrões, restrições de hardware e software e outros. Uma vez que os requisitos são definidos, faz-se necessário que sejam modelados, documentados, validados e acompanhados, ou seja, é de extrema importância para o sucesso do projeto que os requisitos sejam devidamente gerenciados. 3 Gerenciamento de Requisitos de Software O processo de compreensão e controle de mudanças nos requisitos de sistema, em conjunto com outros processos de Engenharia de Requisitos, é denominado Gerenciamento de Requisitos [4]. Seus principais objetivos são gerenciar: (a) mudanças nos requisitos acordados; (b) o relacionamento entre requisitos; e (c) as dependências entre os documentos de requisitos e outros documentos produzidos no processo de Engenharia de Software. [5] As razões pelas quais é de extrema importância para o projeto, a realização do gerenciamento de requisitos são diversas, por exemplo: (a) Alguns sistemas são desenvolvidos de maneira incremental e, entre cada entrega, mudanças nos requisitos são estabelecidas e incorporadas no próximo incremento. (b) Os requisitos são em sua grande maioria mutáveis, sendo este principal causador de manutenções de software e atividades de reengenharia. (c) A existência de sistemas legados que, em diversas organizações são críticos e sustentam operações comerciais e nestes casos, substituir totalmente ou recriar tais sistemas nem sempre é possível, para tanto, necessitam evoluir para que a empresa sobreviva e permaneça competitiva, entre outras [6]. No entanto, independentemente das mudanças que venham a surgir durante o desenvolvimento do software, os requisitos devem continuar a refletir o ambiente do sistema e os objetivos da empresa.

344 Os fatores que mais contribuem para as mudanças de requisitos são [5]: Erros, conflitos e inconsistências nos requisitos que poderão ocorrer durante a fase de implementação; Evolução do conhecimento dos clientes e usuários do sistema: Durante o desenvolvimento dos requisitos, o usuário final e cliente aumentam o nível de compreensão das funcionalidades que realmente desejam; Problemas técnicos, de prazo e de custos: É inevitável que problemas apareçam durante a implementação dos requisitos, resultando em um custo de implementação bastante elevado; Mudanças nas prioridades dos clientes: Durante o desenvolvimento do sistema, poderão ocorrer mudanças no negócio, conseqüentemente, mudanças na prioridade do cliente/ usuário; Mudanças ambientais: Existe a possibilidade de ocorrer mudanças no ambiente o qual o sistema iria funcionar. Portanto, visando manter a compatibilidade, os requisitos deverão ser modificados; e Mudanças organizacionais: Mudanças na estrutura e no processo poderão resultar em novos requisitos de sistema. Segundo [7] é fundamental que as mudanças sejam monitoradas com base nos requisitos e apontam como o principal objetivo do gerenciamento de requisitos, o controle da evolução dos requisitos. Esta pode acontecer pelo surgimento de novas necessidades ou pelo surgimento de deficiências nos requisitos já registrados. A tabela a seguir apresenta um conjunto de atividades de um processo de gerência de requisitos. Estas atividades fornecem apoio na identificação, controle e rastreamento dos requisitos e na realização do tratamento adequado das mudanças [7]. Tabela 1. Atividades de um Processo de Gerência de Requisitos [7] Atividades Receber as solicitações de alteração de requisitos Registrar novos requisitos Analisar impacto da mudança de requisitos Elaborar relatório de Impacto Descrição O grupo de engenharia de requisitos recebe as solicitações de alteração de requisitos, ou por formulário padronizado, ou por meio de um sistema de solicitação de demandas. Novos requisitos também devem ser recebidos formalmente, seja por formulário padronizado, ou por meio de controle sistemático. Uma análise criteriosa deve ser conduzida para avaliar o impacto do requisito a ser incluído, alterado ou excluído sobre cada um dos seus requisitos relacionados, os quais podem ser identificados por meio das matrizes de rastreabilidade. Caso o impacto seja significativo, os requisitos (analisado e relacionado) devem ser revistos. Deve ser mantido um histórico de alterações para cada requisito,

345 Notificar os envolvidos Coletar métricas permitindo uma visão cronológica das principais mudanças nos requisitos. Os envolvidos são um conjunto de pessoas para as quais pode haver um impacto devido à alteração de requisitos (alteração, inclusão ou exclusão de requisitos) e devem ser notificados. As métricas devem ser utilizadas e coletadas periodicamente para o acompanhamento das atividades de Gerência de Requisitos. São diversos os problemas enfrentados pela gerência de requisitos e, dentre estes, destacam-se a dificuldade de elucidar, de forma clara, as mudanças que ocorreram nos requisitos, a falta de habilidade de listar e transpor as mudanças aos patrocinadores, a ausência de aptidão para manter o documento de requisitos de forma consistente e a falta de capacidade para estimar, de forma adequada, os recursos que se fazem necessários para implementação das mudanças nos requisitos [7]. Conforme já apresentado, o principal objetivo da gerência de requisitos, qual seja o acompanhamento da evolução dos requisitos, [8] reforça essa mesma idéia quando afirma que, em sua ausência, este fator torna-se o principal risco que pode levar ao fracasso da grande maioria dos projetos. Os novos requisitos ou modificações significativas nos requisitos existentes, realizadas posteriormente ao conjunto básico de requisitos acordados pelos clientes e desenvolvedores e as falhas para antecipar mudanças de requisitos, as quais afetarão a previsão de aumento ou mudança do escopo do projeto, e conseqüentemente, afetarão nas ações necessárias para lidar com tais variações, tratam-se de potenciais riscos para o projeto. Diante de tantas preocupações e das inúmeras necessidades que aparecem durante o ciclo de vida do software, especialmente de manter um controle adequado de todas as etapas do projeto, as empresas buscam apoio em modelos baseados em boas práticas que visam aumento da produtividade e garantia da qualidade. O guia PMBOK (Project Management Body of Knowledge) atende a este propósito, prestando um grande auxílio aos gestores acerca das dificuldades encontradas ao gerenciar os projetos. 4 Project Management Body of Knowledge (PMBOK) 4.1 Sobre projetos De acordo com [10], os projetos estão presentes em todas as organizações. São de extrema importância para realização de qualquer atividade relacionada à mudança e geração de produtos e serviços. Seguindo este contexto os autores citam alguns

346 exemplos de projetos: desenvolvimento de software, campanhas promocionais, desenvolvimento de um novo produto ou serviço, campanhas de marketing, a implantação de uma estratégia de mudança organizacional, ou mesmo a implantação de uma nova norma organizacional. Um projeto caracteriza-se por ser único um empreendimento único, com início e fim determinados, que utiliza recursos e é conduzido por pessoas, visando atingir objetivos predefinidos [10]. Um projeto, ainda segundo os autores, se caracteriza por ser: temporário, exclusivo ou progressivo. 4.2 Sobre o PMBoK O Guia PMBoK, editado pelo Project Management Institute PMI, presta um grande apoio à gerência, no que diz respeito a gerenciamento de projetos. Este define um programa onde os projetos podem ser gerenciados de forma coordenada e integrada. Atualmente, o Guia está em sua 4ª Edição a qual foi lançada no ano de Este possui 12 capítulos e está dividido da seguinte forma: do capítulo 1 ao 3, apresenta a introdução e conceitos básicos; do capítulo 4 ao 12, especifica as áreas de conhecimento da gestão de projetos. 4.3 Os processos de gerenciamento de projetos (PMBoK ) Segundo o guia PMBoK, classificam-se os processos de gerenciamento de projetos em 5 grupos, conforme explicado a seguir [15] e apresentado na Figura 1: Iniciação, contendo os processos destinados a definir e autorizar um novo projeto ou uma fase de um projeto existente; Planejamento, visando definir o âmbito do projeto, refinar objetivos e definir o curso de ação necessário para alcançar os objetivos e o âmbito para o qual o projeto foi iniciado; Execução, busca integrar pessoas e outros recursos para executar o trabalho definido no Plano de Projeto; Monitoramento/Controle, visa monitorar, rever e regular o progresso e o desempenho do projeto, identificar áreas em que seja necessário efetuar alterações ao Plano de Projeto e executar estas alterações; e Encerramento, concluir todas as atividades ao longo de todos os grupos de processos para encerrar formalmente o projeto ou uma fase do projeto. Figura 1. Mapeamento dos grupos de processos de gerenciamento de projetos (PMBoK ) [14].

347 Durante todo o ciclo de vida do projeto, esses processos interagem entre si trocando informações, de forma que um processo produz entradas para a execução de outro(s) processo(s) ou, ainda, entregas (deliverables) do projeto, conforme ilustrado na figura 2: Figura 2. Processos sobrepostos do gerenciamento de projetos [14]. Cada processo ocorre no mínimo uma vez e, dentro destes, são produzidos diversos documentos de forma a auxiliar no gerenciamento do projeto. Neste ponto, tendo em vista o objetivo deste trabalho, cumpre destacarmos a importância do processo de Iniciação, o qual, apesar de ser relativamente curto, na verdade tem enorme impacto no sucesso (ou insucesso) final de um sistema desenvolvido, conforme pode ser visto em estatísticas demonstradas mais à frente. 4.4 As áreas de conhecimento em gerenciamento de projetos (PMBoK ) Para que se tenha um resultado positivo acerca do gerenciamento de projetos, o Guia PMBoK, apresenta os processos desta gestão, os quais integram as fases já explicitadas em 9 áreas de conhecimento, conforme ilustrado na figura 3 e descrição abaixo: Gerência de Escopo: descreve os processos necessários para assegurar que o projeto contemple todo e somente o trabalho requerido para completar o projeto com sucesso; Gerência de Tempo: descreve os processos necessários para assegurar o encerramento do projeto no tempo definido; Gerência de Custo: descreve os processos necessários para assegurar que o projeto se encerrará dentro do orçamento; Gerência de Qualidade: descreve os processos necessários para assegurar que o projeto satisfará as necessidades contratadas;

348 Gerência de Recursos Humanos: descreve os processos necessários para assegurar o melhor desempenho das pessoas envolvidas; Gerência de Comunicação: descreve os processos necessários assegurar, no tempo certo, a geração, disseminação e armazenamento das informações do projeto; Gerência de Risco: descreve os processos necessários na identificação, análise e controle dos riscos inerentes ao projeto; Gerência de Aquisições: descreve os processos necessários para aquisição de bens e serviços fora da organização; e Gerência da Integração: descreve os processos necessários para assegurar a perfeita coordenação entre todos os processos envolvidos. Figura 3. Áreas de conhecimento da gestão de projetos (PMBOK) [11]. Mais uma vez, em acordo com o objetivo deste trabalho, entende-se que a área de conhecimento Integração deve ser tratada com extrema atenção, tendo em vista que esta será responsável, em última análise, por manter os escopos (requisitos) do projeto em ordem e em dia, ou seja, devidamente acompanhados e controlados. 5 Da importância do tratamento do escopo/requisitos em desenvolvimento de softwares Segundo pesquisa do Standish Group, feita em 2003 [apud 17], quase 70% dos projetos de desenvolvimento de software são entregues fora do prazo. Dos 33% restantes, a pesquisa relata que apenas 20% são usados plenamente, ou seja, apenas 6,6% dos softwares desenvolvidos cumprem corretamente os requisitos inicialmente definidos e/ou são efetivamente utilizados.

349 Figura 4. Estatística sobre desenvolvimento de software feita pelo Standish Group [apud 17]. Poder-se-ia pensar que tal estatística encontra-se defasada, no entanto, pesquisas subseqüentes realizadas pelo mesmo Grupo mostram que, a despeito de ter havido uma ligeira melhora nos anos de 2004 e 2006, no ano de 2009 houve outra grande piora, com os casos de insucesso total passando de 15% (2004) para 24% (2009) [18]. Figura 5. Estatística sobre desenvolvimento de software feita pelo Standish Group 2004, 2006 e 2009 [apud 18]. Mesmo em setores extremamente sensíveis e inseridos no contexto de Administração Pública, como é o caso da área de Defesa, este aspecto também se mostra digno de elevada preocupação. Segundo [21], o segundo item considerado mais importante como fator crítico de sucesso em desenvolvimento de sistemas

350 refere-se a análise detalhada dos requisitos. Diante deste contexto, a pergunta que imediatamente nos surge é a razão para tamanho nível de insucesso. Segundo [17], boa parte da explicação se resume a dificuldades na definição e gerenciamento de requisitos. Afinal, como atesta [20], um requisito adequadamente identificado tornase um indicador da qualidade do software. É bem verdade que diversas e novas abordagens de desenvolvimento têm surgido, como SCRUM, XP e Refactoring, para citar apenas algumas. No entanto, parece haver uma preocupação excessiva em se desenvolver rapidamente um sistema, negligenciando-se, quase que totalmente, aspectos como escopo (requisitos) e seu gerenciamento. Conforme se pode observar pelo exposto até o momento, o PMBOK dá elevada relevância a esta questão, até por suas origens que nos levam a engenheiros da NASA e suas dificuldades em gerir um projeto da magnitude de levar o homem à Lua. Neste sentido, não é difícil compreender os instrumentos práticos e funcionais oferecidos por aquela metodologia as quais, sem dúvida alguma, podem ser facilmente utilizadas dentro da dimensão de desenvolvimento de sistemas. Desta feita, apresenta-se, a seguir, ferramental prático e de fácil compreensão, preconizados pelo PMBoK, os quais tratam aspectos de gerenciamento de escopo/requisitos. 6 Artefatos PMBoK para gerenciamento requisitos De acordo com o guia em foco, os principais documentos que podem ser utilizados para um efetivo monitoramento e controle de requisitos de um projeto são: Termo de Abertura do Projeto Declaração do Escopo do Projeto Plano de Gerenciamento do Projeto Declaração do Trabalho (Statement of Work SoW) Estrutura Analítica do Projeto EAP (Work Breakdown Structure WBS) 6.1 Termo de Abertura do Projeto (Project Charter) Conforme explanado anteriormente, e de acordo com o guia PMBOK, a gerência de integração, descreve os processos necessários para assegurar a perfeita coordenação entre todos os processos envolvidos e, assim, obter um resultado final esperado. A Integração, envolve tomadas de decisão e escolhas diretamente ligadas aos objetivos do projeto e aos processos de desenvolvimento e execução do plano de gerenciamento do projeto, assim como ao processo de controle de mudanças [10]. Os principais processos de gerência de integração são os seguintes [9]: Desenvolver o Termo de Abertura do Projeto: autoriza formalmente um projeto ou uma fase do projeto;

351 Desenvolver a Declaração do Escopo preliminar do projeto: fornece uma descrição de alto nível do escopo; Desenvolver o Plano de Gerenciamento do Projeto: documentação das ações necessárias para a preparação, integração e coordenação de todos os planos do projeto, de modo que gere um documento consistente e coerente; Orientar e gerenciar a execução do Plano de Gerenciamento do Projeto: execução do Plano de Gerenciamento do Projeto por meio da execução do trabalho nele incluído para atingir os requisitos do projeto definidos na Declaração do Escopo; Monitorar e controlar o trabalho do projeto: Monitoramento e controle dos processos exigidos para iniciar, planejar, executar e encerrar um projeto, de forma a alcançar os objetivos definidos no plano de gerenciamento do projeto; Controle integrado de mudanças: Revisão de todos os pedidos, aprovação e controle das mudanças nas entregas e nos ativos de processos organizacionais. Envolvem: diretrizes, normas, procedimentos, políticas, processos definidos, informações históricas, lições aprendidas; e Encerrar o projeto: finalização de todas as atividades envolvidas para encerrar formalmente a fase ou o projeto. A iniciação do projeto é composta por dois grandes processos: Desenvolvimento do Termo de Abertura (área de conhecimento da integração) e Identificação dos Stakeholders (área de conhecimento da comunicação) [15]. A elaboração do termo de abertura tem a finalidade principal de documentar os requisitos do negócio, justificar o projeto, compreender os requisitos reais do cliente e do novo produto, serviço ou resultado que se pretende desenvolver para atender a estas necessidades. Este documento reconhece e comunica o escopo aprovado do projeto aos gerentes funcionais e sua equipe, estabelecendo as responsabilidades e, ainda, fornece ao gerente de projetos a autoridade que necessita para que possa empregar recursos da organização para andamento das atividades. Um termo de abertura deve incluir, entre outros, direta ou indiretamente [10]: O objetivo e justificativa do projeto; a necessidade de negócio, descrição de alto nível do projeto ou requisitos do produto que o projeto deverá contemplar; os requisitos que satisfazem as necessidades e expectativas dos clientes, sponsor e outros interessados pelo projeto; o gestor do projeto designado e respectivo nível de autoridade; a designação do gerente do projeto; o cronograma sumarizado por meio de marcos; as influências dos Stakeholders; as organizações funcionais e respectivas participações; as premissas e restrições organizacionais, ambientais e externas e, orçamento sumarizado. Algumas organizações têm desenvolvido o Termo de Abertura do Projeto de maneira mais detalhada, acrescentando o escopo e objetivos do projeto, especificações, EAP (Estrutura Analítica do Projeto); Timing e plano de gastos e o plano de gerenciamento com os requisitos de recursos e carga horária; Currículos dos colaboradores chave, relações organizacionais e de estrutura, matriz de responsabilidades, apoio necessário de outras organizações, políticas e procedimentos do projeto, plano de gerenciamento de mudança e aprovação da gerência dos demais documentos [10].

352 Depois de realizada a aceitação do Termo de Abertura, este torna-se o primeiro documento oficial do projeto. No entanto, é de grande importância ressaltar que, o termo de abertura deve ser elaborado de uma forma flexível, de maneira que seja permitido realizar mudanças que provavelmente acontecerão durante o ciclo de vida do projeto. 6.2 Declaração de Escopo do Projeto Elaborar a declaração do escopo do projeto é de extrema importância, pois é neste documento que constará uma definição preliminar de alto nível do projeto. Para tal, é necessário utilizar entradas como o termo de abertura do projeto em conjunto com outras entradas que são utilizados no processo de iniciação. Tal declaração tem o objetivo de tratar e documentar os requisitos do projeto e da entrega, bem como os requisitos do produto, os limites do projeto, os métodos de aceitação e o controle de alto nível do escopo. A confecção da declaração do escopo preliminar do projeto é baseada em técnicas, como análise do produto, análise de custo versus benefício, identificação de alternativas e avaliações especializadas, a partir de informações fornecidas pelo patrocinador (iniciador). O refinamento desse documento, pela equipe do projeto, origina a declaração do escopo [10]. A declaração do escopo é que definirá o trabalho a ser realizado. Fornece auxílio à gerência na tomada de decisões e auxilia os interessados no projeto a compreenderem o escopo do mesmo. Como qualquer outro processo, a declaração do escopo deverá ser monitorada e atualizada de forma que sempre reflita às mudanças que vierem a ocorrer durante o ciclo de vida do projeto. Neste sentido tal documento deverá conter as características do produto ou serviço do projeto, os principais resultados e os objetivos do projeto. 6.3 Plano de Gerenciamento do Projeto Começado o projeto oficialmente, com conhecimento do mesmo por parte de todos os stakeholders, identificação dos objetivos, principais entregas e designação do gerente responsável, inicia-se o planejamento do projeto. O primeiro passo da fase de planejamento, a ser realizado pelo gerente de projeto, será estudar os objetivos e entregas para refinar e detalhar a descrição do âmbito do projeto [15]. Para tanto, o autor aponta os passos a serem seguidos para início desta fase: 1. Recolha de requisitos: Desenvolvimento de uma descrição detalhada do âmbito que servirá como base para decisões futuras. A documentação final dos requisitos deve descrever como os requisitos individuais satisfazem as necessidades do negócio para o projeto. Para tanto, os requisitos devem atender a uma série de critérios, antes de passarem para fase de execução: devem ser mensuráveis e testáveis, auditáveis, completos, consistentes e aceitáveis. O documento de

353 requisitos poderá variar, desde um documento simples, com uma lista de todos os requisitos, ordenados por stakeholder e prioridade, até uma forma mais elaborada contendo os seguintes itens: Necessidade empresarial ou oportunidade a ser aproveitada, descrevendo a situação atual e o motivo para a decisão de avançar com o projeto; Objetivo do negócio e do projeto, caso haja necessidade de rastreabilidade no futuro; Requisitos funcionais, incluindo processos de negócio e interações com o produto; Requisitos não-funcionais, como níveis de serviço, desempenho esperado, segurança, cumprimento de normas, facilidade de manutenção, etc.; Requisitos de qualidade; Critérios de aceitação; Regras de negócio descrevendo os princípios orientadores da organização; Requisitos de formação e treino; Pressupostos e restrições dos requisitos. 2. Definição do âmbito: Criação de um plano de gestão do âmbito do projeto, que documente o modo como este será definido, verificado e controlado, e que indique o modo como a EAP será criada e definida; 3. Criação da EAP: Subdivisão das principais entregas do projeto e outro trabalho, em componentes menores e manuseáveis. O plano de gerenciamento do projeto é um documento desenvolvido pelo gerente do projeto em conjunto com a equipe e de alguns stakeholders chaves. Este é considerado o principal documento de apoio ao gerenciamento do projeto. Neste contexto [19], cita as principais documentos que geralmente são incluídos no plano de gerenciamento, quais sejam: Termo de abertura do projeto (Project Charter); Declaração do escopo (Scope Statement); EAP Estrutura Analítica do Projeto (WBS Work Breakdown Structure); Diagrama de rede (Network diagram); Orçamentação ou Plano de Gerenciamento de Custos (Cost budgeting or cost management plan); Cronograma ou Plano de Gerenciamento do Cronograma (Project Schedule or Schedule management plan); Riscos (Risks); Matriz de responsabilidade (Responsability Assignment Matrix); Principais marcos (Major milestones); Sistema de Controle de Mudanças (Change control system); Plano de Gerenciamento de Aquisições (Procurement management plan); Plano de Gerenciamento da Qualidade (Quality management plan); Plano de Gerenciamento das Comunicações (Communications management plan); Linha de base da Medição de Desempenho (Performance measurement baseline). Tal documento contempla as nove áreas de conhecimento, já explicitadas anteriormente. Todos os documentos produzidos deverão ser monitorados para que forneça ao gerente responsável pelo projeto, dados mais próximos da realidade e

354 assim, a tomada de decisões seja de forma correta. A fase de planejamento acontece durante todo o ciclo de vida do projeto. Neste sentido faz-se necessário que tal documento seja elaborado o mais completo possível e ainda, seja de utilidade para medir o desempenho do projeto. 6.4 Declaração do Trabalho (Statement of Work SoW) A Declaração do Trabalho é uma descrição dos produtos a serem fornecidos pelo projeto [9]. Este documento é elaborado com base nas necessidades do negócio, produto ou de serviço. De acordo com esse documento é que os fornecedores decidirão acerca da capacidade de desenvolver o produto ou serviço. São consideradas como declaração de trabalho: Solicitação de Proposta (Request for proposal), Solicitação de Informações (Request for information), Propostas de prestação de serviços, Solicitação de lance (Request for bid) ou partes de um contrato de prestação de serviços [9]. É de grande relevância salientar acerca da cautela em que deve ter ao elaborar este documento, pois o mesmo deve estar em consonância com a Estrutura Analítica do Projeto (EAP). 6.5 EAP - Estrutura Analítica do Projeto Gerenciar o escopo do projeto significa assegurar que a equipe envolvida no projeto realizará somente o trabalho atingir o objetivo esperado. Para que tal objetivo seja alcançado faz-se necessário o cumprimento dos principais processos desta gerência, os quais segundo o guia PMBOK, são os seguintes: Planejamento do escopo: Desenvolvimento do plano de gerenciamento do escopo que documentará como o escopo será definido, verificado, controlado e como a estrutura analítica do projeto (EAP) será criada e definida; Definição do escopo: Desenvolvimento de declaração do escopo detalhada como base para as futuras decisões; Criar a EAP: Subdivisão dos resultados principais do projeto em componentes menores para melhor gerenciamento. Verificação do Escopo: Formalização da aprovação das entregas do projeto; Controle do escopo: Controle das mudanças no escopo do projeto. O resultado do processo de planejamento de escopo é o Plano de Gerenciamento de Escopo, que tem como principal finalidade, apresentar de que forma o projeto deve ter seu escopo gerenciado, como as mudanças serão identificadas, classificadas e, ainda, como estas deverão ser incorporadas ao projeto [10]. Tal como o Termo de Abertura e o Plano de Gerenciamento do Projeto, a EAP é um documento utilizado para auxiliar o gerenciamento de projetos. Trata-se de uma estrutura orientada a produto que evolui com o projeto e que possibilita a identificação e organização das unidades lógicas de trabalho a serem gerenciadas,

355 denominadas "pacotes de trabalho [15]. A EAP é utilizada como base para planejar, organizar e controlar o trabalho a ser feito assegurando que o projeto inclui todo e somente o trabalho necessário. Esta fornece detalhes do escopo do projeto permitindo o monitoramento do progresso do projeto. Se feito corretamente, detalha o custo e auxilia na montagem da equipe e distribuição do trabalho [10]. Este artefato organiza sua estrutura hierarquicamente, bem como define todo o trabalho a ser realizado (ou deliverables) para se atingir os objetivos finais. Fornece um quadro gráfico ou esboço de texto do escopo do projeto e uma estrutura de todas as entregas através do ciclo de vida do projeto e um veículo para integração e avaliação do desempenho de custo e cronograma. Apresenta ainda, a associação de responsabilidade para os stakeholders, facilita o relatório e análises do progresso do projeto e dados de situação do projeto e fornece a estrutura para especificar os objetivos de desempenho. Neste contexto, [10] aponta os principais passos para elaboração de uma EAP: 1. Desenvolver uma visão clara do produto final e de todos os processos pelos quais a EAP será criada; 2. Preparar o desenvolvimento, levando em consideração que cada elemento da EAP deverá representar uma entrega única e tangível. Cada elemento da EAP deverá representar um agrupamento de todos os elementos que lhe são subordinados, listados imediatamente abaixo. Cada elemento subordinado da EAP deverá pertencer somente a um elemento superior e, todos os deliverables do projeto devem estar incluídos na EAP; 3. Elaborar a EAP em forma de cronograma com retângulos que contêm um rótulo descritivo. Vários retângulos devem ser organizados para mostrar as suas relações hierárquicas. A EAP em forma de organograma é melhor para fins de apresentação devido a maior facilidade de compreensão. Utilizar substantivos para rotular (nomear) um produto ou um serviço, reforça a definição básica da EAP, como um arranjo hierárquico de produtos e serviços. 4. Decompor em fases: Uma característica fundamental de uma EAP construído corretamente é o avanço consistente na elaboração do detalhamento, partindo-se do mais geral para o mais específico. 5. Dividir cada item da EAP em pelo menos dois elementos: primeiro, o item propriamente dito e segundo, os serviços de administração necessários para gerenciá-lo. Na maioria dos casos, não pode ser predeterminado o número de níveis a serem usados, portanto a lógica da situação determina o número de níveis. 6. Decompor a EAP em níveis de detalhes, incrementando sucessivos níveis de detalhes, até que um nível seja encontrado e que forneça a visão necessária para o gerenciamento efetivo do projeto. Nem todas as colunas da EAP devem estar iguais em termos do número de níveis desenvolvidos. Não será necessário decompor todas as colunas da EAP se a necessidade está presente somente em uma área. De acordo com [12], para que uma EAP seja considerada adequada deverá mostrar que ajuda os leitores a descobrirem aspectos no escopo do projeto que não sejam óbvios ou estejam sujeitos a omissão (como reuniões de lançamento de projeto e reuniões de acompanhamento de projetos); resulta de processo de criação lógico e

356 disciplinado; baliza exatamente o escopo do projeto; facilita a comunicação do escopo aos Stakeholders; é hierarquicamente organizada e consiste em produtos do projeto, sejam eles produtos propriamente ditos ou serviços; enfatiza os produtos a serem entregues e os serviços de gerenciamento e de apoio associados a cada deliverable e ao projeto como um todo; é formatado na forma de organograma; está sempre atualizado e integrado ao processo de controle das mudanças de escopo e, assegura que cada elemento nivelado mais alto consiste totalmente na soma de seus elementos nivelados mais baixos e nada mais. 7 Conclusão Foi apresentado no decorrer deste trabalho a enorme importância que representa o gerenciamento adequado dos projetos, para um bom desempenho de uma organização e para que esta alcance o sucesso no desenvolvimento dos seus produtos ou serviços. Enfatizou-se que, durante o ciclo de vida do projeto, diversos eventos podem vir a acontecer. Tais geram mudanças e, conseqüentemente, estas poderão trazer uma série de riscos que podem levar ao fracasso do projeto. Diante deste fato, um gerenciamento de requisitos mais robusto é crucial para que potenciais mudanças (e seus impactos) sejam identificadas, analisadas e tratadas adequadamente. Mas não somente isso, faz-se necessário que os requisitos sejam elaborados da forma mais correta possível, obedecendo regras e critérios definidos, evitando-se, assim, danos futuros ao projeto. Para que os projetos consigam passar por todas as suas fases, desde a iniciação até o encerramento e atinja os objetivos esperados, observa-se que é essencial o acompanhamento durante todo seu desenvolvimento e ainda, faz-se de grande importância que o processo de Iniciação não seja negligenciado, pois a realização inadequada deste processo pode causar impactos em todos os processos restantes e influenciar negativamente no resultado final do projeto. Para alcançar os objetivos do projeto, apresentou-se o Guia PMBoK. Este guia presta um enorme apoio, indicando melhores técnicas a serem seguidas, bem como os documentos a serem elaborados, para que o projeto seja monitorado e controlado de forma adequada. Com o seguimento de tais práticas torna-se possível retirar conclusões e tomar decisões de forma sustentada e voltada para uma efetiva gerência dos projetos. Por fim, apresentou-se, neste trabalho, os documentos os quais são sugeridos pelo guia em questão e que servirão de apoio para a gerência durante todo o ciclo de vida do projeto, a saber: Termo de Abertura do Projeto, Declaração do Escopo do Projeto, Plano de Gerenciamento do Projeto, Declaração do Trabalho (Statement of Work SoW) e Estrutura Analítica do Projeto EAP. Referências 1. Tonsing, Sérgio Luiz. Engenharia de Software Análise e Projeto de Sistemas. 2 ed. Rio de Janeiro: Editora Ciência Moderna Ltda., Sommerville, Ian. Engenharia de Software. 8 ed. Addison Wesley BRA, 2007.

357 3. Nardi, Júlio César, Falbo, Ricardo de Almeida. Uma ontologia de requisitos de Software. (2010). 4. De Grande, José Inácio. SIGERAR: Uma Ferramenta para Gerenciamento de Requisitos.http://www.inf.pucrio.br/wer/WERpapers/artigos/artigos_WER06/degrand e.pdf/ (2010). 5. Kotonya, G. e Sommerville, Ian., Requirements Engineering: Processes and Techniques, John Wiley and Sons, Lam, W., Loomes, M. e Shankararaman, V., Managing Requirements Change Using Metrics and Action Planning, Third European on Software Maintenance, Amsterdan, Netherlands, Hazan, Cláudia, Leite, Júlio César Sampaio do Prado. Indicadores para gerência requisitos.http://wer.inf.pucrio.br/werpapers/artigos/artigos_wer03/claudia_hazan. pdf (2010). 8. Jones. Assessment and Control of Software Risks. Prentice Hall, Guia do Conjunto de Conhecimento em Gerenciamento de Projetos, PMI, Dinsmore, Paul Campbell e Cavalieri, Adriane. Como se tornar um profissional em Gerenciamento de Projetos. Qualitymark, Seven Soluções Empresariais. (2010). 12. Keeling, Ralph. Gestão de projetos. Uma abordagem global. Saraiva, Woiler, Samsão, Mathias, Washington Franco. Projetos - Planejamento, Elaboração e Análise. Atlas, Promom, Business & Tecnology Review. Gerenciamento de projetos. pdf (2008). 15. Miguel, Antônio. Gestão Moderna de Projectos. Melhores Técnicas e práticas. FCA, Ciclo PDCA. Wikipedia. (2011). 17. Lima, Rafael. Desenvolvimento de Software. Myfreecomm (2009). Disponível em (2011). 18. Dias, André. Chaos Report 2009, novas informações, velhos problemas. MSDN (2009). Disponível em (2011). 19. Mulcahy, Rita. PMP Exame Preparatório, Mecenas, Ivan; Oliveira, Vivianne de. Qualidade em Software Uma metodologia para homologação de sistemas. Alta Books, Cleland, David I.; Gallagher, James M.; Whitehead, Ronald S. Military Project Management Handbook. McGraw Hill, 1993.

358 Modeling Organizations and Processes CARLOS SALGADO, University of Minho The issue of aligning and integrating business and IT is a focus of many organizations in their strategic and tactical development. Constructing integrated enterprise architecture models and building flexible but stable business process models is halfway to achieve that goal and deploy sound information systems solutions. To better understand the research being done and trends to future work, this paper covers a state of the art over two important topics in this area, namely enterprise architecture modeling and business process modeling. General Terms: Organization strategy, enterprise architecture, business process Additional Key Words and Phrases: modeling, UML, BPMN 1. INTRODUCTION If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. Sun Tzu Any organization fights many battles to survive and thrive in today s world, and an essential part to have success in it is to know itself and the stakeholders (friends or foes) that surround it. For this, the knowledge of its enterprise architecture and the processes that rule its integrated behavior cannot be neglected. To tackle these issues, this paper looks at the area of organization management, trying to perform a state of the art over two more specific topics, the modeling of enterprise architectures and the standards and languages used in business process management area. So, after describing the bibliographic search strategy used on the research for this paper, we follow to cover the main topics on enterprise architecture modeling, establishing its basic grounds, and then to a survey over BPM and all its standards, languages and new trends arising. 2. BIBLIOGRAPHIC SEARCH STRATEGY The main source for bibliographic search for this paper was done through the ISI Web of Knowledge portal (http://www. isiknowledge.com/), with some cross-checking using Google Scholar (http://scholar.google.pt/). On the ISI Web of Knowledge website, search was performed using the keywords of the areas of interest and also by relevant author name. Search refinement was done by selecting the relevant general categories and subject areas, and also prioritizing the article document type. Another technique used, was the ability to browse through the references of the articles found, searching for related work in the subject, and also through the papers that cite each article, allowing to state its impact and relevance in the area. The reference treatment was performed using Mendeley, which demonstrated to be a very useful tool, with its cross-checking of references online and the ease of use with MS Word. Author s addresses: C. Salgado, Information Systems Department, University of Minho. Permission to make digital or hardcopies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation.

359 Table I. Bibliographic References TITLE Reference Enterprise architecture - Literature overview and (Aier, Riege, & Winter, 2008) current practices Major issues in business process management: an (W. Bandara, Indulska, Chong, & Sadiq, 2010) expert perspective Professionalizing Business Process Management: (Wasana Bandara, Harmon, & Michael Towards a Common Body of Knowledge for BPM Rosemann, 2010) The influence of Enterprise Architecture and (Cardwell, 2008) process hierarchies on company success A taxonomy of business process modeling and (Giaglis, 2001) information systems modeling techniques Concepts for modeling enterprise architectures (Hoppenbrouwers, Bonsangue, & Torre, 2004) Enterprise architecture Management - tool and (Jonkers et al., 2006) blueprint for the organisation Business process management (BPM) standards: a (Ko, S. S. G. Lee, & E. W. Lee, 2009) survey Enterprise architecture modelling the issue of (M. Lankhorst, 2004) integration Business Process Modeling Languages: Sorting (Mili, Jaoude, Lefebvre, Tremblay, & through the alphabet soup Petrenko, 2010) Business Process Modeling- A Comparative (Recker, M. Rosemann, Indulska, & Green, Analysis 2010) 3. ENTERPRISE ARCHITECTURE MODELING Organizations face an ever-changing world where they must strive for success, focusing not only on the business side but also on Information Technology (IT) support and opportunities. The problem of aligning and integrating both business and IT is a very important issue of any organization strategy and success, which the design of enterprise architectures (EA) tries to tackle with. In order to survive, organizations need to constantly adapt and follow a strategy of continuous improvement and innovation, a good architecture practice helps an organization in following that path. As (Jonkers et al., 2006) 1 refers, besides supporting the wealth of interconnections with its customers, suppliers, and other partners, the internal drives of the business, there are also external pressures that push organizations toward adopting an EA practice. The regulatory framework, increasingly demands that companies and governmental institutions can prove that they have a clear insight into their operations and that they comply with the applicable laws. So, organizations need to adjust processes to their environment, open up internal systems and make them transparent to both internal and external parties. Architecture is a process as well as a product, serves to guide managers in designing business processes and system developers in building applications in a way that is in line with business objectives and policies. One of the most important roles of an EA is that it serves as an instrument in the communication among diverse groups and interests and provides a common ground for discussion and decision making. Many stakeholders within and outside the organization can be identified, ranging from toplevel management to software engineers, and each one requires specific information presented in an accessible form, to deal with the impact of such wide-ranging developments. According to (Cardwell, 2008), architecture and systems design is often overlooked as one of the most important aspects for ensuring that everyone in the organization understands how they can contribute to its success and thereby improve their own performance and job satisfaction. Also, he stresses the need for simple architectures, which enable people to see how the systems work to achieve company goals, 1 The style of formatting for bibliographic references used throughout this document is APA.

360 structured in a simple set of process hierarchies so the IT function can implement the solutions in a way everyone can understand. The purpose is to avoid the usual communications gap between the workforce and the people designing and implementing the business systems, putting to practice the concept of Organizational Learning, with everyone working to promote the vision and strategies of the organization as the natural way of achieving employee happiness and company success. The instruments needed for creating and using EA are numerous and diverse, but are still in their infancy, the best-known tools being EA frameworks, such as the Zachman framework and The Open Group Architecture Framework (TOGAF). (Jonkers et al., 2006) states that these offer high-level guidance in identifying which areas of business and technology should be considered when creating an EA, but they provide little assistance in creating the architectural artifacts themselves and have scarce theoretical grounds. Additionally, (Cardwell, 2008) refers a somewhat popular solution, a process hierarchy model known as ARIS (Architecture of Integrated Information Systems), which has been incorporated into the SAP-R3 proprietary software packages, includes ISO 9001 requirements, links into many of the TQM-based concepts and tools for optimizing business processes and implementing software systems. He also points out to a more recent authoritative reference to ARIS, the BPTrends EA Pyramid Model, which models better the business processes found in most organizations and fits the structure of the Zachman Framework. The wide variety of frameworks, methodologies, techniques and languages associated with EA, motivated the work of (M. Lankhorst, 2004) and (Hoppenbrouwers, Bonsangue, & Torre, 2004) for a common description language that fully enables integrated enterprise modeling. This is not a simple matter because in each architectural domain, architects use their own modeling techniques and concepts, tool support, visualization techniques, etc., and these domains are usually not approached in an integrated way. Figure 1 represents the (Hoppenbrouwers, Bonsangue, & Torre, 2004) view of the complexity of architectural domains and particularly their relations within the scope of a set of architecture instruments and techniques. Fig. 1. Enterprise architecture (ArchiMate context). Such an integrated language needs to identify and study concepts that relate architectural domains and the concepts for describing the relationships between architecture descriptions at the business, application and technology levels. It should also support views and presentation techniques tailored to the needs of different stakeholders, providing them with insight in their particular area of interest, and facilitating cross-domain discussion and understanding. In their study, these are centered around the notion of a viewpoint, in accordance with the IEEE standard

361 1471, and additionally the analysis techniques used to assess the impact of developments and changes. The metamodel proposed defines concepts at an intermediate abstraction level, selected in such a way that they provide a common basis for the partner-specific concepts in the top and bottom layer (Figure 2). Fig. 2 Metamodels at different levels. At the base of the triangle, there are the metamodels of the architecture modeling concepts used by specific organizations, as well as a variety of existing modeling languages and standards, which include exml, BPML, IDEF, ARIS, Testbed and UML. At the top of the triangle there is the most general" metamodel for system architectures, essentially comprising notions such as object", component", and relation". Some architectural description languages such as ACME8 partly fall into this category. For the state-of-the-art in enterprise modeling, we have to consider languages for organization and process modeling as well as languages for application and technology modeling. Nowadays, in many modern IT-intensive organizations, several types of architects and architectures can be found, and as (M. Lankhorst, 2004) observed, the Unified Modeling Language (UML) is usually the language of choice for interchange and communicating between them. Other languages such as ebxml, ARIS, Testbed and standards such as the XML-based Business Process Modeling Language BPML are somewhat popular in the area too. In the more business-oriented disciplines, working under architecture is a more recent development and visual modeling has not yet gained much acceptance in this field, although there exists some architecture description languages (ADLs), which define high-level concepts for architecture description, such as components and connectors. In this point, the ADL ACME is widely accepted as a standard to exchange architectural information, also between other ADLs. Although a very popular language in the area, the Business Process Modeling Notation s (BPMN) scope is limited to business processes and it does not provide concepts for modeling organizational structures, data models, or the relation between business activities and supporting IT applications, making it of limited use in enterprise architecture. Lastly, another important trend is OMG s Model Driven Architecture (MDA) approach, which strongly leans on OMG standards such as UML, but the applicability of the approach is not limited to specific languages. As referred before, UML is the mainstream modeling approach within IT, and its use is expanding into other areas, as the support for architectural modeling improves in this standard through the Enterprise Distributed Object Computing (EDOC) profile. This makes UML an important language not only for modeling software systems, but also for business processes and for general business architecture. The main issue is that it is not easily accessible and understandable for managers and business

362 specialists, therefore, special visualizations and views of UML models should be provided. In this way, the concepts would be made available to a large user base and be supported by a wide range of software tools. Recently, (Aier, Riege, & Winter, 2008) performed a literature review, revealing the lack of research on the organizational and strategic level of EA, particularly in the methodological support for studies and deployment scenarios, where this part of the EA are often neglected. The potential for applied research is evident, not only on the possible scenarios for enterprise architectures deployment and testing, but also on the methodological support specification of these scenarios, presenting an interesting area for cooperation between research and practice. Modeling has always been at the center of both organizational design and information systems (IS) development. However, both business analysts and IS professionals find it difficult to navigate through a maze of theoretical paradigms, methodological approaches and representational formalisms that have been proposed for both Business process modeling and information system modeling. Evaluating and selecting suitable modeling techniques, depending on the characteristics and requirements of individual projects can be cumbersome. Most languages and tools are aligned with a particular analysis and design method. This wide variety represents a source of complexity and problems of incompatibility among them. (Giaglis, 2001) already faced this issues and also pointed UML attempts, with its extension for business modeling, to address this gap by being a common, universal language, covering everything from business process representation to database schema depiction and software components modeling. Nevertheless, many doubts still subsist for the development of a single, holistic language and technique, applicable in all modeling situations. As we have seen, the enterprise architecture modeling exists only in its infancy and much work is still to be done, in particular, on research approaches to the creation, integration, maintenance and use of new or existing models, and on tool development for this area on all its domains. Also many organizations are still not enjoying the benefits of proper Business Process Management (BPM), since without this approach there are major communication gaps between the several stakeholders. 4. BUSINESS PROCESS MODELING It is widely acknowledged that process enforcement technologies hold the potential to provide the missing-middle that can assist in overcoming the business-it division. In that manner, Business Process Management (BPM) is widely seen as the top priority in organizations wanting to survive the current competitive markets. Nevertheless, BPM is viewed from highly diverse angles ranging from a management strategy to a software system, so much so, that there is still not a common consensus even about the definition of Business Process Management itself. (W. Bandara, Indulska, Chong, & Sadiq, 2010) defines BPM as the term used to encapsulate a process-driven approach to attaining enterprise operational efficiency and points three primary stakeholders in the BPM space, namely the users (organizations), the vendors, and the experts who champion the BPM approach. BPM includes methods, techniques, and tools to support the design, enactment, management and analysis of business processes, and its approaches prescribe that the entire management of an organization - strategy, goal setting, controlling and planning - be based on its core processes. In definitional terms, they set a process as simply a structured, measured set of activities designed to produce a specific output for a particular customer or market. Processes have their origins just after the decline of the function oriented approach, initiated with the Business Process Re-Engineering (BPR) concept, which was further re-enforced by other contemporary practices such as Davenport s Process

363 Innovation (1993), Total Quality Management (TQM), Six Sigma, Lean Management, Time-based Management, and value-based performance measurements. In the last decades there have been significant advances in various BPM research areas, in particular on technological features that support process control and monitoring, and application integration, being the foremost factor in BPM success its achieving improvements in the business outcomes. Despite BPM being ranked as top priority by organizations, current status of BPM research suggests a gap on addressing present industry demand. Although there are many studies and reports that outline particular positive experiences and case studies, others that have attempted to consolidate the various experiences into a comprehensive collection of issues and challenges detected frequently noted issues, such as: lack of top management support, lack of tools for visualization for large processes, lack of tools that link process design to process execution, etc. In a similar way, a study from (Mili, Jaoude, Lefebvre, Tremblay, & Petrenko, 2010) reported that researchers and practitioners in management information systems have long recognized that understanding the business processes that an information system must support is key to eliciting the needs of its users, but lacked the tools to model such business processes or to relate such models to software requirements. Also in business administration, they have long been interested in modeling the processes of organizations for the purposes of understanding, analyzing, and improving such processes but their models were often too coarse to be of use to software engineers. After presenting an overview of business process modeling languages and its progress in the last years, it concludes that the technologies that we are dealing with were not mature when the standardization efforts were started: they were maturing. This means, among other things, that the standards evolved faster than usual, even some standards were dropped along the way and other standardization bodies got merged. Complementary, and reinforcing the findings from (M. Lankhorst, 2004), they remark that UML, above of all alternative standards, along the information, functional, and dynamic views, is overall richer than most of them, and that with its four-layer architecture, can probably handle any view, just needing to define the corresponding metamodel using UML core (or MOF). Notwithstanding, with respect to the organizational view, UML has the ingredients but not yet the focus or tone. Also it cannot be said that UML s dynamic model supports deadlock detection, but it can be reached by other means. The evolution, in the last two decades, of the different standards in BPM is thoroughly analyzed by (Ko, S. S. G. Lee, & E. W. Lee, 2009), after an extensive literature review. As the proliferation of BPM modeling languages, standards and software systems has given rise to much confusion and obstacles to adoption, and as new BPM languages and notation terminologies were not well defined, they find that duplicate features are common. Their study tries to make sense of the myriad of BPM standards, organizing them in a classification framework, and to identify key industry trends. Regarding the BPM life cycle, one of the most consensual representations is presented in Figure 3.

364 Fig. 3 BPM Life Cycle As the interest in BPM from practitioners and researchers grew rapidly, a wide variety of paradigms and methodologies from organization management theory, computer science, mathematics, linguistics, semiotics, and philosophy were adopted, making BPM a cross-disciplinary theory in practice subject. Nevertheless, they realize that a discipline with a history of about three decades has yet to clarify basic BPM terminologies like business process, BPM vs workflow management (WfM), workflow, business process reengineering (BPR) and so on. Other questions are related to new BPM terminologies and technologies that are often not well defined and understood by many practitioners and researchers using them, and new languages and notations proposed that often contain duplicating features for similar concepts, and loosely claim to be based on theoretical formalisms such as Pi-calculus and Petri nets. Most of them have also not been validated, especially in a real business and office environment. Due to all this issues and as a framework to evaluate BPM standards was nonexistent at the time of writing, the authors did an attempt to classify BPM languages, standards and notations into four main groups: execution, interchange, graphical, and diagnosis standards (mapping the BPM life cycle). A graphical representation of it is represented in Figure 4. Fig. 4 BPM languages, standards and notations (1) Regarding the previous presented BPM life cycle, the graphical, execution and interchange standards address the process design and process enactment stage, while diagnosis standards address the diagnosis stage. Graphical standards are currently the highest level of expression of business processes (i.e. most natural to human beings) while the lowest level (i.e. the most technical) are the execution standards. Even though the interchange standards aim to bridge the graphical standard to the execution standard or vice versa, the translation can sometimes be imperfect, as both standards are conceptually different. As system configuration is an organization-based (internal) process, having a

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

Iteração 2 Design inicial

Iteração 2 Design inicial Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Engenharia de Software Iteração 2 Design inicial Projecto: FX-Center Grupo: BEDS David Pacheco (nº 32665) Cesário Lucas

Leia mais

Enunciado de apresentação do projecto

Enunciado de apresentação do projecto Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 Enunciado de apresentação do projecto FEARSe Índice 1 Introdução... 2 2 Cenário de Enquadramento... 2 2.1 Requisitos funcionais...

Leia mais

Lisboa, 18 de Janeiro de 2004

Lisboa, 18 de Janeiro de 2004 Lisboa, 18 de Janeiro de 2004 Realizado por: o Bruno Martins Nº 17206 o Cátia Chasqueira Nº 17211 o João Almeida Nº 17230 1 Índice 1 Índice de Figuras... 3 2 Versões... 4 3 Introdução... 5 3.1 Finalidade...

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

Plataforma integrada para testes em arquitecturas orientadas a serviços

Plataforma integrada para testes em arquitecturas orientadas a serviços Plataforma integrada para testes em arquitecturas orientadas a serviços Índice Introdução... 2 A solução... 2 Plataforma Integrada (principais características)... 4 Eliminar limitações à execução de testes

Leia mais

Fase 1: Engenharia de Produto

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

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA Introdução Nesta edição do Catálogo de Serviços apresentamos os vários tipos de serviços que compõe a actual oferta da Primavera na área dos serviços de consultoria.

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Unified Software Development Process

Unified Software Development Process 59/170 Unified Software Development Process Sumário Breve história do Unified Process O Unified Process O ciclo de vida do Unified Process O RUP (Rational Unified Process) 60/170 Breve História do Unified

Leia mais

Oracle BPM 11g. Análise à Plataforma

Oracle BPM 11g. Análise à Plataforma Oracle BPM 11g Análise à Plataforma Maio de 2010 Tive o privilégio de ser convidado a participar no "EMEA BPM 11g beta bootcamp" em Abril de 2010, no qual tive contacto mais próximo com a última versão

Leia mais

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA Sandra CARVALHO 1, Pedro GALVÃO 2, Cátia ALVES 3, Luís ALMEIDA 4 e Adélio SILVA 5 RESUMO As empresas de abastecimento de água gerem diariamente

Leia mais

Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle

Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle Márcio Araújo Varchavsky, Eduardo Martins Guerra, Clóvis Torres Fernandes

Leia mais

Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos. Requisitos para a 3ª entrega do projecto.

Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos. Requisitos para a 3ª entrega do projecto. Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto Loja Virtual 5 de Maio de 2008 Índice Índice...2 1 Sumário...3 2 Requisitos...3

Leia mais

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual Engenharia de Software Sistemas Distribuídos 2º Semestre, 2007/2008 Departamento Engenharia Informática Enunciado do projecto: Loja Virtual Fevereiro de 2008 Índice Índice...2 Índice de Figuras...3 1 Introdução...4

Leia mais

BPM (Business Process Management)

BPM (Business Process Management) Instituto Superior de Economia e Gestão Ano lectivo 2007/2008 Cadeira de Tecnologias de Informação BPM (Business Process Management) Planeamento e Controlo de Gestão Baseados nos Processos de Negócio José

Leia mais

Workshop. Maturidade da Governação e Gestão de TI em Portugal. Inquérito Nacional 2011. Mário Lavado itsmf Portugal 11-10-2011

Workshop. Maturidade da Governação e Gestão de TI em Portugal. Inquérito Nacional 2011. Mário Lavado itsmf Portugal 11-10-2011 Workshop Maturidade da Governação e Gestão de TI em Portugal Inquérito Nacional 2011 Mário Lavado itsmf Portugal 11-10-2011 Agenda Apresentação dos resultados do estudo de maturidade do ITSM & ITGovervance

Leia mais

Projecto de Engenharia de Software e Sistemas Distribuídos 2009-10. Requisitos para a 3ª entrega do projecto. FeaRSe.

Projecto de Engenharia de Software e Sistemas Distribuídos 2009-10. Requisitos para a 3ª entrega do projecto. FeaRSe. Departamento de Engenharia Informática Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto FeaRSe 6 de Maio de 2010 Índice Índice... 1 1 Sumário... 2 2 Requisitos...

Leia mais

Requisitos Não-Funcionais em Aplicações Orientadas a Serviços: Análise da Tecnologia Fuse ESB

Requisitos Não-Funcionais em Aplicações Orientadas a Serviços: Análise da Tecnologia Fuse ESB Universidade do Minho Escola de Engenharia Alexandre Manuel Loureiro Barbosa Requisitos Não-Funcionais em Aplicações Orientadas a Serviços: Análise da Tecnologia Fuse ESB Dissertação de Mestrado Engenharia

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

ISO/IEC 20000 DOIS CASOS DE SUCESSO DE CLIENTES QUALIWORK

ISO/IEC 20000 DOIS CASOS DE SUCESSO DE CLIENTES QUALIWORK ISO/IEC 20000 DOIS CASOS DE SUCESSO DE CLIENTES QUALIWORK A Norma ISO/IEC 20000:2011 Information technology Service management Part 1: Service management system requirements é uma Norma de Qualidade que

Leia mais

Escola Superior de Tecnologia de Setúbal. Projecto Final

Escola Superior de Tecnologia de Setúbal. Projecto Final Instituto Politécnico de Setúbal Escola Superior de Tecnologia de Setúbal Departamento de Sistemas e Informática Projecto Final Computação na Internet Ano Lectivo 2002/2003 Portal de Jogos Executado por:

Leia mais

Portal AEPQ Manual do utilizador

Portal AEPQ Manual do utilizador Pedro Gonçalves Luís Vieira Portal AEPQ Manual do utilizador Setembro 2008 Engenharia Informática - Portal AEPQ Manual do utilizador - ii - Conteúdo 1 Introdução... 1 1.1 Estrutura do manual... 3 1.2 Requisitos...

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projectos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

WebSphere MQ. Bruno Miguel de Sousa Gonçalves

WebSphere MQ. Bruno Miguel de Sousa Gonçalves WebSphere MQ Bruno Miguel de Sousa Gonçalves 1.Introdução ao WebSphere Os produtos WebSphere providenciam comunicação entre programas através da interligação entre componentes heterogéneos, processadores,

Leia mais

Universidade Fernando Pessoa

Universidade Fernando Pessoa Objectivos da cadeira reconhecer, criar e explorar um recurso de informação usar tecnologias de informação emergentes para a gestão eficaz do recurso informação discutir o impacto das tecnologias de informação

Leia mais

ANEXO 1. Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI. Instituição de acolhimento. Supervisor nomeado pela instituição

ANEXO 1. Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI. Instituição de acolhimento. Supervisor nomeado pela instituição INSTITUTO SUPERIOR DE CIÊNCIAS DO TRABALHO E DA EMPRESA Departamento de Ciências e Tecnologias de Informação DCTI Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI ANEXO 1 Instituição

Leia mais

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento Desenvolvimento Iterativo Esta abordagem ao desenvolvimento assegura que o sistema cresce de forma incremental assegura que a complexidade se mantém controlada permite ainda obter rápido feedback de várias

Leia mais

Web Services como Tecnologia de Suporte a Processos de Negócio

Web Services como Tecnologia de Suporte a Processos de Negócio Web Services como Tecnologia de Suporte a Processos de Negócio Rodrigo C. Macedo, Vasco Mesquita, Artur Caetano, André Vasconcelos, José Tribolet Centro de Engenharia Organizacional, INESC INOV e Departamento

Leia mais

Dynamic Data Center. A infra-estrutura de suporte às SOA. Francisco Miller Guerra Senior Product Manager Fujitsu Siemens Computers

Dynamic Data Center. A infra-estrutura de suporte às SOA. Francisco Miller Guerra Senior Product Manager Fujitsu Siemens Computers Dynamic Data Center A infra-estrutura de suporte às SOA Francisco Miller Guerra Senior Product Manager Fujitsu Siemens Computers As necessidades do negócio pressionam continuamente as infra-estruturas

Leia mais

MODELOS DE MELHORES GOVERNANÇA DE T.I. PRÁTICAS DA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

MODELOS DE MELHORES GOVERNANÇA DE T.I. PRÁTICAS DA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza MODELOS DE MELHORES PRÁTICAS DA GOVERNANÇA DE T.I. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza MELHORES PRÁTICAS PARA T.I. MODELO DE MELHORES PRÁTICAS COBIT Control Objectives for Information

Leia mais

Engenharia de Software. Enunciado da Primeira Parte do Projecto

Engenharia de Software. Enunciado da Primeira Parte do Projecto LEIC-A, LEIC-T, LETI, MEIC-T, MEIC-A Engenharia de Software 2 o Semestre 2014/2015 Enunciado da Primeira Parte do Projecto 1. Primeira Parte do Projecto ES Este enunciado descreve o trabalho a realizar

Leia mais

R/3 e SAP WAS. 8/28/2003 José Alves Marques. R/3 e SAP WAS(2)

R/3 e SAP WAS. 8/28/2003 José Alves Marques. R/3 e SAP WAS(2) R/3 e SAP WAS O R/3 é um ERP Enterprise Resource Planning Um ERP é o sistema empresarial que disponibiliza módulos para os processos de negócio - de uma empresa Um ERP permite aumentar a eficiência dos

Leia mais

Universidade do Minho Licenciatura em Engenharia Informática

Universidade do Minho Licenciatura em Engenharia Informática Universidade do Minho Licenciatura em Engenharia Informática Disciplina de Desenvolvimento de Sistemas de Software Trabalho Prático Fase 1 Ano Lectivo de 2009/10 GereComSaber Grupo 15 Cláudio Manuel Rigueiro

Leia mais

Os Cinco Níveis de Maturidade na Gestão de Requisitos

Os Cinco Níveis de Maturidade na Gestão de Requisitos Os Cinco Níveis de Maturidade na Gestão de Requisitos Ter maturidade significa ser capaz de ver o contexto e efectuar boas escolhas. No âmbito de uma empresa, significa basear as decisões numa compreensão

Leia mais

INSTITUTO POLITÉCNICO DE SANTARÉM ESCOLA SUPERIOR DE DESPORTO DE RIO MAIOR. Licenciatura em desporto Gestão das Organizações Desportivas

INSTITUTO POLITÉCNICO DE SANTARÉM ESCOLA SUPERIOR DE DESPORTO DE RIO MAIOR. Licenciatura em desporto Gestão das Organizações Desportivas INSTITUTO POLITÉCNICO DE SANTARÉM ESCOLA SUPERIOR DE DESPORTO DE RIO MAIOR Licenciatura em desporto Gestão das Organizações Desportivas Unidade Curricular Gestão de Sistemas de Informação II Ano Lectivo

Leia mais

soluções transversais SOLUÇÕES middleware

soluções transversais SOLUÇÕES middleware soluções transversais SOLUÇÕES middleware RESUMO DA SOLUÇÃO ITbank framework 4g performance orquestração interoperabilidade O Middleware SOA ITBank framework 4g implementa uma arquitetura SOA com orquestração

Leia mais

PALAVRAS CHAVE RESUMO

PALAVRAS CHAVE RESUMO ESIG2001 SPATIAL INTELLIGENCE INFORMAÇÃO GEOGRÁFICA COMO MEIO DE SUPORTE À DECISÃO João Machado Costa, Rui Marques Ferreira Novabase www.novabase.pt joao.machado@novabase.pt PALAVRAS CHAVE Spatial Information

Leia mais

Gestão dinâmica de capacidade produtiva para garantia de prazos de encomenda

Gestão dinâmica de capacidade produtiva para garantia de prazos de encomenda Gestão dinâmica de capacidade produtiva para garantia de prazos de encomenda Abstract Ricardo João Costa Almeida (1), Américo Lopes Azevedo (2) (1) Universidade de Aveiro, Aveiro, Portugal almeida.ricardo@gmail.com

Leia mais

4. Aplicações de Software

4. Aplicações de Software 1. Introdução 2. Sistemas de Fabrico 3. Actividades na Gestão do Processo Produtivo 4. Aplicações de Software 5. e-manufacturing 6. Conclusões Eduardo Tovar, Novembro 2002 20 Aplicações de Software (1)

Leia mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

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

Leia mais

Avaliação do valor educativo de um software de elaboração de partituras: um estudo de caso com o programa Finale no 1º ciclo

Avaliação do valor educativo de um software de elaboração de partituras: um estudo de caso com o programa Finale no 1º ciclo Aqui são apresentadas as conclusões finais deste estudo, as suas limitações, bem como algumas recomendações sobre o ensino/aprendizagem da Expressão/Educação Musical com o programa Finale. Estas recomendações

Leia mais

ECTS Total Horas de contacto semestral 4 T TP PL TC S E OT 6 60 10 20 30. Jorge Miguel Calha Rainho Machado/jmachado@estgp.pt

ECTS Total Horas de contacto semestral 4 T TP PL TC S E OT 6 60 10 20 30. Jorge Miguel Calha Rainho Machado/jmachado@estgp.pt Ano Lectivo 2008/09 Curso Engenharia Informática Unidade Curricular Arquitecturas Tecnológicas dos Sistemas de Informação (6º Semestre) Objectivos gerais da Unidade Curricular 1 O objectivo desta unidade

Leia mais

SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI

SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 10 Índice 1 Introdução...

Leia mais

AS AUDITORIAS INTERNAS

AS AUDITORIAS INTERNAS AS AUDITORIAS INTERNAS Objectivos Gerais Reconhecer o papel das auditorias internas Objectivos Específicos Reconhecer os diferentes tipos de Auditorias Identificar os intervenientes Auditor e Auditado

Leia mais

Otimização dos processos de integração de sistemas de informação por meio de barramento de serviços

Otimização dos processos de integração de sistemas de informação por meio de barramento de serviços Otimização dos processos de integração de sistemas de informação por meio de barramento de serviços Celly de Siqueira Martins, André Lara Temple de Antonio Diretoria de Soluções em Billing Fundação CPqD

Leia mais

Manual do Utilizador Aluno

Manual do Utilizador Aluno Manual do Utilizador Aluno Escola Virtual Morada: Rua da Restauração, 365 4099-023 Porto PORTUGAL Serviço de Apoio ao Cliente: Telefone: (+351) 707 50 52 02 Fax: (+351) 22 608 83 65 Serviço Comercial:

Leia mais

COMISSÃO NACIONAL DE PROTECÇÃO DE DADOS. As dinâmicas de grupo e os perfis de consumo

COMISSÃO NACIONAL DE PROTECÇÃO DE DADOS. As dinâmicas de grupo e os perfis de consumo COMISSÃO NACIONAL DE PROTECÇÃO DE DADOS As dinâmicas de grupo e os perfis de consumo O uso de perfis na empresa Os perfis são conjuntos de dados que caracterizam categorias de indivíduos destinados a serem

Leia mais

GESTÃO. Gestão dos Processos e Operações Gestão de Sistemas e Tecnologias de Informação (dentro do capítulo 6) CLF

GESTÃO. Gestão dos Processos e Operações Gestão de Sistemas e Tecnologias de Informação (dentro do capítulo 6) CLF GESTÃO Gestão dos Processos e Operações Gestão de Sistemas e Tecnologias de Informação (dentro do capítulo 6) Informação e Decisões Gerir envolve tomar muitas e frequentes decisões Para decidir com eficácia

Leia mais

OGFI 2015 Group Project BAI07 Primeiro Relatório

OGFI 2015 Group Project BAI07 Primeiro Relatório Primeiro Relatório 62473 Pedro Vasconcelos 63563 Francisco Ferreira 73440 Filipe Correia 74211 Carolina Ferreirinha 82665 Nkusu Quivuna Sumário Este documento é o primeiro relatório de um projeto de análise

Leia mais

Análise e Concepção de Sistemas de Informação

Análise e Concepção de Sistemas de Informação Análise e Concepção de Sistemas de Informação Projecto Versão 2.0 amazon.com 2005-2006 1. Introdução O presente documento tem como objectivo apresentar o enunciado do projecto de ACSI 2005-2006. O projecto

Leia mais

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

Entrega de Folhas de Férias

Entrega de Folhas de Férias Entrega de Folhas de Férias Guia do Utilizador Versão 4.0 Agosto/ 2014 Índice 1. Introdução 2. Criar/ Validar Folhas de Férias 3. Acesso à funcionalidade 4. Inserir/ Consultar Folhas de Férias 5. Comprovativo

Leia mais

Sistemas de Informação no sector da Construção. João Poças Martins, FEUP/GEQUALTEC, 2011 1

Sistemas de Informação no sector da Construção. João Poças Martins, FEUP/GEQUALTEC, 2011 1 Sistemas de Informação no sector da Construção João Poças Martins, FEUP/GEQUALTEC, 2011 1 Sistemas de Informação no sector da Construção 1. SI na Construção. Introdução 2. ERP 3. BIM 4. Outras aplicações

Leia mais

Inteligência de Gestão de Redes e Serviços (2011/12)

Inteligência de Gestão de Redes e Serviços (2011/12) Departamento de Ciências e Tecnologias da Informação Inteligência de Gestão de Redes e Serviços (2011/12) Laboratório 1 (versão 3.0): Criação de serviços usando Parlay/OSA Notas prévias à realização do

Leia mais

PHC dteamcontrol Externo

PHC dteamcontrol Externo PHC dteamcontrol Externo A gestão remota de projectos e de informação A solução via Internet que permite aos seus Clientes participarem nos projectos em que estão envolvidos, interagindo na optimização

Leia mais

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto.

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto. Departamento de Engenharia Informática Modelação, Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto Test O Matic 10 de Maio de 2009 1 Índice 1 Índice... 1 2 Sumário...

Leia mais

5.7.6 Internet/Intranet 176 5.7.7 Gestão logística 177 CAPÍTULO 6. DESENVOLVIMENTO DE SISTEMAS DE WORKFLOW 181 6.1 Métodos de Desenvolvimento 181

5.7.6 Internet/Intranet 176 5.7.7 Gestão logística 177 CAPÍTULO 6. DESENVOLVIMENTO DE SISTEMAS DE WORKFLOW 181 6.1 Métodos de Desenvolvimento 181 SUMÁRIO SUMÁRIO PREFÁCIO AGRADECIMENTOS VII XI XIII INTRODUÇÃO CAPÍTULO 1. ORGANIZAR WORKFLOWS 1 1.1 Ontologia da gestão de workflows 1.2 Trabalho 1 1 1.3 Processos de Negócio 3 1.4 Distribuir e Aceitar

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Desenho de Software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt desenho Desenho (dicionário Priberam on-line) do Lat.! designu s. m., arte de representar

Leia mais

Uma plataforma estratégica

Uma plataforma estratégica Publicado: Fevereiro 2007 Autor: Rui Loureiro Sénior Partner Implementar o Help Desk Quando simplesmente pensamos em implementar um Help Desk, isso pode significar uma solução fácil de realizar ou algo

Leia mais

5.1 Introdução. 5.2 Project Management Institute (PMI)

5.1 Introdução. 5.2 Project Management Institute (PMI) 5 NORMALIZAÇÃO DA GESTÃO DE PROJETOS 5.1 Introdução Embora tradicionalmente o esforço de normalização pertença à International Standards Organization (ISO), no caso da gestão de projetos a iniciativa tem

Leia mais

Mestrado em Segurança da Informação e Direito no Ciberespaço

Mestrado em Segurança da Informação e Direito no Ciberespaço Escola Naval Mestrado em Segurança da Informação e Direito no Ciberespaço Segurança da informação nas organizações Supervisão das Politicas de Segurança Computação em nuvem Fernando Correia Capitão-de-fragata

Leia mais

SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft

SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft SIBS PROCESSOS cria solução de factura electrónica com tecnologias Microsoft A solução MB DOX oferece uma vantagem competitiva às empresas, com a redução do custo de operação, e dá um impulso à factura

Leia mais

NCE/10/01786 Decisão de apresentação de pronúncia - Novo ciclo de estudos

NCE/10/01786 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/10/01786 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/10/01786 Decisão de apresentação de pronúncia - Novo ciclo de estudos Decisão de Apresentação de Pronúncia ao Relatório da

Leia mais

NOTIFICAÇÃO DE NEGÓCIO

NOTIFICAÇÃO DE NEGÓCIO NOTIFICAÇÃO DE NEGÓCIO O Microsoft Business Solutions for Supply Chain Management Navision Business Notification ajudao a gerir a sua empresa mais facilmente e eficazmente. Pode identificar qualquer problema

Leia mais

Relatório Técnico do projecto ARIADNE. Interface de utilizador do NewsSearch

Relatório Técnico do projecto ARIADNE. Interface de utilizador do NewsSearch Relatório Técnico do projecto ARIADNE Praxis XXI Interface de utilizador do NewsSearch Carlos Correia Norman Noronha Daniel Gomes Junho de 2000 Índice 1. INTRODUÇÃO...3 1.1 MOTIVAÇÃO...3 1.2 PROPOSTO...3

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Gestão dos Níveis de Serviço

Gestão dos Níveis de Serviço A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento

Leia mais

EasyNews, um projecto!

EasyNews, um projecto! EasyNews, um projecto! >Francisco Vitor Gomes Salvador Capitão Art Introdução O presente artigo foi elaborado com o intuito de dar a conhecer o trabalho desenvolvido no âmbito da Unidade Curricular de

Leia mais

Sistemas Distribuídos e Paralelos

Sistemas Distribuídos e Paralelos Sistemas Distribuídos e Paralelos Web Services Ricardo Mendão Silva Universidade Autónoma de Lisboa r.m.silva@ieee.org November 29, 2014 Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November

Leia mais

Cadeira de Tecnologias de Informação. Conceitos fundamentais de sistemas e tecnologias de informação e de gestão do conhecimento.

Cadeira de Tecnologias de Informação. Conceitos fundamentais de sistemas e tecnologias de informação e de gestão do conhecimento. Cadeira de Tecnologias de Informação Ano lectivo 2007/08 Conceitos fundamentais de sistemas e tecnologias de informação e de gestão do conhecimento. Prof. Mário Caldeira Profª Ana Lucas Dr. Fernando Naves

Leia mais

Especificações de oferta Monitorização da infra-estrutura remota

Especificações de oferta Monitorização da infra-estrutura remota Descrição dos serviços Especificações de oferta Monitorização da infra-estrutura remota Este serviço oferece serviços de Monitorização da infra-estrutura remota Dell (RIM, o Serviço ou Serviços ) conforme

Leia mais

Integração Orientada a Serviços

Integração Orientada a Serviços Integração Orientada a Serviços Porto Alegre, Agosto de 2006 Agenda Sobre a e-core SOA O que é? Web Services x SOA Principal Motivação - Integração SOI ESB BPEL JBI ServiceMix Solução Proposta A Empresa

Leia mais

A Gestão de Configurações suporte dos Sistemas de Informação

A Gestão de Configurações suporte dos Sistemas de Informação A Gestão de Configurações suporte dos Sistemas de Informação O funcionamento dos sistemas e tecnologias de informação e comunicação têm nas organizações um papel cada vez mais crítico na medida em que

Leia mais

Laboratório de Sistemas e Redes. Nota sobre a Utilização do Laboratório

Laboratório de Sistemas e Redes. Nota sobre a Utilização do Laboratório Nota sobre a Utilização do Laboratório 1. Introdução O laboratório de Sistemas e Redes foi criado com o objectivo de fornecer um complemento prático de qualidade ao ensino das cadeiras do ramo Sistemas

Leia mais

Engenharia de Software Sistemas Distribuídos

Engenharia de Software Sistemas Distribuídos Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 FEARSe Requisitos para a 1 a entrega 18 de Março de 2010 1 Introdução O projecto conjunto das disciplinas de Engenharia de Software

Leia mais

Sistemas Multimédia. Arquitectura Protocolar Simples Modelo OSI TCP/IP. Francisco Maia famaia@gmail.com. Redes e Comunicações

Sistemas Multimédia. Arquitectura Protocolar Simples Modelo OSI TCP/IP. Francisco Maia famaia@gmail.com. Redes e Comunicações Sistemas Multimédia Arquitectura Protocolar Simples Modelo OSI TCP/IP Redes e Comunicações Francisco Maia famaia@gmail.com Já estudado... Motivação Breve História Conceitos Básicos Tipos de Redes Componentes

Leia mais

BusinessRX para Consultores ou Diretores Financeiros

BusinessRX para Consultores ou Diretores Financeiros Business Report expert BusinessRX para Consultores ou Diretores Financeiros Descubra como obter sucesso com o BusinessRX e a modelação de mapas de gestão inteligentes e interativos, que podem ajudá-lo

Leia mais

Desenvolvimento de Sistemas de Software

Desenvolvimento de Sistemas de Software Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/10 João Fernandes, João Gonçalves, José Pereira,

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

Análise e Modelação de Sistemas

Análise e Modelação de Sistemas Análise e Modelação de Sistemas Projeto P3 Campus Alameda Instituto Superior Técnico Universidade de Lisboa Grupo 62 67371 Bruno Oliveira 33 horas 70916 Francisco Maria Calisto 33 horas 76497 João Pedro

Leia mais

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação

A versão básica disponibiliza a informação criada no Microsoft Navision em unidades de informação O Business Analytics for Microsoft Business Solutions Navision ajuda-o a ter maior controlo do seu negócio, tomar rapidamente melhores decisões e equipar os seus funcionários para que estes possam contribuir

Leia mais

Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços

Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços Luan Lima 1, Ricardo Diniz Sul 1,2, Leonardo Guerreiro Azevedo 1,2,3 1 Departamento de Informática Aplicada (DIA) Universidade

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Capítulo 1 Introdução Material de suporte às aulas de Sistemas Distribuídos de Nuno Preguiça Copyright DI FCT/ UNL / 1 NOTA PRÉVIA A apresentação utiliza algumas das figuras do livro

Leia mais

OurDocs. Sistemas Distribuídos Engenharia de Software. Sistema de gestão documental. ic-sod@mega.ist.utl.pt ic-es@mega.ist.utl.pt

OurDocs. Sistemas Distribuídos Engenharia de Software. Sistema de gestão documental. ic-sod@mega.ist.utl.pt ic-es@mega.ist.utl.pt Sistemas Distribuídos Engenharia de Software 2º Semestre, 2006/2007 Departamento Engenharia Informática Enunciado do projecto: OurDocs Sistema de gestão documental ic-sod@mega.ist.utl.pt ic-es@mega.ist.utl.pt

Leia mais

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005 ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos Gestão da Qualidade 2005 Estrutura da Norma 0. Introdução 1. Campo de Aplicação 2. Referência Normativa 3. Termos e Definições 4. Sistema de Gestão

Leia mais

UNIVERSIDADE CATÓLICA PORTUGUESA DSI

UNIVERSIDADE CATÓLICA PORTUGUESA DSI UNIVERSIDADE CATÓLICA PORTUGUESA DSI Gestor de Listas de Distribuição de Emails versão: 0.9.1 Nelson Rodrigues DSI 20-07-2010 ÍNDICE: Introdução... 3 Definição de Mailing List... 3 Grupos de endereços

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Soluções de Gestão Integradas SENDYS ERP. Otimize a Gestão do Seu Negócio!

Soluções de Gestão Integradas SENDYS ERP. Otimize a Gestão do Seu Negócio! Soluções de Gestão Integradas SENDYS ERP Otimize a Gestão do Seu Negócio! Universo da Solução de Gestão SENDYS ERP SENDYS - Copyright 2007 SENDYS é uma marca proprietária da Readsystem, Lda. 2 Universo

Leia mais

SOA 2.0 ou Event-Driven SOA

SOA 2.0 ou Event-Driven SOA SOA SOA 2.0 ou Event-Driven SOA 1 Introdução Recentemente, a Oracle anuciou o termo SOA 2.0. E já deu para imaginar a repercussão que isto teve. Estamos em um momento onde SOA (Service-Oriented Architecture),

Leia mais

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

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

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projetos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais