RELATÓRIO DE PROJECTO sobre WEB APPLICATIONS realizado

RELATÓRIO DE PROJECTO

sobre

WEB APPLICATIONS

realizado na

LINK CONSULTING

por

Bruno Manuel Duarte Bento

Faculdade de Ciências - Universidade de Lisboa DEPARTAMENTO DE INFORMÁTICA

Bloco C6 - Piso 3 - Campo Grande, 1749-016 Lisboa Tel & Fax: 351.217500084

Universidade de Lisboa

Faculdade de Ciências

RELATÓRIO DE PROJECTO

sobre

WEB APPLICATIONS

realizado na

LINK CONSULTING

por

Bruno Manuel Duarte Bento

Responsável pela FCUL: Eng. Pedro Antunes

Responsável pela LINK CONSULTING : Eng. José Afonso Pires

Lisboa, Junho de 2005

Faculdade de Ciências - Universidade de Lisboa DEPARTAMENTO DE INFORMÁTICA

Bloco C6 - Piso 3 - Campo Grande, 1749-016 Lisboa

Tel & Fax: 351.217500084

Agradecimentos

Agora que este estágio se encontra concluído, gostaria de deixar algumas palavras de

agradecimento às pessoas que tornaram a sua realização possível.

Em primeiro lugar, gostaria de agradecer o acompanhamento dado pelo coordenador do

projecto Engº João Assunção, pelo Director da Unidade de Portais & Intranets, Engº José

Afonso Pires e pelo Professor da Faculdade de Ciências da Universidade de Lisboa,

Pedro Antunes, que tiveram a disponibilidade para rever e dar opiniões sobre o

documento. Sem eles, o texto teria muitas mais gralhas do que certamente possui.

Gostaria de agradecer aos meus colegas de trabalho deste projecto e também, de um

modo geral, a todos os colegas da Unidade de Portais & Intranets, de entre os quais

destaco a Drª Cintia Cardoso, o Engº Paulo Monteiro e o Engº Paulo Mateus que

contribuíram significativamente para os conhecimentos que hoje possuo.

Finalmente, à minha família, um enorme pedido de desculpas por estar tão ausente e não

passar, nem de perto nem de longe, o tempo suficiente com eles. É devido a eles que posso

ser quem sou e a quem tudo devo.

Lisboa, Junho de 2005

Bruno Bento

Indíce

Relatório do Projecto em Engenharia Informática Página 4 de 62

1 INTRODUÇÃO .....................................................................................................................6

1.1 APRESENTAÇÃO DO PROJECTO ............................................................................................... 7 1.2 INSTITUIÇÃO LINK ................................................................................................................. 7 1.3 ESTRUTURA DO RELATÓRIO.................................................................................................... 9 1.4 RESUMO DO TRABALHO REALIZADO ...................................................................................... 9

2 OBJECTIVOS DO PROJECTO E CONTEXTO DO TRABALHO .............................10

2.1 OBJECTIVOS DO PRÉ-PROJECTO ........................................................................................... 11 2.2 OBJECTIVOS DO PROJECTO ................................................................................................... 11 2.3 PLANO INICIAL DO PROJECTO............................................................................................... 12 2.4 CONTEXTO DO TRABALHO..................................................................................................... 13

3 METODOLOGIA E CALENDARIZAÇÃO DO TRABALHO......................................16

3.1 METODOLOGIA DE GESTÃO DE PROJECTOS ......................................................................... 17 3.2 MODELO DE DESENVOLVIMENTO ......................................................................................... 17 3.2.1 FASE DE VISÃO..................................................................................................................... 18 3.2.2 FASE DE CONCEPÇÃO........................................................................................................... 18 3.2.3 FASE DE IMPLEMENTAÇÃO................................................................................................... 19 3.2.4 FASE DE TRANSIÇÃO............................................................................................................ 19 3.2.5 FASE DE OPERAÇÃO............................................................................................................. 20 3.3 ANÁLISE DO RISCO ................................................................................................................. 20 3.3.1 IDENTIFICAÇÃO DOS RISCOS................................................................................................ 21 3.3.2 GESTÃO DOS RISCOS............................................................................................................ 21 3.4 RECURSOS............................................................................................................................... 22 3.4.1 ORGANIZAÇÃO E CONTROLO DO PROJECTO ........................................................................ 23 3.4.2 RECURSOS DE HARDWARE..................................................................................................... 25 3.4.3 RECURSOS DE SOFTWARE...................................................................................................... 25 3.5 CALENDARIZAÇÃO FINAL DO TRABALHO............................................................................. 27

4 TRABALHO REALIZADO ...............................................................................................28

4.1 TRABALHO REALIZADO NO PRÉ-PROJECTO ......................................................................... 29 4.1.1 NA SONAE MCH .................................................................................................................. 29 4.1.2 NO PEP ................................................................................................................................ 30 4.1.3 NO EBANKA ......................................................................................................................... 30 4.2 TRABALHO REALIZADO NO PROJECTO................................................................................. 32 4.2.1 ARQUITECTURA TECNOLÓGICA ........................................................................................... 32 4.2.2 .NET FRAMEWORK E LINGUAGEM C# .................................................................................... 33 4.2.3 ARQUITECTURA FÍSICA ........................................................................................................ 36 4.2.4 ARQUITECTURA LÓGICA ...................................................................................................... 36 4.2.5 PLANO DE TESTES................................................................................................................. 47 4.2.6 TRABALHO REALIZADO POR MIM......................................................................................... 48

5 SUMÁRIO E CONCLUSÕES............................................................................................49

5.1 SUMÁRIO................................................................................................................................. 50

Indíce


5.2 CONCLUSÕES.......................................................................................................................... 50

6 GLOSSÁRIO .......................................................................................................................51

7 BIBLIOGRAFIA E REFERÊNCIAS................................................................................53

7.1 ENDEREÇOS WEB .................................................................................................................... 54 7.2 LIVROS E DOCUMENTOS ........................................................................................................ 54

8 ANEXOS ..............................................................................................................................56

8.1 ANEXO I – MODELO DE DADOS .............................................................................................. 57 8.2 ANEXO II – FIGURAS .............................................................................................................. 58


1 INTRODUÇÃO

Introdução


Este documento relata o estágio efectuado por mim, aluno da Licenciatura em

Informática da Faculdade de Ciências da Universidade de Lisboa, na empresa link consulting (LINK).

Neste capítulo faço a apresentação do estágio, uma descrição da estrutura do relatório e uma pequena apresentação daquilo que fiz durante o estágio.

1.1 APRESENTAÇÃO DO PROJECTO

Este projecto visa a integração de alunos da FCUL, que tenham concluído os primeiros quatro anos da Licenciatura em Informática, numa empresa do país, com o objectivo de aí efectuar um Projecto em Engenharia Informática do Curso de especialização profissional em Engenharia da FCUL.

A LINK foi uma das empresas que solicitou um estágio à FCUL no qual fui integrado. O estágio desenrolou-se na Unidade de Portais & Intranets (UPI), durante um período de 9 meses, desde 1 de Setembro de 2004 a 31 de Maio de 2005.

O projecto em causa é para o cliente Sistema Mutimunicipal do rio Lis do Saneamento Integrado (SIMLIS), que pretende que seja construído um Sistema de Informação com o objectivo de fazer a gestão de todo o seu processo de negócio.

O SIMLIS é uma empresa concessionária do Sistema Multimunicipal de Saneamento do Lis com vista à recolha, tratamento e rejeição de efluentes dos municípios de Batalha, Leiria, Marinha Grande, Ourém e Porto de Mós.

Um projecto de execução SIMLIS pode ser encontrado na Internet em http://www.iambiente.pt/IPAMB_DPP/docs/SE131.pdf .

1.2 INSTITUIÇÃO LINK

Como já foi dito o estágio desenrolou-se na LINK, nomeadamente na UPI. Importa referir, de forma resumida, a origem e quais as funções da LINK.

A LINK está situada na Av. Duque D’Ávila, 23, em Lisboa. Esta empresa teve

origem na transformação em estrutura empresarial dos Centros de Transferência de Tecnologia do INESC da área de Informática e Computadores. Estes Centros tinham sido criados em 1991 com base num contrato estabelecido com o PEDIP, no âmbito dos Programas PEDIP. No espírito original do contrato com o PEDIP existia o objectivo de que as actividades dos Centros de Transferência de Tecnologia viessem a ser totalmente suportadas por mecanismos de mercado. Dado ser essa a situação dos Centros da área de Informática e Computadores, no contexto da reorganização das actividades do INESC, decidiram os respectivos sócios efectuar o “spin-off” destas actividades numa única empresa, que veio a dar origem à LINK, cujo propósito foi procurar desenvolver este património técnico.

A LINK, criada em 1999, é uma empresa de consultoria e serviços que intervém nas áreas de consultoria, desenvolvimento e operacionalização de modelos de negócio electrónico e em consultoria e desenvolvimento de infra-estruturas de Telecomunicações, bem como soluções de Comunicações móveis e de Portais de Voz e WAP.

A LINK tem como “Missão” tornar os clientes líderes no alinhamento, integração, eficácia e segurança dos seus processos com as Tecnologias de Informação, através da sua

Introdução


experiência, competência e continua inovação em consultoria e engenharia de sistemas de informação. E como “Visão” ser reconhecida entre as melhores empresas de consultoria e engenharia no sector das Tecnologias de Informação no país; procurada pelos clientes que têm problemas complexos, pelos profissionais que aspiram a grandes desafios e pelos investidores que pretendem um investimento sólido. Os principais clientes são os seguintes:

Figura 1 – Principais clientes da LINK.

A LINK também aposta na penetração de novos mercados.

Figura 2 – Novos mercados onde a LINK aposta.

Introdução


1.3 ESTRUTURA DO RELATÓRIO

O primeiro capítulo é constituído pela a Introdução, onde é apresentado o estágio, a apresentação da instituição onde decorreu, a estrutura do relatório e um resumo do trabalho realizado;

O segundo capítulo apresenta os Objectivos do Projecto e o plano inicial que foi elaborado para se atingir os mesmos. Adicionalmente desenvolve o Contexto de Trabalho do Projecto, tratando-se no essencial de uma introdução técnica ao tema;

No terceiro capítulo é relatada a Metodologia de Trabalho usada no desenvolvimento do mesmo e a respectiva Calendarização;

