Engenharia de Sistemas IVinstitutosiegen.com.br/documentos/euhl.13493799858703.pdfpersonalizável, como é o caso das empresas de ERPs, como a SAP ou a MicroSiga que adaptam partes

Prof. Erwin Alexander Uhlmann – www.institutosiegen.com.br

Engenharia de Sistemas

IV

Prof. Erwin Alexander Uhlmann

Engenharia de Software e UML

UHLMANN, Erwin Alexander. Engenharia de

Sistemas IV. Instituto Siegen. Guarulhos, 2012.


Agradecimentos

Agradeço à minha esposa Kátia por entender

minha ausência, meus pais Mirtes e Günter por

terem criado meu caminho, aos meus alunos que

viabilizaram este trabalho e a todos os autores

de livros e bibliotecas que consultei para que

pudesse devidamente embasar este.


Sumário

Introdução ........................................................................................................................ 1

Aula 1 ................................................................................................................................. 2

O que é um software? .................................................................................................. 2

O que é Engenharia de Software? .............................................................................. 3

Métodos de ES ............................................................................................................. 3

Atributos de software ................................................................................................. 4

Desafios da ES .............................................................................................................. 4

Aula 2 ................................................................................................................................ 6

Sistemas Sociotécnicos ............................................................................................... 6

Exercício ........................................................................................................................ 7

Propriedades Emergentes ....................................................................................... 7

Engenharia de Sistema ............................................................................................ 9

Definição de Requisitos de Sistema ...................................................................... 10

Requisitos ..................................................................................................................... 11

Escopo ...................................................................................................................... 11

Viabilidade ............................................................................................................... 12

Obtenção dos requisitos ............................................................................................ 14

Obtenção de requisitos .......................................................................................... 14

Bibliografia ...................................................................................................................... 18

Índice de Figuras

Nenhuma entrada de índice de ilustrações foi encontrada.

Índice de scripts

Nenhuma entrada de índice de ilustrações foi encontrada.

1


Introdução

A Engenharia de Software é o ponto crucial para o profissionalismo. Criar sistemas

de forma amadora é simples, quase como criar programando, mas depois de um

ano alterar, progredir ou simplesmente fazer a manutenção num programa se

mostra difícil e muitas vezes impossível.

O objetivo deste trabalho é mostrar como a engenharia de software pode ser

simples e rápida de fazer para garantir maior qualidade e profissionalismo à seus

projetos.

Para quem busca entender a engenharia de software além da teoria, com projetos,

este trabalho pode ajudar muito!

Divirta-se!

2


Aula 1

O que é um software?

Para entender o software vamos primeiro disseca-lo.

A informática foi criada com base em bits e Bytes, a coleção deles, a palavra. Com as

linguagens de baixo nível foi possível cria sequencias lógicas de execução, os

scripts. Ao conjunto de scripts foi dado o nome de software.

Mas um software pode ser mais do que a coletânea de scripts. Os dados de

configuração, documentação, e arquivos que associados permitam o software

funcionar adequadamente.

A Microsoft é uma empresa de engenharia, a Apple também tem sua área de

engenharia, a Sony, a Nokia e muitas outras empresas de ponta. O que você deve

pensar para poder chegar onde elas dominam? Engenharia!

Apesar de desenvolver produtos genéricos, como o Windows, o MS Office, o

facebook, e o AutoCAD, as empresas podem desenvolver produtos específicos.

Os softwares genéricos são sistemas que atendem a maioria dos computadores de

uso genérico e seus desenvolvedores é que controlam as especificações enquanto

os sob encomenda são desenvolvidos para um cliente específico ou para um

computador específico e as necessidades são informadas pelo comprador.

Algumas empresas desenvolvem ainda um terceiro tipo, o software genérico

personalizável, como é o caso das empresas de ERPs, como a SAP ou a MicroSiga

que adaptam partes de seus softwares às especificidades dos clientes.

Exemplo:

Um site que tenha um sistema de login e senha. O sistema de login e senha pode

funcionar independente do restante do site? Ele depende de outros dados como de

um banco de dados de usuários de senhas? Os dados exibidos na tela dependem da

programação?

3


O que é Engenharia de Software?

Se entendermos o que software, então a Engenharia de Software é a disciplina

ligada à produção de software.

A engenharia se vale de métodos sistemáticos, esquemas e regras relacionadas ao

funcionamento do software, desde sua produção até seu declínio ou como também

é conhecido vulgarmente como abandonware. Os softwares descartados e que

