Wednesday, November 22, 2006
Tuesday, November 21, 2006
Aula 24 (v.2)
Nesta aula, vimos que um gerente de projeto de software utliza-se de indicadores de produtividade para avaliar a evolução do trabalho realizado. Uma das formas de medir a produtividade de um projeto desta natureza é a taxa de número de linhas de código geradas por dia, por cada programador que faz parte da equipe de projeto. Este indicador (LOC) é o mais utilizado atualmente. Como exemplos temos:
- 1999: 37/dia.
- 2001: 25/dia.
- Windows Vista: 4,2/dia.
- Empresas que utilizam UML: 32/dia.
Existem outras formas de medir a produtividade, como os "pontos por função" criado pela IBM e que utiliza elementos abstratos para gerar um resultado.
Vimos também que as principais atividades de um gerente de projeto são:
- Organizar: identificação e estudo de disponibilidade dos recursos necessários para cumprir seu objetivo.
- Planejar: é a geração de um "blueprint" que contenha a maneira pela qual o objetivo será atingido.
- Coordenar: garantir que os membros da equipe do projeto, artefatos, técnicas e infraestrutura estejam apontando para o objetivo.
- Controlar: assegurar que o plano esteja sendo cumprido.
- 1999: 37/dia.
- 2001: 25/dia.
- Windows Vista: 4,2/dia.
- Empresas que utilizam UML: 32/dia.
Existem outras formas de medir a produtividade, como os "pontos por função" criado pela IBM e que utiliza elementos abstratos para gerar um resultado.
Vimos também que as principais atividades de um gerente de projeto são:
- Organizar: identificação e estudo de disponibilidade dos recursos necessários para cumprir seu objetivo.
- Planejar: é a geração de um "blueprint" que contenha a maneira pela qual o objetivo será atingido.
- Coordenar: garantir que os membros da equipe do projeto, artefatos, técnicas e infraestrutura estejam apontando para o objetivo.
- Controlar: assegurar que o plano esteja sendo cumprido.
Aula 23
A arquitetura sob ótica de reuso foi discutida nesta aula. Novamente observamos que quanto mais trabalho é desprendido durante a codificação, através de preocupação com flexibilidade, armazenamento e catalogamento, mais fácil será o re-uso do código no futuro. Ao passo que menos trabalho, preocupando-se apenas com descrições, buscas e integrações, mais difícil se torna o re-uso.
Em orientação a objetos, devemos reduzir a distância conceitual entre o mundo real e o código, ao definirmos os objetos que virão a interagir entre si, a fim de garantirmos o re-uso do mesmo. Algumas estratégias para reduzir esta distância, organizando de formas distintas os componentes são:
- Design Patterns: Não utiliza o conceito de hierarquias ao adicionar funcionalidades aos componentes.
- Tagging: Os componentes são etiquedados através de palavras-chaves sugeridas pelos usuários.
- Reuso Generativo: Como o nome sugere, visa a generalização dos componentes.
- Rúben Prieto-Diaz: Nome do autor e método, que consiste em organizar os componentes em pares de triplas.
Em orientação a objetos, devemos reduzir a distância conceitual entre o mundo real e o código, ao definirmos os objetos que virão a interagir entre si, a fim de garantirmos o re-uso do mesmo. Algumas estratégias para reduzir esta distância, organizando de formas distintas os componentes são:
- Design Patterns: Não utiliza o conceito de hierarquias ao adicionar funcionalidades aos componentes.
- Tagging: Os componentes são etiquedados através de palavras-chaves sugeridas pelos usuários.
- Reuso Generativo: Como o nome sugere, visa a generalização dos componentes.
- Rúben Prieto-Diaz: Nome do autor e método, que consiste em organizar os componentes em pares de triplas.
Aula 22 (v.2)
Vimos nesta aula o conceito de refatoração e os benefícios que este processo traz ao programador. Ao refatorar um código, devemos nos guiar por 3 principais regras: acoplamento, coesão e encapsulamento. Durante esta re-estruturação, as duplicidades são removidas a fim de garantir coesão, o código pode ser simplificado para facilitar o acoplamento de outros módulos e as informações que podem ocasionar falhas de segurança são encapsuladas.
Fan-in é o termo utilizado para avaliar o número de "inputs" que um módulo recebe, e fan-out, o de "outputs" que um módulo utiliza. Com estes conceitos, podemos inferir que a situação ideal após a refatoração é o aumento de fan-in e a diminuição de fan-out.
O paradigma da orientação a aspectos é auxiliar o programador na separação de interesses, como forma de melhorar a modularização do código. Para tanto são identificadas e removidas as redundâncias de funcionalidades de um código.
Um dos 12 princípios de XP é justamente a refatoração. Os princípios são:
- Jogo de Planejamento;
- Pequenas versões;
- Metáfora;
- Desenho simples;
- Processo de testes;
- Refatoração;
- Programação em pares;
- Propriedade de código coletiva;
- Integração contínua;
- Carga horária sustenstável;
- Alta disponibilidade do cliente;
- Padrões de codificação.
Fan-in é o termo utilizado para avaliar o número de "inputs" que um módulo recebe, e fan-out, o de "outputs" que um módulo utiliza. Com estes conceitos, podemos inferir que a situação ideal após a refatoração é o aumento de fan-in e a diminuição de fan-out.
O paradigma da orientação a aspectos é auxiliar o programador na separação de interesses, como forma de melhorar a modularização do código. Para tanto são identificadas e removidas as redundâncias de funcionalidades de um código.
Um dos 12 princípios de XP é justamente a refatoração. Os princípios são:
- Jogo de Planejamento;
- Pequenas versões;
- Metáfora;
- Desenho simples;
- Processo de testes;
- Refatoração;
- Programação em pares;
- Propriedade de código coletiva;
- Integração contínua;
- Carga horária sustenstável;
- Alta disponibilidade do cliente;
- Padrões de codificação.
Thursday, November 16, 2006
Aula 20 (v.2)
Nesta aula discutimos as principais estratégias de desenvolvimento de software através da adoção de métodos, técnicas e ferramentas (MTF's): Cascata, Prototipação, Espiral, V, RUP e XP.
Cascata:
É a estratégia de desenvolvimento mais comum e consiste em uma sequência de passos (definição, arquitetura e implementação). Como toma bastante tempo e sua validação e verificação se dão após a implementação, o produto torna-se muito caro e dificil de se modificar.
Prototipação:
Apresenta ciclo de vida mais curto, oferecendo ao cliente a possibilidade de realizar modificações há qualquer momento, já que ele tem contato direto com os construtos ainda antes de sua versão final de produção.
Espiral:
Transforma a linearidade da estratégia de cascata em ciclos. Ao final destes são realizadas análises de riscos a fim de garantir a organização do processo e a evolução mais saudável do software.
V:
Desenvolvido na Alemanha, esta estatégia também se assemelha à técnica de cascata, mas busca validar e verificar constantemente (após cada etapa) não só o que está sendo desenvolvido, mas como se está desenvolvendo.
RUP:
Bastante utilizado em projetos orientados a objetos, o Rational Unified Process pode ser visto como uma adaptação do modo espiral que utiliza-se de quatro fundamentais ciclos: lógico, processo, físico e desenvolvimento.
XP:
Uma forma recente e agressiva de produzir softwares. É iniciado com a criação de testes para código ainda inexistente. Representa a quebra de padrões, já que a implementação antescede o próprio design. Traz como vantagem a velocidade com que as primeiras versões são apresentadas ao cliente.
Cascata:
É a estratégia de desenvolvimento mais comum e consiste em uma sequência de passos (definição, arquitetura e implementação). Como toma bastante tempo e sua validação e verificação se dão após a implementação, o produto torna-se muito caro e dificil de se modificar.
Prototipação:
Apresenta ciclo de vida mais curto, oferecendo ao cliente a possibilidade de realizar modificações há qualquer momento, já que ele tem contato direto com os construtos ainda antes de sua versão final de produção.
Espiral:
Transforma a linearidade da estratégia de cascata em ciclos. Ao final destes são realizadas análises de riscos a fim de garantir a organização do processo e a evolução mais saudável do software.
V:
Desenvolvido na Alemanha, esta estatégia também se assemelha à técnica de cascata, mas busca validar e verificar constantemente (após cada etapa) não só o que está sendo desenvolvido, mas como se está desenvolvendo.
RUP:
Bastante utilizado em projetos orientados a objetos, o Rational Unified Process pode ser visto como uma adaptação do modo espiral que utiliza-se de quatro fundamentais ciclos: lógico, processo, físico e desenvolvimento.
XP:
Uma forma recente e agressiva de produzir softwares. É iniciado com a criação de testes para código ainda inexistente. Representa a quebra de padrões, já que a implementação antescede o próprio design. Traz como vantagem a velocidade com que as primeiras versões são apresentadas ao cliente.
Subscribe to:
Posts (Atom)