Projeto Aplicado CETAS

CENTRO UNIVERSITRIO MONTE SERRAT

ERIKA DE OLIVEIRA DO NASCIMENTO GLUCIA BARBOZA DE OLIVEIRA SOUZA

HLIO FERREIRA CRAVO NETO MARINA SUZUKI MARQUES MARIO MACHADO CHAME

DESENVOLVIMENTO DE SOFTWARE PARA O CONTROLE DE ATIVIDADES DOS ANIMAIS DO ZOO DO CURSO DE VETERINRIA DA UNIMONTE COM

NFASE EM QUALIDADE

Santos 2009




NFASE EM QUALIDADE

Trabalho Interdisciplinar apresentado disciplina

Projeto Aplicado como requisito parcial para a

obteno do certificado no 5 mdulo do Curso

Superior de Tecnologia em Anlise e

Desenvolvimento de Sistemas.

Orientador: Prof. MS. Nina Maria Bueno

Santos 2009

Nascimento, rika de Oliveira do, 1982- Desenvolvimento de software para o controle de atividades dos

animais do zoo do curso de veterinria da UNIMONTE com nfase em qualidade. / rika de Oliveira do Nascimento... [et al.]. 2009. 58 f. Orientador: Prof. MS. Nina Maria Bueno Trabalho de concluso de curso (graduao) - Centro Universitrio Monte Serrat, Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas, 2009.

1. Ergonomia de Software. 2. Gerncia de Projetos. 3. Estudo de caso. 4. Concluso. I. Bueno, Nina Maria. II. Desenvolvimento de software para o controle de atividades dos animais do zoo do curso de veterinria da UNIMONTE com nfase em qualidade.




NFASE EM QUALIDADE

Trabalho Interdisciplinar apresentado disciplina

Projeto Aplicado como requisito parcial para a

obteno do certificado no 5 mdulo do Curso

Superior de Tecnologia em Anlise e

Desenvolvimento de Sistemas.

Orientador: Prof. MS. Nina Maria Bueno

BANCA EXAMINADORA: ___________________________________________________________________ Nome do examinador: Titulao: Instituio: ___________________________________________________________________ Nome do examinador: Titulao: Instituio:

Santos 2009

RESUMO

Em todas as atividades, sempre buscou-se, no somente sua realizao de uma maneira eficaz, mas tambm sua execuo de forma eficiente para se atingir sua mxima qualidade, para isso, torna-se necessrio adotar tcnicas, padres e referncias a fim de se parametrizar os processos. Atentando a tudo isto foi desenvolvido um software para automatizar os controles das atividades desenvolvidas no CETAS Centro de Triagem de Animais Selvagens Lello, do curso de veterinria do Centro Universitrio Monte Serrat UNIMONTE, utilizando-se de tcnicas para desenvolvimento de software, tais como, entrevista com os usurios para levantamento dos requisitos; especificao e documentao dos requisitos; modelagem de dados; elaborao dos casos de uso; diagrama dos casos de uso; prototipao e desenvolvimento do sistema em linguagem C# (l-se C Sharp), fundamentando-as em uma pesquisa terica acerca de dois assuntos pertinentes e determinantes para se obter a qualidade em sistemas computacionais: ergonomia de software e gerenciamento de projeto.

Palavras chaves: Qualidade. Software. Desenvolvimento.

LISTA DE FIGURAS

Figura 01: Representao de interface pouco amigvel.......................................... 23

Figura 02: M utilizao de botes poup-up............................................................ 24

Figura 03: Mau emprego de menus em cascata ..................................................... 24

Figura 04: Menu Radio Button................................................................................. 26

Figura 05: Menu em cascata ................................................................................... 27

Figura 06: Caixa de mensagem............................................................................... 28

Figura 07: Caixa de dilogo..................................................................................... 29

Figura 08: cones explicativos ................................................................................. 31

Figura 09: Viso cclica de cada fase ...................................................................... 34

Figura 10: Representao do diagrama de rede em PDM ...................................... 36

Figura 11: Representao do diagrama de rede em ADM ...................................... 37

Figura 12: Representao do grfico curva S ......................................................... 42

Figura 13: Tela de registro de animal ...................................................................... 49

Figura 14: Tela de transferncia de animal ............................................................. 50

LISTA DE TABELAS

Tabela 1 - NBR ISO/IEC 9126-1 - Caractersticas da Qualidade de Software ......... 18

SUMRIO

1 INTRODUO ................................................................................. 8

2 FUNDAMENTAO TERICA...................................................... 10

2.1 ERGONOMIA DE SOFTWARE ................................................ 10 2.1.1 A Psicologia Cognitiva......................................................................... 10 2.1.1.1 Modelos ou Representaes Mentais.............................................. 11 2.1.1.2 Percepo ....................................................................................... 11 2.1.1.3 Memria........................................................................................... 12 2.1.1.4 O Raciocnio e o Aprendizado ......................................................... 13 2.1.1.5 O Curso das Aes.......................................................................... 14

2.1.2 Usabilidade ......................................................................................... 16 2.1.2.1 Ciclo da Engenharia da Usabilidade................................................ 19

2.1.3 Interface Homem Computador (IHC) .................................................. 20 2.1.3.1 Tcnicas utilizadas para obteno de uma interface amigvel........ 21

2.2 GERNCIA DE PROJETOS..................................................... 32 2.2.1 Fases e ciclos de vida do projeto ........................................................ 32 2.2.2 Processos de gerenciamento de projeto ............................................. 34 2.2.2.1 Gerenciamento de integrao do projeto......................................... 35 2.2.2.2 Gerenciamento do escopo do projeto.............................................. 35 2.2.2.3 Gerenciamento do tempo do projeto ............................................... 36 2.2.2.4 Gerenciamento de custos do projeto ............................................... 38 2.2.2.5 Gerenciamento da qualidade do projeto.......................................... 39 2.2.2.6 Gerenciamento dos recursos humanos do projeto .......................... 40 2.2.2.7 Gerenciamento da comunicao do projeto .................................... 41 2.2.2.8 Gerenciamento de riscos do projeto ................................................ 43 2.2.2.9 Gerenciamento de aquisies do projeto (subcontratao / suprimentos / contratos) ................................................................................ 44

2.2.3 Grupos de processos de Gerenciamento de projetos ......................... 44 2.2.3.1 Grupo de processos de iniciao .................................................... 45 2.2.3.2 Grupo de processos de planejamento ............................................. 45 2.2.3.3 Grupo de processos de execuo ................................................... 46 2.2.3.4 Grupo de processos de monitoramento e controle.......................... 46 2.2.3.5 Grupo de processos de encerramento ............................................ 47

3 ESTUDO DE CASO........................................................................ 48

4 CONCLUSO ................................................................................ 52

REFERNCIAS.................................................................................... 54

ANEXO A ............................................................................................. 57

8

1 INTRODUO

O presente trabalho tem como objetivo, descrever todos os processos

necessrios para obteno da qualidade no desenvolvimento e implantao de

software, partindo do interesse em viabilizar e constatar os benefcios na

automatizao dos processos manuais, de controle das atividades rotineiras dos

animais selvagens no CETAS Centro de Triagem de Animais Selvagens Lello, do

curso de veterinria do Centro Universitrio Monte Serrat UNIMONTE.

A crescente utilizao de softwares absorve cada vez mais, o interesse na

busca da qualidade no processo de desenvolvimento dos mesmos e determina que

esta seja uma meta crucial da rea. Entretanto, os desenvolvedores de software

enfrentam vrios problemas de natureza tcnica e gerencial. Tais problemas

englobam caractersticas inerentes de um processo de construo de software

como, por exemplo, a complexidade dos produtos de software, as dificuldades no

estabelecimento e estabilizao dos requisitos, as dificuldades de manuteno de

software e as dificuldades na comunicao entre os stakeholders - usurios,

desenvolvedores, enfim todos os envolvidos no desenvolvimento do software. O

desenvolvimento e implantao deste software tornaro possvel o controle das

atividades dos animais no CETAS, como cadastro dos animais, controle de

identificao e de transferncias de alocaes, antes realizados manualmente.

O desenvolvimento do sistema conta com as seguintes etapas:

Entrevista com os usurios, para levantamento dos requisitos: Nessa

etapa, os desenvolvedores tentam levantar e definir as necessidades dos

futuros usurios do sistema a ser desenvolvido. Essas necessidades so

geralmente denominadas requisitos.

Especificao e documentao dos requisitos: Nele declaram-se todos os

requisitos do sistema.

9

Modelagem de dados: Processo pelo qual se organiza e se projeta a base

de dados para construo de um futuro banco de dados

Elaborao dos Casos de uso: Processo em que se descreve uma

execuo especfica do sistema, do ponto de vista do usurio.

Diagrama dos casos de uso: Um diagrama de Caso de Uso descreve um

cenrio que mostra as funcionalidades do sistema do ponto de vista do

usurio.

Prototipao: Metodologia em que se demonstra uma verso inicial do

sistema ao usurio.

Desenvolvimento do sistema em Linguagem C#: a incorporao das

atividades descritas acima, a fim de automatiz-las em um sistema

computacional para atender a necessidade inicial do usurio, utilizando

como plataforma para desenvolvimento a linguagem para programao

C#.

O presente projeto ser fundamentado teoricamente, com base nos seguintes

conceitos:

Ergonomia de software: Processo para a obteno de qualidade no

desenvolvimento de software baseando-se na relao entre trs

elementos: usurio, software e a tarefa a ser realizada.

Gerenciamento de projeto: a aplicao de conhecimentos, habilidades e

tcnicas na elaborao de atividades para se atingir um conjunto de

objetivos pr-definidos na elaborao de um software.

10

2 FUNDAMENTAO TERICA

2.1 ERGONOMIA DE SOFTWARE

Edla Maria Faust Ramos (2004) definiu como ergonomia: o melhoramento

das condies generalizadas no desenvolvimento de um processo, j software

como programa de computador que executa determinadas tarefas.

