segunda-feira, 28 de setembro de 2009
quinta-feira, 24 de setembro de 2009
[OC] - Registradores
Após última palestra da nossa Semana Acadêmica, aula de registradores.
O material está disponível na página da FAQI. Clique aqui para acessar o material.
Forte Abraço à todos e até a noite!!
(não esqueça: dia 26/setembro - Dia da Responsabilidade Social)
O material está disponível na página da FAQI. Clique aqui para acessar o material.
Forte Abraço à todos e até a noite!!
(não esqueça: dia 26/setembro - Dia da Responsabilidade Social)
quinta-feira, 17 de setembro de 2009
Atividades Avaliativas por Disciplina
FSI
1 - Estudo de Caso: Comparação entre Sites de Comércio Eletrônico
2 -
3 -Estudo de Caso: Dificuldade de Implementação de um SIG
4 - Estudo de Caso: B2B, B2C, C2C... Estratégias de uma empresa no mundo virtual
INAP
1 -
2 -
3 -Expressões aritméticas
4 -Dois execícios (simplificação e expressão em binários) + transformação
OC
1 - Quatro perguntas sobre elementos básicos do computador
2 - Exercício com circuitos de soma de um bit
3 -
4 - Somador Completo
5 - RISC
1 - Estudo de Caso: Comparação entre Sites de Comércio Eletrônico
2 -
3 -Estudo de Caso: Dificuldade de Implementação de um SIG
4 - Estudo de Caso: B2B, B2C, C2C... Estratégias de uma empresa no mundo virtual
INAP
1 -
2 -
3 -Expressões aritméticas
4 -Dois execícios (simplificação e expressão em binários) + transformação
OC
1 - Quatro perguntas sobre elementos básicos do computador
2 - Exercício com circuitos de soma de um bit
3 -
4 - Somador Completo
5 - RISC
segunda-feira, 14 de setembro de 2009
[FSI] B2B, B2C, C2C, ... quanta letrinha!!
Olá Pessoal, boa noite!!
O assunto de hoje é bastante simples, mas cheio de coisas interessantes... primeiramente vamos entender essa sopa de letrinhas...
Clique aqui e leia o post que fala sobre o assunto.
Após, executemos um estudo sobre uma arquiteteura de Sistemas de Informação relevante na construção de soluções informáticas....
Clique aqui e saiba mais sobre SOA.
Depois de conhecer as aplicações e a técnica de programação, façamos a atividade da noite... já, já você descobre qual é!!
O assunto de hoje é bastante simples, mas cheio de coisas interessantes... primeiramente vamos entender essa sopa de letrinhas...
Clique aqui e leia o post que fala sobre o assunto.
Após, executemos um estudo sobre uma arquiteteura de Sistemas de Informação relevante na construção de soluções informáticas....
Clique aqui e saiba mais sobre SOA.
Depois de conhecer as aplicações e a técnica de programação, façamos a atividade da noite... já, já você descobre qual é!!
quinta-feira, 10 de setembro de 2009
[OC] - Aula 5
Olá pessoal... inciamos hoje com algumas conversões de base que faltaram e passamos para microprocessadores.
Binário para Octal
101010012 = 10.101.0012
(separando em grupos de 3, sempre começando da direita para a esquerda)
Sabemos que 0102 = 28 ; 1012 = 58 ; 0012 = 18 portanto 101010012 = 2518
Binário para Hexadecimal
110101011012 = 110.1010.11012
(separando em grupos de 4 bits, sempre começando da direita para a esquerda)
Sabemos que 1102 = 616; 10102 = A16 ; 11012 = D16 ; portanto 110101011012 = 6AD16
Hexadecinal para Binário
3F5H = 11.1111.01012
(convertendo cada dígito hexadecimal em 4 dígitos binários)
Agora microprocessadores: clique aqui e baixe o arquivo!
Binário para Octal
101010012 = 10.101.0012
(separando em grupos de 3, sempre começando da direita para a esquerda)
Sabemos que 0102 = 28 ; 1012 = 58 ; 0012 = 18 portanto 101010012 = 2518
Binário para Hexadecimal
110101011012 = 110.1010.11012
(separando em grupos de 4 bits, sempre começando da direita para a esquerda)
Sabemos que 1102 = 616; 10102 = A16 ; 11012 = D16 ; portanto 110101011012 = 6AD16
Hexadecinal para Binário
3F5H = 11.1111.01012
(convertendo cada dígito hexadecimal em 4 dígitos binários)
Agora microprocessadores: clique aqui e baixe o arquivo!
sexta-feira, 4 de setembro de 2009
Desenvolvimento de Sistemas

Certa vez, em aula, um grande mestre – Prof. Vinícius Gadis Ribeiro, durante uma explicação sobre desenvolvimento de sistema, fez uma observação que até hoje ecoa quando preciso desenvolver qualquer aplicação. Na imagem ao lado, o retângulo representa o problema que o software deveria atender e a bolha o que o sistema realmente executa.
Poderia passar horas filosofando sobre as diferentes interpretações que pelos anos a fora fico imaginando. Detenho-me no que, para o momento, é relevante. A zona de intersecção é muito pequena.
O problema que o cliente tinha foi pouco atingido e, o esforço na produção do software gerou rotinas desnecessárias.
Lembro de uma máxima que se aplica muito bem ao momento: A informática veio para solucionar problemas que não tínhamos sem ela.
Chocante, mas é essa a característica que é atribuídas aos profissionais de TI. Para livrar-se destas amarras, algumas dicas são relevantes:
• Codifique aquilo que soluciona o problema do cliente, não o que você acredita que precisa ser codificado;
• Ouça o cliente, mas realmente ouça. Depois de ouvir descreva tudo o que vai e não vai ser produzido e, só ai parta para desenhos de modelagem do sistema;
• Como o produto não é pra você, teste a funcionalidade das rotinas junto com o cliente;
• E finalmente, a cada momento – antes de iniciar e terminar uma rotina – pergunte-se: O que é essa parte do sistema? Para que ela serve? A quem ela atende? Quanto de esforço/custo ela gera/economiza?
Não custa tentar...
Poderia passar horas filosofando sobre as diferentes interpretações que pelos anos a fora fico imaginando. Detenho-me no que, para o momento, é relevante. A zona de intersecção é muito pequena.
O problema que o cliente tinha foi pouco atingido e, o esforço na produção do software gerou rotinas desnecessárias.
Lembro de uma máxima que se aplica muito bem ao momento: A informática veio para solucionar problemas que não tínhamos sem ela.
Chocante, mas é essa a característica que é atribuídas aos profissionais de TI. Para livrar-se destas amarras, algumas dicas são relevantes:
• Codifique aquilo que soluciona o problema do cliente, não o que você acredita que precisa ser codificado;
• Ouça o cliente, mas realmente ouça. Depois de ouvir descreva tudo o que vai e não vai ser produzido e, só ai parta para desenhos de modelagem do sistema;
• Como o produto não é pra você, teste a funcionalidade das rotinas junto com o cliente;
• E finalmente, a cada momento – antes de iniciar e terminar uma rotina – pergunte-se: O que é essa parte do sistema? Para que ela serve? A quem ela atende? Quanto de esforço/custo ela gera/economiza?
Não custa tentar...
quinta-feira, 3 de setembro de 2009
Assinar:
Postagens (Atom)
