Até o ano de 2005 a principal linguagem de programação estudada no curso de Sistemas de Informação do Centro Universitário Luterano de Santarém era Pascal. Além de Pascal, alguns outros paradigmas eram estudados brevemente na disciplina Paradigmas de Linguagens de Programação, e C++ um pouco mais profundamente abordado em linguagem de Programação Orientada a Objetos. Há muito vinha sendo discutido nas reuniões do colegiado a inclusão de Java como a principal linguagem do curso. Sempre se colocava em pauta a dificuldade que os alunos teriam com o novo paradigma como um obstáculo à concretização da idéia. Observa-se que aos alunos serem apresentados a um paradigma, eles se fecham para todos os outros. Essas dificuldades eram sentidas quando se iniciava o estudo de C++. Enfim, a partir do ano de 2006, Java foi implantada como linguagem a ser estudada nas disciplinas iniciais do curso. Um excelente trabalho foi realizado como forma de disseminar a linguagem entre os membros da comunidade acadêmica do curso, principalmente com a criação do projeto de extensão Java & Eu. O que se constata agora é a resistência oferecida pelos acadêmicos ao serem apresentados a uma nova linguagem para eles, principalmente Pascal. A seguir serão apresentados argumentos que justificam o estudo de Pascal, além de Java, no curso de Sistemas de Informação.
O curso de Sistemas de Informação tem como objetivo formar profissionais que estejam aptos a avaliar, dimensionar e selecionar recursos de tecnologia da informação de acordo com as necessidades específicas de uma organização. Esta é apenas uma das habilidades que deve ter o egresso do curso, além de outras. Assim, o curso deve prover aos acadêmicos diversas abordagens sobre uma mesma matéria de forma que eles estejam preparados para oferecer opções diferenciadas às empresas onde venham prestar serviço. Em conseqüência disso, no caso de linguagens de programação, o curso oferece o Delphi como ambiente para desenvolvimento de software comercial. Sendo o Delphi baseado na linguagem Object Pascal, é natural que essa linguagem também seja utilizada em algumas disciplinas, para preparar os alunos para o estudo de Delphi em Linguagem de Programação Comercial. E por quê Delphi? Por quê não VisualBasic? Se as duas linguagens (ObjectPascal e Basic) em que se baseiam os ambientes forem analisadas sob o aspecto de orientação a objetos a conclusão que se chega é que a abordagem de ObjectPascal é mais eficiente, principalmente quando se trata de herança. Apesar de Basic ser mais simples de ser aprendida que ObjectPascal, deve-se pensar em desenvolvimento em equipe, quando a orientação a objetos é fundamental, devido principalmente à reutilização de código. Ambas estão no grupo das chamadas Rapid Application Development (RAD), o que as tornam as mais populares para o desenvolvimento voltado para ambientes GUI (Interface Gráfica do Usuário). Segundo o índice TIOBE de setembro/2008 a linguagem Delphi é a décima mais popular do mundo. Ao se observar a lista, verifica-se que, Java é a primeira, VisualBasic a quarta e Delphi a décima. VisualBasic é mais popular que Delphi por ser a linguagem da Microsoft e não porque é melhor. As outras linguagens, pela nossa avaliação, não se enquadrariam no que se chama linguagem comercial e visual, e portanto ficam fora dessa discussão. De qualquer forma a opção por uma linguagem para desenvolver um sistema deve levar em consideração as necessidades do cliente. É uma decisão de projeto. Espera-se ter contribuído para justificar o estudo de mais de uma linguagem de programação no curso de Sistemas de Informação e também o porquê da opção pelo ambiente Delphi.
quinta-feira, 11 de setembro de 2008
sábado, 6 de setembro de 2008
Minha paixão pela computação - I
No ano de 1976 entrei para o curso de Engenharia Elétrica - Opção Eletrônica na UFPa. Logo nos primeiros semestres fiz minha matrícula numa disciplina chamada "Introdução à Ciência da Computação". Após a tradicional introdução que conta a história do computador, passando pela numeração binária, iniciamos o estudo de algoritmos e fluxogramas. Veio então meu primeiro programa, na linguagem FORTRAN versão Monitor, muito usada no meio científico naquela época. O professor então nos instruiu como deveríamos proceder para, após criarmos o código do programa, testá-lo no computador da universidade. Hoje, nas aulas de laboratório do curso de Sistemas de Informação do CEULS, temos dois alunos por máquina, às vezes até um por máquina. Nem em meus sonhos mais otimistas conseguia imaginar isso. O fato é que tínhamos que compartilhar um único computador para todas as atividades da instituição. Era um IBM 1130. Esse computador tinha 16K palavras de 16 bits de memória e cada unidade de disco atingia a capacidade de 512k palavras. Algumas imagens dessa maravilha podem ser vistas em http://palazzo.pro.br/hist/ibm_1130.htm. Para testar um programa precisávamos digitar o código em uma máquina chamada perfuradora de cartões. Cada linha de código tinha no máximo 80 caracteres e era inserida em um cartão. Nesse cartão cada caractere inserido correspondia a uma seqüência de furos. Algum tempo na fila da perfuradora e vários cartões estragados depois, juntávamos aquele monte de cartões, chamado deck, e entregávamos a um atendente que protocolava. Dois dias depois de uma espera angustiante recebíamos o resultado: nosso deck de cartões e uma listagem do nosso código. Se tivesse funcionado, o resultado saia na própria listagem. Monitor de vídeo? LCD? O que é isso? E se não funcionasse? Bem, analisávamos a listagem conferindo sintaxe, ordem dos cartões (alguém esbarrou e cairam todos no chão!!!), lógica, etc. Mais algum tempo na fila da perfuradora, cartões inutilizados e nosso deck estava pronto para um novo teste. O ciclo se repetia até que tudo estivesse rodando perfeitamente. Essa história prossegue outro dia.
sexta-feira, 31 de agosto de 2007
Análise de Sistemas
Análise é a tarefa de identificar e descrever os requisitos de um sistema, definindo a forma como ele deve funcionar para atender as necessidades de todos os interessados. A tarefa de análise define "o que" o sistema deve fazer sem se preocupar "como" será feito. Durante a análise são criados diversos modelos do sistema, que o descrevem em diferentes perspectivas e níveis de detalhe.
A análise é um mecanismo de comunicação e também um acordo entre os interessados. Na análise são definidas as funções que serão implementadas no sistema e, por conseguinte, as funções que não farão parte do escopo do mesmo.
Segundo Pressman, qualquer método de análise deve contemplar cinco atividades:
Modelos de Análise
Existem algumas propostas de modelos para descrever a análise de sistemas:
O trabalho de análise é feito a partir da comunicação entre as pessoas interessadas. A comunicação, em geral, é feita da linguagem natural dessas pessoas, tais como o português, o inglês, etc. Um grande problema dessas linguagens é que elas permitem a formação de expressões ambíguas.
No desenvolvimento de sistemas deve-se evitar as duplas interpretações. Assim, deve ser utilizada uma linguagem de forma que uma sentença só tenha uma interpretação. Várias linguagens foram criadas, principalmente as gráficas, com o objetivo de restringir as ambiguidades e também de facilitar o entendimento por todos os interessados. Dentre essas ferramentas de análise podemos relacionar a Técnica Estruturada e a UML (Unified Modeling Language).
A análise é um mecanismo de comunicação e também um acordo entre os interessados. Na análise são definidas as funções que serão implementadas no sistema e, por conseguinte, as funções que não farão parte do escopo do mesmo.
Segundo Pressman, qualquer método de análise deve contemplar cinco atividades:
- Representar e entender o domínio da informação;
- Definir as funções que o sistema deve executar;
- Representar o comportamento do software em função dos eventos externos;
- Separar os modelos de informação, função e comportamento de maneira a apresentar os detalhes de forma hierárquica, e;
- Prover a informação essencial em direção à determinação dos detalhes de implementação.
Modelos de Análise
Existem algumas propostas de modelos para descrever a análise de sistemas:
- Modelo de Negócio: descreve como funciona o negócio onde o sistema está inserido.
- Modelo de Dados: descreve os dados armazenados na forma de um modelo conceitual, utilizando o modelo entidades-relacionamentos.
- Modelo Funcional: descreve a funcionalidade essencial do sistema, utilizando o diagrama de fluxo de dados.
- Modelo Orientado a Objetos: descreve o sistema através dos dados e das funcionalidades, utlizando o diagrama de classes.
O trabalho de análise é feito a partir da comunicação entre as pessoas interessadas. A comunicação, em geral, é feita da linguagem natural dessas pessoas, tais como o português, o inglês, etc. Um grande problema dessas linguagens é que elas permitem a formação de expressões ambíguas.
No desenvolvimento de sistemas deve-se evitar as duplas interpretações. Assim, deve ser utilizada uma linguagem de forma que uma sentença só tenha uma interpretação. Várias linguagens foram criadas, principalmente as gráficas, com o objetivo de restringir as ambiguidades e também de facilitar o entendimento por todos os interessados. Dentre essas ferramentas de análise podemos relacionar a Técnica Estruturada e a UML (Unified Modeling Language).
segunda-feira, 28 de maio de 2007
Cinco tipos de personalidades que você não quer em sua equipe
Há cinco tipos de membros de equipe de projeto que não queremos em nossos projetos - e que você não quer nos seus. Se você notar algumas dessas características abaixo em pessoas com quem você trabalha, você precisa agir para transformá-las em membros de equipe que todos os gerentes de projeto invejam.
O Cowboy: esta pessoa é selvagem e lunática. Cowboys não pensam duas vezes antes de incluir comentários inapropriados ao código, esconder ovos de Páscoa na aplicação, fazer remendos no escopo do projeto. Cowboys frequentemente são trabalhadores inteligentes e rápidos e gostam de ser criativos. Trabalhe com essas pessoas, estabelecendo regras e procedimentos, controle de qualidade, tal como revisões em pares, e conversas diretas sobre o que é permitido.
O Rato: o rato é uma pessoa tímida e retraída que precisa de sua instrução, aprovação e mão forte em cada ação que ela realiza. Ratos podem ser facilmente influenciados pelos membros da equipe, stakeholders, e pelos seus próprios medos de prosseguir no trabalho. Seu trabalho é ensinar os ratos a rugir construindo sua confiança e forçando-os a tomar decisões.
A Rocha: Duro, teimoso e difícil de mudar, esse é a Rocha. Rochas são as pessoas que geralmente tem anos de experiência e querem fazer as coisas à sua maneira porque é a maneira correta. São o tipo de pessoa que dizem, "Há duas maneiras de desenvolver uma aplicação: a minha maneira e a maneira correta - e elas são a mesma". Negocie com a Rocha para estabelecer um comando firme e segui-lo.
O Linguista: Linguistas adoram linguagem, e não sabem quando parar de falar. Suas conversas sem fim consomem tempo de projeto, de reuniões, e roubam tempo de outros desenvolvedores, que estão trabalhando em suas tarefas. Você tem que negociar com essas pessoas diretamente conduzindo-as à direção certa. Se um linguista perturbar a equipe de projeto, você tem que intervir ocasionalmente.
O Tio: Lembra do seu tio favorito? É o cara com todas as brincadeiras, estórias engraçadas e truques de mágica. Você adora o seu tio, mas não quer ele em seu projeto. Tios são normalmente trabalhadores rápidos e supõem que o resto da equipe trabalha tão rápido quanto eles. Dê a eles tarefas mais desafiadoras para garantir que eles não vão ficar entediados e começar a incomodar os ouvidos do restante da equipe.
Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.
O Cowboy: esta pessoa é selvagem e lunática. Cowboys não pensam duas vezes antes de incluir comentários inapropriados ao código, esconder ovos de Páscoa na aplicação, fazer remendos no escopo do projeto. Cowboys frequentemente são trabalhadores inteligentes e rápidos e gostam de ser criativos. Trabalhe com essas pessoas, estabelecendo regras e procedimentos, controle de qualidade, tal como revisões em pares, e conversas diretas sobre o que é permitido.
O Rato: o rato é uma pessoa tímida e retraída que precisa de sua instrução, aprovação e mão forte em cada ação que ela realiza. Ratos podem ser facilmente influenciados pelos membros da equipe, stakeholders, e pelos seus próprios medos de prosseguir no trabalho. Seu trabalho é ensinar os ratos a rugir construindo sua confiança e forçando-os a tomar decisões.
A Rocha: Duro, teimoso e difícil de mudar, esse é a Rocha. Rochas são as pessoas que geralmente tem anos de experiência e querem fazer as coisas à sua maneira porque é a maneira correta. São o tipo de pessoa que dizem, "Há duas maneiras de desenvolver uma aplicação: a minha maneira e a maneira correta - e elas são a mesma". Negocie com a Rocha para estabelecer um comando firme e segui-lo.
O Linguista: Linguistas adoram linguagem, e não sabem quando parar de falar. Suas conversas sem fim consomem tempo de projeto, de reuniões, e roubam tempo de outros desenvolvedores, que estão trabalhando em suas tarefas. Você tem que negociar com essas pessoas diretamente conduzindo-as à direção certa. Se um linguista perturbar a equipe de projeto, você tem que intervir ocasionalmente.
O Tio: Lembra do seu tio favorito? É o cara com todas as brincadeiras, estórias engraçadas e truques de mágica. Você adora o seu tio, mas não quer ele em seu projeto. Tios são normalmente trabalhadores rápidos e supõem que o resto da equipe trabalha tão rápido quanto eles. Dê a eles tarefas mais desafiadoras para garantir que eles não vão ficar entediados e começar a incomodar os ouvidos do restante da equipe.
Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.
A morte pela documentação
Frequentemente nós tendemos a pensar na documentação como um componente adicional a um projeto em vez de uma parte real do projeto. A verdade sobre este assunto é que a documentação pode fazer a diferença entre o sucesso e o fracasso de um projeto.
Vez após vez, organizações têm criado bons produtos mas não investido os recursos necessários em sua documentação. Muitos desses produtos se tornaram um fracasso de mercado, não por serem maus produtos, mas porque as pessoas não sabiam como usá-los.
Havia uma grande organização de software que costumava fazer bons pacotes de desenvolvimento. A versão 3 de um software desta companhia era muito bem aceito e tinha grande chance de se tornar a plataforma de desenvolvimento dominante em uma área específica.
Querendo dominar o mercado, a organização investiu todos os seus recursos na versão 4. A interface com o usuário foi mudada na versão 4. Mudaram as opções. Mudaram as chamadas. Mudaram tanto que os usuário teriam dúvidas se a versão 4 era o mesmo produto que a versão 3.
De fato, foi criado um produto de desenvolvimento que estava bem à frente de seu tempo e teria impulsionado dramaticamente a programação. O que aconteceu, na verdade, é que a coisa toda se inverteu e o software foi descontinuado. Enquanto isso, outra organização liberou o software de desenvolvimento que se tornou padrão de fato.
O que deu errado? Como essa organização falhou tão miseravelmente?
Ela vendeu o produto por dois preços. Pelo primeiro preço a empresa entregava apenas a mídia. Pelo segundo preço (quase duas vezes mais) entregava aos usuários a mídia e milhares de páginas de manuais de como usuá-lo.
Muitos programadores pensaram que mudando da versão 3 para a versão 4 estariam fazendo uma mudança evolucionária, e não compraram os manuais. Sem os manuais, os desenvolvedores se perderam sem conseguir imaginar como fazer o que eles precisavam fazer. Frustrados e aborrecidos, os desenvolvedores abandonaram o pacote.
Aqueles que adquiriram os manuais foram literalmente esmagados pelos milhares de páginas espalhadas por cinco livros que se referenciavam mutuamente de tal modo que os usuários tinham que ter todos os livros abertos ao mesmo tempo de maneira a imaginar como fazer o que precisavam fazer. Estes que gastaram o dinheiro extra também abandonaram a nova plataforma.
Naturalmente a plataforma morreu; não porque não era boa, mas porque a documentação a matou. Documentação escrita adequadamente, empacotada adequadamente como um produto de qualidade, deveria impulsionar a empresa para uma posição invejável.
Quando você projetar sua documentação, tenha em mente essa história e assegure que seus produtos não se tornem presa do mesmo fato. Esta catástrofe é bastante fácil de prevenir, mas você deve fazer um esforço consciente de fazer isso.
Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.
Vez após vez, organizações têm criado bons produtos mas não investido os recursos necessários em sua documentação. Muitos desses produtos se tornaram um fracasso de mercado, não por serem maus produtos, mas porque as pessoas não sabiam como usá-los.
Havia uma grande organização de software que costumava fazer bons pacotes de desenvolvimento. A versão 3 de um software desta companhia era muito bem aceito e tinha grande chance de se tornar a plataforma de desenvolvimento dominante em uma área específica.
Querendo dominar o mercado, a organização investiu todos os seus recursos na versão 4. A interface com o usuário foi mudada na versão 4. Mudaram as opções. Mudaram as chamadas. Mudaram tanto que os usuário teriam dúvidas se a versão 4 era o mesmo produto que a versão 3.
De fato, foi criado um produto de desenvolvimento que estava bem à frente de seu tempo e teria impulsionado dramaticamente a programação. O que aconteceu, na verdade, é que a coisa toda se inverteu e o software foi descontinuado. Enquanto isso, outra organização liberou o software de desenvolvimento que se tornou padrão de fato.
O que deu errado? Como essa organização falhou tão miseravelmente?
Ela vendeu o produto por dois preços. Pelo primeiro preço a empresa entregava apenas a mídia. Pelo segundo preço (quase duas vezes mais) entregava aos usuários a mídia e milhares de páginas de manuais de como usuá-lo.
Muitos programadores pensaram que mudando da versão 3 para a versão 4 estariam fazendo uma mudança evolucionária, e não compraram os manuais. Sem os manuais, os desenvolvedores se perderam sem conseguir imaginar como fazer o que eles precisavam fazer. Frustrados e aborrecidos, os desenvolvedores abandonaram o pacote.
Aqueles que adquiriram os manuais foram literalmente esmagados pelos milhares de páginas espalhadas por cinco livros que se referenciavam mutuamente de tal modo que os usuários tinham que ter todos os livros abertos ao mesmo tempo de maneira a imaginar como fazer o que precisavam fazer. Estes que gastaram o dinheiro extra também abandonaram a nova plataforma.
Naturalmente a plataforma morreu; não porque não era boa, mas porque a documentação a matou. Documentação escrita adequadamente, empacotada adequadamente como um produto de qualidade, deveria impulsionar a empresa para uma posição invejável.
Quando você projetar sua documentação, tenha em mente essa história e assegure que seus produtos não se tornem presa do mesmo fato. Esta catástrofe é bastante fácil de prevenir, mas você deve fazer um esforço consciente de fazer isso.
Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.
quarta-feira, 20 de setembro de 2006
Sobre Requisitos e Projeto
"A parte individual mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita errado. Nenhuma outra parte é mais difícil de consertar depois" (Fred Brooks).
"É melhor saber algumas das questões a todas as respostas" (James Turber).
"O milagre mais comum da engenharia de software é a transição da análise para o projeto e do projeto para o código" (Richard Due).
"Você pode usar uma borracha na prancheta de desenho ou uma marreta no canteiro de obra" (Frank Lloyd Wright).
"Um erro comum que as pessoas cometem quando tentam projetar algo completamente seguro tem sido subestimar a engenhosidade dos inteiramente doidos" (Douglas Adams).
"É melhor saber algumas das questões a todas as respostas" (James Turber).
"O milagre mais comum da engenharia de software é a transição da análise para o projeto e do projeto para o código" (Richard Due).
"Você pode usar uma borracha na prancheta de desenho ou uma marreta no canteiro de obra" (Frank Lloyd Wright).
"Um erro comum que as pessoas cometem quando tentam projetar algo completamente seguro tem sido subestimar a engenhosidade dos inteiramente doidos" (Douglas Adams).
domingo, 3 de setembro de 2006
Engenharia de Software - Uma história de amor e ódio
Palestra de Christian Reis na Feira de Informática 3.0 de 2003 na UFSCar. Eis alguns pontos:
- A profissão moderna mais difícil;
- Exige conhecimento técnico detalhado em uma área em constante ebulição;
- O que eu espero de vocês é que tenham paixão pelos seus produtos, e com estes produtos, que ajudem a construir o Brasil;
- Se não tiverem paixão pelos seus produtos me avisem para eu nem pensar em ser um consumidor;
- Esqueçam suas aulas: desenvolver software (de qualquer maneira) é Engenharia de Software;
- Não se enganem: escrever código, rodar e testar é um processo de software;
- O que nos falta é uma visão de escala: para que tipos de tarefas são adequados que tipos de processo;
- Obviamente, a preocupação com processo de software é menor quando é um projeto de 3 horas;
- Processo de Software é um nome chique para descrever quando sentamos juntos e planejamos construir ou consertar algo:
- Descobrir o que tem para ser feito.
- Descobrir como será feito.
- Fazer. Fazer. Fazer. Fazer.
- Descobrir se faz mesmo o que era para fazer.
(enxague, repita)
- Para aprender como construir software, precisamos de bons exemplos;
- Nenhum processo bem projetado é burocrático, inútil ou sem resultado. Mas o processo tem que se encaixar na sua equipe;
- Engenharia de Software é para ser divertido e interessante (e seu amigo na hora que dá tudo errado);
- Engenharia de Software ensina ter amor pela equipe, amor pelo usuário, amor pelo produto;
- Engenharia de Software é uma passo em direção à evolução da profissão;
- "Pessoas que dizem que algo não pode ser feito não devem interromper quem está fazendo" (Provérbio Chinês)
sábado, 2 de setembro de 2006
O que é Engenharia de Software?
Engenharia de Software é uma disciplina que reúne metodologias, métodos e ferramentas a ser utilizados, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software (CARVALHO, 2001).
Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais (NAUR apud PRESSMAN, 2006).
Engenharia de Software é: (1) aplicação de uma abordagem sistêmica, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software; isto é, a aplicação da engenharia ao software. (2) o estudo de abordagens como as citadas em 1 (IEEE, 1993).
Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais (NAUR apud PRESSMAN, 2006).
Engenharia de Software é: (1) aplicação de uma abordagem sistêmica, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software; isto é, a aplicação da engenharia ao software. (2) o estudo de abordagens como as citadas em 1 (IEEE, 1993).
Assinar:
Postagens (Atom)