O objeto de estudo da ergonomia de software, consiste na relao entre trs

elementos: usurio, software e a tarefa a ser realizada, tendo como princpio bsico

investigar se um dado produto est adaptado para o uso humano, no limitando-se

em utilizar apenas as tarefas como referncia para o contexto de uso, mas tambm

todos os elementos utilizados para a realizao de determinada tarefa, tais como

hardware, sistema operacional, perifricos, entre outros, baseando-se na psicologia

cognitiva que permite uma compreenso maior do comportamento do usurio e das

conseqncias das suas reaes sobre a concepo de aplicaes interativas.

2.1.1 A Psicologia Cognitiva

Segundo Walter de Abreu Cybis et al. (2007), os conhecimentos sobre as

caractersticas humanas no tratamento da informao so to importantes para o

projeto de um software interativo quanto so os conhecimentos sobre a fisiologia da

mo e do brao para o projeto de uma ferramenta manual [...].

Considerar o usurio significa conhecer, alm das informaes provenientes

da anlise ergonmica do trabalho (idade, sexo, formao especfica,

conhecimentos, estratgias), tambm aquelas ligadas as suas habilidades e

capacidades em termos cognitivos. Na medida em que se entende o computador

como uma extenso do crebro humano, fundamental conhecer como se

processam os tratamentos cognitivos na realizao de uma tarefa informatizada.

A psicologia cognitiva defende como pontos principais: a existncia de

diferentes tipos de usurio, e que os mesmos, por razes variadas, no utilizam a

11

mesma lgica da mesma forma; a existncia de uma diferena fundamental entre a

lgica de funcionamento do computador e a lgica de utilizao do computador pelo

homem; a distino entre as tarefas previstas das tarefas efetivamente executadas

pelo usurio, e que as caractersticas da memria de curto tempo tm para o homem

um impacto direto no dilogo homem-mquina e que uma parte da aprendizagem

passa pela formao de automatismos.

Em suas intervenes para a concepo e avaliao de IHC (Interfaces

Humano-Computador), os ergonomistas valem-se dos resultados de estudos sobre o

comportamento (behaviorismo) e mecanismos que explicam o seu funcionamento

(cognitivismo); focando-se nos comportamentos humanos e nas estruturas

cognitivas humanas, que so: os modelos ou representaes mentais, a

percepo, a memria, o raciocnio e o aprendizado, e o curso das aes.

2.1.1.1 Modelos ou Representaes Mentais

Os modelos ou representaes mentais condicionam totalmente o

comportamento do indivduo e constituem a sua viso da realidade, que

modificada e simplificada pelo que funcionalmente significativo para ele.

H dois tipos bsicos de modelos mentais, os que representam

procedimentos e os que representam conceitos. Ambos se organizam em redes

hierrquicas de conhecimentos, semnticos e procedurais. As lgicas de

funcionamento (conceitos) e de operao (procedimentos) de um dispositivo esto

associadas natureza destes dois tipos de representaes mentais e contribuem

igualmente para o seu entendimento. Da a necessidade dos textos de ajuda para

explorarem estas duas perspectivas de um software interativo; como funcionam e

como se operam suas funes.

2.1.1.2 Percepo

A percepo pode ser entendida como o conjunto de estruturas e tratamentos

pelo qual o organismo impe um significado s sensaes produzidas pelos rgos

perceptivos.

12

Robert Gagn (1962, apud CYBIS et al., 2007), distingue na atividade de

percepo trs nveis distintos de processos que so:

Processos de deteco ou neuro-fisiolgico: constatar a existncia de um

sinal;

Processos de discriminao (de identificao) ou perceptivo: classificar as

informaes em categorias. Esta funo s possvel se anteriormente

houve a deteco e se j existirem categorias memorizadas;

Processos de interpretao (tratamento das informaes) ou cognitivo: dar

um significado s informaes. Esta funo s possvel se anteriormente

houve a deteco, a discriminao e se j existirem conhecimentos

memorizados.

No conjunto de sistemas autnomos: percepo visual, percepo auditiva,

percepo da fala, ateno e vigilncia que caracterizam a percepo, estes

processos se verificam, com maior ou menor variao.

No processo da percepo humana, por muitas vezes, a informao que se

resulta de um processo de deteco, incompleta e integrada com uma informao

parecida da memria. De fato, esta informao nem sempre corresponde

realidade. Assim, no processo da percepo humana, ganha-se em rapidez, mas

perde-se em preciso.

2.1.1.3 Memria

A memria outro ponto a ser destacado na psicologia cognitiva, onde os

modelos ou representaes mentais so armazenados e recuperados atravs de um

conjunto de fenmenos que tm em comum o fato de restiturem a informao, com

maior ou menor transformao, aps certo tempo, quando a fonte desta informao

no est mais presente.

A capacidade de memorizao humana pode encadear os seguintes

processos:

13

Reconhecimento: a capacidade humana de reencontrar no seu campo

perceptivo, elementos anteriormente memorizados (reconhecer o nome de

uma opo de menu aps algum tempo sem v-la).

Reconstruo: a capacidade humana de recolocar os elementos

memorizados na sua organizao anterior (qual o caminho na estrutura

de menus e as aes nas caixas de dilogo para a configurao de uma

tabulao de pargrafo definida?). Esta capacidade representa um misto

entre reconhecimento, de uma parcela do modelo mental considerada

vlida e a lembrana de novos elementos para complementar o todo.

Lembrana: a capacidade humana de recuperar, de forma integral, uma

situao anteriormente vivenciada, sem a presena de nenhum dos

elementos dessa situao (lembrar-se da sintaxe correta de comandos a

serem entrados em uma linha de comando).

Os conhecimentos cientficos atuais no permitem definir, de forma exata, os

custos fisiolgicos associados a estes processos. Entretanto, no que se refere a

uma pessoa que se vale de um aplicativo de produtividade, como um editor de

textos ou planilha, de forma intermitente, possvel considerar que a lembrana do

nome exato de um comando, para entrada em uma linha, seja mnemonicamente

mais custosa em relao a seu reconhecimento em um painel de menu.

2.1.1.4 O Raciocnio e o Aprendizado

Entende-se raciocnio como uma inferncia ou atividade mental de produo

de novas informaes, a partir das existentes. Essas atividades possuem duas

finalidades no exclusivas; a de buscar uma coerncia entre as diferentes

informaes, e a de decidir sobre escolhas de aes. A chegada de novos dados

suscita conceitos e hipteses que estimulam o tratamento. A produo de

conhecimentos pode ser feita a partir de regras gerais, cuja validade definida pela

lgica formal, ou a partir de regras heursticas, que podem produzir resultados nem

sempre eficazes.

14

A inferncia dedutiva, quando partindo de uma ou mais premissas

verdadeiras, chega-se a uma concluso seguramente correta. A inferncia dedutiva,

como o tratamento do tipo algortmico dirigido por programas e corresponde a

procedimentos pr-determinados, mais ou menos automatizados.

A inferncia indutiva quando se parte de premissas verdadeiras, chegando-

se a uma concluso mais geral, no necessariamente verdadeira (generalizao). A

analogia uma forma de raciocnio indutivo que baseia-se em conhecimentos

estocados na memria para compreenso de uma situao desconhecida. Trata-se

de um tipo de raciocnio que visa a estabelecer uma relao de similaridade entre

dois objetos ou situaes diferentes.

Na repartio homem-mquina, os projetistas de IHC devem considerar que

os humanos tm dificuldades para o raciocnio algortmico, dedutivo, tendo melhores

possibilidades em analogias e dedues.

J o aprendizado pode ser entendido como o processo de modificao das

representaes acumuladas nos esquemas declarativos e procedurais, fruto das

inferncias internas ou de atividade perceptiva, ao nvel de conhecimentos, define a

competncia (saber), e ao nvel de comportamento define o desempenho (saber-

fazer).

O progresso no aprendizado no ocorre exclusivamente pelo acmulo de

conhecimentos (mudanas quantitativas), mas tambm pela eliminao de hipteses

falsas, de restries inoportunas e pela substituio de procedimentos (mudanas

qualitativas).

De maneira geral, o aprendizado pode se dar pela ao, caracterizada pela

descoberta e a explorao, onde os fatores importantes so o feedback, a

identificao dos pontos crticos da situao, e dos ndices que permitem evocar

situaes anteriores; ou pode se dar por tutorial que refere-se s diversas formas de

transmisso do saber de um instrutor, onde importante que os conhecimentos

anteriores funcionem como um quadro assimilador do novo conhecimento.

2.1.1.5 O Curso das Aes

15

Segundo Walter de Abreu Cybis et al. (2007) o curso das aes onde os

indivduos, para a realizao de uma tarefa encadeiam processos ou atividades

cognitivas.

O curso das aes possui trs etapas principais:

A anlise da situao: inicia-se pela percepo orientada, sendo composta

das seguintes etapas: ativao (um sinal chama a ateno do indivduo, levando-o a

orientar seus sentidos na direo da fonte desta informao, o que provoca um

estado de alerta); observao (a partir do estado de alerta, o indivduo coleta dados

sobre o ambiente, sistema de produo e meios de trabalho); categorizao (o

indivduo dispe agora de um conjunto de dados que pode ser decodificado e

coordenado no sentido de elaborar uma representao do estado do sistema);

interpretao (nesta etapa, o indivduo determina as causas e as conseqncias do

estado do sistema sobre a evoluo da situao de trabalho).

A planificao das aes: refere fixao de objetivos e elaborao de

planos e se baseia em uma representao hierrquica de espaos abstratos.

Atravs da avaliao de quais so as possibilidades de aes, a seleo de uma e

planejamento da sua realizao.

O controle das aes: inicia-se na realizao das tarefas, que uma vez

executadas, so controladas e avaliadas em termos dos resultados obtidos.

A partir das entradas e sadas possveis na realizao e controle das aes,

Rasmussen (1981, apud CYBIS et al., 2007) prope uma formalizao de trs