O quarto capítulo apresenta o Trabalho Realizado em fase de pré-projecto, do qual resultou na integração em equipas de projecto e liberdade de autonomia, e na fase de projecto, documentando aquilo que foi feito e quais as ferramentas utilizadas. Apresenta as várias abordagens estudadas para atingir os objectivos definidos e detalha aquela que foi escolhida. Refere também qual a minha colaboração concreta no projecto;

O quinto capítulo apresenta um Sumário daquilo que foi feito e adicionalmente relata a Conclusão do Relatório;

Por fim, são apresentados o Glossário, a Bibliografia e os Anexos usados.

1.4 RESUMO DO TRABALHO REALIZADO

De uma forma breve e sucinta, podemos dividir o estágio em duas fases. Na primeira, com a duração de cerca de 2 meses, para autoformação (com acompanhamento) em novas tecnologias e integração em equipas de projectos para a realização de pequenas tarefas. E a segunda, para a construção da aplicação para gestão de todo o processo de negócio do SIMLIS.

Por fim, o último mês de estágio, foi passado a realizar um relatório sobre todo o trabalho efectuado no período de estágio.


2 OBJECTIVOS DO

PROJECTO E

CONTEXTO DO

TRABALHO

Objectivos do Projecto e Contexto do Trabalho


2.1 OBJECTIVOS DO PRÉ-PROJECTO

Esta secção encarrega-se de apresentar os objectivos da fase de pré-projecto de uma forma resumida.

Os objectivos focaram com aspectos tecnológicos bem como os relativos a questões de metodologia de trabalho.

Do mencionado anteriormente destacam-se:

Aprendizagem da plataforma .Net, em particular dos WebServices;

Desenvolvimento de competências de programação;

Interiorizar a metodologia de desenvolvimento de projectos. Em termos da integração na equipa de projecto, foram definidos os seguintes

objectivos:

Análise de documentos de requisitos a fim de alcançar o desenvolvimento de componentes;

Autonomia na realização de tarefas de desenvolvimento;

Realização de testes unitários aos componentes desenvolvidos;

Elaboração do manual do utilizador.

2.2 OBJECTIVOS DO PROJECTO

Nesta secção serão descritos os objectivos da fase de projecto. Sabe-se que o objectivo principal é o resultado prático do projecto, ou seja, uma aplicação informática útil para o SIMLIS e que siga as especificações efectuadas e aprovadas.

Contudo, é importante mencionar outros objectivos que estiveram sempre presentes

e que são:

A integração numa equipa de projecto;

Contacto com a documentação funcional e técnica;

Aprofundamento da capacidade de redacção de relatórios;

Adquirir experiência profissional.

De seguida será efectuada a descrição, de uma forma mais pormenorizada, os principais objectivos deste projecto, no que toca ao aplicativo a implementar.

Actualmente os colaboradores do SIMLIS têm a necessidade de aceder a diversa

informação díspar e não relacionada, contida nos imensos volumes de processos existentes.



Por vezes alguns processos podem estar entregues a uma entidade externa por um determinado período de tempo, tornando impossível a sua consulta e mesmo tornando difícil o controlo dos prazos estipulados. Por outro lado, os processos que se encontram no SIMLIS nem sempre se encontram à disposição e em bom estado de conservação ou não se sabe onde estão armazenados, demorando por vezes muito tempo até que se encontrem. Estes problemas são facilmente ultrapassados, com a ajuda de uma Base de Dados Relacional e uma aplicação para gerir a mesma.

A solução apresentada tem como objectivo reduzir a circulação do volume de papel

em que assentam os processos, diminuir o tempo de apreciação dos processos de constituição de expropriação e ter um registo sobre os contactos efectuados, registo da documentação e controlo de pagamentos, e que sirva de apoio à decisão com base em toda a informação e historial que a Base de Dados disponibiliza.

No que toca a aspectos técnicos, a interface da aplicação perante o utilizador é

baseada em HTML produzido por ASP.NET. A partir das páginas ASP.NET pode-se aceder a toda a informação armazenada na Base de Dados (SQL Server 2000 SP2 com Reporting Services), bem como efectuar a gestão dos dados.

Uma das grandes vantagens de se ter utilizado documentos ASP.NET no sistema

WWW é que permite o acesso à informação através de diversos locais e podendo eventualmente aceder com diversos dispositivos. Deste modo, os utilizadores podem aceder à informação a partir de qualquer PC instalado no interior do SIMLIS ou através de um PC externo com ligação à Intranet (caso sejam cumpridos todos os requisitos em termos de configuração de rede e segurança).

Com este sistema a SIMLIS pretende atingir os seguintes resultados:

Importar a informação contida em Excel para um repositório único;

Registar, Pesquisar e Consultar informação relativa a Parcelas e Interessados;

Registar e controlar os pagamentos a titulo de indemnização e compensatórios efectuados aos proprietários;

Registar a obtenção de licenças RAN, REN, DH;

Este projecto foi elaborado por uma equipa de consultores. No capítulo 4.2.6, são apresentadas as funcionalidades implementadas por mim durante o projecto. As funcionalidades a implementar no futuro são descritas no capítulo 5.1.

2.3 PLANO INICIAL DO PROJECTO

O planeamento de um projecto é algo bastante importante e que nos dá uma perspectiva do tempo necessário, recursos e riscos envolvidos na elaboração do mesmo. O plano do projecto é algo que será actualizado ao longo do tempo.

O modelo de desenvolvimento da aplicação é constituído por diversas fases que serão abordadas com maior detalhe no capítulo 3.2.



Figura 3 – Calendarização Inicial

A Calendarização apresentada anteriormente trata-se da Calendarização Inicial

proposta pela equipa LINK tendo em conta os requisitos e envolvimento da equipa do cliente.

No capítulo 3.5 é apresentada a Calendarização Final, que corresponde ao verdadeiro tempo despendido no projecto.

2.4 CONTEXTO DO TRABALHO

Em termos de localização, o projecto desenrolou-se na UPI (instalações da LINK) e por fim é instalado nas instalações do cliente SIMLIS em Leiria.

Ao longo deste capitulo, vou desenvolver o principal objecto de trabalho, Servidões

e Expropriações, sobre o qual incidiu o trabalho. Dizer que o processo de Expropriação consiste na aquisição de uma propriedade

privada mediante o pagamento de uma indemnização e o processo de Servidão consiste na autorização de passagem de tubagens pelo terreno de outrem, é algo demasiado vago. É preciso referir todas as entidades que são envolvidas e como funcionam.

ID Task Name

1 SMLS_04_02692 Gestão do Projecto3 Planeamento4 Start Up5 Controlo6 Encerramento7 Desenho e Concepção8 Levantamento das Interfaces Aplicacionais9 Elaboração da Arquitectura de Informação

10 Arquitectura de Informação Aprovada11 Especificação de Requisitos Funcionais12 Especificação de Requisitos Funcionais Aprovada13 Elaboração do Guião Interactivo14 Guião Interactivo Aprovado15 Concepção do Design Gráfico16 Design Gráfico Aprovado17 Desenho dos Ambientes e Sistemas18 Desenho dos Ambientes e Sistemas Aprovado19 Especificação de Testes de Aceitação20 Desenho Técnico21 Desenvolvimento22 Desenvolvimento e Parametrização33 Importação de dados34 Fim do Desenvolvimento35 Testes de Integração36 Transição37 Infra Estrutura38 Documentação39 Formação40 Testes de Aceitação41 Correcções42 Entrada em Produção

11-2401-2701-28

11-26

12-02

12-03

12-07

12-09

01-10

01-27

22 29 06 13 20 27 03 10 17 24 31 07'04 Dec '05 Jan '05 Feb



De seguida irei descrever, detalhadamente, o propósito de cada um dos tipos de entidades envolvidas e como funcionam.

Subsistema é um conjunto de todas as infra-estruturas com unidades finais de tratamento (bastar ter uma ETAR para já ser um subsistema, no entanto, poderá ainda ser constituído por Estações Elevatórias, ETAR e Emissários), do sistema de saneamento da área de intervenção do SIMLIS.

Projecto é uma empreitada de execução de determinadas infra-estruturas dos diversos subsistemas. Um mesmo projecto poderá envolver obras em diversos subsistemas.

Infra-estrutura responsável pelo transporte efluente. Uma infra-estrutura pertence a um único subsistema e projecto e pode ser construída em várias parcelas.

Parcela representa uma área de terreno necessário para a implantação da infra-estrutura. Numa parcela é construída somente uma infra-estrutura e pode ser possuída por vários interessados. Se não existir acordo para a utilização da parcela com pelo menos um dos interessados então a parcela encontra-se em litígio.

Confrontações consiste na identificação de objectos/terrenos que confinam com a parcela.

Litigio é o conjunto dos processos legais para a entrada no terreno e registo da servidão no caso de não existir acordo. O processo de litígio é único por parcela e é decomposto em dois processos sequencias, Vistoria e Arbitragem, que pode ser resolvido a qualquer altura.

Vistoria é a identificação de todas as características da parcela por um perito nomeado pelo tribunal. Se após este processo se mantiver o litígio então será despoleta a arbitragem.

Arbitragem é a avaliação da parcela por um perito nomeado pelo tribunal, onde o perito vai avaliar a parcela e emitir o relatório a enviar para o tribunal, para o SIMLIS e para os proprietários. Após este processo o valor de indemnização será estabelecido pelo tribunal. O processo de litígio é concluído sem no entanto se ter chegado a acordo com os interessados.

DUP é a Declaração de Utilidade Pública emitida pelo Ministério do Ambiente. Para este processo é necessário juntar determinados documentos dos quais vão ficar registados os seguintes:

o Licenças de RAN e REN no caso de existir alguma parcela com estas naturezas;

o Publicação dos Editais;

o Garantias Bancárias;

o Primeira notificação aos interessados das parcelas que não têm acordo.



A DUP é pedida para cada infra-estrutura com parcelas sem acordo e todos os interessados dessas parcelas notificados. Após a obtenção de DUP, é associada às parcelas, da infra-estrutura, que ainda não tenham DUP definida, a identificação da DUP obtida.

Interessados são todas as entidades envolvidas na parcela (proprietário, arrendatário, procuradores e outros utilizadores) . Um interessado só existe no contexto de uma parcela. A mesma entidade se associada a mais de uma parcela, é tratada como sendo interessados diferentes. Um interessado pode ser contactado pelo SIMLIS várias vezes.

Contacto identifica uma comunicação entre o SIMLIS e um interessado. Um contacto somente é efectuado a um interessado, se uma mesma carta for enviada a múltiplos interessados de uma parcela, resulta em vários contactos efectuados. Cada contacto contem as referências dos documentos enviados ao interessado. Um contacto pode ter mais do que um documento enviado.

