Licenciatura em Eng.ª...

Licenciatura em Eng.ª Informática

Projecto Final de Curso – 3º Ano – 2º Semestre

Relatório de Projecto

Helpdesk Advanced Solution

Engenharia Informática

3º Ano - 2º Semestre

António Ferrão Nº 20064161(Antigo: 2402334)

Ricardo Gonçalves Nº 20064162(Antigo: 2401870)

Relatório Trabalho Final de Curso 21-11-07

Helpdesk Advanced Solution Pág. 2


1 Índice

1 ÍNDICE ............................................................................................................................................ 3

2 RESUMO......................................................................................................................................... 5

3 AGRADECIMENTOS ................................................................................................................... 6

4 ÍNDICE DE FIGURAS................................................................................................................... 7

5 ABREVIATURAS E ACRÓNICOS.............................................................................................. 8

6 CAPITULO I – INTRODUÇÃO ................................................................................................... 9

6.1 NOME DO PROJECTO .................................................................................................................... 9 6.2 DESCRIÇÃO DO PROJECTO........................................................................................................... 9 6.3 TECNOLOGIAS UTILIZADAS ....................................................................................................... 10 6.4 ESTRUTURA DO RELATÓRIO...................................................................................................... 10

7 CAPITULO II - OBJECTIVOS E METODOLOGIAS ............................................................ 11

7.1 OBJECTIVOS................................................................................................................................ 11 7.2 CALENDARIZAÇÃO ..................................................................................................................... 11 7.3 ABORDAGEM METODOLÓGICA ................................................................................................. 12 7.3.1 PLANO DE ACTIVIDADES ........................................................................................................... 13

8 CAPÍTULO III – TRABALHO REALIZADO.......................................................................... 14

8.1 ANÁLISE DE REQUISITOS ............................................................................................................ 14 8.1.1 REQUISITOS – FUNCIONALIDADES PRETENDIDAS..................................................................... 14 8.1.2 REQUISITOS – ENVOLVIDOS COM O SISTEMA ........................................................................... 16 8.1.3 REQUISITOS – DESEMPENHO..................................................................................................... 17 8.1.4 ESTADOS DO PEDIDO................................................................................................................. 17 8.1.5 TIPOS DE RESOLUÇÃO ............................................................................................................... 18 8.1.6 PRIORIDADES DO PEDIDO.......................................................................................................... 19 8.1.7 ESTRUTURA DO PEDIDO ............................................................................................................ 20 8.1.8 RELATÓRIOS.............................................................................................................................. 20



8.1.9 PESQUISA................................................................................................................................... 21 8.2 PROJECTO ARQUITECTURAL ..................................................................................................... 22 8.2.1 FERRAMENTAS E TECNOLOGIAS ............................................................................................... 22 8.2.2 ARQUITECTURA E ESQUEMA RELACIONAL............................................................................... 27 8.3 DESENVOLVIMENTO DO PROJECTO .......................................................................................... 30 8.3.1 INTERFACE UTILIZADOR ........................................................................................................... 30 8.3.2 FLUXO PRINCIPAL DE PEDIDOS ................................................................................................. 46

9 CAPITULO IV – CONCLUSÕES............................................................................................... 51

10 REFERÊNCIAS.......................................................................................................................... 53



2 Resumo

No âmbito da cadeira de projecto do 3º ano da Licenciatura em Engenharia Informática da

Universidade Lusófona, criámos este grupo de trabalho constituído por António Ferrão e

Ricardo Gonçalves, alunos do referido curso.

Chegados a este ponto do percurso académico, e enquadrado na nossa área de interesses a

escolha do projecto final recaiu sobre o desenvolvimento de software. Tendo os referidos

alunos experiência profissional na área das TI, a opção pelo desenvolvimento de uma

ferramenta de Helpdesk foi quase imediata. No nosso caso particular decidimo-nos pelo nome

Helpdesk Advanced Solution.

A palavra Helpdesk é oriunda da língua inglesa e quer dizer “Help = auxílio” e ”Desk =

mesa”, o que significa “um local de auxílio para os problemas”.

O Helpdesk é uma ferramenta de fundamental importância para empresas de qualquer

tamanho, e o número de acções necessárias será determinado pela complexidade e dimensão

do ambiente envolvido. Talvez uma definição clara do serviço de Helpdesk é descrevê-lo

como a manutenção e o suporte técnico-operacional num ambiente corporativo, envolvendo

uma série de actividades distintas mas, ao mesmo tempo, fortemente interdependentes. A

função do Helpdesk é ser um canal de comunicação. É permitir uma maior proximidade entre

o utilizador e o técnico, mas de uma forma organizada e estruturada.



3 Agradecimentos

Antes de mais não podemos deixar de agradecer todo o amor, carinho e apoio que os nossos

familiares nos deram desde sempre, mesmo quando nos fins-de-semana passados a executar

este trabalho não nos permitiram dar a nossa devida atenção.

Agradecemos também todas as coisas novas que nos continuam a ensinar e toda a coragem e

incentivo transmitida.

Ao mestre Pedro Malta por tudo que nos ajudou nesta fase, por vezes complicada de gerir.

Também um agradecimento especial à Professora Inês Oliveira, por ser alguém tão

empreendedora e pró-activa e que mesmo à distância soube gerir de forma tão única este

trabalho.

São apenas algumas das pessoas que mais nos ajudaram nesta caminhada pessoal e que

contribuíram em muito para o que somos hoje em dia.

Por último a todos os nossos eternos amigos da Universidade Lusófona que nos apoiaram, só

podemos agradecer os momentos que passamos juntos, e que iremos continuar a passar.

Aquele abraço para todos eles.



4 Índice de Figuras

Figura 1 – Calendarização.........................................................................................................11

Figura 2 – Modelo em Cascata.................................................................................................12

Figura 3 – Arquitectura Framework .NET................................................................................23

Figura 4 – Arquitectura do sistema...........................................................................................27

Figura 5 – Esquema relacional da base de dados......................................................................28

Figura 6 – Tabelas da Base de Dados Helpdesk.......................................................................29

Figura 7 – Ecrã de Login...........................................................................................................31

Figura 8 – Ecrã de Falha de Login............................................................................................32

Figura 9 – Menu Principal Utilizador.......................................................................................33

Figura 10 – Menu Inserção Pedido...........................................................................................34

Figura 11 – Menu Inserção Pedido (2)......................................................................................35