diferentes tipos de comportamentos humanos os baseados em habilidades, os

baseados em regras; os baseados em conhecimentos.

Os comportamentos baseados em habilidades (skills) so essencialmente

sensrio-motor, acionados automaticamente por situaes rotineiras e que se

desenvolvem segundo um modelo interno, no consciente, adquirido anteriormente.

As habilidades so pouco sensveis s condicionantes ambientais e organizacionais,

permitindo reaes muito rpidas e podendo se desenvolver em paralelo com outras

atividades.

Um exemplo de um encadeamento sensrio-motor complexo o digitar.

Dentro de certos limites, as variaes do estado do teclado, ou as mudanas de

16

velocidade, so tratadas sem interveno da conscincia para assegurar a

continuidade da progresso da tarefa.

Os comportamentos baseados em regras (rules) so seqncias de aes

controladas por regras memorizadas por aprendizagem e exigem o disparo das

mesmas e uma coordenao entre elas, tendo em vista a variabilidade das situaes

encontradas. As atividades conscientes de um usurio experiente na realizao de

tarefas rotineiras, com um software editor de textos, pertencem a este tipo de

tratamento.

Os comportamentos baseados em conhecimentos (knowledge) aparecem em

situaes novas, de resoluo de problemas, para os quais no existem regras pr-

construdas e est mais ligado ao indivduo do que a prpria tarefa. Uma tarefa pode

ser familiar para um indivduo, mas totalmente nova para outro.

A avaliao dos resultados da ao um componente fundamental na

modificao da representao que se tem do problema. Ela necessita uma atitude

geral de reflexo sobre a ao, levando a compreender uma situao e melhoria

do processo de soluo.

Conforme j citado a ergonomia de software estuda a relao humano-

computador, proporcionando a usabilidade que componente importante em um

modelo de qualidade de sistemas, impactando a tarefa no sentido da eficincia,

eficcia e produtividade da interao. A seguir explica-se, a importncia da boa

usabilidade de um software.

2.1.2 Usabilidade

A usabilidade de um sistema, segundo Walter de Abreu Cybis et al. (2007),

est sempre associada s caractersticas de determinados tipos de usurios,

tarefas, equipamentos e ambientes fsicos e organizacionais. Assim, um problema

de usabilidade pode se fazer sentir fortemente em determinados contextos de

operao e ser menor ou mesmo imperceptvel, em outros.

Em ergonomia de software, a prtica utilizada para estudar a usabilidade de

um sistema, encontra-se na engenharia da usabilidade. Walter de Abreu Cybis et al.

(2007) definiu que os benefcios de uma abordagem centrada no uso (estudo da

17

usabilidade) se traduzem em sistemas intuitivos, fceis de aprender e de usar, tais

sistemas causam menos fadiga e proporcionam mais conforto ao usurio, alm de

garantir maior qualidade para o resultado final de seu trabalho..

A engenharia de usabilidade ocupa-se da interface com o usurio, um

componente do sistema interativo formado por apresentaes e estruturas de

dilogo que lhe conferem um comportamento em funo das entradas dos usurios

de outros agentes externos. Ela apresenta painis com informaes, dados,

controles, comandos e mensagens, e por meio dessas apresentaes que a

interface solicita e recepciona as entradas de dados, de controles e de comandos

dos usurios. Por fim, ela controla o dilogo, interligando as entradas dos usurios

com apresentaes de novos painis. Uma interface definida segundo uma lgica

de operao que visa a que o sistema seja agradvel, intuitivo, eficiente e fcil de

operar. Segundo Jakob Nielsen (1993), a usabilidade pode ser dividida em cinco

critrios bsicos, os quais so:

Intuitividade O sistema deve apresentar facilidade de uso permitindo

que, mesmo um usurio sem experincia, seja capaz de produzir algum

trabalho satisfatoriamente.

Eficincia O sistema deve ser eficiente em seu desempenho

apresentando um alto nvel de produtividade.

Memorizao Suas telas devem apresentar facilidade de memorizao

permitindo que usurios ocasionais consigam utiliz-lo mesmo depois de

um longo intervalo de tempo.

Erro A quantidade de erros apresentados pelo sistema deve ser o mais

reduzido possvel, alm disso, eles devem apresentar solues simples e

rpidas mesmo para usurios iniciantes. Erros graves ou sem soluo no

podem ocorrer.

Satisfao O sistema deve agradar ao usurio, sejam eles iniciantes ou

avanados, permitindo uma interao agradvel.

J, a usabilidade, com base no modelo NBR ISO - International Organization

for Standardization (Organizao Internacional de Padres) / IEC - International

Electrotechnical Commission (Comisso Eletrotcnica Internacional) 9126-1 (antiga

18

NBR 13596) pode ser compreendida a partir das seguintes caractersticas e

respectivas subcaractersticas:

TABELA 1 - NBR ISO/IEC 9126-1 - CARACTERSTICAS DA QUALIDADE DE SOFTWARE

Caractersticas Subcaractersticas

Funcionalidade

(satisfao das necessidades)

Adequao (execuo do que apropriado)

Acurcia (execuo de forma correta)

Interoperabilidade (interao com quem deve)

Conformidade (aderncia s normas)

Segurana de acesso (bloqueio de uso no autorizado)

Confiabilidade

(imunidade falhas)

Maturidade (freqncia das falhas)

Tolerncia falhas (forma de reao s falhas)

Recuperabilidade (forma de recuperao de falhas)

Usabilidade

(facilidade de uso)

Inteligibilidade (facilidade de entendimento)

Apreensibilidade (facilidade de aprendizado)

Operacionalidade (facilidade de operao)

Eficincia

(rpido e "enxuto")

Tempo (tempo de resposta, velocidade de execuo)

Recursos (recursos utilizados)

Manutenibilidade

(facilidade de modificar)

Analisabilidade (facilidade de encontrar falhas)

Modificabilidade (facilidade de modificar)

Estabilidade (baixo risco quando de alteraes)

Testabilidade (facilidade de testar)

Portabilidade

(uso em outros ambientes)

Adaptabilidade (facilidade de se adaptar)

Capacidade para ser instalado (facilidade de instalar em outros ambientes)

Conformidade (aderncia a padres de portabilidade)

Capacidade para substituir (facilidade de ser substitudo por outros)

Fonte: http://www.testexpert.com.br/?q=node/126

A norma citada acima, descreve um modelo de qualidade do produto de

software, composto de duas partes:

1. Qualidade interna e qualidade externa (caractersticas)

2. Qualidade em uso (so as subcaratersticas manifestadas externamente

na utilizao do software como parte de um sistema computacional, e so

resultantes de atributos internos do mesmo).

Alm da norma NBR ISO/IEC 9126-1, existem ainda outras normas utilizadas

para identificao da usabilidade de um sistema, as normas da srie 9126, divididas

em:

19

ISO/IEC 9126-2 - Mtricas Externas: Podem ser aplicadas para um produto

no executvel durante os estgios de desenvolvimento. Medem a qualidade de

produtos intermedirios e predizem a qualidade do produto final.

ISO/IEC 9126-3 - Mtricas Internas: Utilizadas para medir a qualidade do

software atravs do comportamento do sistema ou de parte dele. S podem ser

usadas durante a fase de testes do ciclo de vida e durante a operao do sistema.

ISO/IEC 9126-4 - Mtricas da Qualidade do Uso: medem se o produto

atende ou no as necessidades dos usurios, fazendo-os atingir seus objetivos com

efetividade, produtividade, segurana e satisfao. S podem ser usadas no

ambiente real ou em uma aproximao do ambiente real.

2.1.2.1 Ciclo da Engenharia da Usabilidade

A usabilidade desenvolvida atravs de um conjunto de atividades, que

dependendo do paradigma para o ciclo de vida do produto, podem estar encadeadas

de diversas formas: em cascata, em ciclos de prototipagem e testes, em espirais

evolucionrias ou em diagonais de reutilizao.

A pertinncia de um modelo ou outro vai depender do contexto do

desenvolvimento, em particular, do carcter inovador das propostas, do

conhecimento do domnio do sistema, dos recursos e do tempo disponvel, da

experincia de equipe. Mas seja qual for o modelo escolhido, as atividades

necessrias para o desenvolvimento pertencero a uma das trs categorias ou

perspectivas principais: anlise, sntese e avaliao.

A perspectiva da anlise refere-se ao esforo de estabelecer uma

compreenso do contexto de operao do sistema, a partir da sua subdiviso em

aspectos ligados aos usurios, a seus objetivos e ao ambiente de trabalho. Para o

desenvolvimento da usabilidade, a anlise no s de uma situao existente, mas

tambm de uma futura, importante, uma vez que por meio destas atividades que

se estabelece um foco e um processo de comunicao e de envolvimento do usurio

no desenvolvimento. Quanto mais freqente e progressivo o processo de anlise,

maior ser a qualidade nas decises de projeto.

20

Perspectiva da Sntese - O processo de sntese de uma interface com o

usurio deve ser fruto de uma seqncia lgica de etapas. Mesmo um prottipo, a

partir do qual a interface evolui, no aparece do nada, como pretendem os mtodos

populares de engenharia de software. A lgica da perspectiva de sntese

(especificao, projeto e implementao) de uma nova interface com o usurio,

apresenta a seguinte estrutura de atividades:

A usabilidade a alcanar, quantitativa e qualitativamente;

O novo contexto de operao, incluindo a nova estrutura do trabalho;

O estilo para a interface (guias de estilo);

A estrutura e o processo da nova interface.

Perspectiva da Avaliao - O entendimento da avaliao como perspectiva

fundamental para o sucesso no desenvolvimento de interfaces com o usurio.

Todas as metas (resultados intermedirios) deste processo devem ser verificadas

(por seus projetistas) e validadas (por seus usurios). Em particular, os testes da

usabilidade devem ter como eixos de exame:

A eficcia da interao humano-computador face efetiva realizao das

tarefas por parte dos usurios;

