Nessa aula, estudamos sobre gerência e alguns conceitos foram expostas sobre índices usados para medir produtividade. São eles:

Linhas de código

Bastante usado no mercado e baseia-se na premissa de a quantidade de linhas de códigos produzidos por uma empresa dita a sua produtividade.

Segundo dados da empresa de consultoria Gardner, em 2001 foram produzidos aproximadamente 6000 linhas de códigos por ano, com uma média de 25 linhas de código por dia.

Já no Windows Vista, apenas 1000 linhas de códigos foram produzidas por ano, com a média de 4,2 linhas de códigos por dia. Tal fato se explica por ter sido considerado apenas linhas de códigos “novas”, não tendo sido considerado os códigos reescritos e/ou refeitos.

Ainda segundo a empresa Gardner, em um pesquisa realizada com as maiores empresas norte-americanas que usam UML, onde apenas 175 responderam ao questionários, os seguintes dados foram coletados:

• $ 1,000,000 gasto em projeto (incluindo não só salários)
• 50.000 linhas de códigos totais do projeto
• 6,5 homem-ano

De onde se tira que por ano foram produzidos em torno de 7692 linhas de códigos ( 50.000 / 6,5 ), e ficamos com uma média de 32 linhas de código/dia.

Parece que está média em torno de 30 linhas de código/dia ser um número bom por aparecer em diversas pesquisas com empresas que utilizam práticas de Engenharia de Software em seus projetos.

Pontos por função

Outro índice bastante usado, criado pela IBM.

Baseia-se em elementos abstratos como:

• Entrada
• Saída
• Processos
• Arquivo

“Processos” se divide em Cal+ e Cal++, representando respectivamente, pouco ou muito processamento.

Maiores informações sobre este método pode ser achado no site http://www.ifpug.org/ (Grupo internacional de usuários de Pontos de função)

Na gerência clássica, as etapas são as seguintes:

• Organizar (recursos)
• Planejar (como chegar ao objetivo)
• Controlar (saber como o projeto está indo)
• Dirigir (usar os recursos, motivar)

Esse modelo clássico gera um paradigma com o modelo de gerente de software porque nesse segundo caso entram as seguintes variáveis que acabam por dificultar o trabalho do gerente:

• Pessoas com nível cultural melhor, que se em alguns momentos facilita em outros dificulta;
• Conhecimento
• Natureza do processo / produto
• Domínio

Existe um conceito de delta em gerência, onde delta = Planejado – Realizado.

Com isso, o trabalho do gerente fica sendo o de corrigir os desvios e quando esses desvios se mostrarem acentuados, deve-se planejar novamente o trabalho.

Aprendemos também sobre o modelo de gerenciamento PERT, onde existem softwares como Microsoft Project ou Primavera, que ajudam na execução dessa técnica.

PERT é um método para analisar as tarefas envolvidas em um projeto, especialmente o tempo necessário para completar cada tarefa e identificar o tempo mínimo necessário para completar cada tarefa.

Nessa aula aprendemos como ser mais eficiente do ponto de vista da arquitetura.

Com isso, o desenvolvedor que produz código para reusar, colocando seu foco de atenção em flexibilidade, armazenamento e catalogação acaba por ter mais trabalho.

Já aquele produz reusando, com foco em como descrever o que quer, em procurar e integrar, tem menos trabalho do que o primeiro.

Torna-se necessário então definirmos aquilo que estamos procurando e verificar qual dos objetos que tenho se adapta de forma mais perto daquilo que eu quero; a escolha da menor distância conceitual.

Nem sempre é se torna trivial a medição dessa distância conceitual, e então criam-se estruturas auxiliares que ficaram responsáveis por ajudar na organização e classificação dos objetos. Pode acontecer de a classificação de um objeto ocorrer em mais de uma categoria, como citado o exemplo do ornitorrinco, tendo-se que optar por uma decisão em detrimento de atender a todas as expectativas.

O reuso de um software pode acontecer em três camadas:

• Código
• Desenho
• Requisito