Pagamento identifica um pagamento efectuado pelo SIMLIS no âmbito de obtenção de contracto de servidão para uma parcela. Um pagamento somente é efectuado para uma parcela. Cada pagamento contem referências dos documentos associados ao pagamento. Um pagamento pode ter mais do que um documento associado. Pagamentos com valores negativos são recebimentos.

Pedido Pagamento é o conjunto de todos os documentos que comprovam a ocorrência das despesas elegíveis das respectivas candidaturas aos fundos comunitários e que permitem receber os respectivos subsídios. Um pedido pagamento é o conjunto de todas as despesas.

Despesa é o conjunto de todos os documentos que comprovam a ocorrência das despesas elegíveis por parcela e tipo de pagamento. Uma despesa é associada a um pedido de pagamento. Para um mesmo pedido de pagamento e parcela uma despesa de uma dado tipo é única.

Correspondência é a entidade que representa um contacto de correspondência do SIMLIS. Correspondência é de entrada, do exterior para o SIMLIS. Correspondência é de saída, do SIMLIS para o exterior identificada por nº de ordem interno indexado ao ano. Correspondência é sempre dirigida a um destinatário.

Referência Documento identifica a referência para um documento físico arquivado. Várias entidades contêm referências a documentos nomeadamente:

o Parcela – documentos associados a uma parcela;

o Pedido DUP – documentos manipulados no âmbito de um pedido DUP;

o Contacto – notificações, documentos enviados a interessados de parcelas;

o Pagamento – documentos associados a pagamentos.


3 METODOLOGIA E

CALENDARIZAÇÃO DO

TRABALHO

Metodologia e Calendarização do Trabalho


3.1 METODOLOGIA DE GESTÃO DE PROJECTOS

A LINK, consciente da importância da gestão dos seus projectos, engloba na sua estrutura organizacional uma área designada por Project Support Office (PSO). O PSO tem como missão garantir a qualidade da gestão dos projectos LINK, desenvolveu uma metodologia para esse efeito e tem vindo a desenvolver sistemas de informação de suporte à mesma.

O modelo de gestão de projectos da LINK, encontra-se representado na Figura 4 -

Metodologia de Gestão de Projectos da LINK, no anexo II - Figuras. Este modelo resulta da adaptação do modelo seguido pelo Project Management Institute (PMI) e é aplicável a qualquer tipo de projecto, independente da tecnologia envolvida.

Podemos observar que o modelo divide-se em cinco macro-processos que respeitam

ao arranque do projecto, ao planeamento, execução, controlo e encerramento do projecto. Entre os processos de execução e de controlo verifica-se um ciclo que só é

quebrado quando estão criadas as condições, de acordo com o plano de projecto, para se passar ao processo de encerramento, ou quando é assegurada pelos fluxos de reporting de progresso da execução dos trabalhos, dos quais é obtido feedback que se poderá traduzir na aprovação dos trabalhos executados ou em pedidos de correcção.

Cada um dos macro-processos acima referenciados encontra-se detalhado no

documento de referência da Link Consulting (2004) - “Metodologia de Gestão de Projectos”, que não está disponível*.

3.2 MODELO DE DESENVOLVIMENTO

O desenvolvimento de software é um processo complexo, que não deverá ser realizado ao acaso, sendo tomadas decisões apenas quando preciso, ou dependendo totalmente na qualidade das tecnologias disponíveis. Pelo contrário, deve seguir uma metodologia que combine métodos compreensivos para todas as fases do trabalho, ferramentas de desenvolvimento, técnicas para assegurar a qualidade do software e uma filosofia de coordenação, controle e gestão dos recursos disponíveis. Esta metodologia tem como objectivo ajudar ao planeamento das tarefas de cada fase do desenvolvimento, bem como a definição da melhor forma de as realizar.

O modelo de desenvolvimento usado foi o Modelo da LINK que é uma

metodologia iterativa que segue uma instanciação do RUP, aplicável a qualquer tecnologia escolhida. Este modelo é apresentado esquematicamente na Figura 5 - Metodologia de desenvolvimento da LINK, no anexo II - Figuras.

O modelo apresentado processa-se em ciclos, como se pode observar, e cada ciclo

resulta numa nova release da aplicação. Isto processa-se usualmente de acordo com um plano de releases, definido quer devido à necessidade de lançamentos faseados com funcionalidade incremental, quer por ser exigida a construção prévia de protótipos que têm que ser evoluídos para os produtos finais.



A passagem da Fase de Visão para a Fase de Concepção dá-se sempre que há uma

definição de objectivos a desenvolver. A passagem para a Fase de Implementação ocorre no final da fase de desenho. Quando a aplicação está pronta a entrar em operação, inicia-se a fase de Transição, normalmente com uma release beta (também conhecida como piloto), apenas disponível a um conjunto restrito de utilizadores. Esta fase termina com o roll-out (entrega) definitivo da aplicação e a sua disponibilização aos utilizadores em geral. Retoma-se então a fase de Visão, para o desenvolvimento da próxima release da aplicação.

3.2.1 Fase de Visão

A primeira Fase de Visão coincide normalmente com a elaboração da proposta, esta deve assegurar o acordo relativamente aos objectivos a serem desenvolvidos.

É durante a Fase de Visão que se estabelecem as regras de negócio para a aplicação a desenvolver e se define o âmbito do projecto.

Os resultados expectáveis desta fase são apresentados de seguida:

Uma visão genérica dos requisitos fundamentais, características chave e constrangimentos principais da aplicação a desenvolver;

Elaboração de um ou mais protótipos. Alguns dos principais critérios a ter em conta na Fase de Visão são:

A concordância dos vários intervenientes relativamente ao âmbito e estimativas;

A compreensão dos requisitos essenciais, por vezes evidenciada com alguns casos de uso iniciais;

A credibilidade das estimativas, prioridade, riscos e o processo de desenvolvimento.

3.2.2 Fase de Concepção

A Fase de Concepção tem como objectivo a análise e desenho da aplicação. As actividades desta fase asseguram a estabilidade da arquitectura e requisitos e a minimização dos riscos, de forma a ser possível predizer com certeza o esforço necessário para completar o desenvolvimento.

Os principais critérios de avaliação da Fase de Concepção são normalmente os seguintes:

A estabilidade da visão da aplicação;

A estabilidade da arquitectura;

O tratamento e resolução dos maiores riscos técnicos. Genericamente, os resultados da Fase de Concepção são em geral os seguintes:



O modelo de casos de uso e a captura de requisitos suplementares, não funcionais, não associados a um caso de uso especifico;

Levantamento das entidades;

O desenho da interface com o utilizador;

A revisão da lista de riscos e do caso de negócio apresentado na visão; Nesta fase, são produzidos um conjunto de documentos que descrevem o resultado

da análise de concepção da aplicação. A Fase de Concepção termina com as estimativas dos tempos de implementação por

parte da equipa de desenvolvimento. As estimativas por caso de uso devem incluir as fases de análise, desenho, codificação, testes unitários, integração e documentação.

3.2.3 Fase de Implementação

Durante a fase de implementação, todas as componentes e funcionalidades da aplicação são desenvolvidas, integradas numa release e cuidadosamente testadas. O resultado desta fase é “uma aplicação” pronta a ser disponibilizada aos seus utilizadores finais. Este deverá no mínimo compreender os seguintes aspectos:

Estar integrado nas plataformas adequadas;

Ser acompanhado de uma primeira versão dos manuais de utilização e instalação;

O desenho detalhado, conteúdo a descrição de release. Os critérios de avaliação para esta Fase de Implementação são:

A estabilidade e maturidade do desenvolvimento, por forma a ser disponibilizado à comunidade de utilizadores;

Resultados dos testes;

A preparação de todos os intervenientes para a transição da aplicação.

3.2.4 Fase de Transição

O objectivo principal da Fase de Transição é fazer transitar a aplicação para a sua comunidade de utilizadores, ou seja conseguir:

A autonomia dos utilizadores fase ao suporte;

A concorrência dos intervenientes de que a aplicação está consciente com a visão inicial;

Disponibilizar a release final da aplicação, da forma mais rápida e prática.



A Fase de Transição inicia-se sempre que o desenvolvimento se encontra “maduro” o suficiente para ser disponibilizado aos seus utilizadores finais. Isto requer tipicamente que um subconjunto das funcionalidades sejam completadas a um nível aceitável de qualidade, e que a documentação para os utilizadores esteja disponível de forma que a transição forneça resultados positivos a todas as partes.

A Fase de Transição inclui o seguinte:

Testes para validar o sistema relativamente às expectativas dos utilizadores;

Se é o caso, a operação paralela com as aplicações que está substituir;

Se é o caso, conversação de base de dados operacionais;

Formação dos utilizadores e administradores. No final desta fase decide-se se os objectivos da visão foram atingidos e se deve

iniciar outro ciclo de desenvolvimento. Os critérios de avaliação para esta fase centram-se exclusivamente na satisfação dos

seus utilizadores.

3.2.5 Fase de Operação

No caso da metodologia de desenvolvimento de aplicações da LINK, a fase de operação compreende a garantia da aplicação, que assegura apenas a manutenção correctiva dos desenvolvimentos efectuados pela LINK. A garantia exclui os aspectos como os seguintes:

O suporte a anomalias de sistemas externos;

Alterações que resultem de mudanças face aos requisitos especificados nos documentos produzidos na Fase de Concepção;

Testes. Cada uma das fases mencionadas anteriormente encontra-se detalhada no

documento de referência de Assunção, João (2003) - “Metodologia de Desenvolvimento de Aplicações Workflow”, que não se encontra disponível*.

3.3 ANÁLISE DO RISCO

Sempre que somos confrontados com um projecto de desenvolvimento de software, temos que ter em conta a análise do risco relacionada com processo de desenvolvimento.

A análise do risco é constituída por duas actividades, sendo a primeira, a identificação dos riscos inerentes ao projecto em questão, porque nem todos os projectos estão sujeitos aos mesmos riscos, a segunda é a gestão dos riscos identificados na actividade anteriormente, ou seja, é o estudo e escolha de medidas alternativas que permitam minimizar e controlar os riscos.



De seguida são apresentados os que foram mais importantes no projecto e como foram abordados.

3.3.1 Identificação dos Riscos

Os riscos que vamos enfrentar são de três tipos: riscos de projecto, riscos técnicos e riscos de negócio.

