Aula 01

1,153 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,153
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Aula 01

  1. 1. Engenharia de Software Aula 01 Prof. Cleuber Moreira Fernandes Mestre em Ciência da Computação - UnB Cleubermf@yahoo.com.br http://br.groups.yahoo.com/group/ES-UNIP 1. Introdução Apesar de se afirmar desde a década de 70 que a construção de software deve ser uma atividade planejada e ordenada, o que se percebe é que ainda hoje está mais para artesanato. Durante a década de 90 a palavra de ordem nas empresas foi de eliminar todas as atividades que não agregassem valor. Dessa forma, áreas de metodologia, administração de dados, gerencia de configurações e controle de qualidade de software, foram menosprezadas pela concepção errônea de que apenas a codificação agregava valor. No entanto, essa visão de curtíssimo prazo gerou enormes problemas. Muito re-trabalho, prazos e custos estourados, software sem confiabilidade e conseqüentemente uma crescente insatisfação de clientes. Ou seja, um barato que saiu caro! Isso ocorre porque a utilização de técnicas de engenharia de software e a adoção de processos formais de desenvolvimento de software, como RUP, agregam enorme valor ao produto final. Contudo, este valor não pode ser medido diretamente em um único projeto, apenas por medição contínua ao longo do tempo. Como exemplo, pode-se citar empresas que implantaram o modelo CMM. Em média, essas empresas levaram dois anos para obterem o nível 2 do modelo de maturidade e capacidade, e tiveram aumentos de produtividade superiores a 100% e reduções de defeitos superiores a 70%. Frente a essa realidade, é indiscutível a importância das metodologias de engenharia na construção de softwares de qualidade, obedecendo cronograma e orçamento. 2. Características do Software • Software não possui características físicas, concretas, que possam ser sentidas; • Software não pode ser manufaturado. Os custos estão no desenvolvimento, não na manufatura; • Software não se desgasta com o uso, mas deteriora-se; • Não pode ser construído aproveitando-se componentes prontos; • Existem diferentes formas de se chegar ao produto final; 3. Dificuldades para desenvolver software • O velho dilema entre “o que o cliente diz que precisa”, “o que o analista de sistemas entende” e “o que o cliente realmente precisa”; • Mudança de requisitos; • Complexidade tecnológica: ferramentas, linguagens, hardware, arquitetura; • Eliminar falhas antes da entrega; • Controlar versões e configurações; • A dependência pessoal e o dilema da produtividade versus quantidade de desenvolvedores; • Por fim, equacionar a tríade escopo, custo e prazo. 4. Crise do Software • A crise está associada às dificuldades e problemas para desenvolver software; • Produção de softwares com número excessivo de falhas; • Não implementação da totalidade das funcionalidades previstas; • Prazos e/ou Orçamentos estourados; • Alto custo de manutenção; • Confiabilidade e credibilidade muito baixas; • Alto índice de Insatisfação dos usuários e clientes;

×