A eficincia desta interao, face os recursos empregados (tempo,

quantidade de incidentes, passos desnecessrios, busca de ajuda);

A satisfao ou insatisfao (efeito subjetivo) que ela possa trazer ao

usurio.

Estes objetivos devem ser pensados em relao aos diferentes contextos de

operao previstos para o sistema.

2.1.3 Interface Homem Computador (IHC)

Entende-se por Interface do usurio, segundo, Moran (1981), como parte de

um sistema computacional com a qual uma pessoa entra em contato com o mesmo,

fisicamente, perceptivamente e conceitualmente, j a Interface homem computador,

21

pode ser definida de acordo com Marco Silva e Edma Santos (2006), como uma

rea multidisciplinar que envolve reas da cincia da computao, psicologia,

fatores humanos e lingstica, dentre outras, a fim de se produzir interfaces

amigveis (user-friendly).

Roberto Cabral de Mello Borges (2007) definiu que interfaces amigveis, so

aquelas que proporcionam ao usurio facilidade para que o mesmo concentre-se

nas realizaes das tarefas, sendo de fcil uso e aprendizado, preocupando-se com

a reduo de custo no treinamento, possuindo pequenas taxas de erros. Tambm

deve ser de recordao rpida e ser atrativa.

2.1.3.1 Tcnicas utilizadas para obteno de uma interface amigvel

Para a obteno de uma interface amigvel, a adoo de algumas tcnicas,

fundamental para se atingir tal objetivo.

Um dos principais itens a ser destacado, sobre a importncia de

desenvolver uma interface mais prxima do possvel que o usurio j esteja

habituado utilizar, considerando se usurio ou empresa segue um padro de

interface em todos os aplicativos j utilizados.

Nos dias de hoje, tem-se observado que os aplicativos grficos utilizam cada

vez mais interfaces de alta produtividade, desenvolvidas atravs de ferramentas

IDEs - Integrated Development Environment (Ambiente Integrado de

Desenvolvimento) que um programa de computador que rene caractersticas e

ferramentas de apoio ao desenvolvimento de software e que possuem excelentes

recursos visuais, disponibilizando bibliotecas de componentes como botes, menus,

caixas de dilogos, entre outros, As IDEs mais utilizadas pelo mercado so: Visual

Basic; Visual C# (Plataforma .NET) ; C++ builder; Delphi entre outras. (informao

verbal)1.

Segundo Roberto Cabral de Mello Borges (2007), ao mesmo tempo em que

deve-se explorar a grande gama de recursos visuais disponveis atualmente,

necessrio no exagerar na utilizao de interfaces muito cheias de animaes e

imagens, pois ao contrrio do que se pensa, esse tipo de interface cria inmeras

dificuldades ao usurio em navegar ou clicar em um boto especfico no programa

ou consultar uma informao, alm de transmitir uma impresso de que o mesmo

22

complexo e difcil de ser operado. A poluio visual uma das maiores fontes de

resistncia dos usurios aos novos sistemas de computador e uma dos maiores

causadores de erros de entrada de dados, devido confuso visual que proporciona

ao seu operador.

Outro fator que deve ser analisado so as diferentes maneiras que o usurio

utiliza-se para interagir com um programa, que so denominadas de estilos de

interao.

Maria Madalena Dias (2001), definiu como estilos de interao uma coleo

de objetos de interface e tcnicas associadas que um projetista de interface pode

escolher quando projeta um componente de interao de uma interface. Eles

fornecem uma viso comportamental de como o usurio se comunica com o

sistema. So classificados como componentes de estilos de interao:

Janelas

Menus

Caixas

A seguir, segue detalhadamente, as definies e algumas recomendaes

usuais e funcionais que devem ser adotadas para a utilizao dos estilos de

interao, a fim de se obter interfaces amigveis.

Janelas

Uma janela um objeto de tela que fornece uma arena para apresentao de

objetos e interao com objetos. Toda interao entre um usurio e o sistema ocorre

atravs de uma janela.

Recomenda-se, as seguintes prticas para o desenvolvimento de uma janela,

em uma interface amigvel:

Evite ao mximo usar edits (campo onde geralmente so inseridos dados

pelo usurio), labels ( antecedem alguns componentes e so utilizados

para descrever o nome , ou uma ao relacionada ao componente) botes

multicoloridos ou piscantes. Somente use-os com critrio e para realmente

chamar a ateno do usurio para um campo ou dado imprescindvel.

23

Animaes e imagens devem ser usadas restritamente e devero, em

caso de uso, representar o propsito da janela em uso ou de uma

operao especfica nesta. Ou ento apenas conter o logotipo do sistema

ou da empresa. Devem estar tambm limitadas a uma imagem por janela

e sempre colocada em local distante da rea de entrada ou sada de

dados.

Procure usar sempre as cores padro do sistema operacional. Cores

fortes, como o vermelho, somente devero ser usadas em locais que se

pretende chamar a ateno do operador.

A figura abaixo, representa um exemplo de interface pouco amigvel, com

telas confusas e cheias de botes.

FIGURA 01: REPRESENTAO DE INTERFACE POUCO AMIGVEL.

Fonte: www_geocities_com-SiliconValley-Bay-1058-InterfaceConfusa_jpg.mht

Sempre coloque uma tela de crditos, com o nome da equipe que

participou do projeto do sistema.

24

No tire do usurio, facilidades comuns a interfaces mais utilizadas no

mercado, como redimensionamento e cores de tela. Essa regra s deve

ser quebrada em casos muito especiais.

Faa a estrutura do menu principal o mais parecido possvel dos softwares

mais utilizadas no mercado,. Por exemplo: Arquivo | Novo | Abrir | Fechar

|... | Sair; Ajuda |... | Sobre;

Evite usar menus em cascatas infinitas. O ideal deve ficar em at 2 a 3

subnveis de menu. Acima disto j comea a criar dificuldades para o

operador manipular submenus. No dispense a implementao das teclas

de acesso rpido. Para os menus pop-up (menus acionados com o boto

direito do mouse), somente um nico subnvel de menu.

As figuras abaixo, exemplificam respectivamente, o uso demasiado de

subnveis de botes pop-up e de menus em cascata.

FIGURA 02: M UTILIZAO DE BOTES POUP-UP


FIGURA 03: MAU EMPREGO DE MENUS EM CASCATA

25


Devemos evitar colocar os componentes e controles de um s lado do

form -rea delimitada para construo de uma interface- (seno seu

desenho fica pesado para a esquerda ou para a direita).

Alinhar os edits e labels.

No aglomere muito os edits, procure deix-los separados de forma que

transmita clareza e leveza da janela ao usurio.

Em cadastros muito extensos deve-se usar panels separando alguns

grupos de Campos.

Se colocar os campos horizontalmente coloque os controles na vertical (e

vice-versa).

Use cones e/ou imagens do mesmo tamanho e de cores compatveis

entre eles (no colocar um muito colorido entre vrios com somente 3 ou 4

cores).

Prefira letras mais escuras que o fundo. Letras muito claras podem criar

confuso ou dificuldade de interpretao por parte do usurio.

Procure sempre que possvel deixar seu formulrio com uma aparncia o

mais semelhante possvel com a do sistema operacional. Isto facilita e j

deixa o usurio pr-familiarizado com o mesmo.

No mais observe os formulrios de outros sistemas e tire proveito das

boas idias.

Menus

Maria Madalena Dias (2001) definiu menus como uma lista de itens dos quais

uma ou mais selees so feitas pelo usurio. um dos estilos de interao mais

populares. So divididos em:

Menus push-button

Menus radio-button

Menus check-button

Menus pull-down

26

Menus pop-up

Menus de opes

Menus toggle

Menus em cascata

Menus pie (muito fcil)

Menus palette

Menus embutidos

Menus dinmicos

Abaixo, descreve-se a definio de dois principais tipos de menus: menus

radio-button e menus em cascata.

Menus radio-button - como nos botes do rdio do carro, somente uma

estao escolhida em um determinado momento. Exemplo: em um

processador de palavras, um usurio s pode selecionar uma fonte (ou

tamanho) para o texto. A figura 4 exemplifica a utilizao deste menu.

FIGURA 04: MENU RADIO BUTTON

Fonte: www.din.uem.br/~mmdias/disciplina%20I/IHC_1311.doc

Menus em cascata (hierrquicos) que segundo Maria Madalena Dias

(2001), funcionam da seguinte forma: quando um usurio pressiona o

boto do mouse sobre o ttulo do primeiro menu na seqncia, o prximo

menu aparece. O usurio pode ento mover o cursor para baixo para

selecionar uma escolha daquele menu, aparecendo um outro menu,

geralmente direita do primeiro, no qual o usurio pode fazer uma outra

escolha, assim por diante, enquanto o boto de mouse continuamente

27

pressionado. Uma escolha final feita quando o usurio libera o boto do

mouse sobre uma escolha do menu no fim daquela seqncia. Um

exemplo deste tipo de menu ilustrado na Figura 5.

FIGURA 05: MENU EM CASCATA


Caixas de dilogo e mensagens

Segundo, Maria Madalena Dias (2001), uma caixa em um sistema, um

retngulo, rea de tela delineada que usada para mensagens, entrada de texto,

comandos, seleo e controle do usurio. Muitos tipos de caixas aparecem como um

resultado de aes de usurio (exemplo: caixas de lista), enquanto outras (exemplo:

caixas de mensagem) so mostradas pelo sistema, para informar o usurio sobre

uma situao corrente. Caixas tm uso temporrio de espao de tela e so uma

tcnica que suporta o agrupamento visual de diferentes tipos de funcionalidades

relacionadas a objetos.

Aborda-se a seguir, a utilizao de dois tipos de caixas: caixas de mensagem

e caixa de texto.

28

Caixa de mensagem - um objeto de interao que apresenta sada para o

usurio. Ela geralmente mostrada pela aplicao, sem a requisio direta de um

usurio. Caixas de mensagem so tipicamente usadas para apresentar informao