Os que mais poderão influenciar o projecto a ser desenvolvido são:

Riscos de projecto

o Interpretação incorrecta dos requisitos do cliente;

o Desenvolver um produto cujo custo final seja muito elevado;

o Atraso na entrega do produto final.

Riscos técnicos

o Interface inapropriada para o tipo de utilizador;

o Impossibilidade de garantir a manutenção do sistema;

o Tecnologia inadequada.

Riscos de negócio

o Falta de formação dos utilizadores;

o Perder o apoio da direcção do SIMLIS;

o Desenvolver um produto que não venha a ser utilizado.

3.3.2 Gestão dos Riscos

Finalmente, são apresentadas as medidas que poderão permitir minimizar e controlar cada um dos riscos indicados.

Riscos do projecto

o Interpretação incorrecta dos requisitos do cliente. O contacto por parte da direcção do SIMLIS com a aplicação que estava a ser desenvolvida permitiu que qualquer erro resultante de má interpretação fosse corrigido de imediato;

o Desenvolver um produto cujo custo final seja muito elevado. No inicio do projecto foram definidos os recursos de hardware e software necessários. Entretanto foi utilizada tecnologia sobre a qual nunca tinha sido usada e como tal não se sabia dar uma estimativa exacta. Contudo foi atribuída uma



tarefa para autoformação na tecnologia em questão tendo em conta os recursos monetários disponíveis;

o Atraso na entrega do produto final. Para evitar este risco foi necessário levar a sério a calendarização do projecto, certificar-se das tarefas já concluídas, preparar adequadamente as restantes e controlar os prazos definidos para a realização de cada uma, de acordo com a calendarização.

Riscos técnicos

o Interface inapropriada para o tipo de utilizador. Quanto a este risco, só quando os utilizadores começarem a utilizar a aplicação é que podemos tirar conclusões. No entanto tentou-se identificar o melhor possível o domínio da aplicação, assim como o grau de conhecimento e objectivos dos utilizadores da aplicação. Também será fornecido um Manual do Utilizador para ajudar os utilizadores na utilização do sistema. Contudo, as aplicações da Web, hoje em dia, têm vindo a ser muito populares daí que se opta-se pela criação de ecrãs da aplicação sob a forma de páginas HTML;

o Impossibilidade de garantir a manutenção do sistema. A melhor maneira de combater este risco foi a criação de documentação, para auxiliar os programadores e informar sobre todos os passos do processo de desenvolvimento de software;

o Tecnologia inadequada. Este risco foi combatido com a escolha das tecnologias mais poderosas que existem actualmente no mercado. No entanto, sabe-se que no futuro aparecerão novas tecnologias mais potentes. Este risco poderá ser superado no futuro com a adaptação da nova tecnologia através do processo de migração.

Riscos de negócio

o Falta de formação dos utilizadores. Este risco é travado com o fornecimento do Manual do Utilizador e através de formação dada pelos responsáveis da LINK aos utilizadores finais;

o Perder o apoio da direcção do SIMLIS. É conveniente manter a direcção informada em relação ao estado do processo de desenvolvimento de software;

o Desenvolver um produto que não venha a ser utilizado. Este risco segue as medidas a serem tomadas no risco da “Interface inapropriada para o tipo de utilizador”.

3.4 RECURSOS

Para que o planeamento efectuado seja cumprido é necessário dispor de recursos humanos, de hardware e de software.



3.4.1 Organização e Controlo do Projecto

3.4.1.1 Organização do Projecto

A Organização do Projecto apresentada tem como objectivo definir os níveis de responsabilidade e decisão, bem como os canais e processos de comunicação, capazes de assegurarem o sucesso do projecto.

Figura 6 – Organização do Projecto O Gestor de Projecto, Engº João Assunção, da LINK tem como responsabilidades:

O planeamento e controlo dos objectivos do projecto, nomeadamente âmbito, tempo, custos, qualidade e organização;

A garantia da correcta identificação e quantificação dos riscos do projecto, bem como o planeamento das acções de resposta aos mesmos;

A constituição e gestão da equipa de projecto e a direcção das reuniões com a equipa de projecto;

O controlo do projecto, comparando a situação actual face ao planeado, identificando desvios e propondo acções correctivas;

A elaboração e distribuição de relatórios periódicos de situação do projecto, assegurando a comunicação com os vários stakeholders. O gestor de projecto do cliente tem como responsabilidades:



Assegurar e coordenar o envolvimento dos elementos da sua organização de acordo com o definido no plano do projecto;

Assegurar, conjuntamente com o gestor de projecto da LINK, o controlo do projecto, especialmente nos componentes definidos sendo da responsabilidade da sua organização;

Colaborar, conjuntamente com o gestor de projecto da LINK, na elaboração dos relatórios de progresso do projecto. O Responsável Técnico, Engº Paulo Mateus, da LINK tem como responsabilidades:

O planeamento e controlo do processo de desenvolvimento de software;

A garantia da qualidade do software desenvolvido;

A decisão sobre as opções tecnológicas que melhor se enquadrem face aos requisitos da solução a desenvolver;

A distribuição da execução das tarefas de garantia de qualidade (especificação de requisitos, especificação de testes) e de controlo de qualidade (testes de unidade; testes de integração, testes de carga e desempenho);

A elaboração e distribuição de relatórios periódicos de progresso do projecto, assegurando a comunicação com a Gestão do Projecto. A Equipa de Consultores, constituída por Engº Paulo Mateus, Engº Carlos Dias e por mim, Bruno Bento, tem como responsabilidades:

A equipa de consultores, coordenada pelo Responsável Técnico na vertente de execução técnica e pelo Gestor de Projecto da LINK na vertente de gestão de recursos humanos, assegurará a execução de todas as actividades de acordo com o planeamento acordado. A Equipa do Cliente tem como responsabilidades:

A Equipa do Cliente, cuja coordenação é da exclusiva responsabilidade do Gestor de Projecto do Cliente, pode contar com Utilizadores Chave, aptos a definirem os requisitos funcionais e de desempenho da solução, bem como de verificarem a conformidade da solução final face aos requisitos.

3.4.1.2 Controlo do Projecto

Para efectuar o Controlo do Projecto foram usados os seguintes procedimentos de comunicação:

Relatórios de controlo de projecto;

Reuniões de controlo de projecto.



Ao longo do Ciclo de Vida do projecto foram produzidos periodicamente relatórios de progresso. Estes relatórios, destinados ao Gestor de Projecto, reflectem a situação de cada componente do projecto relatada pelos coordenadores de cada um dos pacotes de trabalho.

As reuniões de controlo de progresso tiveram uma periodicidade semanal, tendo por

objectivo a revisão dos relatórios de progresso. Evidenciam:

O trabalho concluído desde a última reunião;

O trabalho em curso;

O trabalho em atraso;

O planeamento do trabalho para o próximo período;

3.4.2 Recursos de hardware

Os recursos de hardware utilizados no desenvolvimento da aplicação foram os seguintes:

Máquina servidor de Base de Dados;

Máquina servidor de web;

Máquinas clientes de desenvolvimento.

3.4.3 Recursos de software

O software instalado nestas máquinas para o desenvolvimento da aplicação pretendida é:

Microsoft Visual Source Safe

o O VSS é uma ferramenta de colaboração para programadores de aplicações. Com esta ferramenta é possível dentro da equipa de desenvolvimento, controlar os acessos e versões. A grande vantagem de usar este software e não outro semelhante existente no mercado prende-se com a integração com os produtos Microsoft. Esta ferramenta foi adoptada para controlar o código fonte do projecto.

Concurrent Version System

o O CVS é também uma ferramenta de controlo de versões e acessos de um sistema durante o processo de desenvolvimento. Esta é a ferramenta de eleição na LINK para controlo de versões de documentos. Os documentos em questão são a especificação técnica e funcional, o manual do utilizador e de instalação, entre outros.

Visual Studio 2003



o O VS 2003 é o ambiente de desenvolvimento das aplicações .NET.

.NET Framework

o Trata-se da infra-estrutura básica sobre a qual as aplicações correm.

Microsoft Internet Information Services

o O IIS é um servidor Web da plataforma Microsoft.

Microsoft SQL Server 2000

o O SQL Server é uma base de dados de referência do mercado proporcionando uma base sólida e escalável do sistema.

Microsoft Office Visio 2003

o É uma ferramenta simples e flexível para criar com facilidade gráficos e fluxogramas para entender, visualizar conceitos mais rapidamente e comunicar informações com maior eficiência.

Microsoft Office Word 2003

o Processador de texto escolhido para processar todos os documentos realizados para o projecto.

Internet Explorer v6.0

o Ferramenta utilizada para visualizar as páginas web.

SQL Server Query Analyzer

o Ferramenta que oferece um ambiente extremamente flexível para correr ad hoc queries. Esta ferramenta faz parte do pacote do SQL Server.

SQL Server Enterprise Manager

o Ferramenta que oferece um ambiente para criar e gerir Base de Dados, bem como navegar pelos dados. Esta ferramenta faz parte do pacote do SQL Server.

Microsoft Windows XP Professional Version 2002 Service Pack 2

o Sistema operativo sobre o qual todas as ferramentas mencionadas anteriormente correm.

Os produtos anteriormente seleccionados para a realização do projecto foram

aqueles que têm em conta o valor que trazem para o SIMLIS quer para este projecto quer a médio e longo prazo. Na decisão da escolha do software pesou o SIMLIS ter um contrato com a Microsoft no que toca aos produtos.



3.5 CALENDARIZAÇÃO FINAL DO TRABALHO

Apesar do esforço feito para cumprir à risca a calendarização inicial, é sempre de esperar que aconteçam sempre imprevistos que levem ao atraso das tarefas definidas.

A falta de experiência da minha parte, nomeadamente na resolução de bugs

(problemas), levou a que pontualmente fosse notado algum atraso, que mais tarde foi recuperado com um esforço adicional da minha parte. Este contratempo permitiu que mais tarde o desenvolvimento do código para a aplicação fosse mais rápido.

Sendo considerada informação sensível no que toca à sua divulgação ao exterior, o

plano de projecto final não será aqui exposto.


4 TRABALHO

REALIZADO

Trabalho Realizado

Relatório do Projecto em Engenharia em Informática Página 29 de 62

4.1 TRABALHO REALIZADO NO PRÉ-PROJECTO

Esta secção encarrega-se de relatar o trabalho realizado durante a fase de pré-projecto de uma forma resumida.