eventualmente não funcionarão mais por falta de hardware ou outro meio que o

permita, como é o caso do Windows 3, jogos do Atari ou softwares baseados em

arquiteturas de sistemas operacionais antigas.

E qual a diferença entre engenharia de software e de sistemas?

A engenharia de sistema está baseada no desenvolvimento completo, que inclui

hardware, software e peopleware, enquanto a engenharia de software é parte

integrante deste processo. A Ciência da Computação abrange a engenharia de

sistemas.

Uma pergunta simples que frequentemente é negligenciada e, portanto,

determinante para um projeto, é quanto ao custo. Quanto custa um processo de

software?

Isto depende dos profissionais envolvidos, o tempo e a quantidade deles em cada

fase. No modelo cascata, a especificação dura cerca de 20% do tempo total de

processo de um software, o projeto cerca de 25%, o desenvolvimento, cerca de 20% e

a integração e testes, cerca de 35%. Cada profissional pode ter um custo, e cada fase

uma quantidade de profissionais.

Métodos de ES

Cada tipo de software pode ser produzido com um determinado modelo, como o de

Análise Estrutura, comum na década de 1970, o de Orientado à Funções, na década

de 1980 e por fim, com o desenvolvimento da UML, a Orientada à Objetos (OO), a

partir da década de 1990.

4


Atributos de software

Característica do produto Descrição

Facilidade de Manutenção O SW deve ser desenvolvido para que a manutenção, alteração e/ou evolução atendam as necessidades de mudanças de mercado. O sistema deve ser pensado em independência funcional, baixo acoplamento e alta coesão. Uma página HTML envia os dados para a página com a programação ou modelo de negócio (PHP) e esta envia para o Banco de Dados.

Confiança Confiabilidade: Funcionamento até a falha; Proteção: Divido em camadas para que não haja acesso; Segurança: Sistema que permita o acesso por meio de chave;

Eficiência Software que utilize o mínimo do computador, como códigos simplificados (OO), e tempo de resposta reduzido.

Usabilidade Que permita o acesso ao usuário para qual foi projetado, sem esforço demasiado ou dificultado.

Desafios da ES

A ES deve pensar sempre no desenvolvimento de softwares com Independência

Funcional, baixo Acoplamento e Alta Coesão.

Independência Funcional: Como diz o nome, o funcionamento não deve depender

de outras partes, está ligado à modularidade, ocultação de informações e

abstração. A ocultação de informações se dá pelo fato de não alocar dados sigilosos

como senhas no mesmo script ou módulo. Abstração é a consideração de apenas

uma das partes do software em detrimento do todo, isto é, ele deve ser pensado

apenas como aquele módulo, sem se considerar o programa inteiro.

Baixo Acoplamento: É a medida de interdependência entre dois ou mais módulos.

Se pensarmos num software com classes, qual a interdependência entre as classes?

E se uma dessas classes for removida, o script continuará a funcionar?

5


Alta Coesão: É a medida da força funcional entre módulos, isto é, quando um

módulo disponibilizar dados o outro que precisar poderá utilizá-lo sem perdas,

falhas ou necessidade de tratamento de dados para poder utilizar.

Então, se um programa for elaborado com independência funcional, poderá ser

utilizado mesmo que outros módulos não estejam disponíveis, desde que ele tenha

baixo acoplamento ou que não dependa de outros módulos para funcionar.

Diferente da independência funcional que prevê o funcionamento e fornecimento

de dados independente o acoplamento prevê que módulos poderão ser instalados

ou removidos sem afetar o funcionamento do todo e por fim, a alta coesão indica o

fornecimento de dados deste módulo no formato correto de leitura.

O desafio da heterogeneidade pressupõe que os softwares devem estar cada vez

mais disponíveis em sistemas distribuídos, como na web e se adaptar a sistemas

legados sem que o usuário tenha que trocar de ambiente entre os novos sistemas e

os antigos ou que a empresa tenha que ter mais de um sistema, como sistemas de

apoio.

O desafio da entrega é sobre a necessidade de desenvolvimento de forma cada vez

mais ágil e com menor impacto ao cliente, ainda que se considerassem as mudanças

de escopo do projeto.

Desafio da confiança que é desenvolver softwares que transmitam, armazenem e

seja apenas o desejado, em especial em sistemas web em que se não se tem certeza

sobre o que está sendo transmitido, armazenado nem se a página visitada é

realmente a desejada, como em sites de bancos.

6


Aula 2

Sistemas Sociotécnicos

