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