Como já foi mencionado no capítulo 2.1, os objectivos do pré-projecto consistiam na adaptação ao trabalho em equipas de trabalho segundo a Organização e Controlo do Projecto, e também no enriquecimento de conhecimentos das novas tecnologias.

De seguida são apresentados os projectos em que estive inserido nesta fase.

4.1.1 Na Sonae MCH

A minha primeira colaboração foi dada no projecto que era para o cliente Sonae Distribuição – Modelo Continente Hipermercados e consistiu num processo de uniformização dos layouts das aplicações WF (WorkFlow). Pretendia-se alterar o design e as cores para corresponder ao conteúdo do Guião Interactivo Genérico que entretanto fora actualizado.

As vantagens deste desenvolvimento são várias:

Restabelecimento de um padrão uniforme de interface para o utilizador, que está de acordo com o grafismo da Worklist Única e da própria NGI (Nova Geração do INSITE). Este ponto é especialmente importante tendo em conta o crescente número de utilizadores deste WF.

Enriquecimento de algumas componentes do WF Bens e Serviços, que permitem no futuro uma maior rapidez na alteração das interfaces.

Melhoria significativa na usabilidade de alguns dos ecrãs que serão alterados.

Adopção de alguns componentes comuns, reduzindo esforço de desenvolvimento.

Na Figura 7 - Exemplo de um ecrã do WF Bens e Serviços, no anexo II - Figuras,

encontra-se um exemplo que ilustra os resultados que se pretendem obter com este desenvolvimento.

A minha participação no projecto foi nas seguintes etapas definidas na metodologia:

Desenvolvimento

o Alterações das Interfaces

o Passagens a Staging (pré-produção)

Transição

o Preparação da Passagem a Produção

Trabalho Realizado


Neste trabalho também tive a oportunidade de aprofundar os meus conhecimentos em folhas de estilo CSS, JavaScript e HTML.

4.1.2 No PEP

Noutra aplicação da Sonae, PEP, “Planeamento de Eventos Promocionais”, o objectivo era desenvolver novas funcionalidades, utilizando a tecnologia VBA em Excel onde pude aprofundar os meus conhecimentos académicos.

O PEP é um sistema de informação, cuja principal base é o sistema Retek, que

permite a gestão centralizada das lojas, com destaque para a gestão de produtos, fornecedores e encomendas.

A Figura 8 - Folha “Definição de Promoções” da aplicação PEP, no anexo II - Figuras, mostra um dos ecrãs da aplicação PEP.

A proposta de desenvolvimento do PEP que me foi pedido para implementar

encontra-se no documento de referência de Monteiro, Paulo (2004) - “Proposta Desenvolvimento: PEP - Desenvolvimento da template v1.18”, o qual não se encontra disponível*.

4.1.3 No eBanka