Em Engenharia de Software é preciso pensar num sistema composto pelo próprio

software, o hardware e as pessoas que irão utilizá-lo, ou seja, peopleware, o

componente humano.

Um sistema é um conjunto de componentes interrelacionados criados para atingir

um determinado objetivo.

Para planejar um sistema um sistema é preciso pensar no componente técnico,

como as especificações de hardware e software e no levantamento de processos,

regras internas da organização, leis, entre outros fatores que rejam as pessoas.

Então num levantamento para um sistema sócio técnico é preciso pensar:

No âmbito da empresa:

Situação Descritivo técnico

Atual

Quais são os processos que o setor/função faz? (Funções)

Como estes processos são feitos? (manualmente, Excel...)

De onde vêm os dados? (Contabilidade, RH, Cliente...)

Qual o formato? (Papel, verbal, txt...)

BPM, leis, regras.

Desejada

Como os itens levantados na situação atual irão ficar?

Instalação de um sistema integrado com interfaceamento via XML

entre os sistemas das filiais.

Motivadores

Por que mudar?

Agilidade logística, de vendas, tomada de decisão, controle, redução

de custos, etc. Isto norteará o projeto!

No Âmbito do Software:

Situação Descritivo técnico

Atual Quais os softwares utilizados? Qual formato exportam arquivos?

7


Qual a plataforma? (Windows, Linux, Oracle...)

Desejada

Como os itens levantados na situação atual devem ficar?

Instalação de um sistema integrado com interfaceamento via XML

entre os sistemas das filiais.

Motivadores

Por que mudar?

Agilidade logística, de vendas, tomada de decisão, controle, redução

de custos, etc. Isto norteará o projeto!

Exercício

Crie exemplos próximos da realidade de uma pizzaria comum de bairro. Ela tem o

processo de atendimento, cocção da pizza e entrega via motoboy.

No atendimento há um computador simples com 3 anos de uso e um sistema de

código aberto (freeware) de controle de pedido, cadastro de clientes, pedidos por

entrega, calculo de valores, e alguns relatórios de tempo de entrega, total de

pedidos, produto mais pedido, entre outros, em Excel.

O cliente deseja melhorar seu sistema. Crie um projeto que permita isto conforme o

já estudado.

Propriedades Emergentes

A propriedade emergente de um sistema é a somatória das partes, isto é, cada

parte tem sua função, mas o conjunto é mais que a soma das funções, é a

propriedade que emerge do sistema. 1 + 1 = 3!

O descritivo das propriedades pode ser feita separadamente do emergente.

Uma roda serve para girar, com pneu, serve para absorção de irregularidades e

tração, o pedal recebe a força motriz e em conjunto com a corrente que transmite

para a coroa, transfere esta força para a roda. O chassi (corpo) junta as partes e a

bicicleta serve para transportar de forma rápida e leve uma pessoa, sendo isto sua

propriedade emergente.

As propriedades emergentes são divididas em funcionais e não-funcionais.

8


Funcionais: Para que se destina um software. Sua função. Somar, imprimir,

desenhar, gerenciar backup, etc.

Não-funcionais: Qual o comportamento do software. Como ele realiza as

funções. Sendo:

Volume: Espaço ocupado em disco, medido em Bytes. Um sistema distribuído pode

ocupar 10MB em um servidor, 2MB em outro e mais 1MB nos clientes, sendo assim,

o volume total é de 10 + 2 + (1 x nº de clientes).

Confiabilidade: A confiabilidade do sistema depende de seus componentes. As

interações podem causar situações inesperadas e falhas. Ela é medida pelo tempo

de uso normal até a falha. Se o sistema em produção (software pronto, instalado e

com pessoal treinado), funciona normalmente, desde seu início até a data atual, 2

meses depois, a confiabilidade é de 2 meses. Corrigida a falha, a confiabilidade deve

ser novamente contada, desde a correção.

Proteção: É a capacidade de resistir a ataques. Um pouco diferente da

confiabilidade, a proteção é de difícil mensuração. Não se pode medir a proteção

até sua invasão. Se for invadido, não está protegido. Sua maior dificuldade não está

em criar mecanismos e meios de proteção para ataques conhecidos, mas para os

desconhecidos.

Facilidade de reparos: Reflete a capacidade de resolver uma falha em razão do

tempo e da complexidade. Isto depende da capacidade de diagnosticar, acessar o

componente e corrigir o problema. Ex.: Para diagnosticar o próprio sistema pode

