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

MARIO MACHADO CHAME

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
Desenvolvimento de Sistemas.
Orientador: Prof. MS. Nina Maria Bueno
Santos
2009
Nascimento, rika de Oliveira do, 1982Desenvolvimento 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.
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.

MARIO MACHADO CHAME

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
Desenvolvimento de Sistemas.
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
INTRODUO ................................................................................. 8
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
ESTUDO DE CASO........................................................................ 48
CONCLUSO ................................................................................ 52
REFERNCIAS .................................................................................... 54
ANEXO A ............................................................................................. 57
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.
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.
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
10
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
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.
11
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:
12
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.
13
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, chegandose 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 (saberfazer).
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
14
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
15
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 prconstrudas 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 humanocomputador, 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
16
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
17
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
Funcionalidade
(satisfao das necessidades)
Confiabilidade
(imunidade falhas)
Usabilidade
(facilidade de uso)
Eficincia
(rpido e "enxuto")
Subcaractersticas
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)
Maturidade (freqncia das falhas)
Tolerncia falhas (forma de reao s falhas)
Recuperabilidade (forma de recuperao de falhas)
Inteligibilidade (facilidade de entendimento)
Apreensibilidade (facilidade de aprendizado)
Operacionalidade (facilidade de operao)
Tempo (tempo de resposta, velocidade de execuo)
Recursos (recursos utilizados)
Analisabilidade (facilidade de encontrar falhas)
Manutenibilidade
Modificabilidade (facilidade de modificar)
(facilidade de modificar)
Estabilidade (baixo risco quando de alteraes)
Testabilidade (facilidade de testar)
Adaptabilidade (facilidade de se adaptar)
Portabilidade
Capacidade para ser instalado (facilidade de instalar em outros ambientes)
(uso 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:
18
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.
19
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,
20
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
21
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.
22
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.
23
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
24
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
25
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
26
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.
27
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.
28
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
29
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:
Informao
Pare
Exclamao
30
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.
31
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?

32
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
33
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
34
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
35
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.
Ativ.
1
Ativ. 2
Ativ.
5
Incio
Fim
Ativ.
3
Ativ.
4
FIGURA 10: REPRESENTAO DO DIAGRAMA DE REDE EM PDM

Fonte: Engenharia de Software Fundamentos, Mtodos e Padres.
36
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.
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.
37
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.
38
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).
39
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
40
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
41
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.
42
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.
43
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
suprimentos/ contratos)
do
projeto
(subcontratao/
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.
44
So
definies
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;

45
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.

46
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.
47
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;

48
As figuras abaixo representam as duas principais telas do software:
FIGURA 13: TELA DE REGISTRO DE ANIMAL

Fonte: Sistema de Controle CETAS.
49
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.
50
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.
51
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
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
52
profissionais da rea de anlise e desenvolvimento de sistemas sejamos capazes de

exercer nossas competncias com um grande diferencial no mercado de trabalho.
53
REFERNCIAS
AZEVEDO, Ramon D. Projeto - A importncia do ciclo de vida. 2004. Disponvel em:

<http://imasters.uol.com.br/artigo/2651/projeto_-_a_importancia_do_ciclo_de_vida>
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:
<http://books.google.com/books?hl=pt-
BR&lr=&id=F4kmAeDBScEC&oi=fnd&pg=PA12&dq=%22Cybis%22+%22Ergonomia
+e+UsabilidadeConhecimentos,+M%C3%A9todos+e+...%22+&ots=hEfDGgtHsc&sig=5DT0mDzzlzO
XASpH326hYpYAIyw#PPA15,M1>.
BORGES, Roberto Cabral de Mello. INF0 43 Comunicaco Homem-Computador

Parte 9. 2008. Disponvel em:
<http://www.inf.ufrgs.br/~cabral/06.Erg.Soft.Abr.2008.ppt#269,1,INF
043
Comunicaco Homem-Computador Parte 6>
CAMPOS, Fbio Martinho. Quais so as Reais Caractersticas da Qualidade da NBR

ISO/IEC 9126-1? 2007. Disponvel em: <http://www.testexpert.com.br/?q=node/126>
CAMPOS, Fbio Martinho. Qualidade, Qualidade de Software e Garantia da

Qualidade
de
Software
So
as
Mesmas
Coisas?
2008.
Engenharia
de
Disponvel
em:
<http://www.testexpert.com.br/?q=node/669>.
CYBIS,
Walter
de
Abreu.
Usabilidade:
uma abordagem ergonmica.

Disponvel em: <http://www.labiutil.inf.ufsc.br/hiperdocumento/conteudo.html>.
DIAS, Maria Madalena. UEM/CTC/DIN - Disciplina: Engenharia de Software I.

Disponvel em: <http://www.din.uem.br/~mmdias/disciplina%20I/IHC_1311.doc>
54
JORNAL VICENTINO. Centro de Triagem de Animais Selvagens (CETAS) de So

Vicente
tm
novos
hspedes
em
tratamento.
2008.
Disponvel
em:
<http://www.jornalvicentino.com.br/home/2008/07/10/centro-de-triagem-de-animaisselvagens-cetas-de-sao-vicente-tem-novos-hospedes-em-tratamento/>
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:
<http://books.google.com.br/books?id=O9aWoUq6L88C&pg=PA253&dq=ergonomia
+software&lr=#PPA255,M1>.
NIELSEN,
Jakob.
Engenharia
de
Usabilidade.
1993.
Disponvel
em:
<http://www.labiutil.inf.ufsc.br/hiperdocumento/Engenharia_de_Usabilidade_Nielsen.
doc>
PAULA FILHO, Wilson de Pdua. Engenharia de Software: fundamentos, mtodos e

padres. 2000. Disponvel em: <http://www.scribd.com/doc/14157509/Engenhariade-Software-Fundamentos-Metodos-e-Padroes>
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:
<http://www.lsc.ufsc.br/~edla/ine5624/materiais/IntrodCCognicao.doc>
SANTOS, Edma; SILVA, Marco. Avaliao da aprendizagem em educao online

fundamentos, interfaces e dispositivos, relatos de experincias. Edies Loyola.
2006. Disponvel em:
<http://books.google.com.br/books?id=hxZSNbgrWMwC&pg=PA315&lpg=PA315&dq
=Avalia%C3%A7%C3%A3o+da+aprendizagem+em+educa%C3%A7%C3%A3o+onli
55
ne+fundamentos,+interfaces+e+dispositivos,+relatos+de+experi%C3%AAncias&sour
ce=bl&ots=rBf0lb2XbU&sig=GxzKVqIhorSTAnL3F28qQWt5Nko&hl=ptBR&ei=mzQXSszwD6XFtgev8_jDA&sa=X&oi=book_result&ct=result&resnum=1#PPP1,M1>
WIKIPDIA,
enciclopdia
livre.
Janela
(informtica).
Disponvel
em:
<http://pt.wikipedia.org/wiki/Janela_(inform%C3%A1tica)>
56
ANEXO A
Cronograma de desenvolvimento do trabalho.
57
CRONOGRAMA PROJETO APLICADO 5 ADS

Id
Nome da tarefa
Projeto Aplicado - Cronograma
Durao
FASE PROPOSTA
Incio
Trmino
88 dias
Ter 3/2/09
Qui 4/6/09
39 dias
Ter 3/2/09
Sex 27/3/09
Apresentao do Projeto Interdisciplinar
4 dias
Ter 3/2/09
Sex 6/2/09
Definio do Tema
5 dias
Seg 9/2/09
Sex 13/2/09
Desenvolvimento da Proposta
20 dias
Seg 16/2/09
Sex 13/3/09
Apresentao da Proposta
5 dias
Seg 16/3/09
Sex 20/3/09
Entrega da Proposta - Escrita
5 dias
Seg 23/3/09
Sex 27/3/09
FASE TRABALHO INTERDISCIPLINAR
48 dias
Seg 23/3/09
Qua 27/5/09
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
12 dias
Qua 20/5/09
Qui 4/6/09
16
Simpsio
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
Projeto: Projeto Aplicado - Cronogram

Data: Qui 21/5/09
Fevereiro
Maro
Abril
Maio
Junho
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/6
Tarefa
Etapa
Tarefas externas
Diviso
Resumo
Etapa externa
Andamento
Resumo do projeto
Data limite
Pgina 1

Projeto Aplicado CETAS

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projeto Aplicado CETAS

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO UNIVERSITRIO MONTE SERRAT

ERIKA DE OLIVEIRA DO NASCIMENTO

DESENVOLVIMENTO DE SOFTWARE PARA O

ERIKA DE OLIVEIRA DO NASCIMENTO

DESENVOLVIMENTO DE SOFTWARE PARA O

Trabalho Interdisciplinar apresentado disciplina

Orientador: Prof. MS. Nina Maria Bueno

1. Ergonomia de Software. 2. Gerncia de Projetos. 3. Estudo

ERIKA DE OLIVEIRA DO NASCIMENTO

DESENVOLVIMENTO DE SOFTWARE PARA O

Orientador: Prof. MS. Nina Maria Bueno

Em todas as atividades, sempre buscou-se, no somente sua realizao de uma

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

ERGONOMIA DE SOFTWARE ................................................ 10

O presente trabalho tem como objetivo, descrever todos os processos

Entrevista com os usurios, para levantamento dos requisitos: Nessa

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

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

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

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

Prototipao: Metodologia em que se demonstra uma verso inicial do

Desenvolvimento do sistema em Linguagem C#: a incorporao das

O presente projeto ser fundamentado teoricamente, com base nos seguintes

Ergonomia de software: Processo para a obteno de qualidade no

Gerenciamento de projeto: a aplicao de conhecimentos, habilidades e

2.1 ERGONOMIA DE SOFTWARE

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

caractersticas humanas no tratamento da informao so to importantes para o

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

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

2.1.1.1 Modelos ou Representaes Mentais

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

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

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

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

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

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

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

Reconhecimento: a capacidade humana de reencontrar no seu campo

Reconstruo: a capacidade humana de recolocar os elementos

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

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

2.1.1.4 O Raciocnio e o Aprendizado

A inferncia dedutiva, quando partindo de uma ou mais premissas

2.1.1.5 O Curso das Aes

velocidade, so tratadas sem interveno da conscincia para assegurar a

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

Intuitividade O sistema deve apresentar facilidade de uso permitindo

Eficincia O sistema deve ser eficiente em seu desempenho

Memorizao Suas telas devem apresentar facilidade de memorizao

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

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

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

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

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

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)

Maturidade (freqncia das falhas)

Tolerncia falhas (forma de reao s falhas)

Recuperabilidade (forma de recuperao de falhas)

Inteligibilidade (facilidade de entendimento)