ao usurio, mostrando progresso, respondendo uma questo do usurio, dando ao

usurio um aviso de advertncia ou requisitando alguma ao ao usurio.

A figura abaixo, representa um modelo de caixa de mensagem.

FIGURA 06: CAIXA DE MENSAGEM


Caixas de dilogo - um objeto de interao que pode conter outros objetos

de interao, tal como listas, botes, caixas, campos de entrada de texto. Uma caixa

de dilogo tipicamente mostrada como parte de uma seqncia de tarefa,

freqentemente em resposta a uma escolha de um menu pull-down ou uma ao de

chave de acelerador. Caixas de dilogo desaparecem como um resultado de uma

ao do usurio, geralmente dentro da caixa e so usadas para agrupar funes

para vrias tarefas relativas ao usurio, de forma oposta a um menu, que permite

um usurio desempenhar somente uma funo em determinado momento.

29

FIGURA 07: CAIXA DE DILOGO

Fonte: http://pt.wikipedia.org/wiki/Janela_(inform%C3%A1tica)

As caixas de dilogo podem ser divididas em modalidades, que so

classificadas e definidas como:

No modal

Flutuam e permitem interao com outros objetos.

Servem para informar ou aguardar uma entrada. Exemplo: uma caixa de

ferramentas.

Aplicativo modal

Permite mudar de aplicativo, mas no permite mudar de objeto dentro do

mesmo aplicativo. Exemplo: uma caixa com informao que est

imprimindo.

Sistema modal

Paralisa todo o sistema, at que se responda ao que solicitado.

usada para informar a ocorrncia de erros, e aguardar instrues de

como prosseguir.

Aplicativo semi-modal

30

Permitem selecionar objetos, mas no executar aes. Exemplo: na

planilha uma caixa que solicita coordenadas; pode-se sair da caixa e

marc-las com o mouse.

Mobilidade

Mveis: podem ser deslocadas para qualquer posio da janela.

Fixas: ocupam sempre o mesmo local.

Caixas Desdobrveis

Podem ser abertas para mostrar mais detalhes.

Devem tambm poder ocultar detalhes.

Ainda deve ser considerada a utilizao de textos e botes nas caixas de

dilogos. Abaixo, segue os diferentes tipos de textos e botes, as finalidades e

disposio de cada um:

Textos

Sugere-se um cone explicativo:

Informao (I)

Exclamao (!)

Interrogao (?)

Parada (sinal de Pare)

A figura a seguir, representa alguns cones explicativos:

Pare Informao

Exclamao

31

FIGURA 08: CONES EXPLICATIVOS

Fonte: www.inf.ufrgs.br/~cabral/06.Erg.Soft.Abr.2008.ppt

Botes

OK, Cancelar (OK, Cancel)

Sim, No (Yes, No)

Sim, No, Cancelar (Yes, No, Cancel)

Disposio e finalidade

Vertical: todos os botes devem ter mesma altura e mesma largura.

Horizontal: mesma altura, mas a largura pode ser varivel.

Botes de OK: sempre acima ou esquerda.

Botes de OK e Cancelar devem estar juntos.

Botes devem conter todo o nome sem abreviaes.

Help posio oposta ao OK, espaado.

Sempre uma linha de texto por boto.

Botes de Cancelar: no fazem nada e retornam.

Botes de Parar (ou Interromper): param e retornam.

No captulo a seguir, sero descritos todos os processos da gerncia de

projetos, utilizados no desenvolvimento de software.

32

2.2 GERNCIA DE PROJETOS

Roger Pressman (1995) definiu projeto como um empreendimento

temporrio, com data de incio e fim, cujo objetivo criar ou aperfeioar um produto

ou servio, tendo sua origem normalmente nas organizaes.

Ramon de Azevedo (2004) observou que a maturidade da organizao em

relao ao seu sistema de gerenciamento de projetos, sua cultura, seu estilo, sua

estrutura organizacional e seu escritrio de projetos so fatores determinantes que

podem influenciar todo um projeto.

Gerenciar um projeto atuar de forma a atingir os objetivos propostos dentro

de parmetros de qualidade determinados, obedecendo a um planejamento prvio

de prazos (cronograma) e custos (oramento).

Um gerente de projetos o responsvel por garantir que os objetivos

propostos sejam atingidos atentando as metas, e as restries de recursos e tempo,

para tanto, se faz necessrio o gerenciamento de elementos tais como fases e ciclo

de vida do projeto; o emprego de processos para gerenciamento de projeto e atentar

e monitorar os riscos envolvidos em um projeto.

A seguir, segue detalhadamente a descrio e delimitao de cada um

desses elementos.

2.2.1 Fases e ciclos de vida do projeto

Segundo Roger Pressman (1995), as fases de ciclo de vida de um projeto so

utilizadas como parmetros para oferecer um melhor controle gerencial, partindo

das seguintes questes:

Que trabalho tcnico deve ser realizado em cada fase?

Quando as entregas devem ser geradas em cada fase e como cada

entrega revisada, verificada e validada?

Quem est envolvido em cada fase?

Como controlar e aprovar cada fase?

33

Essas fases so caracterizadas da seguinte maneira:

O trmino e a aprovao de um ou mais produtos caracteriza uma fase do

projeto;

Produto: resultado mensurvel do trabalho;

As fases tambm podem ser subdivididas em subfases devido a restries

de tamanho, complexidade, nvel de risco e fluxo de caixa;

Uma fase do projeto em geral concluda com uma reviso do trabalho

realizado e dos produtos para definir a aceitao;

Uma fase pode ser encerrada sem a deciso de iniciar outras fases;

O trmino formal da fase no inclui a autorizao da fase seguinte.

Segundo Ramon de Azevedo (2004), simplificadamente, o ciclo de vida de um

projeto dividido em cinco fases: fase de iniciao, fase de planejamento, fase de

execuo, fase de controle e fase de finalizao, possuindo cada uma delas, a

seguinte definio:

Fase de Iniciao: apresentao de uma necessidade e estruturao da

mesma, num problema a ser resolvido. essencial que a misso e objetivo sejam

definidos, bem como as estratgias que sero utilizadas.

Fase de Planejamento: nesta fase detalhado tudo que ser realizado no

projeto, incluindo cronograma, interdependncias entre atividades, alocao dos

recursos envolvidos, anlise de custos, para que possa ser executado sem

dificuldades. Nesta etapa devemos ter ateno especial para comunicao da

equipe, qualidade, riscos, aquisies e recursos humanos envolvidos.

Fase de Execuo: execuo de tudo que foi planejado. importante

destacar que grande parte do oramento e esforo ser despendida nesta fase e na

anterior.

Fase de Controle: execuo em paralelo com as fases de planejamento e

execuo. O objetivo principal desta fase acompanhar e avaliar tudo que est

sendo feito na situao atual, pautando-se na situao planejada. Caso o projeto

no esteja dentro do desejado, nesta etapa que devero ser realizadas aes

34

corretivas para que se volte ao rumo certo. A grande vantagem de utilizar est fase

a possibilidade de sempre acompanhar de perto o projeto.

Fase de Finalizao: aqui que sero avaliadas todas as tarefas e fases

atravs de uma auditoria, interna ou externa (equipe de terceiros), todos os

documentos so entregues e podemos utilizar este momento para que toda a equipe

passe por um processo de aprendizado.

As fases so realizadas quase que simultaneamente e cada uma constitui o

seu prprio ciclo. Cada fase pode ser considerada como um projeto, possuindo,

portanto uma iniciao, planejamento, execuo, controle e finalizao. Conforme a

figura abaixo:

FIGURA 09: VISO CCLICA DE CADA FASE

Fonte: http://imasters.uol.com.br/artigo/2651/projeto_-_a_importancia_do_ciclo_de_vida

2.2.2 Processos de gerenciamento de projeto

Roger Pressman (1995) definiu processo como um conjunto de aes e

atividades inter-relacionadas realizadas para obter um conjunto pr-especificado de

produtos, resultados ou servios.

Alguns autores dividem em nove principais categorias os processos de

gerenciamento de projeto, Wilson de Pdua Paula Filho (2005), classificaram-nas

em: gerenciamento de integrao do projeto, gerenciamento do escopo do projeto,

gerenciamento do tempo do projeto, gerenciamento de custos do projeto,

gerenciamento da qualidade do projeto, gerenciamento dos recursos humanos do

projeto, gerenciamento da comunicao do projeto, gerenciamento de riscos do

35

projeto e gerenciamento de aquisies do projeto (subcontratao / suprimentos /

contratos). A seguir, em detalhes, a definio de cada um dos processos de

gerenciamento.

2.2.2.1 Gerenciamento de integrao do projeto

O processo de gerenciamento de integrao do projeto pode ser definido

como a atividade responsvel por integrar os elementos do gerenciamento de

projetos, que so identificados, definidos, combinados, unificados e coordenados

dentro dos grupos de processos de gerenciamento de projetos, e de realizar as

seguintes aes: Desenvolver o termo de abertura do projeto, Desenvolver a

declarao do escopo preliminar do projeto, Desenvolver o plano de gerenciamento

do projeto, Orientar e gerenciar a execuo do projeto, Monitorar e controlar o

trabalho do projeto, pelo controle integrado de mudanas e de encerrar o projeto.

2.2.2.2 Gerenciamento do escopo do projeto

Entende-se como escopo de um projeto o trabalho que deve ser realizado

para se obter um produto ou servio com determinadas caractersticas e recursos. O

Gerenciamento do escopo do projeto tem por finalidade, definir o que deve ser feito

e o que no deve. Para tanto, utiliza-se uma ferramenta que possibilita a

decomposio do trabalho do projeto em partes manejveis, denominada Work

Breakdown Structure (Estrutura Analtica de Projeto - EAP), que pode ser definida

como uma estrutura em rvore exaustiva, hierrquica que parte da mais geral para

mais especfica de entregveis (deliverables) e tarefas que precisam ser feitas para