Figura 17 – Reporte Pedido......................................................................................................41

Figura 18 – Histórico de Pedido...............................................................................................42

Figura 19 – Pesquisa Avançada................................................................................................43

Figura 20 – BackOffice.............................................................................................................44

Figura 21 – Relatórios - BackOffice.........................................................................................45

Figura 22 – Adição de Utilizador..............................................................................................46

Figura 23 – Diagrama de Fluxos de Estado de Pedidos............................................................47

Figura 24 – Solution Explorer – Visual Studio 2005................................................................48



5 Abreviaturas e Acrónicos

ASP – Active Server Pages

VB – Visual Basic

SQL - Structured Query Language

Web (ou WWW) - World Wide Web

IIS - Internet Information Service

ADO - ActiveX Data Objects

API – Application Programming Interface

BD – Base de Dados

SGBD - Sistema Gestor de Base de Dados

PHP - Hypertext Preprocessor

VBScript - Visual Basic Scripting Edition

CSS - Cascading Style Sheets

HTTP – HyperText Transport Protocol

TFC – Trabalho Final de Curso

SI – Sistemas de Informação

RH – Recursos Humanos

MN – Manutenção

EM – Economato



6 Capitulo I – Introdução

6.1 Nome do Projecto

Para o nosso projecto escolhemos um nome simples, e de fácil identificação com o âmbito do

projecto propriamente dito, Helpdesk Advanced Solution.

6.2 Descrição do Projecto

Uma ferramenta de Helpdesk consiste essencialmente num software que permita realizar a

gestão dos vários pedidos colocados por utilizadores. Partindo do pressuposto que existem

inúmeras ferramentas no mercado, todas elas com especificidades próprias, aquilo a que nos

propomos por forma a diferenciarmos a nossa ferramenta das demais, é construirmos uma

ferramenta que permite de uma forma simples, e com pouco custo de desenvolvimento, ser

escalável ao ponto de se ter tantos helpdesk’s dentro duma empresa quantos aqueles que a

mesma ache necessário. Ou seja, tradicionalmente as ferramentas de Helpdesk são

vocacionadas para os Sistemas de Informação, Recursos Humanos, Manutenção, entre outras

áreas. O que nós nos propomos a desenvolver é uma ferramenta que agregue de forma quase

transparente todos estes tipos de helpdesk, e que permita ao mesmo tempo adicionar tantos

quantos quisermos de uma forma simples e com poucos custos de desenvolvimento. Outra

funcionalidade que achamos importante implementar é aquilo que denominamos por “Ajudas

de Tipificação” ou seja, como se consegue facilmente padronizar a maioria dos pedidos que

os utilizadores colocam, é interessante que ao colocar um pedido seja automaticamente

solicitado ao utilizador a informação necessária para a resolução do mesmo. Num ambiente

empresarial é expectável uma grande dinâmica de evolução de conhecimentos e tecnologias,

assim como uma constante mudança que leva a que novos problemas possam surgir todos os

dias. Torna-se assim interessante que a ferramenta possa possuir um BackOffice que permita

criar novas ajudas de tipificação sempre que seja identificado um novo padrão de pedidos.

Pretendemos ainda que todas as acções sobre os pedidos sejam acompanhadas de notificações

para todos os intervenientes via mail.



Por fim, e para que a ferramenta possa ter um impacto não só ao nível operacional, mas

também ao nível de gestão, iremos desenvolver mecanismo de reporte que ajudarão a

perceber e a identificar potencias falhas na organização. Estas serão sem dúvida as “Task

Force” da nossa ferramenta, as mais valias, o factor diferenciador.

Outra preocupação que iremos ter durante o processo de desenvolvimento é criarmos um

interface agradável, mas ao mesmo tempo praticamente intuitivo. A utilização da ferramenta

tem que ter em conta que a mesma pode ser usada por uma multiplicidade de graus de

conhecimentos informáticos.

6.3 Tecnologias Utilizadas

Para o desenvolvimento desta solução, por uma questão de expectativas profissionais,

resolvemo-nos pela utilização da tecnologia ASP. NET 2.0 [2] utilizando as linguagens C# [5]

e VB .NET [6]. Em complementaridade iremos utilizar a base de dados SQLServer 2005

Express Edition [4]. De referir que o trabalho será desenvolvido com a ferramenta de

desenvolvimento Visual Studio 2005 Professional Edition [7].

6.4 Estrutura do Relatório

No primeiro capítulo pretende-se dar a conhecer o contexto de realização do projecto, e

oferecer uma breve descrição do projecto.

No segundo capítulo são descritos os objectivos do projecto final de curso, assim como as

várias etapas do desenvolvimento da aplicação.

O terceiro e principal capítulo do relatório, pretende descrever detalhadamente o trabalho

realizado. Todas as fases do desenvolvimento da aplicação são sucintamente descritas, e

quando necessário, auxiliadas por um esquema gráfico. Para além disso, serão descritas todas

as funcionalidades exigidas, e será ainda neste capítulo definida a interface com o utilizador.

É aqui explicada em mais detalhe a tecnologia utilizada, assim como o modelo de dados e

arquitectura escolhidas.

No quarto e último capítulo descrevem-se os objectivos alcançados, assim como se comparam

os objectivos iniciais com os concluídos no final do projecto.



7 Capitulo II - Objectivos e Metodologias

7.1 Objectivos

O objectivo principal que nos propomos atingir é no final do desenvolvimento do trabalho de

projecto termos uma ferramenta que funcione, simples e que reflicta os requisitos que forem

identificados. Ao atingirmos este objectivo teremos então um software pronto a ser

comercializado. Pretendemos ainda atingir um grau de desenvolvimento pessoal no que diz

respeito às tecnologias que iremos utilizar. Assim como, uma aprendizagem no que diz

respeito à gestão de projectos realizados em equipa.

7.2 Calendarização

A figura seguinte mostra a calendarização das fases mais importantes do nosso projecto.

24/Set Atribuição de Orientador de Projecto

24/Set 15/Oct

Análise de Requisitos

Especificação de Sistema

15/Oct 17/Oct

Projecto Arquitectural

Projecto de Interface

17/Oct 20/Oct Esboço de interface

20/Oct 14/Nov Codificação e Integração

14/Nov 21/Nov Período de testes

21/Nov 23 /Nov Entrega do Projecto

Figura 1 – Calendarização



7.3 Abordagem Metodológica