Se estas 3 camadas estiverem bem conectadas dizemos que o software atende ao requisito.

Alguns conceitos apresentados ainda durante a aula:

• Rúben Prietro-Diaz – sugere uma organização baseada no modelo em que 2 triplas classificam os componentes segundo definição e uso;
• Design Patterns – não existe hierarquia, sendo um modo não-taxonômico de se organizar os desenhos;
• Reuso Generativo – maneira mais flexível de se reutilizar o desenho, não deixando o código amarrado ao desenho;
• Tags – maneira de se catalogar informação, baseada na opinião da maioria, podendo ser uma maneira bem eficaz de se classificar por estar ligada ao bom-senso coletivo, colaborando para que a informação seja “achada” de forma mais fácil pela maioria.

del.icio.us do lucas : del.icio.us/weblucas

del.icio.us do fernando : del.icio.us/loureiro.fernando

A refatoração tem o objetivo de melhorar o acoplamento, coesão e information hiding. Além disso, é responsável por diminuir a complexidade do software e consequentemente aumentar sua qualidade. Quanto mais alto o fan-out pior e quanto mais alto o fan-in melhor. A regra [3,6] continua valendo na hora de se fazer a refatoração.

Regra de evolução do software:

Quando a taxa de erros está muito alta é necessário fazer a refatoração do sistema.

No XP essa queda na curva não ocorre, pois quando ocorre a integração de um novo módulo já verifica se é necessário fazer a refatoração. Não basta funcionar, é necessário melhorar o código, manter a qualidade, mantê-lo organizado.

A curva de crescimento no XP é menor, pois a refatoração é feita, se necessário, em cada integração de novos módulos.

ESCOPO DE CONTROLE / ESCOPO DE EFEITO:

Se o módulo A chama B e ocorre uma tomada de decisão em B, o resultado disso não pode ser refletido em A, isto é, não existe uma mudança de comportamento de A.

Práticas do XP (Extreme Programming)

1. O jogo do planejamento

Identifica junto do cliente quais as prioridades.

1. Pequenas versões

Libera versões rapidamente. O XP tem um ciclo de desenvolvimento de 3 semanas.

1. Refatoração

Já explicado anteriormente.

1. Programação em pares

Existe uma pessoa conferindo o que o outro faz. Isso ajuda a reduzir o número de erros e aumentar a qualidade do software.

1. propriedade coletiva

O código não pertence à uma pessoa ou à dupla, mas sim a toda a equipe. Não existe documentação. A documentação esta na cabeça de cada pessoa.

1. 40 horas por semana

Trabalhar mais de 40 horas semanais faz com que o trabalho não renda tanto. É necessário acabar com a falsa liberdade de trabalhar a qualquer hora ou trabalhar por tarefas, pois desta maneira acaba-se trabalhando mais que 40 horas semanais.

1. Cliente 24/7

O cliente está disponível para tirar as dúvidas e validar os cenários.

1. Metáfora

Tem a ver com a idéia de usar sistemas antigos como metáfora para a construção do novo sistema.

1. Padrões de codificação

Facilita a compreensão por parte das pessoas que trabalham no software. Isto é bom pois não existe documentação.

1. Desenho simples

Tem como obejtivo melhorar a qualidade do software.

1. Teste contínuo

Os erros devem ser corrigidos a medida que aparecem.

1. Medir código honestamente

Manter-se atento à qualidade do código através de métricas.

Uma ótima fonte de informações para o XP é o site http://www.improveit.com.br/xp/ , é uma empresa especializada na tecnica e seu diretor é autor do primeiro livro sobre XP no brasil. Outro lugar é o grupo de discusão XPrio, eles promovem reuniões mensais também que são bastante interessantes e são de graça. http://xprio.blogspot.com/ e http://groups.yahoo.com/group/xprio

Modelo Clássico (“Cascata”)

É o processo mais antigo e o mais conhecido.

Desenvolvedores seguem basicamente alguns passos na seguinte ordem:

1. Estudam requisitos
2. Analisam estes requisitos
3. Projetam uma solução aproximada
4. Arquitetam um framework para a solução
5. Desenvolvem o código
6. Testam
7. Colocam em uso
8. Fazem a manutenção

Embora o modelo cascata ter sido o paradigma mais utilizado na Engenharia de Software, ele é extremamente passivo e formalista, o tornando bastante burocrático, uma vez que a questão da documentação (elaboração e aprovação) “amarra” a continuidade do processo de produção.

Se por um lado esse modelo trouxe disciplina ao desenvolvimento de software, ele é mais indicado para modelos que apresentem seus requisitos bem conhecidos antecipadamente já que a rigidez do modelo dificulta mudanças de requisitos e de gerências futuras, coisas freqüentes no processo de desenvolvimento de um software.

Modelo Espiral

Diferencia do Modelo de Cascata por não ser linear, e sim cíclico, com um incremento nas funcionalidades do software conforme um ciclo é concluído.

Cada ciclo consiste em quatro estágios, onde:

Primeiro estágio – composto pela determinação dos objetivos do projeto

Segundo estágio – avaliação dos riscos envolvidos na escolha das alternativas para execução dos objetivos

Terceiro estágio – o desenvolvimento das atividades previstas é concretizado. A parte de dificuldade econômica para continuidade do projeto é analisada neste estágio, podendo sair de um projeto lógico para um projeto detalhado, ou ainda para uma segunda versão.

Quarto estágio – planejamento das fases seguintes e também avaliação e revisão dos avanços atingidos com definição de metas seguintes.

Modelo Extreme Programming (XP)

É um dos processos conhecidos mais ágeis atuais.

Primeiramente, escrevem-se testes automáticos para prover objetivos concretos para o desenvolvimento. Em seguida, começar a se codificar em dupla (pessoas de mesmo nível técnico). A codificação é finalizada quando todos os testes são atingidos e não se consegue imaginar nenhum outro teste a ser realizado. A parte de design e arquitetura do software vem da refatoração e somente depois da codificação. O design é feito pelas mesmas pessoas que codificaram.

Dessa maneira, o sistema ainda incompleto, mas já funcional é demonstrado para o cliente e pego seu feedback. E então, o ciclo se inicia novamente com mais testes.

Conforme falado pelo professor em aula, a jargão “O código é rei” se aplica nesse método, uma vez que utiliza-se de pouca documentação sobre definições e arquiteturas.

Modelo V

Modelo padrão da administração federal Alemã que descreve não só o que tem que ser feito, mas também como, quando e quem é responsável por fazer isto. Descreve as atividades e os resultados que tem que ser produzidos durante o desenvolvimento de software.

Este modelo sumariza os passos principais a serem tomados em conjunto com os correspondentes a serem entregues usando algumas vezes sistemas de validação computadorizada.

Rational Unified Process

Processo baseado em uma série de princípios de desenvolvimento de software, tais como interatividade no desenvolvimento de software, gerenciamento de requisitos, arquitetura baseada em componentes, visualização do modelo, controle de qualidade e controle de mudanças.

O processo foi desenhado utilizando-se as mesmas técnicas que a equipe usa para fazer o design de software: UML.

O ciclo de vida do RUP é uma implementação do modelo Espiral, contendo quatro fases, conforme pode-se analisar no gráfico abaixo:

Modelo de Prototipação

Modelo onde o principal objetivo é construir um protótipo robusto em uma estrutura e refiná-lo constantemente. O protótipo evolucionário, quando construído, forma o coração do novo sistema, e as improvisações e requisições futuras serão construídas nele.

Acredita-se que não é possível entender a todos os requisitos e constrói-se apenas aqueles que estão bem entendidos. Com isso, este técnica permite que a equipe de desenvolvedores adicionem funcionalidades ou façam modificações que não poderiam ser concebidas durante a fase de requisitos e de design.

Neste modelo, tem-se a vantagem de que os desenvolvedores podem focar no desenvolvimento de partes do sistema que eles entenderam ao invés de trabalhar no desenvolvimento do sistema inteiro.