informar erros com mensagens, acessar componentes de forma rápida com

separação dos componentes em camadas e corrigir com documentação adequada,

backups e sistemas de restauro.

Usabilidade: Facilidade de uso. Quantos cliques para acessar a informação, gravação

em tempo real, histórico, meios alternativos de operação (alternativos ao mouse,

teclas de atalho, disponibilidade de informações no mesmo lugar, etc.)

9


Confiabilidade de HW: Qual a estatística de falhas? Qual a probabilidade? Qual o

tempo de conserto?

Confiabilidade de SW: Uma falha de HW pode ser intermitente, mas no SW, que não

desgasta, deve ser recorrente e persistente. Qual a probabilidade de falha? Quanto

tempo para conserto.

Confiabilidade de PW: Probabilidade de erro do operador. O que pode gerar erro ou

engano? Cuidado com a linguagem. Gravar ou Executar?

Engenharia de Sistema

A Engenharia de Sistemas abrange as seguintes atividades:

Especificação: Requisitos de software, hardware e pessoas;

Projeto: UML, documentação, arquitetura de HW, etc;

Implementação: Criação de ambiente de teste para de produção, ajustes e

treinamento;

Validação: Consequência da Implementação, homologação;

Manutenção: Rotina de limpeza de logs, de arquivos excluídos, e atividades em HW;

Upgrade: Melhorias no sistema. Deve obedecer aos requisitos funcionais e não-

funcionais;

Definição de

Requisitos

Projeto do

sistema

Desenv. De

subsistemas

Integração

do sistema

Instalação

do sistema

Evolução do

sistema

Desativação

do sistema

10


Definição de Requisitos de Sistema

Os requisitos são as definições do que o sistema deverá fazer, suas funções, e suas

propriedades essenciais e desejáveis.

Requisitos funcionais abstratos: Especifica as propriedades do projeto sem se

preocupar em como fazer, mas com o que fazer, como:

Elaborar um sistema que integre o sistema administrativo do colégio, o

cadastro dos alunos, professores, disciplinas, notas, faltas e

histórico escolar, uma rede social, uma wiki e um site, com interface

web.

Estas especificações NÃO SÃO requisitos funcionais abstratos:

O sistema deverá ter um Banco de Dados com dados dos alunos, das

disciplinas cursadas, em curso e possíveis de cursar, os professores,

salas, diário de sala, histórico do aluno, faltas e notas.

Propriedades de sistema:

São as propriedades emergentes do sistema como segurança, disponibilidade,

desempenho.

Exemplo:

O sistema deverá contar com segurança para uso de cartão de crédito,

envio de senhas, estar disponível 24h por dia, 7 dias por semana e

como se trata de um e-commerce, ter alto desempenho para envio e

recebimento de dados.

Características que não devem ser apresentadas no sistema:

Para trabalhadores em uma linha de produção, o sistema NÃO deverá apresentar

informações em excesso, não deverá ver informações sobre dados do cliente, ou

ainda sobre as finanças da empresa.

Site do colégio Rede social

Wiki Sistema de

gestão

11


Requisitos

O problema a ser resolvido é estabelecer uma linguagem compreensível entre o

cliente e o programador, o desenvolvedor do software, de modo formal.

A Engenharia de Sistemas é ampla, abrangente e abstrata e a Engenharia de

Software é técnica, específica e concreta. A primeira não especifica como fazer, mas

o quê fazer e a segunda não é compreensível pelo cliente ou ele não é capaz de

especificar corretamente para o desenvolvimento.

Para resolver o problema de comunicação, a análise de requisitos pode ajudar na

solução. Para tanto é preciso elaborar:

Escopo;

Estudo de viabilidade; e

Obtenção dos requisitos.

Escopo

O escopo deve ser elaborado com o cliente, veja um modelo:

Item Conteúdo

Patrocinador Quem solicitou ou o pagador.

Gerente Identificação, responsabilidades e autoridade

Organograma do projeto Organograma

Time do projeto Relação de recursos humanos

Comitê executivo Responsável pela análise e aprovação de mudanças

Descrição do projeto Do que se trata o projeto

Objetivo do projeto Por que e para quê será feito este

Engenharia de

Sistemas

Engenharia de

Software R

12


projeto?

Justificativa do projeto Em função dos problemas e das soluções propostas (contidos no escopo), atende o objetivo?

Produto do projeto Pré-projeto, simples e descritivo

Expectativa do cliente Conformidade com o termo de abertura, no prazo e custos estabelecidos