Foram definidas várias etapas, para o desenvolvimento da ferramenta de Helpdesk, de modo a

garantir uma construção estruturada e coerente. Estas etapas foram definidas em intervalos de

tempo (definidos na calendarização) que, mais do que prazos críticos, funcionam como

orientadores a seguir, para garantir que se segue um desenvolvimento atempado. Por uma

questão de organização decidimos adoptar um modelo de desenvolvimento que nos obrigasse

a nós próprios a cumprir com um conjunto de tarefas sequenciais no tempo. A este tipo de

modelos geralmente dá-se o nome de modelo em cascata [8], será este o modelo a seguir no

processo de desenvolvimento do software. Podemos ver na figura 2 o modelo em cascata.

Este modelo segue uma abordagem ‘top-down’ [9], e tem como principal característica a

sequência de actividades, onde cada fase transcorre completamente e os seus resultados são

vistos como necessários para a entrada numa nova fase.

Figura 2 – Modelo em Cascata



7.3.1 Plano de actividades

7.3.1.1 Especificação

1. Análise de Requisitos: levantamento das necessidades da aplicação. A análise tem

como objectivo produzir uma especificação de requisitos.

2. Especificação de Sistema: descrição funcional do sistema.

7.3.1.2 Desenho do Projecto

1. Projecto Arquitectural: onde é desenvolvido um modelo conceptual para o sistema.

2. Projecto de Desenvolvimento.

7.3.1.3 Implementação

1. Codificação: a implementação em si do sistema numa linguagem de programação.

2. Integração.



8 Capítulo III – Trabalho Realizado

8.1 Análise de requisitos

Por definição: requisitos são as necessidades às quais o produto deve atender para resolver.

A especificação de requisitos é um documento que contém a descrição precisa de cada

funcionalidade e/ou necessidade para o sistema. Esta deve evitar ao máximo termos ambíguos

ou duvidosos, que podem ser um futuro ponto de discórdia ou controvérsia. A especificação

de requisitos deve descrever os aspectos funcionais (requisitos funcionais) do sistema e

também suas características estruturais (estrutura lógica). Pode-se relacionar as características

funcionais com as acções do sistema. As características não funcionais podem ser

relacionadas com qualidades ou atributos do sistema.

8.1.1 Requisitos – Funcionalidades Pretendidas

No processo de levantamento de requisitos foram identificados um conjunto de

funcionalidades pretendidas. É esse conjunto de funcionalidades que descrevemos de seguida.

1. Só acedem à aplicação utilizadores válidos e activos através de um processo de login.

2. Sempre que um utilizador acede pela primeira vez à aplicação é-lhe solicitada a

alteração da sua password.

3. Existe um processo de recuperação de password.

4. Todos os colaboradores podem colocar pedidos em todos os tipos de helpdesk.

5. O acompanhamento dos pedidos é realizado em modo online através da utilização de

um internet browser.

6. Os pedidos podem ter prioridades diferentes.

7. ‘Aberto’ é o estado inicial de um pedido.

8. ‘Fechado’ é o estado final de um pedido. Este estado é irreversível.

9. Ao longo do processo entre o estado ‘Aberto’ e o estado ‘Fechado’ os pedidos sofrem

alterações de estado que serão sempre registadas num histórico.

10. Um pedido tem que ter sempre uma descrição, um dono, um criador, uma data de

colocação.



11. Um pedido não tem que ser necessariamente ‘Resolvido’. Por isso é necessário a

gestão de tipos de resolução de pedidos.

12. Tem de existir a possibilidade de qualquer dos intervenientes no processo solicitar

mais informação sobre o pedido.

13. Existem três tipos de utilizadores da aplicação, os utilizadores normais, os técnicos e o

helpdesk.

14. O utilizador helpdesk (área funcional) é quem recebe todos os pedidos colocados pelos

utilizadores na sua área. É este utilizador que faz a atribuição de pedidos a técnicos

mas que também pode concluir pedidos.

15. O utilizador helpdesk também pode colocar pedidos em nome de utilizadores, por

exemplo no caso em que o computador não funcionar o utilizador não poder colocar o

pedido.

16. Os técnicos também visualizam a caixa de pedidos abertos do helpdesk e sendo assim

podem atribuir pedidos a eles próprios. São os técnicos e o utilizador Helpdesk que

concluem os pedidos.

17. Só os utilizadores que colocaram os pedidos, são os que podem fechar os mesmos.

18. É necessária informação sobre o número de pedidos atribuídos a cada técnico de forma

a optimizar a atribuição dos mesmos.

19. Os pedidos devem estar agrupados, no que ao utilizador diz respeito, em quatro níveis:

à espera de intervenção do utilizador, colocados pelo utilizador mas atribuídos, à

espera de intervenção por parte de outrem e concluídos ou fechados.

20. Só o utilizador pode reabrir pedidos concluídos.

21. Os pedidos devem contemplar a funcionalidade de, ao serem criados, se anexarem

ficheiros.

22. Têm de existir notificações via mail.

23. Os pedidos podem ser pesquisados de forma rápida através do seu número ou através

de uma pesquisa avançada.

24. Cada pedido pode ter um conjunto de utilizadores que estão interessados no desenrolar

do mesmo. Sempre que existir uma alteração, estes utilizadores são notificados via

mail.

25. É necessário um BackOffice de controlo de tabelas mestres. Este deve permitir criar,

modificar apagar utilizadores, tipos de resolução, ajudas de tipificação e prioridades.

26. É necessário um conjunto de relatórios que permitam um visionamento sobre a

utilização da ferramenta.



27. Deve existir um conjunto de relatórios que permita uma análise do desempenho dos

técnicos.

28. Devem ser fornecido um conjunto de relatórios que permita uma análise por áreas e

grupos de utilizadores de colocação de pedidos.

8.1.2 Requisitos – Envolvidos com o Sistema

8.1.2.1 Estado dos Utilizadores

• Activo

• Inactivo

Os utilizadores podem estar no estado activo ou inactivo.

8.1.2.2 Perfis de Utilizadores

1. Normal

2. Helpdesk

3. Normal e BackOffice

4. BackOffice

5. Técnico

6. Técnico e BackOffice

Os tipos de utilizador são implementados através de uma estratégia de permissões. Os

utilizadores com permissões ‘BackOffice’ têm acesso ao BackOffice da aplicação. Os

utilizadores com permissões ‘Helpdesk’ são os utilizadores que recebem os pedidos colocados

