Engenharia de Software Conceitos e Práticas Raul Sidnei Wazlawick Preencha a ficha de cadastro no final deste livro E receba gratuitamente informações sobre os lançamentos e as promoções da Elsevier. Consulte também nosso catálogo completo, últimos lançamentos e serviços exclusivos no site www.elsevier.com.br Engenharia de Software Conceitos e Práticas Raul Sidnei Wazlawick 1ª edição © 2013, Elsevier Editora Ltda. Todos os direitos reservados e protegidos pela Lei no 9.610, de 19/02/1998. Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos, gravação ou quaisquer outros. Coordenação editorial: Adriana Ayami Takimoto Copidesque: Andrea Vidal Revisão: Eloiza Mendes Lopes Editoração Eletrônica: Thomson Digital Elsevier Editora Ltda. Conhecimento sem Fronteiras Rua Sete de Setembro, 111 – 16o andar 20050-006 – Centro – Rio de Janeiro – RJ – Brasil Rua Quintana, 753 – 8o andar 04569-011 – Brooklin – São Paulo – SP Serviço de Atendimento ao Cliente 0800-0265340 [email protected] ISBN: 978-85-352-6120-2 Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nosso Serviço de Atendimento ao Cliente, para que possamos esclarecer ou encaminhar a questão. Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens originados do uso desta publicação. CIP-BRASIL. CATALOGAÇÃO-NA-FONTE SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ W372e Wazlawick, Raul Sidnei, 1967- Engenharia de software: conceitos e práticas / Raul Sidnei Wazlawick. - Rio de Janeiro: Elsevier, 2013. 28 cm ISBN 978-85-352-6084-7 1. Engenharia de software 2. Software - Desenvolvimento. I. Título. 13-0677. CDD: 005.1 CDU: 004.41 30.01.13 01.02.13 042501 Sobre o Autor Raul Sidnei Wazlawick é Professor Associado IV do Departamento de Informática e Estatística da Universidade Federal de Santa Catarina (UFSC), Bacharel em Ciência da Computação (UFSC, 1988), Mestre em Ciência da Computação pela Universidade Federal do Rio Grande do Sul (UFRGS, 1991) e Doutor em Engenharia (UFSC, 1993), com Pós-Doutorado em Informática pela Universidade Nova de Lisboa (1998). Desde 1986, trabalha na área de Engenharia de Software, sendo docente desde 1992 na UFSC e em cursos e palestras em dezenas de outras universidades e empresas no Brasil e no exterior. Trabalha também em projetos de pesquisa em consultoria em empresas para melhoria de processos de desenvolvimento de software. Foi membro do Conselho da Sociedade Brasileira de Computação (SBC), coordenador dos cursos de Bacharelado e Mestrado em Ciência da Computação da UFSC, coordenador do XX Simpósio Brasileiro de Engenharia de Software (SBES 2006) e chair do Working Group 3.2 (Higher Education) da International Federation for Information Processing (IFIP). Foi também membro da Comissão de Especialistas em Ensino de Informática e Computação do Ministério da Educação (MEC). Orientou dezenas de dissertações de mestrado, teses de doutorado e trabalhos de graduação; tendo também publicado mais de uma centena de artigos científicos em eventos e periódicos internacionais. Recebeu, juntamente com sua orientanda Marília Guterres Ferreira, o prêmio Best Paper Award na Conferência Ibero-americana de Engenharia de Software em 2011. É bolsista de produtividade em desenvolvimento tecnológico e extensão inovadora pelo CNPq. Prefácio O SWEBOK1 (Software Engineering Book of Knowledge), organizado pela IEEE Computer Society, define o corpo de conhecimentos usualmente aceito relacionado à Engenharia de Software (IEEE Computer Society, 2004). Esta publicação relaciona dez áreas de conhecimento, das quais sete são tratadas aqui neste livro (Teste de Software, Manutenção de Software, Gerenciamento de Configuração de Software, Gerenciamento de Engenharia de Software, Processo de Engenharia de Software, Ferramentas e Métodos de Engenharia de Software e Qualidade de Software), enquanto as outras três áreas (Requisitos de Software, Design de Software e Construção de Software) são tratadas no livro Análise e Projeto de Sistemas de Informação Orientados a Objetos (Wazlawick, 2011). Este livro não possui um capítulo específico sobre ferramentas de Engenharia de Software, porque elas são mencionadas ao longo de todos os capítulos onde se fazem necessárias. As referências incluem, sempre que possível, produtos gratuitos e proprietários, bem como a referência para o site da empresa ou grupo responsável pela ferramenta. As referências bibliográficas, também, sempre que disponíveis na Internet, têm sua URL referenciada no local em que aparecem no texto, de forma a facilitar uma eventual busca pelas fontes originais deste trabalho. O livro não esgota o assunto relacionado à Engenharia de Software, mas os tópicos mais fundamentais estão detalhados de modo que o leitor consiga efetivamente usar as técnicas, e não apenas ouvir falar delas. A profundidade com que os tópicos são abordados corresponde ao que o autor entende que seria adequado a um aluno de graduação em Sistemas de Informação ou Ciência da Computação, para que possa desempenhar a função de engenheiro de software adequadamente no mercado de trabalho. O livro também pode ser de grande valia para profissionais que tenham interesse em se reciclar ou dar o passo inicial para implantar processos produtivos mais organizados em suas empresas. O conteúdo deste livro pode ser abordado possivelmente em uma disciplina de 90 horas ou ainda em três disciplinas de 30 horas cada, em que cada disciplina abordaria uma das partes do livro: processo de engenharia de software, gerenciamento de projeto de software e qualidade de software. Uma quarta disciplina de cerca de 40 a 50 horas ainda poderia ser acrescentada com o uso do livro Análise e Projeto de Sistemas de Informação Orientados a Objetos, que complementa este livro com a apresentação de técnicas detalhadas para requisitos, análise, design e geração de código. Não foram incluídos exercícios no livro porque estão disponibilizados no site da editora, bastando, para acessá-los, usar o código fornecido pelo próprio livro. Esta escolha visa, por um lado, permitir que o livro tenha um preço mais acessível, já que diminui o número total de páginas e, por outro lado, permite que novos exercícios possam ser dinamicamente adicionados pelo autor, à medida que são produzidos. Os leitores são incentivados a entrarem em contato com o autor pelo email [email protected] para apresentar sugestões de melhoria ao livro, pois, de acordo com as sugestões apresentadas no próprio livro, o feedback do usuário é fundamental para a criação de produtos de qualidade. Este livro foi produzido em ciclos iterativos entre os anos de 2010 e 2012, a partir de diversas fontes bibliográficas e da experiência do autor na área, que iniciou em 1985 seus estudos e, até hoje, leciona, publica e presta consultoria na área de Engenharia de Software. O livro pode ser lido do início ao fim, mas também pode ser lido em qualquer outra ordem, visto que os capítulos são autocontidos e eventuais referências a outros capítulos são feitas quando necessário. Alguns detalhamentos relacionados a normas técnicas podem ser omitidos da leitura, e mantidos à mão para referência, mas, mesmo assim, foram mantidos no corpo do livro, visto que, apesar de extensos, tais trechos reforçam as boas práticas de Engenharia de Software que devem ser seguidas para que sejam desenvolvidos sistemas com qualidade. Este livro é dedicado a todos aqueles que acreditam e trabalham para que o Brasil possa um dia ser referência mundial na área de produção de software com qualidade e criatividade. Vamos melhorar nossos processos de produção para que isso ocorra ainda nesta geração! Ingleses do Rio Vermelho, distrito de Florianópolis, 16 de fevereiro de 2012. 1www.computer.org/portal/web/swebok/html/contents C a p í t u l o Introdução 1 Este capítulo apresenta uma introdução ao assunto de engenharia de software, iniciando pelos clássicos a crise do software (Seção 1.1) e os mitos do software (Seção 1.2). Procura-se dar um entendimento às expressões “engenharia de software” (Seção 1.3) e “engenheiro de software” (Seção 1.4), já que a literatura não é homogênea em relação a elas. A evolução da área é brevemente apresentada (Seção 1.5), bem como uma classificação dos tipos de sistemas referentes à engenharia de software (Seção 1.6), uma vez que este livro se especializa em engenharia de software para sistemas de informação (outros tipos de sistema poderão necessitar de técnicas específicas que não são tratadas aqui). Finalmente, os princípios da engenharia de software, que permeiam todos os capítulos do livro, são brevemente apresentados (Seção 1.7). 1.1 A Crise dos Desenvolvedores de Software Menos Preparados Por algum motivo, os livros de engenharia de software quase sempre iniciam com o tema “crise do software”. Essa expressão vem dos anos 1970. Mas o que é isso, afinal? O software está em crise? Parece que não, visto que hoje o software está presente em quase todas as atividades humanas. Mas as pessoas que desenvolvem software estão em crise há décadas e, em alguns casos, parecem impotentes para sair dela. Em grande parte, parece haver desorientação em relação a como planejar e conduzir o processo de desenvolvi- mento de software. Muitos desenvolvedores concordam que não utilizam um processo adequado e que deveriam investir em algum, mas ao mesmo tempo dizem que não têm tempo ou recursos financeiros para fazê-lo. Essa história se repete há décadas. A expressão “crise do software” foi usada pela primeira vez com impacto por Dijkstra (1971)1. Ele avaliava que, considerando o rápido progresso do hardware e das demandas por sistemas cada vez mais complexos, os desenvolvedo- res simplesmente estavam se perdendo, porque a engenharia de software, na época, era uma disciplina incipiente. Os problemas relatados por Dijkstra eram os seguintes: a) Projetos que estouram o cronograma. b) Projetos que estouram o orçamento. c) Produto final de baixa qualidade ou que não atenda aos requisitos. d) Produtos não gerenciáveis e difíceis de manter e evoluir. 1Disponível em: <www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF>. Acesso em: 21 jan. 2013. 1 2 Engenharia de Software Alguma semelhança com sistemas do início do século XXI? Muitas! Sucede que, embora a engenharia de software tenha evoluído como ciência, sua aplicação na prática ainda é muito limitada, especialmente em empresas de pequeno porte e em empresas novas. Mesmo depois de 40 anos, ainda são comuns as queixas da alta administração das empresas em relação ao setor de informática quanto a prazos que não são cumpridos, custos ainda muito elevados, sistemas em uso que demandam muita manutenção e também ao fato de que é difícil recrutar profissionais qualificados. Os usuários também estão infelizes: encontram erros e falhas inadmissíveis em sistemas entregues, sentem-se inseguros em usar tais sistemas, reclamam da constante necessidade de manutenção e do seu alto custo. Os desenvolvedores, por sua vez, não estão mais satisfeitos: sentem que sua produtividade é baixa em relação ao seu potencial, lamentam a falta de qualidade no produto gerado por seu trabalho, sofrem pressão para cumprir prazos e orçamentos apertados, e ficam inseguros com as mudanças de tecnologia que afetam sua qualificação em relação ao mercado. Booch (1994) afirma: “We often call this condition ‘the software crisis’, but frankly, a malady that has carried on this long must be called ‘normal’”2. Pode-se concluir que a crise do software continuará enquanto os desenvolvedores continuarem a utilizar processos artesanais e a não capitalizar erros e acertos. Teixeira (2010)3 compara o desenvolvimento de software ao artesanato da Idade Média, quando, por exem- plo, um artesão fazia um par de sapatos como um produto único para cada cliente. Buscava-se a matéria-prima, cortava-se e costurava-se para produzir um sapato que servisse ao cliente. O software, em muitas empresas, ainda é desenvolvido dessa forma artesanal. Porém, apenas a adoção de processos efetivamente industriais para a produção de software poderá fazer essa área desenvolver-se mais rapidamente, com mais qualidade e, finalmente, sair dessa dificuldade crônica que já nem pode ser chamada de crise. 1.2 Os Eternos Mitos São bastante conhecidos também os mitos do software, identificados por Pressman (2005). Esses mitos são crenças tácitas e explícitas que permeiam a cultura de desenvolvimento de software. Os mais experientes acabam percebendo que elas não têm fundamento, constituindo-se realmente em mitos, mas a cada ano novos desenvolvedores de software entram no mercado e reavivam as velhas crenças, já que seu apelo é grande. Pressman classifica os mitos em três grupos: administrativos, do cliente e do profissional. Seguem alguns comentários sobre os mitos administrativos: a) A existência de um manual de procedimentos e padrões é suficiente para a equipe produzir com qualidade. Na verdade, deve-se questionar se o manual é realmente usado, se ele é completo e atualizado. Deve-se trabalhar com processos que possam ser gerenciáveis e otimizados, ou seja, sempre que a equipe identificar falhas no processo, deve haver outro processo para modificá-lo. b) A empresa deve produzir com qualidade, pois tem ferramentas e computadores de última geração. Na verdade, ferramentas e computadores de boa qualidade são condições necessárias, mas não suficientes. Parafraseando Larman (2001), comprar uma ferramenta não transforma você instantaneamente em arquiteto. c) Se o projeto estiver atrasado, sempre é possível adicionar mais programadores para cumprir o cronograma. O desenvolvimento de software é uma tarefa altamente complexa. Adicionar mais pessoas sem que haja um planejamento prévio pode causar mais atrasos. Se não fosse assim, um programa de 20 mil linhas poderia ser escrito rapidamente por 20 mil programadores. d) Um bom gerente pode gerenciar qualquer projeto. Gerenciar não é fazer, e o desenvolvimento de software é um processo complexo por vários motivos. Assim, mesmo que o gerente seja competente, se não houver boa comunicação com a equipe, competência técnica e um processo de trabalho previsível, ele pouco poderá fazer para obter um produto com a qualidade desejada. 2Frequentemente chamamos essa condição de “crise do software”, mas, francamente, uma doença que já dura tanto tempo devia ser chamada de “normalidade”. 3Disponível em: <pt.scribd.com/doc/37503268/A-Crise-de-SW-Hugo-Vidal-Teixeira>. Acesso em: 21 jan. 2013. Introdução 3 Entre os mitos relacionados ao cliente, pode-se citar: a) Uma declaração geral de objetivos é suficiente para iniciar a fase de programação. Os detalhes podem ser adicionados depois. É verdade que não se pode esperar que a especificação inicial do sistema esteja correta e completa antes de se iniciar a programação, mas ter isso como meta é péssimo. Deve-se procurar obter o máximo de detalhes possível antes de iniciar a construção do sistema. Técnicas mais sofisticadas de análise de requisitos e uma equipe bem treinada poderão ajudar a construir as melhores especificações possíveis sem perda de tempo. b) Os requisitos mudam com frequência, mas sempre é possível acomodá-los, pois o software é flexível. Na verdade, o código é fácil de mudar – basta usar um editor. Mas mudar o código sem introduzir erros é uma tarefa bastante improvável, especialmente em empresas com baixa maturidade de processo. O software só será efetivamente flexível se for construído com esse fim. É necessário, entre outras coisas, identificar os requisitos permanentes e os transitórios, e, no caso dos transitórios, preparar o sistema para sua mudança utilizando padrões de design adequados. Mesmo que o software não seja um elemento físico, como um edifício ou uma ponte (mais difíceis de serem modificados), a mudança do software também implica esforço e custo (em tempo), e muitas vezes esse esforço e esse custo não são triviais. c) Eu sei do que preciso. Os desenvolvedores costumam dizer o inverso: o cliente não sabe do que precisa. É necessário que os analistas entendam que os clientes (a não ser que sejam técnicos especializados) raramente sabem do que realmente precisam e têm grande dificuldade para descrever e até mesmo para lembrar-se de suas necessidades. De outro lado, analistas muitas vezes confundem as necessidades do cliente (alvo da análise) com as soluções possíveis (alvo do design). Por exemplo, um analista pode achar que o cliente precisa de um sistema web com tabelas relacionais, mas essa não é uma boa descrição de uma necessidade. É a descrição de uma solução para uma necessidade que possivelmente não foi estabelecida de maneira clara. Outras soluções poderiam ser aplicadas. Outros mitos de Pressman dizem respeito ao profissional, e são comentados a seguir: a) Assim que o programa for colocado em operação, nosso trabalho terminou. Na verdade, ainda haverá muito esforço a ser despendido depois da instalação do sistema, por causa de erros dos mais diversos tipos. Estudos indicam que mais da metade do esforço despendido com um sistema ocorre depois de sua implantação (Von Mayrhauser & Vans, 1995). b) Enquanto o programa não estiver funcionando, não será possível avaliar sua qualidade. Na verdade, o pro- grama é apenas um dos artefatos produzidos no processo de construção do software (possivelmente o mais importante, mas não o único). Existem formas de avaliar a qualidade de artefatos intermediários como casos de uso e modelos conceituais para verificar se estão adequados mesmo antes da implementação do sistema. c) Se eu esquecer alguma coisa, posso arrumar depois. Quanto mais o processo de desenvolvimento avança, mais caras ficam as modificações em termos de tempo e dinheiro. d) A única entrega importante em um projeto de software é o software funcionando. Talvez essa seja a en- trega mais importante, porém, se os usuários não conseguirem utilizar o sistema ou se os dados não forem corretamente importados, pouco valor ele terá. O final de um projeto de informática costuma envolver mais do que simplesmente entregar o software na portaria da empresa do cliente. É necessário realizar testes de operação, importar dados, treinar usuários, definir procedimentos operacionais. Assim, outros artefatos, além do software funcionando, poderão ser necessários. Leveson (1995) também apresenta um conjunto de mitos correntes, a maioria dos quais está relacionada à confia- bilidade do software: a) O teste do software ou sua verificação formal pode remover todos os erros. Na verdade, o software é cons- truído com base em uma especificação de requisitos que usualmente é feita em linguagem natural e, portanto, aberta a interpretações. Nessas interpretações pode haver erros ocultos. Além disso, a complexidade do software contemporâneo é tão grande que se torna inviável testar todos os caminhos possíveis. Assim, a única possibilidade é testar os caminhos mais prováveis de ocorrer ou de provocar erros. As técnicas de teste é que vão indicar quais caminhos é interessante verificar. b) Aumentar a confiabilidade do software aumenta a segurança. O problema é que o software pode ser confiável apenas em relação à sua especificação, ou seja, ele pode estar fazendo certo a coisa errada. Isso normalmente 4 Engenharia de Software se deve a requisitos mal compreendidos. É consenso que corrigir erros durante o levantamento de requisitos é muito mais barato do que corrigi-los em um sistema em operação. c) O reúso de software aumenta a segurança. Certamente, pois os componentes reusados já foram testados. O problema é saber se os requisitos foram corretamente estabelecidos, o que leva de volta ao mito anterior. Além disso, se os componentes reusados forem sensíveis ao contexto (o que acontece muitas vezes), coisas inesperadas poderão acontecer. Porém, de nada adianta estar consciente dos mitos. Para produzir software com mais qualidade e confiabilidade é necessário utilizar uma série de conceitos e práticas. Ao longo deste livro, vários conceitos e práticas úteis em Engenharia de Software serão apresentados ao leitor de forma que ele possa compreender o alcance dessa área e seu potencial para a melhoria dos processos de produção de sistemas 1.3 (In)Definição de Engenharia de Software Segundo a Desciclopédia4, a Engenharia de Software pode ser definida assim: A Engenharia de Software forma um aglomerado de conceitos que dizem absolutamente nada e que geram no estudante dessa área um sentimento de “Nossa, li 15 kg de livros desta mesma. e não aprendi nada”. É tudo bom senso. Apesar de considerar que o material publicado na Desciclopédia seja de caráter humorístico, a sensação que muitas vezes se tem da Engenharia de Software é mais ou menos essa mesma. Pelo menos foi essa a sensação do autor deste livro e de muitos de seus colegas ao longo de vários anos. Efetivamente, não é algo simples conceituar e praticar a Engenharia de Software. Mas é necessário. Primeira- mente, deve-se ter em mente que os processos de Engenharia de Software são diferentes, dependendo do tipo de software que se vai desenvolver. O Capítulo 2, por exemplo, vai mostrar que, dependendo do nível de conhecimento ou estabilidade dos requisitos, deve-se optar por um ou outro ciclo de vida, o qual será mais adequado ao tipo de desenvolvimento que se vai encontrar. O Capítulo 8, por outro lado, vai mostrar que uma área aparentemente tão subjetiva como “riscos” pode ser sistematizada e tratada efetivamente como um processo de engenharia, e não como adivinhação. O Capítulo 7 apresentará formas objetivas e padronizadas para mensurar o esforço do desenvolvimento de software, de forma a gerar números que sejam efetivamente realistas, o que já vem sendo comprovado em diversas empresas. Assim, espera-se que este livro consiga deixar no leitor a sensação de que a Engenharia de Software é possível e viável, desde que se compreenda em que ela realmente consiste e como pode ser utilizada na prática. Várias definições de Engenharia de Software podem ser encontradas na literatura, como, por exemplo: a) Engenharia de software é uma profissão dedicada a projetar, implementar e modificar software, de forma que ele seja de alta qualidade, a um custo razoável, manutenível e rápido de construir (Laplante, 2007). b) Engenharia de software é a aplicação de abordagens sistemáticas, disciplinadas e quantificáveis ao desenvolvimen- to, operação e manutenção de software, além do estudo dessas abordagens (IEEE Computer Society, 2004)5. Neste livro será considerada com maior ênfase a definição da Engenharia de Software como o processo de estu- dar, criar e otimizar os processos de trabalho para os desenvolvedores de software. Assim, embora isso não seja consenso geral, considera-se, que as atividades de levantamento de requisitos, modelagem, design6 e codificação, por exemplo, não são típicas de um engenheiro de software, embora, muitas vezes, ele seja habilitado a realizá-las. Sua tarefa consiste mais em observar, avaliar, orientar e alterar os processos produtivos quando necessário. A seção seguinte procura deixar mais clara essa distinção entre as atividades dos desenvolvedores e do engenheiro de software. 4Disponível em: <desciclo.pedia.ws/wiki/Engenharia_de_Software>. Acesso em: 21 jan. 2013. 5Disponível em: <www.computer.org/portal/web/swebok/htmlformat>. Acesso em: 21 jan. 2013. 6As palavras inglesas design e project costumam ser traduzidas para o português como “projeto”. Para evitar confusão entre os dois significados, neste livro o termo design não será traduzido.