Blog

Aula 17/08/2011 Desenvolvimento de software Evolução do software (1950-1965) – O hardware sofreu continuas mudanças – O software era uma arte “secundaria” para a qual havia poucos métodos sistemáticos -O hardware era de propósito geral – O software era específico para cada aplicação – Não havia documentação Foco era o hardware (1965 – 1975) – Multiprogramaçáo e – Técnicas interativas – Sistemas de tempo – ID geração de SGBD – Produto de softwar p – Bibliotecas de software – Cresce numero de sistemas baseado em computador – Manutenção quase impossível (1975- Hoje) Sistemas distribuidos – Redes locais e Globais -Uso generalizado de microprocessadores-produtos inteligentes -Hardware de baixo custo – Impacto no consumo (Quarta era do software de computadr) – Tecnologia orientada a objeto – Sistemas especialistas e software de inteligência artificial usados na prática -Software de rede neural artificial – Computação paralela. Manutenção Fase de definição: “o que” será desenvolvido. – Análise do sistema – Planejamento do projeto de software – Análise de requisitos Fase de desenvolvimento: “como” o software vai ser desenvolvido. Projeto de software Codificação – Realização de teste do software Fase de manutenção: concentra-se nas “mudanças” que ocorrerão depois que o software for liberado para uso operacional – Correção -E-voluçao _ prevenção – Adaptação Atividade de proteção as fases e etapas correlatas discretas são complementadas por uma série de atividades de proteção – Revisão – Documentação – Controle de mudanças Engenharia de Software Estabelece uso de princípios sólidos de engenharia, com o intuito de obter, economicamente, software que seja confiável e funcione eficientemente em maquinas reais. Ferramentas Métodos Produtividade dealmente, o modelo(prototipação) seme como um mecanismo para identificar os requisitos de software. Apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saida com detalhes. Obtenção dos Requisitos Construção produto Construção Prototipo Refinamento Prototipo Projeto Rápido Avaliação Prototipo Ciclo Vida Espiral – Engloba as melhores características do ciclo de vida clássico e da prototipação, adicinado um novo elemento: a análise de risco Segue a abordagem de passos sistemáticos do ciclo de vida clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real – Usa a prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos.

Técnicas de 40 geração Concentra-se na capacidade de se especificar o software a uma maquina em um nível que esteja próximo a linguagem natural engloba um conjunto de ferramentas de software que possibilitam que: – O sistema seja especificado em uma linguagem de alto nível – O código fonte, Seia gera amente a partir dessas As dificuldades com análise de sistemas “O desconhecimento do analista” “O desconhecimento do usuário” “Como distinguir a floresta das árvores” “A dificuldade da documentação” “O projeto físico prematuro” Abordagens metodológicas Essencial Engenharia da informação Orientada a Objeto Estruturada Aula 05/10/11 Extreme Programming Desenvolvimento – Requisitos Mutáveis -Sistema que demora 6 meses de projeto e 1 ano de implementação nao resolve os problemas reais – Limitação da Complexidade – Quanto mais complexo, maior o custo de manutenção. – Agilidade Divulgação (recalses) freqüentes garante soluções, para problemas críticos em menor tempo. Novos Tipos de Engenharia – Desenvolvimento Ad-hoc – Resultados muito ruins – Engenharia tradicional – projetar antes de construir – Engenharia para o controle de desenvolvimento do software. Necessidade de alterar o software – Inicio -> falta de conhecimento Software evolui para atender negócios – nunca fica pronto Metodologia para mudanç 4 ferramentas Software em funcionamento mais que documentação abrangente.

Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Mesmo dando valor aos itens à direita, valorizamos mais os itens à esquerda. ” XP – Valores Comunicação -Preferência -Chat à e-mail – Telefone à chat – Conversa presente à telefone – Trabalhar junto à salas isoladas -Trabalhar em conjunto à revisões de resultado final Simplicidade – O Projeto de software é simplificado continuamente. – A solução adotada deve ser sempre a mais simples que atinja os objetivos – Descarte de projeto, processo ou código pensando em interações futuras. Coragem -Necessário para – Apontar problemas no projeto.

Parar quando está cansado -Pedir ajuda quando necessário – Simplificar código que está funcionando – Jogar fora código desnecessário – Dizer ao cliente que um requisito esta fora do prazo – Abandonar processos formais de projetos e documentação Feedback -Maior agilidade – Problema evidenciado rápido pode ser resolvido rápido – Oportunidades descobertas podem ser aproveitadas Aula 26/10/11 S Parte existe, mesmo sem finalizar o projeto -Avaliação do cliente – Retorno rápido do cliente -> detecção de problemas – Cada lançamento tem prioridades – Valores definidos pelo cliente Práticas Essenciais – Projeto simples – Integração contínua Projeto Simples Projeto começa simples e deve permanecer simples através de testes e refinamentos de projeto -Projeto Simples e Claro – O que não é necessário não será implementado -Menor complexidade, menor risco – Software não pode ser mais complexo do que a necessidade -Sem previsão do futuro – Não se gasta recurso com estórias que alguém “acha” que será necessáno Programação em duplas – Desenvolvimento XP é feito em pares -Duas cabeças pensam melhor do que uma – Um computador, um teclado, dois programadores Um piloto, um co-piloto – Papeis alternados – pares trocados – Uma cabeça obriga a outra a pensar -Melhor qualidade -Maior comunicação -Menor distração -Nivelamento da equipe (diferentes experiências – ambos crescem) – Se um colega não entende o código ele não está suficientemente claro e não será entendido depois.

Aula 16/11/2011 Metricas de software – Referem-se a um conjunt edidas para software. profissionais de software podem avaliar o que funciona e o que não funciona “Metricas de software permitem que você saiba quando rir e quando chorar’ Tom Gilb 4 Razões para medir *Caracterizar Para compreensão dos processos, produtos, recursos e ambientes – Estabelecer uma base para comparação com avaliações futuras *Avaliar – Determinar a situação em relação aos planos – As medidas são sensores que nos permitem dizer quando nossos projetos e processos estão saindo dos trilhos Poder retornar o controle – Verificar a realização de nossas metas – Verificar os impactos das melhorias de tecnologia e processos nos produtos. Produzir (medições prognosticas) – Para poder planejar – Envolvem obter conhecimento dos relacionamentos entre os processos Os valores já obtidos podem ser usados para produzir Base para estimativa de custos, planejamento(prazo) e qualidade – Auxiliar na analise de riscos e na relação de custo-beneficio. *Melhorar – Com informações suficientes para auxiliar a identificar ineficiências e oportunidades de melhora de qualidade. Melhoria do processo “A única maneira racional de melhorar qualquer processo é medir caracteristicas específicas do processo, desenvolver um conjunto de metricas significativas baseadas nestas caracteristicas e então prover Indicadores que irão conduzir para uma estratégia para melhoria” Roger S. Pressman Tipos de medição