e numa primeira instância realizam o primeiro nível de filtragem de pedidos. Os técnicos são

os responsáveis por responder ao pedido e são os utilizadores com permissões de ‘Técnico’.

Por fim, os utilizadores com permissões ‘Normal’ são utilizadores normais.



8.1.2.3 Ambiente do Utilizador

O ambiente do Utilizador é obtido através de um Web browser, pois o projecto será

desenvolvido como uma “Web Application” [10].

8.1.3 Requisitos – Desempenho

Dependendo do número de utilizadores pretendidos terá que se dimensionar o tipo de servidor

necessário, dado que sendo uma aplicação via Web o número de sessões poderá ter um

impacto notório no desempenho da aplicação.

8.1.4 Estados do Pedido

1. Aberto

2. Atribuído

3. Em Avaliação

4. Planeado

5. Em Execução

6. Requer Informação

7. Concluído

8. Fechado

8.1.4.1 Aberto

O estado aberto é o estado em que se encontra o pedido a partir do momento em que o mesmo

é criado. É o estado inicial, os pedidos em estado aberto estão na caixa de helpdesk.

8.1.4.2 Atribuído

Significa que o pedido está atribuído, ou seja que foi atribuído a um técnico para resolução.

8.1.4.3 Em Avaliação

É um estado apenas disponível para o Helpdesk e os técnicos, que informa que o pedido se

encontra a ser estudado.



8.1.4.4 Planeado

O helpdesk ou o técnico após avaliação do pedido informa o utilizador do tempo disponível

para a sua resolução no caso da resolução do mesmo não ser imediata.

8.1.4.5 Em Execução

O pedido está a ser resolvido.

8.1.4.6 Requer Informação

O helpdesk ou o técnico necessitam de obter mais informação sobre o pedido. Ao colocar o

mesmo neste estado é enviado um mail para o utilizador a solicitar a informação. O dono do

pedido passa a ser o utilizador, mas quando inserir a informação requerida o pedido volta

novamente ao técnico que solicitou a informação.

8.1.4.7 Concluído

O helpdesk ou o técnico deram o pedido por concluído. Neste caso o dono do pedido passa a

ser novamente o utilizador que poderá fechar o pedido ou então reenviar o mesmo para o

técnico, informando as razões porque não considera que o pedido esteja concluído.

Neste caso o pedido passa para o técnico no estado em avaliação.

8.1.4.8 Fechado

Só o utilizador pode fechar o pedido. O fecho do pedido significa que a solicitação chegou ao

seu fim e o utilizador está satisfeito com a resolução ou com o esclarecimento prestado.

8.1.5 Tipos de Resolução

1. Resolvido

2. Alternativa

3. Esclarecido

4. Não Reproduzível

5. Sem Resolução

6. Recusado

7. Duplicado



8.1.5.1 Resolvido

A solicitação introduzida foi objecto de uma intervenção e foi resolvido o problema.

8.1.5.2 Alternativa

É apresentada uma alternativa à questão introduzida e não a resolução tal como pretendia o

utilizador.

8.1.5.3 Esclarecido

A situação apresentada não era um problema e portanto esclareceu-se o utilizador.

8.1.5.4 Não Reproduzível

O utilizador apresentou uma situação que não foi possível reproduzir, pelo que não se

consegue identificar nem resolver.

8.1.5.5 Sem Resolução

O problema apresentado não tem resolução conhecida.

8.1.5.6 Recusado

É recusado a resolução deste pedido.

8.1.5.7 Duplicado

Já existe um pedido do mesmo utilizador para resolver esta questão.

8.1.6 Prioridades do Pedido

Sobre as prioridades dos pedidos optámos por seleccionar quatro tipos que achamos serem

suficientes para descrever o grau de urgência:

• Urgentes e Importantes

• Importantes e não Urgentes

• Urgentes e não Importantes

• Não Urgentes e Não Importantes



8.1.7 Estrutura do Pedido

Sobre o pedido propriamente dito, convém distinguir com bastante clareza os seguintes três

conceitos: o utilizador do pedido, o dono do pedido e o criador do pedido. O utilizador do

pedido é o utilizador ao qual o pedido diz respeito. Pode não ser ele o criador do mesmo, dado

que o helpdesk pode criar um pedido em seu nome. O criador do pedido é quem

efectivamente colocou o pedido no sistema. O dono do pedido é o utilizador a quem o pedido

está atribuído para realizar uma tarefa.

Importa referir que, sempre que um pedido é criado o primeiro dono é o utilizador helpdesk

da área funcional onde o pedido foi criado, e quando um pedido é concluído ou fechado o

dono do mesmo é sempre o utilizador ao qual o pedido diz respeito.

Ao se colocar um pedido a propriedade obrigatória de preenchimento é a descrição. O

utilizador poderá ainda seleccionar uma prioridade, escolher uma ajuda de tipificação, inserir

observações, inserir anexos e por fim inserir interessados.

Os interessados não são nada mais do que utilizadores que acompanharam a evolução do

pedido. O utilizador ao qual o pedido diz respeito e o helpdesk da área funcional relacionada

são sempre considerados interessados no pedido.

8.1.8 Relatórios

São especificados nesta secção um conjunto de documentos de reporte que o sistema deverá

fornecer. Os relatórios serão uma ferramenta de trabalho que permitirá aferir sobre o

funcionamento do sistema, sobre a sua utilidade, assim como obter informação relevante para

melhorar o desempenho da empresa.

8.1.8.1 BackOffice

1) Tipos de tipificação

2) Pedidos descriminados por dono

3) Pedidos agrupados por estados - por dias em aberto

4) Pedidos não fechados agrupados por dias em aberto

5) Pedidos Fechados agrupados por utilizados

6) Pedidos concluídos agrupados por utilizador e por dias em aberto



7) Pedidos descriminados por helpdesk Com totais e subagrupados por estados de

pedido.

8.1.8.2 Helpdesk

1) Meus pedidos

2) Pedidos colocados no helpdesk

3) Pedidos fechados

4) Pedidos por técnico

5) Pedidos de que o helpdesk é dono ordenados por aberto á mais tempo

6) Detalhe do pedido

7) Histórico do pedido

8.1.8.3 Técnico

1) Meus pedidos

2) Detalhe do pedido

3) Historico do pedido

4) Pedidos de que o técnico é dono ordenados por aberto à mais tempo

8.1.8.4 Utilizador

1) Meus pedidos