completar um projeto. A partir do escopo do projeto, pode-se passar para a fase de

detalhamento das tarefas.

A satisfao do cliente determinante para a delimitao do que deve ser

feito definidas no que denomina-se de pr-venda, cabendo ao gerente de projetos

de forma meticulosa, cuidadosa e disciplinada escrever tudo o que o sistema deve

ter e fazer. Este processo o planejamento de escopo e num software deve se

36

abranger desde as telas at os relatrios. Esta tarefa pode ser delegada para um

analista, mas a responsabilidade est intrinsicamente ligada ao gerente.

Palavra chave: definir o escopo, em sntese, saber o que deve ser feito para

atender a necessidade do cliente.

2.2.2.3 Gerenciamento do tempo do projeto

Para se definir o que um processo de gerenciamento do tempo de um

projeto, necessrio entender o conceito de atividade.

Atividade

Wilson de Pdua Paula Filho (2005) definiu atividade, como um elemento de

trabalho realizado durante o decorrer de um projeto. Um diagrama de rede constitui

a forma de visualizao grfica das atividades de um projeto e do relacionamento

lgico ou dependncia entre elas. Usualmente representa-se um diagrama de rede

de duas formas: PDM e ADM.

PDM - mtodo do diagrama de precedncias (precedence diagramming

method) - as atividades so representadas por pequenos retngulos interligados por

flechas que representam as dependncias.

FIGURA 10: REPRESENTAO DO DIAGRAMA DE REDE EM PDM

Fonte: Engenharia de Software Fundamentos, Mtodos e Padres.

Incio Fim

Ativ.

1

Ativ. 2

Ativ.

3

Ativ.

4

Ativ.

5

37

ADM - mtodo do diagrama de flechas (arrow diagramming method) - as

atividades so representadas por flechas e os eventos so pequenas bolas nas

quais as atividades se interligam.

B D

A

F

C E

FIGURA 11: REPRESENTAO DO DIAGRAMA DE REDE EM ADM


Toda atividade tem uma dimenso e tempo delimitados por eventos que

podem ser entendidos como marcos de incio e de fim de cada atividade.

Deve-se tambm definir estimativa de durao de cada atividade, que entre

outras, possui as seguintes caractersticas:

Processo de determinar a quantidade de perodo de trabalho que sero

necessrios para execuo de cada atividade.

Construda de forma progressiva (rever as duraes at o prazo total mais

preciso).

Dados necessrios para estimar: restries, premissas, recursos

necessrios, habilidade dos recursos, informaes histricas e riscos

identificados.

Tcnicas: Opinio especializada, estimativa anloga e histrica.

38

2.2.2.4 Gerenciamento de custos do projeto

O gerenciamento de custos do projeto trata segundo Wilson de Pdua Paula

Filho (2005), principalmente do custo dos recursos necessrios para terminar as

atividades do cronograma. No entanto, o gerenciamento de custos do projeto

tambm deve considerar o efeito das decises do projeto sobre o custo de

utilizao, manuteno e suporte do produto, servio ou resultado do projeto. Por

exemplo, a limitao do nmero de revises de projeto pode reduzir o custo do

projeto custa de um aumento nos custos operacionais do cliente. Essa viso mais

ampla do gerenciamento de custos do projeto muitas vezes chamada de

estimativa de custos do ciclo de vida. A estimativa de custos do ciclo de vida,

juntamente com tcnicas de engenharia de valor, pode aprimorar a tomada de

decises e usado para reduzir o custo e o tempo de execuo e para melhorar a

qualidade e o desempenho da entrega do projeto.

O gerenciamento de custos do projeto considera as necessidades de

informao das partes interessadas no projeto. Diferentes partes interessadas iro

medir os custos do projeto de diferentes maneiras e em momentos diferentes. Por

exemplo, o custo de um item adquirido pode ser medido quando a deciso de

aquisio tomada ou lanada, o pedido colocado, o item enviado e o custo real

incorrido ou registrado para fins de contabilidade do projeto, para isso, torna-se

indispensvel o planejamento dos recursos, que entre outros, responsvel por:

Determinar quais recursos (e em que quantidade) devem ser utilizados para

executar as atividades do projeto

Recursos: pessoas, equipamentos, mquinas.

Em seguida, aps o planejamento dos recursos, realiza-se a estimativa dos

recursos que responsvel por desenvolver uma estimativa dos custos dos recursos

necessrios para as atividades do projeto, definidas previamente no processo de

gerncia de tempo.

O oramento dos custos aloca as estimativas de custos globais aos itens

individuais de trabalho, considerando que qualquer mudana mo oramento do

projeto, deve ser controlada a partir do processo de controle dos custos, que tem por

objetivos monitorar o desempenho do custo para detectar as variaes do plano e

Impedir que mudanas no-autorizadas ou inapropriadas sejam includas.

39

2.2.2.5 Gerenciamento da qualidade do projeto

O gerenciamento da qualidade do projeto segundo Wilson de Pdua Paula

Filho (2005), trata de assuntos referentes qualidade em projeto e produtos de

software, baseando-se na garantia da qualidade que trata as atividades de garantia

da qualidade das organizaes produtoras de software tornando-se uma atividade

preventiva em relao aos problemas da qualidade de produto que poderiam surgir,

incluindo em seus processos uma srie de mecanismos preventivos que diminuem o

numero de defeitos injetados ao longo do projeto, diminuindo-se assim a quantidade

de defeitos que tero que ser removidos posteriormente e possuindo como principais

objetivos:

Dar suporte ao trabalho das equipes dos projetos de software para garantir

a qualidade de atividades e resultados de cada projeto;

Verificar as atividades e os resultados dos projetos de software;

Fornecer gerncia executiva informao atualizada sobre o status dos

projetos e sua conformidade com os padres da qualidade da

organizao.

Em termos mais especficos, a Garantia da Qualidade de Software visa a

fazer com que:

Sejam seguidos padres e recomendaes em vigor organizao;

Sejam usados mtodos tcnicos apropriados de engenharia de software,

conforme com os padres em vigor;

Sejam realizadas revises e auditorias, para todos os projetos, por

equipes independentes em relao ao projeto em questo.

Para tanto, necessrio atentar aos fatores de qualidade de software, que

segundo Roger Pressman (1995), podem ser subdivididos em dois grupos distintos:

fatores que podem ser medidos diretamente (por exemplo, erros, Kloc/unidade de

tempo) e fatores que podem ser medidos apenas indiretamente (por exemplo,

usabilidade ou manutenibilidade).

40

Em cada caso, deve ocorrer medio. Precisamos comparar o software

(documentos, programas e dados) com algum dado e checar a uma indicao de

qualidade.

Os fatores de qualidade de software so compostos pelas seguintes

caractersticas:

Corretitude medida que um programa satisfaz sua especificao e

cumpre os objetivos visados pelo cliente.

Confiabilidade medida que se pode esperar que um programa

execute sua funo pretendida com a preciso exigida.

Eficincia A quantidade de recursos de computao e de cdigo exigida

para um programa execute sua funo.

Integridade medida que o acesso ao software ou a dados por

pessoas no autorizadas pode ser controlado.

Usabilidade O esforo para aprender, operar, preparar a entrada e

interpretar a sada de um programa.

Manutenibilidade O esforo exigido para localizar e reparar erros num

programa.

Flexibilidade O esforo exigido para modificar um programa

operacional.

Testabilidade O esforo exigido para testar um programa a fim de

garantir que ele execute sua funo pretendida.

Portabilidade O esforo exigido para transferir o programa de um

ambiente de sistema de hardware e/ou software para outro.

Reusabilidade medida que um programa (ou partes de um programa)

pode ser reusado em outra aplicao.

Interoperabilidade O esforo exigido para se acoplar um sistema a

outro.

2.2.2.6 Gerenciamento dos recursos humanos do projeto

Wilson de Pdua Paula Filho (2005) concluiu que o Gerenciamento dos

Recursos Humanos do Projeto inclui os processos requeridos para possibilitar o uso

41

mais efetivo das pessoas envolvidas com o projeto, isto , todos os interessados do

projeto, fornecendo uma viso geral dos seguintes processos principais:

Planejamento Organizacional identificar, documentar e designar as

funes, responsabilidades e relacionamentos de reporte dentro do

projeto.

Montagem da Equipe conseguir que os recursos humanos

necessrios sejam designados e alocados ao projeto

Desenvolvimento da Equipe desenvolver habilidades individuais e do

grupo para aumentar o desempenho do projeto.

2.2.2.7 Gerenciamento da comunicao do projeto

O processo de gerenciamento, segundo Roger Pressman (1995) descrevem

os processos relativos gerao, coleta, disseminao, armazenamento e

destinao final das informaes do projeto de forma oportuna e adequada. Esse

processo de gerenciamento baseia-se no conceito de que a comunicao fator

determinante no tempo de ao e/ou reao dos possveis eventos (negativos ou

positivos) que ocorrem durante todo o projeto, e que pode influenciar, nos demais

objetivos de um projeto como custo, escopo e qualidade, portanto, cabendo ao

gerente de projetos utilizar tcnicas adequadas a cada projeto, com o intuito de

garantir uma comunicao eficaz e efetiva.

Ele responsvel pela execuo das seguintes tarefas: Planejamento das

comunicaes, Distribuio das informaes, Relatrio de desempenho e Gerenciar

as partes interessadas, as quais possuem as seguintes caractersticas:

Planejamento das comunicaes determinao das necessidades de

informaes e comunicaes das partes interessadas no projeto. O planejamento

envolve a identificao e definio das seguintes informaes: quem precisa das

informaes e quais so elas; quando precisaro delas e com qual freqncia; como

ela ser fornecida e por quem.

Distribuio das informaes colocao das informaes necessrias

disposio das partes interessadas no projeto no momento adequado. As

informaes do projeto podem ser distribudas usando uma variedade de mtodos

42

incluindo reunies de projeto, distribuio de cpias de documentos, acesso