Apresentação parcial do primeiro trabalho de PES.

Aula 18:

Apresentação final do primeiro trabalho de PES.

Aula 19:

Estudo para a prova.

Aula 20:

P1 de PES.

Aula 22:

Revisão da P1.

link do fabiola http://pes.inf.puc-rio.br/e0211427/site/login.html

Em arquiteturas temos componentes e conectores. Os conectores aumentam o número de possíveis combinações entre os componentes. Foi feita uma analogia entre lego, quebra-cabeças e o reúso de softwares e conexão de componentes. O reúso é facilitado quando fazemos uma interface mais genérica enquanto uma interface específica para um determinado projeto não facilitaria o reúso. No caso, a interface mais genérica seria representada pelas peças de lego, que possuem maior capacidade de formar as coisas pois não têm encaixes específicos, o que já não acontece com o quebra-cabeça que possibilita apenas uma opção de encaixe. Com os design patterns ocorre a mesma coisa, pois eles fornecem modelos e esses modelos podem ser modificados para a situação que você precisa facilitando o reúso. No entanto, fazer coisas genéricas demais pode sair muito caro e por isso é necessário estudar qual a melhor coisa a se fazer em uma situação, seguindo o mantra: “nem 8, nem 80… 44”, que diz que devemos ter bom senso ao se construir um determinado sistema.

Todo padrão deve ter:

1. Objetivo
2. Sinônimo
3. Motivação
4. Aplicabilidade
5. Estrutura
6. Participantes
7. Colaboração
8. Consequência
9. Implementação
10. Nome

Ex: Software Design Patterns (Gangue dos 4).

Macro Arquitetura:

Ex: Software Architectures (Mary Shaw)

Tipos de Macro Arquiteturas:

1. Tubos e Filtros:

Os processos se comunicam através de pipes. Esta arquitetura é usada em sistemas que devem ser síncronos. É necessário que uma etapa 1 tenha terminado antes se ser executada a etapa 2 e assim sucessivamente. Os dados podem ser filtrados, o que é útil para diminuir a quantidade de dados no sistema.

2. Camadas:

As camadas só podem se comunicar com camadas que estão na sua fronteira e essa comunicação ocorre através de mensagens.

3. Quadro-Negro:

Existe uma memória compartilhada pelos componentes da arquitetura e isto possibilita uma padronização da comunicação, paralelismo e baixo overlay. Um dos componentes escreve no blackboard e outro pode utilizar o que foi escrito lá. Pode ser usado em aplicativos que usam paralelismo e necessitem de um overlay baixo. É muito usado em aplicações de IA. A desvantagem é o acoplamento forte, que te obriga a ter um controle muito forte sobre o blackboard.

4. Orientado à Objetos:

O próprio nome já diz. Além disso, já foi explicado em aulas anteriores.

5. Rede:

Existem vários nós e arestas. É semelhante a orientação à objetos.

A arquitetura distribuída é mais segura do que a central (ex: blackboard). No entanto, os ganhos e perdas ao se escolher uma determinada arquitetura.

O SADT tem duas perspectivas:

• Processos (Actigramas)
• Dados (Datagramas)

O SADT baseia-se na teoria de que “todo sistema é um sub-sistema de um sistema maior”. É também baseado na cibernética (ciência do controle). A cibernética diz respeito ao feedback que o sistema mantém, isto é, ele recebe informações sobre seu próprio funcionamento. O próprio sistema trata da informação, controle e regulação.

Actigrama:

• Contém um objetivo
• Contém um ponto de vista
• O sistema deve conter obrigatoriamente setas de controle e saída, podendo conter também setas de entrada e mecanismo.
• Deve-se utilizar frases verbais no retângulo que representa o processo e as setas devem conter substantivos.
• Um actigrama pode ter vários níveis e devemos tomar cuidado para não esquecer que o seguinte mantra continua valendo: “tudo que entra entra e tudo que sai sai”.

OBS: O DFD tem uma visão de fluxo de dados enquanto o SADT tem uma visão de relacionamento entre as partes