Aula 01

Prévia do material em texto

Universidade Paulista (UNIP)
Instituto de Ciências Exatas e Tecnológicas (ICET)
Disciplina: Engenharia de Software
Prof. MSc. Vladimir Camelo
O que é Engenharia de software
A Engenharia de software é uma área da computação direcionada à especificação, desenvolvimento e manutenção de softwares, com aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, com o objetivo de organizar, aumentar a qualidade e também a produtividade no processo de desenvolvimento.
Nos dias de hoje, estas tecnologias e práticas está diretamente relacionada a linguagens de programação (em sua grande maioria orientada a objetos), banco de dados (relacionais), ferramentas, plataformas, bibliotecas, padrões de projetos, processos e a questão da Qualidade de Software.
Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que possibilitam ao engenheiro de software especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas características e qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema computacional.
Definição
Friedrich Ludwig Bauer foi o primeiro dizendo: "Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe em máquinas reais".
O próprio significado de engenharia já traz os conceitos de criação, construção, análise, desenvolvimento e manutenção.
A Engenharia de Software se concentra nos aspectos práticos da produção de um software, enquanto a ciência da computação estuda os fundamentos teóricos dos aspectos computacionais. O termo foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO Science Committee. Sua criação surgiu numa tentativa de contornar a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software complexos.
A Engenharia de Sistemas é uma área mais ampla por tratar de todos os aspectos de sistemas baseados em computadores, incluindo hardware e engenharia de processos além do software.
Áreas de conhecimento da Engenharia de Software:
Requisitos de Software (Requirements)
Projeto de Software (Design)
Construção de Software (Construction)
Teste de Software (Testing)
Manutenção de software (Maintenance)
Gerência de Configuração de Software
Gerência de Engenharia de Software
Processos de Engenharia de Software
Ferramentas e Métodos de Engenharia de Software
Qualidade de Software (Quality)
O que é Software:
Software é uma seqüência de instruções escritas para serem interpretadas por um computador com o objetivo de executar tarefas específicas.
Em um computador, o software é classificado como a parte lógica cuja função é fornecer instruções para o hardware, sendo responsabilidade a execução destas instruções. O hardware é toda a parte física que constitui o computador, por exemplo, a CPU, a memória e os dispositivos de entrada e saída. 
O termo inglês "software" foi usado pela primeira vez em 1958 em um artigo escrito pelo cientista americano John Wilder Tukey. Foi também ele o responsável por introduzir o termo "bit" para designar "dígito binário".
Os softwares podem ser classificados em três tipos:
Software de Sistema: é o conjunto de informações processadas pelo sistema interno de um computador que permite a interação entre usuário e os periféricos do computador por meio de uma interface gráfica. Engloba o sistema operativo e os controladores de dispositivos (memória, impressora, teclado entre outros).
Software de Programação: é o conjunto de ferramentas que permitem ao programador desenvolver sistemas informáticos, geralmente usando linguagens de programação e um ambiente visual de desenvolvimento integrado.
Software de Aplicação: são programas de computadores que permitem ao usuário executar uma série de tarefas específicas em diversas áreas de atividade como arquitetura, contabilidade, educação, medicina e outras. São ainda os vídeo jogos, as base de dados, os sistemas de automação industrial, etc.
Licença de Software
As licenças de software especificam, de forma legal, o que o usuário pode ou não fazer com o software. Essas licenças normalmente estão disponíveis no site do projeto, no programa de instalação do aplicativo, no início dos arquivos de código fonte ou em algum documento texto na árvore de código fonte.
Um projeto de software open source pode utilizar qualquer licença, pode usar uma licença pronta como a GNU GPL ou pode até criar uma própria voltada para os interesses do projeto. O projeto precisa definir algumas liberdades básicas:
A liberdade de usar o software, para qualquer fim
A liberdade de alterar o software (O código fonte aberto é um pré-requisito para essa liberdade).
A liberdade de distribuir o software, versões modificadas ou sem modificações.
As várias licenças de software open source
Originalmente escrita por Richard Stallman para o projeto GNU, a GNU General Public License, ou simplesmente GPL, é a mais popular licença de software livre utilizada em projetos abertos. Essa licença se distingue das outras por obrigar que trabalhos derivados de algum código GPL, passe a ser GPL também. Caso use alguma parte de código GPL dentro do código fonte de algum software proprietário, ao distribuí-lo você está legalmente obrigado a distribuir o código fonte de todo o software.
A GPL garante que quem usar algum software derivado ganhará os mesmos direitos do primeiro usuário que realizou alterações.
Outra licença muito comum é a BSD, ela é menos restritiva e permite o uso integral ou parcial do seu código fonte em programas proprietários. Isso significa que qualquer um pode derivar um trabalho publicado originalmente sob licença BSD e torná-lo um software proprietário. Neste caso, a única exigência é exibir em algum lugar do software ou do material utilizado para distribuir o software as notas de copyrights das partes de código que o software utiliza.
Outras licenças também seguem a linha da licença BSD, como a licença MIT e a LGPL, esta última seguindo as mesmas características da GPL porém sem exigir que os trabalhos derivados estejam na mesma licença.
Licenças duplas
Alguns projetos de software open source fornecem duas licenças, uma livre e outra comercial. A licença livre normalmente é a GPL, que exige que os trabalhos derivados também sejam GPL. Neste caso, se uma empresa quiser desenvolver um aplicativo comercial e não quiser abrir o código fonte para o público, pode optar por comprar uma licença comercial do software, que permite o uso em aplicações proprietárias. Esse modelo de negócio tem sido usado por empresas como a TrollTrech, que desenvolve a biblioteca gráfica multiplataforma Qt.
Essa biblioteca, com a sua licença aberta (GPL), é usada no projeto KDE, um ambiente gráfico livre para GNU/Linux e outros Unix-like. Porém, softwares proprietários multiplataforma, como o Skype e o navegador Opera, também a usam, além da sua licença comercial.
Copyrights
As licenças livres não retiram os direitos autorais de seus autores. O autor do software pode, se desejar, alterar a licença das partes de software que ele escreveu. A próxima versão poderia vir em qualquer outra licença de software, podendo ser até um software proprietário.Os usuários prejudicados poderiam, neste caso, fazer um fork da última versão aberta ao público e então iniciar um novo desenvolvimento em torno daquele código.
Crise do Software
A partir de 1961 o mundo presenciou o surgimento de novos computadores, mais modernos e com mais poder computacional. A partir dessa data o software ganhou notoriedade e, por conta disso, uma série de problemas relacionados ao “amadorismo” utilizado para sua construção ficou evidente. Esses fatores originaram o que ainda hoje é conhecido como a Crise do Software, em meados de 1968. Otermo expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda existente, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento que funcionassem adequadamente ou pudessem ser validados.
Os problemas que originaram essa crise tinham relacionamento direto com a forma de trabalho das equipes. Eram problemas que não se limitavam a "sistemas que não funcionam corretamente", mas envolviam também dúvidas sobre como desenvolver e manter um volume crescente de software e ainda estar preparado para as futuras demandas. Essencialmente, eram sintomas provenientes do pouco entendimento dos requisitos por parte dos desenvolvedores, somados às técnicas e medidas pobres aplicadas sobre o processo e o produto, além dos poucos critérios de qualidade estabelecidos até então.
Em 1968 aconteceu a NATO Software Engineering Conference, um evento criado com o objetivo de discutir alternativas para contornar a Crise do Software. Essa conferência marcou assim o início dessa nova área na computação. Esta conferência teve como um dos participantes o ilustre professor de Matemática, da Universidade Eindhoven de Tecnologia Edsger Dijkstra. Em 1972 Dijkstra recebeu o Prêmio Turing (Turing Award), que é dado anualmente pela Association for Computing Machinery (ACM), para uma pessoa selecionada por contribuições de natureza técnica feitas para a comunidade de computação. Seu discurso para recebimento do prêmio, intitulado “O Pobre Programador” (The Humble Programmer) tornou-se um clássico da Engenharia de Software.
Um trecho desse discurso, traduzido para o português e que resume a crise, é exibido a seguir: 
“A maior causa da crise do software é que as máquinas tornaram-se várias ordens de magnitude mais poderosas! Para esclarecer melhor: quando não havia máquinas, a programação não era um problema; quando tínhamos poucos computadores, a programação tornou-se um problema razoável, e agora, que nós temos computadores gigantes, a programação tornou-se um problema igualmente grande”.
Causas relacionadas à crise de software
As causas relacionadas a crise do software estão ligadas a complexidade do processo de software e a relativa imaturidade da engenharia de software como profissão:
As estimativas de prazo e de custo frequentemente são imprecisas
Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software;
Com poucos dados históricos como guia as estimativas tem sido a olho, com resultados previsivelmente ruins;
A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços;
Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente;
A qualidade de software às vezes é menos que adequada: Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software;
O software existente é muito difícil de manter a tarefa de manutenção devora o orçamento destinado ao software; a facilidade de manutenção não foi enfatizada como um critério importante.
 A crise se manifesta de varias formas:
Projetos estourando o orçamento;
Projetos estourando o prazo;
Software de baixa qualidade;
Software muitas vezes não atingiam os requisitos;
Projetos não gerenciáveis e o código difícil de manter.
Em um relatório apresentado em 1969, esse problema já havia sido reconhecido. Conforme foi observado, cerca de 50 a 80% dos projetos nunca foram concluídos ou estavam tão longe de seus objetivos que foram considerados fracassados. Dos sistemas que foram finalizados, 90% haviam terminado 150 a 400% acima do orçamento e dos prazos predeterminados.
A maior parte dos projetos ainda hoje continuam com os mesmos problemas, assim pode se dizer que a crise persiste mesmo após 40 anos. Podem ser aplicadas soluções com o objetivo de minimizar esta crise, entre elas:
O uso de melhores técnicas, métodos e ferramentas;
Treinamento para a equipe de projeto (Atualmente não se investe o suficiente);
Reeducação da equipe em aspectos relacionados ao desenvolvimento;
Mudança de paradigma sobre o que é desenvolver software e como deveria ser feito.
Mitos do Software
Os mitos de software são “falsas verdades” que existem no mundo da indústria de software. Tanto jovens engenheiros quanto pessoas mais experientes tendem a acreditar neles, distorcendo a verdadeira face do processo de engenharia. Os mais comuns são:
Um bom manual, repleto de padrões e regras, fornecerá a equipe tudo que ela precisa saber:
Desenvolvimento não é uma receita de bolo! Os clientes são diferentes, os projetos são diferentes, os programadores são diferentes, as prioridades dependem do projeto. Basicamente, TUDO é diferente. Por exemplo, um site de e-commerce desenvolvido para a empresa X valerá para a empresa Y, e vice-versa. O planejamento é fundamental para o levantamento dos requisito e realização dos trabalhos necessários em cada projeto.
Caso ocorra atraso no cronograma este poderá ser contornado alocando-se mais programadores ao projeto:
Por mais que exista o conceito de “Fábrica de Software” não pode-se pensar no processo de desenvolvimento como uma linha de produção. Ao se inserir um programador em um projeto, ele levará algum tempo para se familiarizar com o código e com o que está sendo feito, para então, começar de fato a produzir. Outro grande pecado que muitos gestores comentem é tratar o programador como “pedreiro” ou “peão”. Se o desenvolvedor não entende nada do processo da empresa, tenha certeza que não poderá contribuir da melhor maneira possível.
Terceirizar um projeto é garantia de tranquilidade e nenhum trabalho:
Quando um projeto é muito trabalhoso, requer know-how maior do que a sua equipe possui ou o cronograma está apertado, muitos optam pela terceirização achando que esta é uma garantia de tranquilidade e nenhum trabalho. A questão é que qualquer problema será um problema seu também e não da empresa terceirizada. A maioria das empresas terceiriza o serviço, mas ao comprar o código, fica responsável por suas manutenções. A questão é: A terceirização fez o serviço direito? Comentou o código? Documentou o que foi feito? Sua equipe tem pessoal para trabalhar nesse código.
Um software pode ser construído observando-se o seu propósito geral – os detalhes podem ser levados em conta posteriormente:
Ao se pensar em um software deve-se mapear o máximo possível de suas funcionalidades a serem desempenhadas. É claro que em um primeiro momento é difícil pensar em tudo, uma coisa ou outra vai entrar como correção. Mas pensar em algo básico demais e querer enfeita-lo demais depois, envolve mais tempo e o pior: retrabalho! Desenvolvedores geralmente não gostam de destruir algo para refazer, pois o cliente mudou de ideia. Aliás, ninguém gosta.
Mesmo que os requisitos de um software mudem, as alterações são realizadas facilmente pois temos uma boa equipe que sabe como fazer o serviço muito bem:
Mais uma vez, se você não é desenvolver e não entende do processo, não julgue uma atualização como simples. Somente um programador poderá avaliar o quão simples uma alteração é – e muitas vezes, ela só vai realmente ter a ideia depois que estiver trabalhando com o código. Mesmo que você tenha uma boa equipe, modificações devem ser analisadas, discutidas com relação a sua viabilidade e testadas. Lembre-se sempre: alocar um programador requer algum tempo para que esse se familiarize com o que vem sendo feito. As coisas não são tão simples.
Se o programa funciona, nosso trabalho está completo. Se o programa ainda não está finalizado e “rodando”, não posso avaliar sua qualidade:
Se um programa roda isso não garante que o seu trabalho está feito. Todo o processo de desenvolvimento deve buscar a qualidade e apenas funcionar não lhe garante isso – ou seja, o processo da avaliação de qualidade não se limita a essa etapa. O seu código é bem comentado? Está bem feito? Otimizado?A tecnologia utilizada é adequada? Os banco de dados estão otimizados? Sua relações foram criadas corretamente? A infraestrutura do cliente suporta o que está sendo desenvolvido? Se o seu sistema foi feito para suportar vários acessos, ele realmente suporta isso? Um programa é mais do que o executável. Você vende todo o processo.
O único produto que entregarei ao cliente é o código executável:
Em alguns casos, o produto “palpável” que o cliente recebe é somente o executável. Em outros, trabalha-se com o código fonte e com a documentação. Contudo, independente do caso, lembre que, como foi dito no item anterior: Um programa é mais do que o executável. Você vende todo o processo de desenvolvimento. Por isso, deve-se pensar em faze-lo com perfeição.
O processo de planejamento fará com que criemos documentação volumosa que atrasará a execução do projeto, atrasando o cronograma:
Planejamento é fundamental! Muitas pessoas ainda confundem planejamento com “papelada”, ma não! Mesmo trabalhando-se em um time Agile, planejar é fundamental! A documentação do projeto será trabalhada na melhor metodologia adotada mas um plano do que será feito deverá ser estudado antes de “colocar a mão na massa”. Somente com o estudo dos processos e necessidades do cliente você conseguirá criar um software que trabalhe com excelência!