2) Histórico do pedido

8.1.9 Pesquisa

As pesquisas são sempre algo de extrema importância neste tipo de ferramentas. A sua

principal função na nossa aplicação será encontrar um determinado pedido ou um conjunto de

pedidos com as mesmas características. Para atingirmos tal objectivo vamos desenvolver dois

tipos de pesquisa, a pesquisa rápida e a pesquisa avançada.



8.1.9.1 Pesquisa Rápida

Consiste em procurar um pedido pelo seu identificador, ou seja pelo número de pedido.

8.1.9.2 Pesquisa Avançada

Consiste em procurar um pedido introduzindo um conjunto de dados para pesquisa.

8.2 Projecto Arquitectural

Esta secção define a arquitectura do sistema, assim como as ferramentas e tecnologias que são

utilizadas. O sistema de Heldesk Advanced Solution foi desenvolvido recorrendo à

Framework .NET 2.0 [11] da Microsoft e utilizando o modelo Aplication Service Provider

(ASP). Isto significa que os utilizadores podem aceder à aplicação Helpdesk Advanced

Solution a partir de uma ferramenta de acesso à internet ou Web browser. Esta Framework

permitiu-nos a utilização de variados componentes como o Crystal Reports da Bussiness

Objects [1] para executar os relatórios pretendidos.

A arquitectura escolhida permite que haja uma ou mais instâncias da aplicação a correr

simultaneamente.

8.2.1 Ferramentas e Tecnologias

O sistema Helpdesk Advanced Solution foi concebido e desenvolvido com o recurso às

ferramentas e tecnologias da Microsoft. Esta aplicação foi implementada no ambiente de

desenvolvimento. NET. Como principais componentes desta Framework utilizados neste

trabalho destacam-se as linguagens de programação C# [5], VB .NET [6] e ASP. NET 2.0 [2],

não esquecendo a tecnologia ADO .NET 2.0 [3]. A escolha desta Framework incide

principalmente na possibilidade de reutilização de código de qualquer outro projecto escrito

para a Framework .NET, mesmo que em linguagem diferente. Uma página ASP.NET escrita

em VB.NET [6] pode chamar componentes escritos em C# ou Web Services escritos em C++,

por exemplo. Ao contrário da tecnologia ASP, as aplicações ASP.NET são compiladas antes



da execução, trazendo sensível ganho de desempenho. As aplicações Web ASP .NET

necessitam do Framework .NET e do servidor IIS para serem executadas, pelo menos na

plataforma Windows. A Framework .NET é uma iniciativa da Microsoft em que visa uma

plataforma única para desenvolvimento e execução de sistemas e aplicações.

O sistema disponibiliza os serviços aos utilizadores recorrendo a uma arquitectura servidor-

cliente, utilizando como servidor o Microsoft IIS (“Internet Information Service”). Os

utilizadores acedem à aplicação através de um “Web browser”, que pode ser o Internet

Explorer da Microsoft, Firefox, Netscape ou outro idêntico.

A base de dados que contem a informação introduzida e manipulada pela aplicação é também

uma tecnologia Microsoft, o SQL Server 2005 Express Edition [4]. A arquitectura do

Framework .NET 2.0 encontra-se ilustrada na Figura 3.

Figura 3 – Arquitectura Framework .NET

Como SGBD (Sistema Gestor de Base de Dados) utilizámos a aplicação Microsoft SQL

Server 2005 Express Edition [4], para a qual a Framework .NET está especialmente

preparada, possuindo mecanismos que possibilitam um acesso optimizado aos dados geridos

por este SGBD. Como referido anteriormente, como ambiente de desenvolvimento é utilizado

o Microsoft Visual Studio 2005, ambiente especialmente indicado para a Framework .NET e

como servidor Web usámos o IIS da Microsoft (Internet Information Service).



Este conjunto de ferramentas tem como vantagem o facto de serem produtos desenvolvidos

pela Microsoft e consequentemente serem facilmente compatíveis umas com as outras.

8.2.1.1 C# (CSharp)

A linguagem C# [5] é uma linguagem de desenvolvimento orientada por objectos, criada pela

Microsoft, que apresenta muitas semelhanças à linguagem JAVA. É uma linguagem

desenvolvida especialmente para integração na Framework .NET e consequentemente

apresenta vantagens ao nível da integração com as outras componentes da mesma.

Página da ferramenta: http://msdn2.microsoft.com/en-us/vcsharp/aa336809.aspx

8.2.1.2 ADO .NET

A tecnologia ADO.NET [3] (ou a nova tecnologia ActiveX Data Objects) consiste num

conjunto de classes definidas pela Framework .NET (localizadas no namespace System.Data)

que pode ser utilizado para aceder aos dados armazenados numa base de dados remota.

Sendo um mecanismo de acesso a dados, que podem ser armazenados em tecnologias

diferentes (SQL SERVER, XML, Oracle,etc), possibilita que esse acesso seja feito de forma

semelhante independentemente da forma de armazenamento. Utiliza para esse efeito objectos

como os DataSets e DataReaders.

Página da ferramenta: http://www.microsoft.com/brasil/msdn/adonet/default.mspx

8.2.1.3 Visual Studio 2005 Professional Edition

O Microsoft Visual Studio é um pacote de programas da Microsoft, para desenvolvimento de

Software, especialmente dedicado ao Framework .NET e às linguagens Visual Basic (VB), C,

C++ (C Plus Plus), C# (C Sharp) e J# (Jey Sharp).

Embora se possa desenvolver aplicações ASP.NET utilizando somente o “notepad” e o

compilador .NET, o ambiente de desenvolvimento mais comum das aplicações ASP.NET é o

Visual Studio .NET já que possui algumas características que facilitam o trabalho do

programador, como os componentes visuais para criação de formulários de páginas Web. No


http://msdn2.microsoft.com/en-us/vcsharp/aa336809.aspx

http://www.microsoft.com/brasil/msdn/adonet/default.mspx


nosso caso, o ambiente de desenvolvimento utilizado foi o Visual Studio 2005 Professional

[10].

Página da ferramenta: http://msdn2.microsoft.com/pt-br/asp.net/Aa336618.aspx

8.2.1.4 ASP .NET 2.0

ASP.NET [2] é a plataforma da Microsoft para o desenvolvimento de aplicações Web e é o

sucessor da tecnologia ASP. É um componente do IIS que permite através de uma linguagem

de programação integrada na Framework .NET criar páginas dinâmicas.