Restrições Custo, prazo, pessoas, equipamentos, etc.

Premissas As pessoas poderão se adequar, a comunicação será por meio tal, qte de horas/semana dos recursos, etc.

Limites do projeto O que será feito e não será feito?

Estrutura analítica do projeto Esquema visual do que será feito

Principais atividades e estratégias Descritivo da estrutura analítica

Entregas O que será feito? SW, HW, documentação

Orçamento Quando e quando será pago?

Plano de entregas O que será e quando será entregue (documentos)

Riscos iniciais Falta de mão de obra, leis, erros de execução, etc.

Registro de alterações Data, quem modificou, quem aprovou e o que mudou

Viabilidade

O estudo da viabilidade permite criar indicadores para decisão de continuar no

planejamento e desenvolvimento do software ou não, bem como apontar soluções

alternativas para a solução de problemas de desenvolvimento. Para tanto, a análise

deve conter:

O projeto pode ser feito?

o Quais linguagens estão envolvidas?

o Qual hardware é necessário?

o As pessoas envolvidas têm as possuem as competências essenciais

para elaborar o projeto?

O produto final terá valor para o cliente?

o Valor é medido pela garantia e utilidade, que são:

Garantia é servir para o uso sem variações de desempenho;

Ex.: De 100 vezes que você utilizou seu computador, quantas

13


ele travou (por hardware) ou não iniciou o sistema

operacional?

Utilidade é servir para um propósito ou melhorar o

desempenho médio;

Ex.: de todos os dias da semana, quantas vezes você utilizou

seu computador pessoal? Das vezes que você utilizou, quanto

tempo a menos você levou para elaborar suas tarefas?

o Identificação dos problemas e possíveis soluções

Identificação e qualificação de problemas

Gravidade Baixa Impactos dentro dos planos contingenciais de autonomias dos gerentes, não impacta no tempo.

Média Impactos afetarão o tempo de entrega em até 10%, o custo acima das autonomias gerenciais

Alta Afetará o tempo em mais de 10% do prazo e o custo com acionamento do Gerente ou Sponsor. Qualificação

Baixa (até 20% de prob.) 1 em cada 5 vezes pode ocorrer

Atraso no processo de codificação do sistema (programação) por transito (trabalho no cliente) em mais 1h por dia. Baixa gravidade, pois não afeta o processo como um todo e baixa probabilidade de ocorrer.

Perda de um programador durante o processo, no segundo quartil. Probabilidade! Gravidade média, pois deverá haver novo treinamento e interação com o projeto. Baixa probabilidade, pois os salários são adequados, a mão de obra não é específica ou o projeto é de linguagem única.

Falha no levantamento dos requisitos que desqualifiquem o projeto, mudança de lei, ausência ou demissão de um dos dois programadores (50%). Gravíssimo! Mas a probabilidade de ocorrer é baixa.

Média (21% à 60%) Até 3 em cada 5 vezes ocorre.

Alta (> que 60%) Mais do 3 em 5 vezes ocorre

Se o local fica em área alagável, a probabilidade de alagamento é alta no verão e se for exatamente lá que ocorrer o trabalho no estilo Just In Time... Gravíssimo!

Identificação de soluções e prioridades

o Definição da solução adotada

14


Estudo e planificação da estrutura organizacional, usuários, softwares

existentes, políticas, funções, cargos, missão, visão, objetivos, etc.

Tipificação de viabilidade

Operacional

Índice de funções solicitadas (processos organizacionais) e os entregues

adequadamente. Caso hajam inconsistências, é preciso levantar se foram problemas

de requisitos, de execução ou de mudanças realizadas depois do projeto, para tanto

é preciso documentar e datar.

Técnica

Quantos recursos devem ser envolvidos para solucionar um problema. Qual o valor

(financeiro e de mais valia) do sistema?

Cronograma

Tempo de realização do projeto x recursos = custo do projeto (R$)

Econômica

A organização pode determinar o custo do processo, você pode determinar o

ganho em tempo para realizar o cálculo de custo x benefício.

Obtenção dos requisitos

Para obter bons requisitos é preciso uma visão top down ou bottom up. Isto vai

depender do tipo de sistema e como se deve estrutura-lo.

Para se elaborar os requisitos, podem ser consultados:

Clientes, para determinar o desejado;

Usuários, que utilizarão o sistema;

Administradores, para compreensão do modelo de negócio;

Pares, pessoas que conheçam o assunto ou especialistas na área para

validação;

Concorrentes.

Obtenção de requisitos