compartilhado rede eletrnica de bancos de dados, fax, e-mail, canal de voz, vdeo

conferncia e projeto intranet.

Relatrio de desempenho coleta e distribuio das informaes sobre o

desempenho. Isso inclui o relatrio de andamento, medio do progresso e previso.

Os relatrios de desempenho organizam e sumarizam as informaes obtidas e

apresentam os resultados de quaisquer anlises. Os relatrios devem fornecer os

tipos de informaes e o nvel de detalhe requerido pelos vrios interessados,

conforme documentado no plano de gerencia da comunicao.

Os formatos comuns para os relatrios de desempenho incluem grficos de

barras (tambm chamados de grficos de Gantt), curva S, histogramas e tabelas.

FIGURA 12: REPRESENTAO DO GRFICO CURVA S


Gerenciar as partes interessadas gerenciamento das comunicaes para

satisfazer os requisitos das partes interessadas no projeto e resolver problemas com

elas, possuindo os seguintes objetivos:

Satisfazer as necessidades das partes interessadas.

Resolver problemas entre eles:

Problemas externos: ex: cliente empresa ou fornecedor empresa.

Problemas internos: ex: entre gerentes de projetos diferentes ou entre

desenvolvedores.

Um bom gerenciamento das partes interessadas traz aumento de

probabilidade do projeto no se desviar do curso, alm das pessoas trabalharem em

harmonia e sincronismo, limitando interrupes durante o projeto.

43

2.2.2.8 Gerenciamento de riscos do projeto

Roger Pressman (1995) definiu que o processo de gerenciamento de riscos

de software responsvel em avaliar e controlar os riscos que afetam o projeto,

processo ou produto de software, considerando os riscos de projeto como

condies que, caso venham a ocorrer, podem comprometer ou impedir a realizao

de um dado projeto.

A melhor maneira de descobrir os riscos definir, inicialmente, os objetivos e

metas do projeto, partindo das seguintes questes: qual o risco contido no plano?

Qual o risco contido no trabalho ainda restante?

Uma das principais caractersticas do risco a sua probabilidade de

ocorrncia, que ser sempre maior do que zero e menor do que 100 por cento. Se a

probabilidade de ocorrncia for zero, o risco no existe. Se for 100%, trata-se de um

problema um risco que j se realizou.

A probabilidade de ocorrncia do risco um dos fatores para a determinao

de sua prioridade. Um dos conceitos fundamentais do Gerenciamento de Riscos a

perda. preciso que haja um potencial de perda para que haja risco. A perda pode

ter origem em um resultado negativo ou em uma oportunidade perdida. O resultado

negativo pode ser, por exemplo, uma quantidade de erros inaceitvel no produto, ou

um atraso na data de entrega do mesmo. A oportunidade perdida pode se referir, por

exemplo, a lucros perdidos, pela incapacidade de levar o produto ao mercado antes

da concorrncia. Outro conceito fundamental a ser considerado o tempo. Embora

o tempo seja um recurso valioso, no possvel acumul-lo. Uma vez perdido, no

h como recuper-lo. Conforme o tempo passa, as opes viveis vo se reduzindo.

A perda do tempo reduzida atravs do Gerenciamento de Riscos.

Segundo Shari Lawrence Pfleeger (1991), os riscos podem ser caracterizados

de acordo com os principais itens: Pessoal insuficiente; Cronograma e Oramentos

que no so realistas; Desenvolver funo do software erradas; Desenvolvimento de

uma interface com o usurio inadequada; Simplificar os requisitos (construo de

prottipo, anlise do custo beneficio, projeto de acordo com o custo); Insuficincia

nas tarefas realizadas externamente; Insuficincia nos componentes fornecidos

externamente; Insuficincia no desempenho em tempo real; Exceder a capacidade

da cincia da computao.

44

Aps a identificao dos principais itens de riscos, se faz necessrio sua

constante monitorao. A monitorao dos riscos, entre outras aes, de acordo

com Roger S. Pressman (1995), acompanhar o status de cada risco e as opes de

aes definidas para enfrent-los, caso eles venham a se tornar problemas reais..

A monitorao tambm se preocupa em avaliar a probabilidade de ocorrncia

de um risco, qual o seu impacto no andamento do projeto e como contorn-lo. Por

exemplo, numa determinada tarefa crtica a contratao de dois profissionais pode

parecer um exagero, mas o gerente do projeto sabe que se algo acontecer nesta

rea do projeto o impacto ser grande no restante. Os profissionais passam a ser

um backup do outro dentro da linha de que quem tem um, no tem nenhum.

2.2.2.9 Gerenciamento de aquisies do projeto (subcontratao/ suprimentos/ contratos)

O processo de gerenciamento de aquisies do projeto o processo capaz

de identificar as atividades que compram ou adquirem produtos, servios ou

resultados, e que tambm gerenciam os contratos. Esse processo caracterizado

pelas aes de planejar compras e aquisies; planejar contrataes; solicitar

respostas de fornecedores; selecionar fornecedores; administrao de contrato e

encerramento do contrato.

2.2.3 Grupos de processos de Gerenciamento de projetos

Os processos de gerenciamento de projetos so divididos em cinco grupos

distintos, sendo eles:

Grupo de processos de iniciao,

Grupo de processos de planejamento,

Grupo de processos de execuo,

Grupo de processos de monitoramento e controle

Grupo de processos de encerramentos.

45

So definies e caractersticas de cada grupo de processo de

gerenciamento:

2.2.3.1 Grupo de processos de iniciao

Responsveis por definirem e autorizarem o projeto ou uma fase do projeto.

Desenvolvem o termo de abertura do projeto;

Desenvolvem a declarao do escopo preliminar do projeto.

2.2.3.2 Grupo de processos de planejamento

Definem os objetivos e planejam a ao necessria para alcanar os objetivos

e o escopo para os quais o projeto foi realizado.

Desenvolvem o plano de gerenciamento do projeto;

Planejam o escopo;

Definem o escopo (o que precisa ser realizado);

Criam a EAP (Estrutura Analtica de Projeto);

Definem a atividade e o sequenciamento das atividades;

Realizam a estimativa de recursos da atividade;

Realizam a estimativa de durao da atividade;

Desenvolvem o cronograma;

Realizam a estimativa de custos;

Criam o oramento;

Planejam a qualidade;

Definem os recursos humanos;

Planejam as comunicaes;

Planejam o gerenciamento de riscos;

Identificam os riscos;

Analisam os riscos;

Analisam quantitativamente os riscos;

Planejam o tempo de respostas a riscos;

46

Planejam as compras e aquisies;

Planejam as contrataes.

2.2.3.3 Grupo de processos de execuo

Integram as pessoas e outros recursos para realizar o plano de

gerenciamento do projeto para o projeto.

Orientam e gerenciam a execuo do projeto.

Realizam a garantia da qualidade.

Contratam ou mobilizam a equipe do projeto.

Desenvolvem a equipe do projeto.

Distribuem as informaes.

Solicitam respostas de fornecedores.

Selecionam os fornecedores.

2.2.3.4 Grupo de processos de monitoramento e controle

Responsveis por medirem e monitorarem regularmente o progresso para

identificar variaes em relao ao plano de gerenciamento do projeto, de forma que

possam ser tomadas aes corretivas quando necessrio para atender aos objetivos

do projeto.

Monitoram e controla o trabalho do projeto.

Controlam integradamente as mudanas.

Verificam o escopo.

Controlam o escopo

Controlam o cronograma.

Controlam os custos

Realizam o controle da qualidade.

Gerenciam a equipe do projeto.

Realizam o relatrio de desempenho.

Gerenciam as partes interessadas.

47

Monitoram e controla os riscos.

Administram os contratos.

2.2.3.5 Grupo de processos de encerramento

Formalizam a aceitao do produto, servio ou resultado e conduz o projeto

ou uma fase do projeto a um final ordenado.

Encerrar o projeto.

Encerramento do contrato.

Os grupos de processos de gerenciamento de projetos esto ligados pelos

objetivos que o produzem. Em geral, as sadas de um processo se tornam entradas

para outro processo ou so entregas do projeto. A esta situao dar-se o nome de

interao entre grupos de processos, pois em muitos casos os grupos de processos

trabalham paralelamente ou iniciam-se antes que o outro termine. Cabe ao gerente

de projetos elaborar um mapeamento dos grupos de processos, documentando de

forma clara e objetiva o inicio, definio de processos, planejamento, controle e

encerramento de cada grupo de processos.

48

3 ESTUDO DE CASO

Este trabalho apresenta todo o aprendizado adquirido, de tcnicas e

tecnologias determinantes para obteno da qualidade no desenvolvimento e

implantao de um software, que beneficiar toda a rotina no CETAS Centro de

Triagem de Animais Selvagens Lello, do curso de veterinria do Centro

Universitrio Monte Serrat UNIMONTE.

Instalado em uma estrutura de 586 m, o CETAS possui capacidade para

receber animais de pequeno e mdio porte, entre eles papagaios, araras, gavies,

sagis, macacos-pregos, bugios, muriquis, lontras, gavies, gatos do mato,

jaguatiricas, bichos-preguia, tamandus-mirins, antas, capivaras e onas. Para

atender a demanda e seus principais objetivos, que so dentre outros, reabilitar

animais vtimas da caa indiscriminada e da ao de traficantes, o CETAS possui

uma estrutura arquitetnica totalmente indoor (fechada), compatvel com os modelos

encontrados na Europa e diferente da maior parte vista no Brasil, que ficam a cu

aberto.

Outro destaque do local fica por conta da sala de atendimento em

neonatologia, para a manuteno de filhotes e recm-nascidos, e da sala de

descontaminao, para procedimentos de limpeza de animais acometidos por

petrleo e derivados. Alm disso, o centro rene ambientes como ambulatrio,

biotrio, sala de apoio, viveiros com tanques, viveiros com sistema de cambiamento

(manejo), viveiros com divisrias, salas de quarentena, cozinha e despensa, para