Não é nem uma linguagem de programação como VBScript, PHP, nem um servidor Web

como IIS ou Apache. O ASP.NET é baseado na Framework .NET, herdando todas as suas

características, e por isso, como qualquer aplicação .NET, as aplicações para essa plataforma

podem ser escritas em várias linguagens, como C# e Visual Basic .NET.

A tecnologia ASP .NET apresenta algumas vantagens como o mecanismo de “web forms”

(páginas .aspx), que permite o desenho de interfaces de uma forma relativamente simples.

Também é de destacar o facto de se poderem produzir controlos (.ascx) que podem ser

reutilizados em múltiplas páginas, permitindo menor esforço de desenvolvimento, e que no

caso deste trabalho é um mecanismo essencial, pois são a base dos módulos da nossa

aplicação.

Página da ferramenta: http://www.asp.net/

8.2.1.5 ASP .NET Maker 3

Esta ferramenta permitiu-nos ajuda na execução do módulo de BackOffice, visto este módulo

servir para visualizar, editar, pesquisar, adicionar e apagar registos nas tabelas da base de

dados do Helpdesk Solution. Esta ferramenta permite gerar código para ASP .NET 2.0 a partir

de uma base de dados Microsoft SQL Server.

Página da ferramenta: http://www.hkvstore.com/aspnetmaker/


http://msdn2.microsoft.com/pt-br/asp.net/Aa336618.aspx

http://www.asp.net/

http://www.hkvstore.com/aspnetmaker/


8.2.1.6 IIS – Internet Information Services

IIS, é um servidor Web, mail e FTP da Microsoft. A escolha do mesmo teve a ver com o

ambiente de desenvolvimento para execução deste trabalho.

8.2.1.7 SQLSERVER 2005 Express Edition

O Microsoft SQL Server 2005 Express Edition [4] (SQL Server Express) é um Sistema

Gestor de Base de Dados da Microsoft poderoso e confiável que fornece recursos robustos,

protecção de dados e desempenho para clientes de aplicativos incorporados, aplicativos Web

simples e armazenamentos de dados locais. É um produto gratuito que além de utilizar o

mesmo “engine” do SQL Server 2005, possui características de rede e segurança que o

diferenciam das demais edições do SQL Server 2005.

Por ser uma edição digamos, “light”, possui algumas limitações. Como consequência,

características como execução de consultas em paralelo não é suportado pelo SQL Server

Express. Suporta um número máximo de 50 instâncias na mesma máquina desde que cada

instância seja unicamente identifica, ou seja, pode-se realizar até 50 instalações do SQL

Express desde que cada instância tenha um nome diferente. Por padrão o SQL Server Express

é instalado com uma “named instance” chamada SQLEXPRESS.

O SQL Server 2005 Express não possui a limitação de usuários concorrentes, conhecida como

“Concurrent Workload Governor”, e suporta a maioria das funcionalidades do SQL Server

2005.

Sendo seguro e totalmente grátis, compatível com outras edições do SQL Server 2005 e sua

integração com o Visual Studio 2005, torna mais simples o desenvolvimento de aplicações

que utilizam o SQL Server como repositório de dados.

Criado para ser de protótipo rápido e de fácil implantação, o SQL Server Express está

disponível gratuitamente, sendo possível redistribuí-lo com outros aplicativos.

Mais uma vez a escolha deste produto teve a ver com o ambiente de desenvolvimento do

trabalho.

Página da ferramenta: http://msdn2.microsoft.com/pt-br/sql/Aa336346.aspx


http://msdn2.microsoft.com/pt-br/sql/Aa336346.aspx


8.2.2 Arquitectura e Esquema Relacional

8.2.2.1 Arquitectura do Sistema

A arquitectura do sistema é definida pela seguinte figura:

Figura 4 – Arquitectura do sistema.

8.2.2.2 Esquema Relacional

Este esquema determina a estrutura dos dados, assim como a interacção entre os vários

componentes. Este esquema é particularmente útil para estruturar uma Base de Dados, dado

que foi feita uma transposição directa da informação. Podemos ver o esquema na figura 5.



Figura 5 – Esquema relacional da base de dados.



8.2.2.3 Base de Dados: Tabelas

Depois do levantamento e análise de requisitos, percebeu-se quais as necessidades inerentes

ao desenvolvimento e especificação da base de dados.

A mesma foi estruturada de acordo com o esquema relacional previamente definido.

Helpdesk – Tabelas

Figura 6 – Tabelas da Base de Dados Helpdesk

• Areas: Esta tabela contém a descrição das áreas funcionais referentes aos

Utilizadores;

• TipoPedido: Esta tabela contém ajudas de tipificações de pedidos – nível 1;

• TipoPedido1: Esta tabela contém ajudas de tipificações de pedidos – nível 2;

• TipoPedido2: Esta tabela contém ajudas de tipificações de pedidos – nível 3;

• Descrições de Tipificação: Esta tabela contém o tipo de informação necessária

correspondente à escolha de tipificação dos Utilizadores (Referente às Tabelas

TipoPedidoX);

• Estados: Esta tabela contém a descrição do estado possível dos Utilizadores (Activo

ou Inactivo);

• EstadosPedidos: Esta tabela contém a descrição de todos os estados possíveis dos

Pedidos;



• Funcoes: Esta tabela contém as descrições referentes às Funções dos Utilizadores;

• Helpdesks: Esta tabela contém todos os tipos de Helpdesk existentes (SI, RH, MN,

EM);

• Historico: Esta tabela contém o histórico das transições de estado dos Pedidos

inseridos;

• Permissoes: Esta tabela contém os tipos de permissões existentes dos Utilizadores;

• Prioridades: Esta tabela contém os tipos de prioridade para os pedidos;

• Resolucao: Esta tabela contém os tipos de resoluções possíveis para os pedidos;

• Utilizadores: Esta tabela contém toda a informação necessária dos utilizadores do

sistema.

• UnidadesOrganizacionais: Esta tabela contém as Unidades Organizacionais

existentes na empresa;

• PedidosCab: Esta tabela contém os dados necessários dos pedidos colocados pelos

Utilizadores;

• Localidades: Esta tabela contém as Localidades existentes dos Utilizadores;

8.3 Desenvolvimento do Projecto

8.3.1 Interface Utilizador

A interface utilizador é não só o “lugar onde pessoas e computadores se encontram”, vai

muito para além deste factor pois esta tem um especial impacto sobre o esforço que um

