Em aula vimos que o artigo sobre triagem de problemas estava relacionado a evolução porque mostra uma visão operacional da tarefa de modificação de programas. No entanto, para termos essa visão foi necessário entendermos como deve funcionar o processo de registro de problemas e sua relação com o processo de modificação. O aspecto de quem indicar para o tratamento de um dado problema, o tema principal do artigo, serviu para termos uma visão do aspecto operacional do processo de mudança. Apesar de não ser o tema principal do artigo, fica evidente o papel de gerência de mudança, principalmente quanto vimos as conclusões do artigo.
O processo de triagem é parte de um processo mais complexo, o processo de gerência de mudança. Vale salientar que essa mudança ocorre em função da retro-alimentação proveniente do contexto onde atua o software. Vimos também que o processo de gerência de mudança está intimamente ligado ao processo de controle das versões do software.
Portanto vimos uma visão abstrata da evolução através da teoria de Lehman e o debate sobre sua abrangência e vimos, através de um relato ortogonal, uma visão do nível operacional da evolução.
O aspecto importante sobre essas duas visões é que elas levam ao conceito de gerência de mudança. Em software o processo de gerência de mudança é fundamentado no conceito
de gerência de configuração.
Portanto para a Aula 6 leremos o clássico: "Version Models For Software Configuration Management"
quinta-feira, março 29, 2007
segunda-feira, março 26, 2007
Aula 4
Na aula anterior discutimos, na maior parte do tempo, o tipo de crescimento das curvas de volume de código. A discussão entre o crescimento ser o inverso do quadrado, linear, super linear afetava principalmente as leis 4 e 5.
Para a proxíma aula vejam o artigo que mencionei sobre o desenvolvimento de código aberto. É uma artigo bem interessante. Vale a pena ler.
No entanto, discutiremos o artigo com o título "Who Should Fix this Bug" apresentado no último ICSE. Estou usando o endereço do curso sobre evolução de software que é lecionado na Universidade de Waterloo. Vale a pena visitar a página com o programa daquele curso.
Para a proxíma aula vejam o artigo que mencionei sobre o desenvolvimento de código aberto. É uma artigo bem interessante. Vale a pena ler.
No entanto, discutiremos o artigo com o título "Who Should Fix this Bug" apresentado no último ICSE. Estou usando o endereço do curso sobre evolução de software que é lecionado na Universidade de Waterloo. Vale a pena visitar a página com o programa daquele curso.
segunda-feira, março 19, 2007
Aula 3
“Processos de evolução de software são sistemas de retro-alimentação em múltiplos níveis, em múltiplos laços (loops) e envolvendo múltiplos agentes.”.
Voltamos à frase que caracteriza a oitava lei de Leham. Para consolidar o conceito de retro-alimentação apresentei o modelo ultra-estável de Ashby segundo a visão de Jaques Mélèse. Veja aqui um exemplo desse modelo. O texto está em Francês, mas as figuras são fáceis de entender.
O importante desse modelo é a divisão de trabalho entre: Detectar, Controlar (entender o desvio e formalizar seu entendimento) e Regular (agir sobre o sistema). Com isso, além de, simplesmente, lidarmos com entrada e saída, temos as varáveis essenciais e as variáveis de ação.
Vimos também que o conceito de institucionalização de sistemas de informação, ajuda o entendimento do porque os sistemas de software têm uma vida longa (“old code never dies”).
Debatemos em mais detalhes a Leis 4 e 5. No fundo, meu entendimento da Lei 4 já pressupõe a Lei 8, no entanto, a seguir o que diz Lehman, fatores referentes a capacidade laboral da organização responsável pela software é que melhor explicariam essa lei. Vejam que a definição da Lei 4 mudou no segundo artigo que lemos, para tocar no ponto da retro-alimentação.
No que concerne a Lei 5, “De maneira geral, a taxa de crescimento incremental e taxa crescimento a longo prazo tende a declinar.” a explicação passa pela noção de limite. Ou seja, a organização entende que para um determinado produto, já não vale a pena o crescimento face aos problemas que ele pode gerar.
A próxima leitura é um artigo com críticas as leis da evolução.
Voltamos à frase que caracteriza a oitava lei de Leham. Para consolidar o conceito de retro-alimentação apresentei o modelo ultra-estável de Ashby segundo a visão de Jaques Mélèse. Veja aqui um exemplo desse modelo. O texto está em Francês, mas as figuras são fáceis de entender.
O importante desse modelo é a divisão de trabalho entre: Detectar, Controlar (entender o desvio e formalizar seu entendimento) e Regular (agir sobre o sistema). Com isso, além de, simplesmente, lidarmos com entrada e saída, temos as varáveis essenciais e as variáveis de ação.
Vimos também que o conceito de institucionalização de sistemas de informação, ajuda o entendimento do porque os sistemas de software têm uma vida longa (“old code never dies”).
Debatemos em mais detalhes a Leis 4 e 5. No fundo, meu entendimento da Lei 4 já pressupõe a Lei 8, no entanto, a seguir o que diz Lehman, fatores referentes a capacidade laboral da organização responsável pela software é que melhor explicariam essa lei. Vejam que a definição da Lei 4 mudou no segundo artigo que lemos, para tocar no ponto da retro-alimentação.
No que concerne a Lei 5, “De maneira geral, a taxa de crescimento incremental e taxa crescimento a longo prazo tende a declinar.” a explicação passa pela noção de limite. Ou seja, a organização entende que para um determinado produto, já não vale a pena o crescimento face aos problemas que ele pode gerar.
A próxima leitura é um artigo com críticas as leis da evolução.
domingo, março 11, 2007
Aula 2
Nessa aula centramos nossa atenção na taxonomia de classificação presente no artigo de
Verhoef. Lembro que esse artigo foi encontrado no "Software Engineering Body of Knowledge" na versão "stoneman".
Usando as classes apresentadas no artigo falamos do processo de produção de software em geral e citamos alguns exemplos.
Começamos a discutir a frase de Lehman e continuaremos na próxima aula. Uma importante caractéristica da frase é que ela aplica-se a sistemas do tipo E. E o que são sistemas que não são do tipo E? Esses são chamados sistemas do tipo S. Veja exemplos aqui e aqui.
Para a próxima aula vamos discutir as leis de Lehman, no artigo indicado na Aula 1. Além disso, devemos ler outro artigo do Prof. Lehman: "Rules and Tools for Software Evolution Planning and Management". Vejam o elo para o artigo, bem como uma tradução das leis em uma postagem feita em 2006.
Como disse, espero que cada um faça seu "blog" e nele coloque o resumo do que leu, pesquisou e do que anotou/observou em aula. Assim que tiver o endereço me digam, para que possa postar aqui, como foi feito no ano anterior (elos -- 2006-1).
Verhoef. Lembro que esse artigo foi encontrado no "Software Engineering Body of Knowledge" na versão "stoneman".
Usando as classes apresentadas no artigo falamos do processo de produção de software em geral e citamos alguns exemplos.
Começamos a discutir a frase de Lehman e continuaremos na próxima aula. Uma importante caractéristica da frase é que ela aplica-se a sistemas do tipo E. E o que são sistemas que não são do tipo E? Esses são chamados sistemas do tipo S. Veja exemplos aqui e aqui.
Para a próxima aula vamos discutir as leis de Lehman, no artigo indicado na Aula 1. Além disso, devemos ler outro artigo do Prof. Lehman: "Rules and Tools for Software Evolution Planning and Management". Vejam o elo para o artigo, bem como uma tradução das leis em uma postagem feita em 2006.
Como disse, espero que cada um faça seu "blog" e nele coloque o resumo do que leu, pesquisou e do que anotou/observou em aula. Assim que tiver o endereço me digam, para que possa postar aqui, como foi feito no ano anterior (elos -- 2006-1).
quinta-feira, março 01, 2007
Aula 1
sob o Enfoque de Re-Engenharia". Temos uma cópia na biblioteca. Vale a pena ler.
Para Souza a manutenção deveria ser classificada em: corretiva, adaptativa, evolutiva, preventiva e de suporte. Em artigo recente, Chris Verhoef classifica manutenção em: antes da entrega, corretiva, adaptativa, perfectiva, e preventiva. No fundo essas propostas são fundamentalmente baseadas no trabalho de Swanson de 1976.
Lembrem que fiz uma diferença entre o conceito de manutenção e o conceito de evolução.
Algumas das primeiras idéias sobre evolução estão explicitadas numa palestra convidada que proferi na JAIIO em Buenos Aires em 1997.
A leitura para a próxima aula é Laws of Software Evolution Revisited do Professor Lehman. O objetivo principal é procurar entender o que é o conceito de "complex, multi loop multilevel feedback system"
Para Souza a manutenção deveria ser classificada em: corretiva, adaptativa, evolutiva, preventiva e de suporte. Em artigo recente, Chris Verhoef classifica manutenção em: antes da entrega, corretiva, adaptativa, perfectiva, e preventiva. No fundo essas propostas são fundamentalmente baseadas no trabalho de Swanson de 1976.
Lembrem que fiz uma diferença entre o conceito de manutenção e o conceito de evolução.
Algumas das primeiras idéias sobre evolução estão explicitadas numa palestra convidada que proferi na JAIIO em Buenos Aires em 1997.
A leitura para a próxima aula é Laws of Software Evolution Revisited do Professor Lehman. O objetivo principal é procurar entender o que é o conceito de "complex, multi loop multilevel feedback system"
Assinar:
Postagens (Atom)