armazenamento de raes e suplementos.

Para se automatizar as rotinas de controle deste Centro, desenvolveu-se um

software denominado Sistema de Controle do CETAS, que possui as seguintes

funcionalidades:

Cadastro dos animais acolhidos pelo CETAS;

Consulta de espcies de animais;

Controle de identificao dos animais alocados no centro;

Controle de transferncias internas e externas dos animais do centro;

49

As figuras abaixo representam as duas principais telas do software:

FIGURA 13: TELA DE REGISTRO DE ANIMAL

Fonte: Sistema de Controle CETAS.

50

FIGURA 14: TELA DE TRANSFERNCIA DE ANIMAL

Fonte: Sistema de Controle CETAS.

Para o desenvolvimento das funcionalidades do software, utilizou-se as

seguintes tcnicas:

Entrevista com os usurios, para levantamento dos requisitos: Atravs

desta atividade, foi possvel junto Prof Cludia Carvalho do Nascimento, mdica

veterinria, responsvel pelo Centro, levantar os requisitos para o desenvolvimento

das funcionalidades do sistema, a partir de um roteiro de entrevista e visita ao

Centro.

Especificao e documentao dos requisitos: Aps o levantamento dos

requisitos do sistema, criou-se um documento de requisitos, com o propsito de

acompanhar o status do desenvolvimento de cada funcionalidade do sistema. O

documento de requisitos, tambm contribuir para futuras evolues do sistema.

51

Modelagem de dados: A partir dos dados acerca dos animais e das

atividades do CETAS contidos em uma planilha eletrnica disponibilizado pela Prof

Cludia aplicou-se a terceira forma normal para desenvolver o banco de dados.

Elaborao dos casos de uso: Foi elaborado atravs do documento de

requisitos a fim de representar as funcionalidades do sistema.

Diagrama dos casos de uso: Foi criado a partir da elaborao dos casos de

uso para ilustrar a relao entre o usurio e as funcionalidades do sistema.

Prototipao: Por meio desta tcnica, criou-se um prottipo, um esboo da

interface de cada tela do sistema, antes do seu desenvolvimento.

Desenvolvimento do sistema em Linguagem C#: Foi a consolidao de

todas as tcnicas descritas acima, automatizando as atividades do CETAS por meio

de um sistema computadorizado, utilizando como linguagem de programao para

desenvolvimento de software, a linguagem C#.

Fundamentao terica Ergonomia Gerncia de projetos: Com a

realizao da pesquisa terica, direcionou-se todas as atividades para o

desenvolvimento do software, no sentido de se obter a sua qualidade.

52

4 CONCLUSO

As seguintes concluses foram obtidas com a realizao deste projeto:

Junto aos professores e veterinria responsvel pelo CETAS, foram obtidos

todos os requisitos necessrios para o desenvolvimento do software de controle dos

animais do Centro, fomentando-os com a pesquisa terica.

Foi desenvolvido, considerando as necessidades levantadas pela veterinria

responsvel pelo Centro, o software de controle, participando de todas as etapas

consideradas essncias para o desenvolvimento de um software (anlise,

desenvolvimento e implantao).

O seguinte problema de pesquisa proposto - Quais os benefcios de

automatizar os processos de controle da rotina dos animais de um zoolgico? - foi

respondido a partir da construo do projeto.

Os processos manuais, desenvolvido dantes no Centro, como cadastro dos

animais acolhidos, registro e controle das transferncias dos animais, foram

convertidos em funcionalidades em um sistema computacional, garantindo assim

uma maior otimizao e organizao destes processos.

A fundamentao terica disponibilizou os parmetros para o

desenvolvimento do software de controle, a fim de se obter a qualidade necessria

em um sistema computacional, tais como, a determinao da sua usabilidade, a

compreenso da relao entre usurio e mquina, o seu comportamento quanto a

utilizao do software e a adoo das melhores maneiras de interao do usurio

com a interface do software, obtidas partir da pesquisa sobre ergonomia; a

organizao das atividades e etapas necessrias para o desenvolvimento do

projeto, delimitando as tarefas para cada componente do grupo e adotando

cronogramas a fim de se controlar o tempo estimado para concluso do software,

embasando-se nas referncias obtidas com a pesquisa de gerncia de projeto.

Em suma, cada atividade desenvolvida ao longo deste projeto, converteu-se

em conhecimento de boas prticas para se obter a qualidade no desenvolvimento de

um sistema computacional, oferecendo a experincia inicial para que ns futuros

53

profissionais da rea de anlise e desenvolvimento de sistemas sejamos capazes de

exercer nossas competncias com um grande diferencial no mercado de trabalho.

54

REFERNCIAS

AZEVEDO, Ramon D. Projeto - A importncia do ciclo de vida. 2004. Disponvel em:

BETIOL, Adriana Holtz; FAUST, Richard; CYBIS, Walter de Abreu. Ergonomia e

Usabilidade - Conhecimentos, Mtodos e Aplicaes. 1. ed., Novatec Editora, 2007.

p. 17, 103, 295. Disponvel em: .

BORGES, Roberto Cabral de Mello. INF0 43 Comunicaco Homem-Computador

Parte 9. 2008. Disponvel em:

CAMPOS, Fbio Martinho. Quais so as Reais Caractersticas da Qualidade da NBR

ISO/IEC 9126-1? 2007. Disponvel em:

CAMPOS, Fbio Martinho. Qualidade, Qualidade de Software e Garantia da

Qualidade de Software So as Mesmas Coisas? 2008. Disponvel em:

.

CYBIS, Walter de Abreu. Engenharia de Usabilidade:

uma abordagem ergonmica.

Disponvel em: .

DIAS, Maria Madalena. UEM/CTC/DIN - Disciplina: Engenharia de Software I.

Disponvel em:

55

JORNAL VICENTINO. Centro de Triagem de Animais Selvagens (CETAS) de So

Vicente tm novos hspedes em tratamento. 2008. Disponvel em:

KOSCIANSKI, Andr; SOARES, Michel dos Santos. Qualidade de software aprenda

as metodologias e tcnicas mais modernas para o desenvolvimento de software. 2.

ed., Novatec Editora, 2007. Disponvel em:

.

NIELSEN, Jakob. Engenharia de Usabilidade. 1993. Disponvel em:

PAULA FILHO, Wilson de Pdua. Engenharia de Software: fundamentos, mtodos e

padres. 2000. Disponvel em:

PFLEEGER, Shari Lawrence. Engenharia de Software. 1991.

PRESSMAN, Roger S. Engenharia de Software. 3. ed., Editora Makron, 1995.

RAMOS, Edla Maria Faust. Fundamentao Terica - Parte 3: Ergonomia de

Software. 2004. Disponvel em:

SANTOS, Edma; SILVA, Marco. Avaliao da aprendizagem em educao online

fundamentos, interfaces e dispositivos, relatos de experincias. Edies Loyola.

2006. Disponvel em:

56

ne+fundamentos,+interfaces+e+dispositivos,+relatos+de+experi%C3%AAncias&sour

ce=bl&ots=rBf0lb2XbU&sig=GxzKVqIhorSTAnL3F28qQWt5Nko&hl=pt-

BR&ei=mzQXSszwD6XFtgev8_j-

DA&sa=X&oi=book_result&ct=result&resnum=1#PPP1,M1>

WIKIPDIA, a enciclopdia livre. Janela (informtica). Disponvel em:

57

ANEXO A

Cronograma de desenvolvimento do trabalho.

Id Nome da tarefa Durao Incio Trmino

1 Projeto Aplicado - Cronograma 88 dias Ter 3/2/09 Qui 4/6/09

2 FASE PROPOSTA 39 dias Ter 3/2/09 Sex 27/3/09

3 Apresentao do Projeto Interdisciplinar 4 dias Ter 3/2/09 Sex 6/2/09

4 Definio do Tema 5 dias Seg 9/2/09 Sex 13/2/09

5 Desenvolvimento da Proposta 20 dias Seg 16/2/09 Sex 13/3/09

6 Apresentao da Proposta 5 dias Seg 16/3/09 Sex 20/3/09

7 Entrega da Proposta - Escrita 5 dias Seg 23/3/09 Sex 27/3/09

8 FASE TRABALHO INTERDISCIPLINAR 48 dias Seg 23/3/09 Qua 27/5/09

9 Fundamentao Terica 10 dias Seg 23/3/09 Sex 3/4/09

10 Metodologia de Pesquisa 10 dias Seg 23/3/09 Sex 3/4/09

11 Construindo o Trabalho Interdisciplinar 25 dias Seg 23/3/09 Sex 24/4/09

12 Redao e Consolidao do Trabalho Interdisciplinar 15 dias Seg 27/4/09 Sex 15/5/09

13 Entrega 1 verso do trabalho finalizado para validao 1 dia Qua 6/5/09 Qua 6/5/09

14 Preparao Banner 5 dias Seg 18/5/09 Sex 22/5/09

15 Apresentao do Trabalho - Prvia para nota 1 dia Qua 27/5/09 Qua 27/5/09

16 Simpsio 12 dias Qua 20/5/09 Qui 4/6/09

17 Entrega do trabalho escrito em 3 vias + CD 3 dias Qua 20/5/09 Sex 22/5/09

18 Realizao do Simpsio de Educao Tecnolgica 4 dias Seg 1/6/09 Qui 4/6/09

18/1 25/1 1/2 8/2 15/2 22/2 1/3 8/3 15/3 22/3 29/3 5/4 12/4 19/4 26/4 3/5 10/5 17/5 24/5 31/5 7/6Fevereiro Maro Abril Maio Junho

Tarefa

DivisoAndamento

EtapaResumo

Resumo do projeto

Tarefas externas

Etapa externaData limite

CRONOGRAMA PROJETO APLICADO 5 ADS

Pgina 1

Projeto: Projeto Aplicado - CronogramData: Qui 21/5/09

Documents

Projeto Aplicado CETAS