Terminei a primeira fase do estágio num projecto que se chama eBanka (http://ebanka.promosoft.com/) que é um produto constituído por Home Banking com componente de portal institucional e tem como objectivo responder às necessidades das instituições bancárias que pretendem utilizar a Internet como mais um canal de comunicação com os seus actuais e potenciais clientes. Desta maneira permite que os clientes efectuem operações de transferências internas e externas, consulta de saldos, pedidos de cheques, extravio de cheques, consulta de movimentos, consulta de câmbios, etc.

A figura seguinte mostra o ambiente da aplicação eBanka na sua vertente de Home Banking:

Trabalho Realizado


Figura 9 – Aplicação eBanka A equipa deste projecto era constituída por um gestor de projecto, um responsável

técnico e um consultor. Eu desempenhei a função de consultor, onde executei as tarefas que me foram atribuídas.

A minha contribuição neste projecto consistia em desenvolver um WebService que é responsável por receber as operações dos clientes, verificar se os clientes estão registados no sistema e invocar um Componente COM, utilizando a tecnologia C# sobre WebServices do .Net.

Este WebService também é responsável por manipular todas as mensagens XML retornadas pelo Componente COM, esta manipulação foi feita com a ajudas das classes de manipulação de XML do .Net.

WebServices são uma nova e inovadora técnica para a troca de dados via Web que se tem utilizado muito para fornecer e consumir serviços na Web. Toda a comunicação entre os servidores WebServices e os seus clientes é através de mensagens XML sobre o protocolo HTTP.

Mas para a comunicação ser baseada em XML é necessário um protocolo que seja responsável por encapsular as chamadas dos métodos e propriedades dos objectos em XML, este protocolo chama-se SOAP.

Contudo, para um cliente invocar os serviços fornecidos por um servidor é necessário que conheça a assinatura desses serviços e isto é conseguido através do padrão WSDL, que fornece a descrição de tudo que um WebService possui.

Trabalho Realizado


4.2 TRABALHO REALIZADO NO PROJECTO

4.2.1 Arquitectura tecnológica

Este capitulo foi reservado ao relato das soluções tecnológicas abordadas e adoptadas para a realização do projecto.

Antes da criação do projecto foi necessário decidir, em fase de especificação

técnica quais as linguagens de programação a utilizar, e quais os mecanismos de comunicação da aplicação com a Base de Dados a implementar e qual a interface mais apropriada para o sistema.

Para desenvolver a aplicação para o negócio do SIMLIS foi colocada a questão do

tipo de interface, windows application ou web application. As windows applications consistem em aplicações com interface com o utilizador

semelhante aos dos programas actuais para o Sistema Operativo Windows, pelo que, as web applications são aplicações destinadas a serem vistas sobre a Internet em browsers.

A solução escolhida foi a interface das web applications, esta solução permite o acesso à informação através da Internet. Desta modo são apresentadas as seguintes vantagens no seu uso:

Os utilizadores SIMLIS podem aceder de uma forma fácil à informação a partir de qualquer PC instalado no interior do SIMLIS ou através de um PC externo com ligação à Internet;

Facilita a manutenção do sistema, uma vez que as actualizações reflectem para todos os utilizações sem afectar nada;

Não necessita de ser instalado nada no computador do cliente, somente ter um browser. No entanto para a concretização da interface web application é necessário ter uma

infra-estrutura sobre o qual a aplicação corre. Como infra-estrutura, optou-se pela .Net Framework, embora exista outra concorrente forte como a J2EE da Sun.

Dentro da .Net Framework optámos por escolher a linguagem de programação C#, porque é uma linguagem nova e moderna que visa facilitar o desenvolvimento de aplicações.

O capítulo 4.2.2 foi reservado à .Net Framework e à linguagem C#, onde estas foram abrangidas de uma forma mais resumida.

A escolha da interface anteriormente mencionada levou à necessidade de utilização

de um servidor web para permitir o acesso às páginas ASP.NET e HTML criadas, por parte dos browsers instalados nas máquinas do SIMLIS e por qualquer máquina com acesso à Internet.

No entanto, não só a escolha de um servidor web se tornou necessária, mas também a escolha do servidor de Base de Dados. Existiam duas soluções possíveis para resolver o problema.

Trabalho Realizado


A solução passava pela implementação através da utilização do Servidor Web da Microsoft, chamado IIS.

Relativamente ao servidor de Base de Dados tínhamos a oportunidade de escolher entre o SQL Server e o Oracle, decidimos escolher o SQL Server.

Ambos os Sistemas de Gestão de Base de Dados referenciados são grandes potências no mercado, que podem ser usados para construir sistemas eficientes e estáveis.

Apesar de tudo a escolha foi obvia já que o cliente com a escolha do SQL Server, não teria adição de custos.

Mas o SQL Server tem algumas vantagens em comparação com Oracle e vice-versa.

Algumas vantagens do SQL Server são as seguintes:

É mais barato comprar que o Oracle;

É geralmente mais fácil de instalar, usar e gerir. O conjunto de produtos seleccionados para concretizar o projecto SIMLIS passou

pelo facto de o SIMLIS possuir um acordo de licenciamento com a Microsoft para usar os seus produtos.

Como ferramentas de controlo de versões e acessos do projecto durante o processo

de desenvolvimento usou-se o VSS e o CVS. O VSS é uma ferramenta que permite de forma segura, dentro da equipa de

desenvolvimento, controlar os acessos e versões. Esta ferramenta foi adoptada para controlar o código fonte do projecto.

O CVS também permite o controlo de acesso e versões, mas decidiu-se usar este utilitário para manipular os documentos do projecto, pois a integração das ferramentas com o VSS é total.

Como ferramenta de desenvolvimento de aplicações .NET utilizou-se o VS 2003.

Este ambiente de desenvolvimento abrangente para múltiplas linguagens, destinada ao rápido desenvolvimento e integração de aplicações. Também oferece um ambiente altamente produtivo para o desenvolvimento de uma ampla variedade de aplicações e tecnologias conectadas com a plataforma .Net. Através do uso do ambiente de runtime de alta performance Microsoft .Net Framework, o VS 2003 .NET oferece aos programadores poderosas ferramentas de design, construção, testes e instalação de aplicações, permitindo também que as melhores práticas e orientações possam ser partilhadas num ambiente de trabalho em equipa.

4.2.2 .Net Framework e linguagem C#

Este capitulo foi dedicado para explicar de forma resumida uma das partes preponderantes onde incidiu o projecto realizado.

A .Net Framework trata-se da infra-estrutura, que visa obter uma forma simples e unificada de desenvolvimento de aplicações, e sobre a qual as aplicações correm. Esta infra-estrutura é constituída por diversas partes, tal como é ilustrado na figura 11.

Trabalho Realizado


Figura 10 – Arquitectura da plataforma .NET

Todas as aplicações escritas para a .NET correm dentro de uma máquina

virtual chamada CLR. O código que se encontra a executar aqui dentro chama-se managed code e beneficia de várias características como:

Gestão automática de memória

o O CLR dispõe de um garbage collector que se encarrega de limpar os objectos que já não estão a ser utilizados pelas aplicações.

Segurança

o O CLR mecanismos que permitem atribuir permissões ao código baseadas na sua proveniência e em quem está a executar. Existem também mecanismos que permitem garantir que o código a executar é valido e não irá corromper outros programas que se encontrem a executar no CLR.

Tradução de código intermédio para código nativo

o Ao compilar um programa na plataforma .NET, tipicamente este é traduzido de uma linguagem de alto nível para uma linguagem intermédia chamada MSIL. O CLR possui um compilador just-in-time que se encarrega de traduzir código intermédio para código nativo do processador, antes de o executar.

Carregamento dinâmico de classes

o O CLR torna possível carregar em tempo de execução segmentos de código que antes não estavam presentes na máquina virtual.

O CLR encontra-se a executar por cima do sistema operativo, utilizando os seus serviços.

Por cima da máquina virtual básica, existe um conjunto de bibliotecas estandardizadas que permitem às aplicações tomar pedido de um rico conjunto de APIs. Existe um conjunto de bibliotecas básicas, denominadas por Base Class

Trabalho Realizado


Library, que oferecem recursos como acesso a ficheiros, estruturas de dados básicas (hash tables, listas, etc.), acesso a recursos de rede e outras. Em seguida, encontram-se bibliotecas que permitem aceder a base de dados (ADO.NET) e manipular informação em geral (por exemplo, em XML). No topo da hierarquia estão as bibliotecas que permitem efectuar desenvolvimento web (ASP.NET) e criar interfaces com o utilizador em Windows (Windows Forms).

Um ponto interessante é que o .NET foi pensado não apenas para aplicações que sejam programadas em C#, mas também noutras linguagens. Na .NET Framework, as linguagens de alto nível são compiladas para uma linguagem intermédia chamada MSIL. É esse código que é executado no CLR. A Common Language Specification constitui uma norma que especifica o que é que tem de ser suportado a nível de uma linguagem de programação para esta ser compatível com a infra-estrutura .NET e com as aplicações que se encontram a correr no CLR.

Quanto ao C# posso dizer que é uma linguagem nova e moderna que visa facilitar o desenvolvimento de aplicações. Combina as melhores características do C++, do Visual Basic e mesmo do Java. Eis as principais características desta nova linguagem, que acho que são dignas de referência:

Orientada aos componentes

o Um dos grandes passos em termos de engenharia de software, foi o conceito de componente. Um componente é uma unidade binária de código que pode ser incluída numa aplicação. Tipicamente a manipulação de componentes faz-se de forma visual, por drag-and-drop e, configuração das suas propriedades e interligações.

Robusta e moderna

o O C# é uma linguagem orientada aos objectos, possuindo mecanismos como, garbage collection, que liberta o programador da gestão explícita da memória; excepções, que permitem uma gestão robusta dos erros nos programas.

Familiar

o O C# baseia a sua sintaxe na linguagem C++ e, em certa medida, na linguagem Java. Hoje em dia existem muitos programadores que já conhecem essas linguagens, fazendo com que a transição para o C# seja relativamente pacífica.

No entanto uma nova linguagem por muito poderosa que seja não é verdadeiramente útil se não tiver um grande número de bibliotecas de funções directamente disponíveis. O C# em si não possui bibliotecas. Contudo os programas escritos nesta linguagem executam sobre a .NET Framework, que possui um vasto conjunto de bibliotecas, assim como outras funcionalidades que permitem uma grande versatilidade em C#.

Trabalho Realizado


4.2.3 Arquitectura física

O conjunto de soluções escolhidas no capítulo 4.2.1, deu origem à seguinte arquitectura:

Figura 11 – Arquitectura física

Os componentes apresentados relacionam-se da forma apresentada a seguir. O servidor IIS recebe pedidos dos browsers das máquinas cliente e é responsável

por dirigi-los ao servidor da Base de Dados. Para que tal seja possível é preciso efectuar uma conexão entre estes dois servidores, passando o IIS a ser cliente do servidor de Base de Dados. Essa conexão é realizada via SQL Server .Net Data Provider. Depois de executar a resposta ao pedido, o servidor da Base de Dados enviá-la-á para o IIS. Esta resposta é a informação que o IIS envia à aplicação C#, que constrói uma página ASP.NET e passa ao browser.

4.2.4 Arquitectura lógica

A arquitectura de desenvolvimento da aplicação pode ser caracterizada num serviço de três camadas:

Camada de apresentação;

Camada de lógica de negócio;

Trabalho Realizado


Camada de base de dados.

Figura 12 – Arquitectura lógica A arquitectura lógica apresentada permite que a interface com o utilizador apenas

trate de aspectos de visualização de informação. Todos os pedidos de informação são efectuados à lógica de negócio. Assim, torna-se muito mais simples realizar a manutenção da interface do utilizador. Qualquer mudança neste componente da arquitectura não influência outros.

A camada lógica de negócio permite separar a lógica de negócio da Base de Dados, deixando de estar dependente do Sistema de Gestão de Base de Dados utilizado. Esta camada é implementada utilizando tipicamente linguagens como o C#, VB ou outras semelhantes que permitem muito maior flexibilidade e complexidade em relação ao que está disponível nos Sistemas de Gestão de Base de Dados, onde as linguagens estão muito mais direccionadas por forma a permitir fácil e rápida implementação de consultas, actualizações, inserções e remoções.

Por fim temos a camada de Base de Dados como base de toda a aplicação. Aqui residem os dados dos utilizadores. Ao exterior são oferecidas capacidades de execução de consultas, actualizações, inserções, remoções usando o standard SQL. As potencialidades disponíveis dependem sempre de qual o Sistema de Gestão de Base de Dados escolhido, sendo que a utilização de funcionalidades especificas do Sistema de Gestão de Base de Dados para melhoria de performance ou facilitação do desenvolvimento é totalmente independente e não afecta de forma alguma a implementação da lógica de negócio e da interface gráfica.

Trabalho Realizado


4.2.4.1 Camada de apresentação

O primeiro componente do sistema é o único que é visível para o utilizador, o browser. A partir deste utilitário o utilizador pode efectuar operações de consultar, pesquisar, inserir, alterar e eliminar sobre a informação da Base de Dados de uma forma transparente, dando a sensação que a aplicação é constituída somente por este componente.

Nesta secção faço uma explicação sobre o funcionamento da aplicação em geral, estruturas de dados e linguagens utilizadas para realizar esta camada. De seguida é abordada a validação de dados, terminando com a segurança da aplicação.

4.2.4.1.1 Modelo de programação

Em ASP.NET existem dois modelos de programação: code behind e code in page. O modelo utilizado foi o code behind, aqui encontramos uma verdadeira separação do HTML e do código C#. Neste modelo, para cada ficheiro .aspx, extensão dos ficheiros ASP.NET, existe um ficheiro .aspx.cs onde está escrito todo o código.

No ficheiro aspx, existe apenas, a parte HTML e a parte da declaração dos componentes do ASP.NET, onde o reaproveitamento do código é grande e facilita muito a programação. Os componentes utilizados foram:

HTML Controls

o São os controlos HTML básicos (Div, B, Table, ...).

HTML Server Controls

o São controlos HTML executados no servidor Web (Calendar, Datagrid, ...).

Web Server Controls

o São os controlos ASP.NET.

Web User Controls

o São Web Server Controls definido pelo programador.

Validation Controls

o São Web Server Controls que contêm lógica para validar o input de outros Server controls.

No ficheiro .aspx.cs encontra-se o código C# correspondente às funcionalidades da

interface.

4.2.4.1.2 Interface HTML

Relativamente ao funcionamento da aplicação, para se utilizar a mesma o utilizador tem que ter um browser aberto e depois carregar sobre o menu Favorites e escolher a opção SIMLIS ou então escrever o URL da aplicação, http://localhost/SIMLIS_WEB/homepage.aspx, na caixa de texto Address.

Trabalho Realizado


Figura 13 – Inicialização da aplicação a partir dos Favorites Após seleccionada a opção SIMLIS, a página principal da aplicação é exibida como

mostra a Figura 14 - Ecrã principal da aplicação do SIMLIS, no anexo II - Figuras. O Menu SIMLIS permite ao utilizador aceder às seguintes opções:

Área de gestão de dados relativos a Pagamentos;

Área de gestão de dados relativos ao Cadastro;

Área de gestão de dados relativos a Candidatura a Fundos de Coesão;

Área de gestão de dados auxiliares. Em todas as páginas do SIMLIS existe a barra de funcionalidades que está exibida

na Figura 15 do anexo II - Figuras. Nesta barra podemos encontrar funcionalidades que estão apresentadas na Figura 16

do anexo II - Figuras. Cada um dos itens apresentados no Menu SIMLIS quando seleccionados, exibem

uma página semelhante à apresentada na Figura 17 do anexo II - Figuras. A página seleccionada é constituída por um Menu Lateral que permite navegar

entre os vários dados relativos à área gestão de dados seleccionada, nesta caso, ao Cadastro; por um rodapé; por uma Área de Operação, reservada às operações de pesquisa, consulta, inserção, actualização e remoção de registos; para além da Barra de Funcionalidades.

Para o efeito foram utilizados usercontrols (ficheiros .ascx), que foram desenhados para permitir reutilizar funcionalidades comuns da interface do utilizador:

<uc1:cabecalhopage id="Cabecalho" Tipo=”C” runat="server"></uc1:cabecalhopage>

o Este usercontrol é responsável pela apresentação da barra de cabeçalho correspondente à área de gestão de dados seleccionada e servir como link para o Menu SIMLIS.

Trabalho Realizado


Ver as Figuras 18, 19, 20, 21, 22, no anexo II - Figuras, que apresentam as várias barras de cabeçalho da aplicação.

<uc3:MenuCabecalho id="MenuCabecalho" runat="server"></uc3:MenuCabecalho>

o Este usercontrol é responsável pela construção do menu do cabeçalho correspondente à Barra de Funcionalidades, e servir como link para cada área de dados.

Ver a Figura 23 do anexo II - Figuras.

<uc5:Menu id="MenuLateral" runat="server" ElemId="C" ElemOpen="InterL" ElemSelected="InterL" SubElemSelected="InterC"></uc5:Menu>

o Este usercontrol é responsável pela construção do menu lateral correspondente à área de dados seleccionada, neste caso, foi a área de dados relativos ao Cadastro.

Ver a Figura 24 do anexo II - Figuras.

< uc2:FooterPage id="Footer" runat="server"></uc2:FooterPage>

o Este usercontrol é responsável pela construção do rodapé comum a todas as áreas de dados.

Na Área da Operação não foi mencionado nenhum usercontrol, porque esta varia consoante a operação escolhida, daí serem aplicados diversos usercontrols para cada uma das operações.

No caso da operação escolhida tenha sido a pesquisa, foi utilizado um usercontrol de pesquisa, que agrupa um conjunto de outros usercontrols e de controlos ASP.NET, como por exemplo:

<asp:CheckBox>

<asp:Panel>

<asp:TextBox>

<asp:ValidationSummary>

<asp:Button>

<asp:CompareValidator> Os controlos de HTML utilizados foram:

<Div>

<A href>

<Br>

<Table>

Trabalho Realizado


<input>

<H3>

<Label> Os usercontrols usados dentro do usercontrol de pesquisa tem a função preencher

DropDownLists (caixas de selecção), como por exemplo, preencher a DropDownList dos subsistemas com todos os subsistemas disponíveis no sistema; ou exibir um calendário para o utilizador seleccionar uma data.

Ainda na operação de pesquisa foi utilizado outro usercontrol para apresentar a listagem das ocorrências encontradas segundo o critério de pesquisa escolhido. Este usercontrol recebe um objecto Pesquisa com os dados dos campos de pesquisa e depois é responsável por chamar os métodos da camada da lógica de negócio para receber os dados da Base de Dados e por fim apresenta-os ao utilizador através dum controlo <asp:DataGrid>, este controlo apresenta um grande número de funcionalidades para formatar a listagem dos dados apresentados.

A Figura 25 do anexo II - Figuras, ilustra a utilização do controlo <asp:DataGrid>. Na operação de inserção, actualização, consulta e remoção foi utilizado um

usercontrol responsável por encapsular um conjunto de controlos ASP.NET, que constroem a página de inserção, actualização, consulta e remoção. Os controlos utilizados servem para exibir os campos a preencher e para validar os dados digitados ou seleccionados pelo utilizador nesses campos. De seguida são exibidos alguns controlos utilizados:

<asp:ValidationSummary>

<asp:Panel>

<asp:Hyperlink>

<asp:RequiredFieldValidator>

<asp:Label>

<asp:Button> Alguns controlos de HTML utilizados foram:

<Table>

<Label>

<Input>

<Div> A Figura 26 no anexo II - Figuras, ilustra o uso dos controlos referenciados . A área da operação de inserção está disponível a partir da selecção do tópico inserir

do menu lateral, dentro da área de dados seleccionada.

Trabalho Realizado


As operações de actualização e remoção estão disponíveis a partir da listagem das ocorrências ou da operação de consulta. Por fim a operação de consulta está disponível a partir da listagem.

Todos os outros itens quer desta área de dados quer das restantes, seguem o mesmo

raciocínio. O documento de referência de Bento, Bruno (2005) - “SMLS_04_0269 Manual

Utilizador”, onde se encontra o funcionamento da interface com maior detalhe, não está disponível*.

4.2.4.1.3 Validação de dados

Um aspecto muito importante a nível da camada de apresentação é a validação de dados. Nunca podemos ficar na expectativa que o utilizador insira valores coerentes com os da Base de Dados, porque, por exemplo, pode digitar dados numéricos no nome de uma pessoa para criar um novo registo, sem aperceber-se do acontecido.

Na aplicação desenvolvida existem vários formulários de inserção e actualização referentes a diversos tipos de informação; nomes, moradas, telefones, nº de contribuintes e bilhetes de identidade, datas, idades, etc.; pelo que se torna obrigatório analisar a coerência dos valores digitados pelo utilizador. É obvio que os erros ortográficos não são apanhados pelos validadores. Contudo, numa actualização posterior desse registo, o utilizador pode corrigi-lo.

Existem duas formas de validar os dados introduzidos pelo utilizador. Validações feitas no lado do cliente (clientside), ou seja pelo browser, através da linguagem JavaScript ou do lado do servidor (serverside) pelo código C#. Das duas formas apresentadas, a primeira é a preferível porque não requer o consumo de recursos do servidor e por isso sempre que foi possível optou-se pelo uso desta linguagem. Mas o que acontece é que por vezes não é possível fazer as validações do lado do cliente, como por exemplo, antes de inserir um dado identificador na Base de Dados temos de verificar se já lá existe.

De seguida na Figura 27 no anexo II - Figuras, é apresentado um ecrã com o uso da linguagem JavaScript.

4.2.4.1.4 Segurança

Outro aspecto que requer destaque neste documento é a segurança, mais propriamente dito, a validação de utilizadores que entram na aplicação ASP.NET desenvolvida.

A .Net Framework juntamente com o IIS disponibilizam sistemas de autenticação, optou-se pelo método de Windows Integrated Authentication e Digest Authentication pelo facto de estes tipos de autenticação já se encontrarem implementados.

Trabalho Realizado


Figura 28 – Métodos de Autenticação fornecidos pelo IIS

No método Windows Integrated Authentication a autenticação é feita através do

sistema operativo Windows que vai utilizar os utilizadores registados no sistema operativo que, normalmente, já existem no sistema das empresas.

Por outro lado, no método Digest Authentication os utilizadores fornecem um username e password para se conectarem, no entanto, a password é cifrada antes de ser enviada sobre a rede.

Após ter sido feita a autenticação no IIS, o processo é encaminhado para a aplicação ASP.NET, cujas verificações são feitas com base no ficheiro de configuração, web.config, da aplicação.

Para concretizar o nosso objectivo tivemos que definir no web.config o tipo de autenticação, Windows, recorrendo ao uso das tags que se segue:

<system.web> <authentication mode=”Windows” /> </system.web> Depois de termos indicado o tipo de autenticação, tivemos de definir as

autorizações tanto de utilizadores (users) como de grupos (roles) de utilizadores. <authorization> <deny users=”[comma separated list of users]” roles=”[comma separated list of roles]” />

<allow users=”[comma separated list of users]” roles=”[comma separated list of roles]” />

</authorization>

O método Digest Authentication só é utilizado caso o método Windows Integrated

Authentication falhe.

Trabalho Realizado


4.2.4.2 Camada de lógica de negócio

A lógica de negócio estabelece a ligação entre a camada de interface e o Sistema de Gestão de Base de Dados, via SQL Server .Net Data Provider, tratando os dados de modo a que estes se encontrem de acordo com as regras de negócio do sistema.

A linguagem de programação eleita para o desenvolvimento desta camada foi o C#

pelas razões mencionadas no capítulo 4.2.2. A .Net Framework fornece um conjunto de classes para facilitar o acesso das

aplicações às Base de Dados de diversos tipos, cujo nome é ADO.NET. Um exemplo de como usar estas bibliotecas é mostrado de seguida. //importar o conjunto de classes fornecidas pelo SqlServer .Net Data Provider para acesso à Base de Dados using System.Data.SqlClient; Os principais objectos utilizados do SqlServer .Net Data Provider são:

SqlConnection

o Representa um única conexão persistente ao SQL Server data source.

SqlParameter

o Representa um parâmetro a ser passado, neste caso numa ad hoc query (instrução SQL executada directamente).

SqlCommand

o Representa alguma coisa que pode ser executada, neste caso uma ad hoc query.

SqlDataReader

o Representa a maneira mais rápida para ir buscar um conjunto de dados a partir de uma Base de Dados.

Os objectos mencionados anteriormente foram utilizados nas operações de

pesquisar, inserir, consultar, eliminar e actualizar informação das diversas entidades sobre a Base de Dados.

Para realizar a camada de lógica de negócio da operação de pesquisa definimos um objecto Pesquisa, com o valor dos campos digitados pelo utilizador, de seguida foi necessário utilizar um objecto SqlConnection para abrir uma ligação com o data source. Quando se abre uma conexão é preciso que se defina a propriedade ConnectionString do objecto SqlConnection. SqlConnection myConnection = new SqlConnection();

Comentários em C#

Trabalho Realizado


myConnection.ConnecyionString = “Server=SQLSRV01;” + “Database=SMLS_04_0269;” + “UserID=sa;” + “Pwd=;”;

De seguida, foi necessário preparar um objecto SqlCommand com a ad hoc query a ser executada mediante um dado critério de pesquisa definido pelo utilizador através da interface.

SqlCommand myCommand = new SqlCommand();

Para definir um critério foi necessário recorrer à utilização do objecto SqlParameter, como podemos observar a seguir.

SqlParameterCollection Params = myCommand.Parameters; Params.Add(new SqlParameter("@subsistemaId", SqlDbType.Int)); Params["@subsistemaId"].Value = “S1”; myCommand.CommandText = “SELECT nome FROM Interessado”;

myCommand.Connection = _ctx.Dados.Connection; myCommand.Transaction = _ctx.Dados.Transaction;

Por fim, utilizou-se o objecto SqlDataReader para ir buscar o conjunto de dados devolvidos pelo critério definido na operação pesquisar sobre a Base de Dados. O conjunto de resultados, resultset, contido num SqlDataReader é forward-only e read-only, isto significa que, somente se pode ler as linhas dentro de um resultset sequencialmente a partir do inicio ao fim, não se pode modificar quaisquer dados. SqlDataReader myReader = myCommand.ExecuteReader(); while(myReader.Read()){

myReader.GetInt32(0), //INTERESSADO_ID -> InteressadoId myReader.GetString(1), //SUB_SISTEMA_ID -> SubSistemaId

}

Cada resultado do conjunto de resultados é colocado num objecto Info, este objecto foi criado por nós para guardar os dados vindos da Base de Dados para posterior manipulação.

Na camada de lógica de negócio da operação de inserção criámos um objecto Info com o valor do campos digitados pelo utilizador. Para além do objecto Info foi também necessário utilizar um objecto SqlConnection, SqlCommand, SqlParameter e definir as suas propriedades, tal como na operação de pesquisa. Ao invés da operação de pesquisa, onde se utilizou o método ExecuteReader() do objecto SqlCommand, na operação de inserção utiliza-se o ExecuteScalar(), este método retorna a primeira coluna da primeira linha do resultset, neste caso, retorna o identificador atribuído à nova ocorrência.

object ret = myCommand.ExecuteScalar();

Ou utiliza-se o ExecuteNonQuery(), este método não retorna um resultset, neste caso, não pretendemos obter o identificador atribuído à nova ocorrência a quando da inserção.

Executar a ad hoc query sob o efeito de transacção

Associar um comando à conexão definida anteriormente

Criar um atributo do critério de pesquisa, neste caso subsistemaId

Propriedade do objecto SqlCommand que define a ad hoc query a executar

Connection String

Trabalho Realizado


myCommand.ExecuteNonQuery();

Para a operação de consulta foram utilizados as mesmas propriedades e métodos dos objectos mencionados na operação de pesquisa.

Para a operação de actualização foram utilizados as mesmas propriedades e métodos dos objectos mencionados na operação de pesquisa, com excepção do método ExecuteReader(), do objecto SqlCommand, que foi substituído pelo método ExecuteNonQuery() e do objecto Pesquisa que foi substituído por dois objectos Info, um com os novos dados actualizados, o outro com os dados não actualizados, isto para saber quais os campos a actualizar.

myCommand.ExecuteNonQuery();

Para a operação de eliminação foram utilizados as mesmas propriedades e métodos dos objectos mencionados na operação de actualização, com excepção dos objectos Info.

4.2.4.3 Camada de Base de Dados

Esta camada é responsável pela persistência dos dados da aplicação, isto foi conseguido com a utilização de uma Base de Dados. O Sistema de Gestão de Base de Dados foi o SQL Server.

A informação foi organizada em tabelas, atributos e registos. E de seguida foi

definido o modo como estas tabelas se relacionam entre si. Para aceder e manipular os dados da Base de Dados SQL Server usou-se ad hoc

queries. As Ad hoc queries fornecem uma maneira rápida de ir buscar dados á Base de Dados ou de fazer alterações na Base de Dados.

As quatro principais instruções T-SQL usadas para manipular os dados SQL Server foram:

SELECT

o Instrução que permite ir buscar os dados armazenados na Base de Dados.

INSERT

o Instrução permite adicionar novos dados à Base de Dados.

UPDATE

o Esta instrução permite modificar dados que já se encontram na Base de Dados.

DELETE

o Através desta instrução é possível eliminar dados a partir da Base de Dados. Para construir as ad hoc queries foi utilizada a ferramenta SQL Server Query

Analyzer.

Trabalho Realizado


O ambiente de desenvolvimento usado para gerir tabelas, campos e dados; relacionamentos de tabelas; e criar diagramas de base de dados. foi o SQL Server Enterprise Manager.

No Anexo I encontra-se o Modelo de Dados da aplicação.

4.2.5 Plano de testes

Este capitulo foca sobre o plano de testes a executar sobre a aplicação desenvolvida anteriormente.

O objectivo dos testes é avaliar a conformidade da aplicação desenvolvida

relativamente aos requisitos especificados e ao desenho, garantindo deste modo a qualidade do código produzido.

Para a aplicação em questão foram escolhidos fazer Testes Funcionais (caixa preta),

tendo em conta o baixo orçamento e a importância que estes trazem para o SIMLIS. Por exemplo, os Testes de Carga não são de tanta importância, uma vez que, o tempo de resposta não é importante e a quantidade de dados é baixa.

Cada especificação de testes é identificada por:

Ref. Teste

o Por exemplo, 1.

Classe Teste

o Por exemplo, FU – Funcional e UI – User Interface.

Teste a executar

o Por exemplo, inserir interessado já existente.

Passos/detalhe do teste

o Por exemplo, Escolher Parcela e de seguida inserir novo registo usando o NOME de um interessado já existente.

Requisitos/Pré-Condições

o Por exemplo, Perfil Cadastro.

Resultado esperado

o Por exemplo, o sistema não permite e apresenta uma mensagem a informar.

Responsável pela execução

Data execução

Trabalho Realizado


Resultado Após a realização destes testes, efectuados por uma equipa, sempre que possível,

distinta da de desenvolvimento, serão feitos os testes pelo cliente para se dar a aceitação da aplicação.

4.2.6 Trabalho realizado por mim

No projecto em questão, a minha contribuição foi dada nas Fases de Implementação, Transição e Operação onde fui um dos elementos da equipa responsável pela implementação da aplicação Web.

Quando entrei no projecto o meu trabalho foi ler os documentos da especificação funcional e técnica que tinha de seguir para realizar o trabalho, para depois ser feita uma reunião com o Responsável Técnico para tirar dúvidas que eventualmente surgissem.

Passada esta altura fui integrado na equipa de desenvolvimento. O documento de referência de Mateus, Paulo (2004) - “SMLS_04_0269

Especificação Técnica” e Mateus, Paulo (2004) - “SMLS_04_0269 Especificação Funcional”, onde se encontra a especificação técnica e funcional do projecto, não está disponível*.

Durante a fase de planeamento decidiu-se que eu na Fase de Implementação iria ter

a oportunidade de fazer um pouco de tudo excepto o Modelo de Dados que iria ser feito por outro elemento experiente nessa área.

Eu fiquei responsável por desenvolver a camada de interface, as páginas ASP.NET, e a camada da lógica de negócio, os ficheiros de acesso à Base de Dados, para as entidades Interessado, Contacto, Pagamentos, Gestão de Pedidos Dup, Gestão de Referências Documentos da Pedido Dup, Gestão de Referências de Documentos de Contacto, Gestão de Despesas, Gestão de Correspondência e Gestão de Pedidos de Pagamento.

Na Fase de Transição, fui responsável pela elaboração do Manual de Utilização da

aplicação. Por fim também fui integrado na Fase de Operação onde terei como funções

assegurar a manutenção correctiva dos desenvolvimentos efectuados.


5 SUMÁRIO E

CONCLUSÕES

Sumário e Conclusões


5.1 SUMÁRIO

Este capitulo apresenta uma síntese do trabalho que foi realizado neste estágio. O resultado deste estágio foi o desenvolvimento de uma Web Application que

permite efectuar as operações inserir, actualizar, pesquisar, consultar e eliminar sobre a informação que se encontra numa Base de Dados, que permitirá aos colaboradores SIMLIS obter um registo de vários pontos fulcrais como, contactos efectuados, registo de documentação e controlo de pagamentos.

A aplicação em questão foi desenvolvida de forma a ser acedida através da Internet.

Para o efeito, foi necessário configurar o IIS para criar uma Web que receba os pedidos dos clientes e envie-os à aplicação para respectivo processamento e que devolva o resultado do processamento ao cliente.

5.2 CONCLUSÕES

Durante este período de estágio na LINK tive a oportunidade de trabalhar com um conjunto diversificado de tecnologias na área das Web Applications, que revolucionaram o mercado quer pelo ambiente de execução quer pelas linguagens que dispõe, muito poderosas para a criação de aplicações.

Tive o privilégio de prestar os meus serviços numa das grandes empresas deste país

na área de consultoria informática, quer pela diversidade de áreas de competência, quer pelos clientes, onde destaco a unidade em que estive inserido durante este período, a UPI.. Aqui foi-me dada a possibilidade de integração em ambientes de produção, a aquisição de novos conhecimentos, ganhar autonomia e experiência profissional. Este estágio foi a ponte entre a vida académica e a vida profissional.

A parte curricular da licenciatura teve papel preponderante na minha formação,

onde destaco as cadeiras de Fundamentos de Sistemas de Informação, Tecnologias de Base de Dados, Programação Imperativa, Interfaces Pessoa-Máquina e Projecto de Sistemas de Informação que contribuíram de forma decisiva para a angariação de outros conhecimentos fundamentais para a realização deste projecto.

Por fim, este estágio permitiu-me realizar uma certificação “Microsoft 70-315:

Developing and Implementing Web Applications with Microsoft Visual C#.NET”, nas tecnologias que utilizei para a realização do projecto, passando assim a possuir um titulo de MCP (Microsoft Certified Professional).


6 GLOSSÁRIO

Glossário


A lista de siglas e abreviaturas utilizadas neste documento encontram-se organizadas por ordem alfabética ascendente.

* Documento interno que não pode ser divulgado. ** Alguns dados não podem ser divulgados, por serem dados pessoais. ADO Access Data Objects API Application Programming Interface ASP Active Server Pages ASP.NET Active Server Pages .NET BCL Base Class Library CLR Common Language Runtime CLS Common Language Specification CSS Cascading Style Sheets CVS Concurrent Version System ETAR Estação de Tratamento de Águas Residuais HTML HyperText Markup Language IE Internet Explorer IIS Internet Information Services INESC Instituto de Engenharia de Sistemas de Computadores FCUL Faculdade de Ciências da Universidade de Lisboa LINK Link Consulting – Tecnologias de Informação, S.A. MCH Modelo Continente Hipermercados MSIL Microsoft Intermediate Language PC Personal Computer PEDIP Programa Estrutural de Desenvolvimento para a Indústria Portuguesa PL/SQL Procedural Language / Structured Query Language PMI Project Management Institute PSO Project Support Office RUP Rational Unified Process SIMLIS Saneamento Integrado dos Municípios do Lis SOAP Simple Object Access Protocol T-SQL Transact-Structured Query Language UPI Unidade de Portais & Intranets URL Uniform Resource Locator VBA Visual Basic for Applications VS Visual Studio VSS Visual Source Safe XML Extensible Markup Language XSL Extensible Stylesheet Language WAP Wireless Application Protocol WBS Work Breakdown Structure WSDL WebServices Description Language WWW World Wide Web


7 BIBLIOGRAFIA E

REFERÊNCIAS

Bibliografia e Referências


7.1 ENDEREÇOS WEB

http://msdn.microsoft.com/library - Portal de Documentação sobre Programação http://www.pontonetpt.com - Portal de Documentação sobre Programação .NET http://www.link.pt - Site da Link Consulting – Tecnologias de Informação, S.A. http://www.w3schools.com

- Portal de Documentação sobre Programação para a Web http://www.codeproject.com/aspnet

- Portal de Documentação sobre Programação para a Web http://www.hitmill.com/programming/dotnet/csharphtml

- Site com uma série de Links para sites de C#

http://www.softsteel.co.uk/tutorials/cSharp/contents.html - Site sobre programação C#

http://www.adp.pt - Site das Águas de Portugal

7.2 LIVROS E DOCUMENTOS

Kalani, Amit (2003) - “MCAD/MCSD Training Guide (70-315): Designing And Implementing Web Applications With Visual C# .NET”

Microsoft - “Documentação do .NET Framework SDK” USA: Microsoft, 2000 Marques, Paulo e Cardoso, Hernâni (2002) - “C# Curso Completo” Assunção, João (2003) - “Metodologia de Desenvolvimento de Aplicações

Workflow”

Vieira, João (2003) - “Programação com ASP.NET” Falcão, Luís (2003) - “A plataforma .NET”, Centro de Cálculo do Instituto

Superior de Engenharia de Lisboa Link Consulting (2004) - “Proposta nº SMLS_04_0269” Link Consulting (2004) - “Metodologia de Gestão de Projectos”

Bibliografia e Referências


Mateus, Paulo (2004) - “SMLS_04_0269 Especificação Técnica”

Mateus, Paulo (2004) - “SMLS_04_0269 Especificação Funcional” Bento, Bruno (2005) - “SMLS_04_0269 Manual Utilizador” Monteiro, Paulo (2004) - “Proposta Desenvolvimento: PEP - Desenvolvimento da template v1.18”

Documents

RELATÓRIO DE PROJECTO sobre WEB APPLICATIONS realizado