utilizador precisa de realizar para compreender o sistema na sua plenitude. Tentámos ser

simples e intuitivos.

Neste capítulo vamos mostrar os ecrãs disponíveis na aplicação, sendo que cada um é

acompanhado por uma breve descrição para uma melhore compreensão dos mesmos.



8.3.1.1 Login

Descrição: Ecrã inicial em que o utilizador insere as credenciais (Utilizador e Password) para

aceder ao sistema.

Figura 7 – Ecrã de Login.



8.3.1.2 Login – Falha Autenticação

Descrição: Ecrã inicial em que o utilizador falhou a autenticação devido a ter inserido

credenciais inválidas para aceder ao sistema.

Figura 8 – Ecrã de Falha de Login.



8.3.1.3 Menu Principal Utilizador

Descrição: Menu inicial apresentado ao Utilizador após Login efectuado com sucesso.

Neste Menu é permitido ao utilizador inserir pedidos para os Sistemas de Informação,

Recursos Humanos, Manutenção e Economato. Permite também a visualização de pedidos

atribuídos ao mesmo, pedidos em desenvolvimento, pedidos já concluídos e pedidos fechados.

Figura 9 – Menu Principal Utilizador.



8.3.1.4 Menu Inserção Pedido

Descrição: Nesta visualização é permitido ao utilizador verificar os seus dados pessoais.

Figura 10 – Menu Inserção Pedido.



Menu Inserção Pedido (continuação)

Descrição: Nesta visualização é permitido ao utilizador a inserção de um pedido no SI, onde

o mesmo está a requerer DVD´s. Podemos verificar na ajuda de tipificação os detalhes do

pedido.

Figura 11 – Menu Inserção Pedido (2).




Descrição: Descrição: Nesta visualização é permitido ao utilizador a inserção de observações

no pedido.





Descrição: Nesta visualização é permitido ao utilizador a adição de interessados ao pedido.





Descrição: Nesta visualização é permitido ao utilizador anexar ficheiros no pedido.





Descrição: Após submissão de pedido, podemos verificar que o mesmo fica em

desenvolvimento pelo HelpdeskSI.





Descrição: Após submissão de pedido, também é enviado um mail para o utilizador e

interessados (os interessados vão em CC).




8.3.1.5 Detalhe de Pedido

Descrição: É possível a visualização dos detalhes do pedido, quando o mesmo é

seleccionado.

Figura 17 – Reporte Pedido.



8.3.1.6 Histórico de Pedido

Descrição: É possível a visualização do histórico do pedido, quando o mesmo é seleccionado.

Figura 18 – Histórico de Pedido.



8.3.1.7 Pesquisa Avançada

Descrição: É possível fazer uma pesquisa avançada sobre os pedidos.

Figura 19 – Pesquisa Avançada.



8.3.1.8 BackOffice

Descrição: Menu inicial apresentado ao Utilizador após ter seleccionado a opção de

BackOffice. No BackOffice, são efectuadas todas as operações de gestão sobre as Tabelas da

Base de Dados Helpdesk. Permite a visualização de vistas personalizadas, usando queries à

base de dados. Permite também a visualização de relatórios pré-definidos.

Nota: Só quem tem permissões de BackOffice é que consegue aceder ao mesmo.

Figura 20 – BackOffice.



8.3.1.9 BackOffice - Visualização de relatório de Pedidos não fechados

Descrição: Visualização de relatório de pedidos não fechados, sendo os mesmos agrupados

por duração de dias em aberto. É também permitido exportar os mesmos para Excel e Word.

Figura 21 – Relatórios - BackOffice.



8.3.1.10 BackOffice - Adicionar Utilizador à Tabela Utilizadores

Descrição: Ecrã de adição de utilizador.

Figura 22 – Adição de Utilizador.

8.3.2 Fluxo Principal de Pedidos

Aqui descrevemos o fluxo que relaciona pedidos e diferentes tipos de utilizadores com o

diferente tipo de acções que cada interveniente pode tomar nos mesmos. Tudo deverá

começar com a inserção do pedido. O utilizador ou o helpdesk em nome deste colocará um

pedido que cairá na caixa de helpdesk no estado aberto no meio o pedido poderá passar por

diversos estados até que será fechado apenas pelo utilizador do pedido.



8.3.2.1 Diagrama de Fluxo de Estados de Pedido

Na figura abaixo podemos verificar o fluxos de estados possíveis dos pedidos inseridos.

Figura 23 – Diagrama de Fluxos de Estado de Pedidos.



8.3.2.2 Configurações Técnicas

Para pôr a correr esta aplicação no ambiente de desenvolvimento Visual Studio 2005 temos

que definir alguns parâmetros. De seguida descrevemos quais os parâmetros que devemos ter

em atenção.

Base de Dados

• Temos que copiar a Base de Dados para o directório do SQL Server. Assim sendo

copiar os dois ficheiros (Helpdesk_log.ldf e Helpdesk.mdf) para “C:\Program

Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data”.

Visual Studio 2005

Figura 24 – Solution Explorer – Visual Studio 2005.



Para pôr a correr esta aplicação no ambiente de desenvolvimento Visual Studio 2005 temos de

definir alguns parâmetros:

No Solution Explorer do Visual Studio 2005, temos que alterar os ficheiros Web.config do

projecto Backoffice e Helpdesk da seguinte forma:

• No Projecto Helpdesk, alterar a connectionString para a base de dados respectiva,

como o exemplo abaixo:

<connectionStrings>

<add name="HelpdeskConnectionString" connectionString="Data

Source=RIGO\SQLEXPRESS;Initial Catalog=Helpdesk;Integrated

Security=True" providerName="System.Data.SqlClient"/>

</connectionStrings>

• No Projecto Backoffice, alterar a connectionString para a base de dados respectiva,

como o exemplo abaixo:

<connectionStrings>

<add name="HelpdeskConnStr" connectionString="Data

Source=RIGO\SQLEXPRESS;Initial Catalog=Helpdesk;Integrated

Security=True" providerName="System.Data.SqlClient" />

</connectionStrings>

De seguida no Projecto Helpdesk, alterar o ficheiro HelpDeskDetalhe1.aspx.cs da seguinte

forma:

• Onde está a linha: auxanexo = auxanexo.Replace("C:\\Documents and Settings\\Ricardo\\My

Documents\\Visual Studio

2005\\Projects\\HelpDeskSolution\\Helpdesk\\Upload\\", "~/Upload/");

Substituir pelo directório correcto.



No Projecto Helpdesk, alterar o ficheiro InserirPedido.aspx.cs da seguinte forma:

• Onde estão as linhas:

arquivo.PostedFile.SaveAs(@"C:\Documents and Settings\Ricardo\My

Documents\Visual Studio 2005\Projects\HelpDeskSolution\Helpdesk\Upload\" +

Session["idUtilizador"].ToString() + "-" + data + "-" + s2);

txtAnexos.Text = txtAnexos.Text + @"C:\Documents and Settings\Ricardo\My

Documents\Visual Studio 2005\Projects\HelpDeskSolution\Helpdesk\Upload\" +

Session["idUtilizador"].ToString() + "-" + data + "-" + s2 + ";" + "\n";


No Projecto Helpdesk, dentro do folder “Relatórios” alterar os ficheiros de relatórios “.aspx”

de forma a alterar as linhas que contêm: <Report FileName="C:\Documents and Settings\Ricardo\My Documents\Visual Studio

2005\Projects\HelpDeskSolution\Helpdesk\Relatorios\pedidosHelpdesk.rpt">

</Report>




9 Capitulo IV – Conclusões

As novas tecnologias e o desenvolvimento de software têm cada vez mais um papel nuclear

dentro das organizações. Dentro desta premissa, os custos de desenvolvimento de software

assumem uma relevância enorme dentro do planeamento das mesmas. Com este projecto,

aprendemos como se desenvolve um software desde a fase de levantamento e análise de

requisitos até à implementação propriamente dita. Acreditamos que este factor constitui uma

mais valia para os nossos percursos profissionais.

Após analisar todas as vertentes do projecto serão apresentadas as principais conclusões e

contribuições que se podem retirar deste trabalho.

Todos os planos iniciais foram cumpridos. Tivemos como preocupação central responder aos

requisitos identificados ou seja às funcionalidades pedidas. A outra grande preocupação foi

com que conseguíssemos concretizar uma aplicação de funcionamento simples, por mais

complexas que fossem as regras de negócio especificadas.

As funcionalidades descritas estão todas implementadas, e, no que diz respeito à interface,

pensamos que a mesma é ao mesmo tempo agradável e funcional, sendo que, constitui o

aspecto onde se poderá trabalhar um pouco mais em termos futuros pelo menos no que diz

respeito ao design apresentado.

Mais uma vez importa salientar aquilo que consideramos ser a mais valia deste software de

helpdesk, a sua fácil escalabilidade. Este era talvez o maior desafio que se deparava no

desenho de implementação da ferramenta. Para implementarmos mais um helpdesk na

ferramenta basta para isso despender algum esforço de desenvolvimento que não ultrapassará

o período de uma hora. Este é sem dúvida o factor diferenciador relativamente aos produtos

que existem no mercado. É também, um factor bastante interessante ao nível do aspecto

financeiro, mais uma vez se aplica a premissa, tempo é dinheiro.

As ajudas de tipificação, com a implementação do BackOffice ficam completamente ao dispor

de quem percebe do negócio, nunca esquecendo que cada empresa e cada negócio têm as suas

especificidades próprias. Estas ajudas podem ser parametrizadas através do BackOffice.

Conseguimos ainda implementar o fluxo de estados de pedidos desenhado e os relatórios

solicitados nos requisitos assim como o envio de informação sobre a alteração de estados de

pedidos via mail. No que diz respeito ao desenvolvimento pessoal, a realização deste trabalho

foi sem dúvida uma experiência enriquecedora. Este projecto, quer no que diz respeito à

investigação, quer no que diz respeito a organização, foi sem dúvida um trabalho proveitoso



que nos servirá de exemplo e nos muniu de ferramentas que nos serão extremamente úteis

quer ao nível pessoal quer ao nível profissional.

Finalmente, sabemos que este projecto não representa o fim de um percurso mas sim apenas

mais uma etapa importante na nossa formação. A aprendizagem é algo que se pretende ser

contínua ao longo da vida num mundo globalizado e competitivo como de hoje. Olhamos para

este trabalho com a certeza de que se formos capazes de partir do zero e atingirmos o

objectivo com vontade, trabalho, dedicação e perseverança atingiremos os objectivos a que

nos propusermos ao longo da nossa vida.




10 Referências

[1] Web Site comercial da ferramenta Business Objects:

http://www.businessobjects.com/

[2] Microsoft ASP .NET 2.0 Web Site.

http://asp.net

[3] Dennis Lu, Doug Rothaus, “Best Practices for Using ADO.NET”, Julho 2002.

http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/dnadonet/html/adonetbest.asp

Dev Center – ADO .NET WebSite:


[4] Microsoft SQL Server 2005 Express Edition Web Site:

http://www.microsoft.com/sql/editions/express/default.mspx

[5] The C# Language Web Site.


[6] Visual Basic Developer Center Web Site:

http://msdn2.microsoft.com/pt-br/vbasic/default.aspx

[7] Visual Studio 2005 Professional Edition Web Site:

http://msdn2.microsoft.com/pt-br/vstudio/default.aspx

[8] Modelo em Cascata Web Site:

http://pt.wikipedia.org/wiki/Modelo_em_cascata

[9] Modelo Cascata ou Clássico Web Site:

http://w3.ualg.pt/~pventura/ep/aulas_tp/t1_g13.pdf

[10] Visual Studio 2005 Web Application Projects Web Site:


[11] .NET Framework Developer Center

http://msdn2.microsoft.com/pt-br/netframework/default.aspx

Engenharia Informática

3º Ano - 2º Semestre

António Ferrão Nº 20064161(Antigo: 2402334)

Ricardo Gonçalves Nº 20064162(Antigo: 2401870)

http://www.businessobjects.com/

http://asp.net/

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/html/adonetbest.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/html/adonetbest.asp


http://www.microsoft.com/sql/editions/express/default.mspx


http://msdn2.microsoft.com/pt-br/vbasic/default.aspx

http://msdn2.microsoft.com/pt-br/vstudio/default.aspx

http://pt.wikipedia.org/wiki/Modelo_em_cascata

http://w3.ualg.pt/%7Epventura/ep/aulas_tp/t1_g13.pdf


http://msdn2.microsoft.com/pt-br/netframework/default.aspx

Licenciatura em Eng.ª...

Documents

Transcript of Licenciatura em Eng.ª...