Modelo RAPITO

15


Requisitos, Análise, Projeto, Implementação, Teste e Operação;

Motivação: Como criar uma documentação com linguagem comuns para o cliente e

a equipe de desenvolvimento?

Técnicas de obtenção de requisitos

Entrevista estruturada, com formulários padrão;

Ata de Reunião de Entrevista Projeto: <<nome do projeto>> Presentes: Integrantes Ausentes: Data: Local:

Data: <<data da entrevista>>

Entrevistados: <<nomes e papéis dos entrevistados, separados por vírgula>>

Entrevistadores: <<nomes dos entrevistadores, separados por vírgula>>

Duração: <<duração no formato 00:00>>

Assunto: <<texto sucinto indicando o assunto principal da reunião>>

Objetivos: • <<texto descrevendo o objetivo 1 da entrevista>> • <<texto descrevendo o objetivo n da entrevista>>

Perguntas Formuladas: • <<listar as perguntas formuladas na ordem em que elas foram feitas ao entrevistado>>

Pontos Discutidos: • <<texto descrevendo alguma informação relevante capturada na entrevista>>

Workshop;

Estudo de cenários;

Casos de Uso;

Diagrama de Atividades;

Protótipos;

Etc;

16


Tipos de Requisitos

Requisitos Funcionais são assuntos de importância fundamental ou essencial ao

produto. Eles descrevem o que o produto tem de fazer ou que ações processuais

deve tomar.

Comumente são descritos em documentos como RF ou REF e acompanhado de

numerais sequenciados. RF01 ou REF02.

Requisitos Não Funcionais são as propriedades que as funções devem ter, tais

como desempenho, usabilidade, proteção, entre outros.

Comumente são descritos em documentos como RNF e acompanhado de numerais

sequenciados. RNF01.

Notações

Linguagem Natural Estruturada;

o Formulários;

o Uso da taxonomia; (uso adequado e descritivo das palavras). Ex:

Agregar valor: Agregar, juntar, somar. Valor: Garantia + Utilidade;

Garantia: Nº total de vezes de uso com sucesso. Utilidade: Nº total de

possibilidades de uso / nº efetivo de usos = taxa de utilidade. Assim:

X = (Nº de Funcionalidades do sistema legado);

Y = (Nº de uso + (nº de usos) + (nº possib. De uso / nº efetivo de uso));

Valor Agregado = Y – X

Linguagem de descrição de projetos

o Portugol, linguagem estruturada;

Notações gráficas

o IDEF0, UML, DFD, etc;

Modelo de Levantamento de Requisitos

Solicitante (Sponsor):

Usuários: Defina quem irá utilizar o sistema. A quem se destina.

17


Requisitos de Negócio(RN): Qual o objetivo do SW, por que a organização precisa

deste software, veja mais no Escopo.

Responsabilidade dos usuários: As responsabilidades devem estar alinhadas com as

funções do usuário.

Prioridades de desenvolvimento:

Prazos:

Responsável:

Checklist de Requisitos

Os requisitos podem e foram mensurados? Foram criadas as métricas para os

requisitos Funcionais e Não Funcionais?

O requisito viola alguma regra de negócio? Corrija o requisito!

É possível definir testes para os requisitos? Como?

Os requisitos seguem as referências?

o Especificação de Requisitos de Software (ERS);

IEEE/ANSI 830-1998;

18


Bibliografia

HOGAN, Brian P. Web Design para Desenvolvedores. Rio de Janeiro. Editora Ciência

Moderna, 2011.Pressman, Roger S. Engenharia Web. Rio de Janeiro. LTC, 2009.

PRESSMAN, Roger S. Engenharia Web. Rio de Janeiro. LTC, 2009.

CYBIS, Walter. Ergonomia e Usabilidade: conhecimentos, métodos e aplicações. São

Paulo. Novatec, 2007.

SILVA, Maurício Samy. Construindo sites com CSS e (X)HTML: sites controlados por

folhas de estilo em cascata. São Paulo. Novatec, 2008.

POWERS, Shelley. Aprendendo JavaScript. São Paulo. Novatec, 2010.

SILVA, Maurício Samy. Criando sites com HTML: sites de alta qualidade com HMTL e

CSS. São Paulo. Novatec, 2008.

Documents

Engenharia de Sistemas IVinstitutosiegen.com.br/documentos/euhl.13493799858703.pdfpersonalizável, como é o caso das empresas de ERPs, como a SAP ou a MicroSiga que adaptam partes