Engenharia de Software

Transcrição

1 Engenharia de Software 21 Engenharia de Software 22.1 Enquadramento O software é conhecimento incorporado e, como esse conhecimento está inicialmente disperso, tácito, latente e, em larga medida, incompleto, o desenvolvimento de software é um processo de aprendizagem social [Baetjer, 1998], um diálogo em que o conhecimento que se deve transformar em software é reunido e incorporado no sistema. O processo fornece interacção entre utilizadores e engenheiros de sistemas, entre utilizadores e tecnologia (ferramentas evolutivas), e entre engenheiros de sistemas e tecnologia. Na realidade, desenvolver software é um processo de aprendizagem iterativo e o resultado é uma corporização de conhecimento recolhido, destilado e organizado à medida que o processo é conduzido. Um projecto de software apresenta duas dimensões fundamentais: engenharia de software e gestão do projecto. A dimensão da engenharia trata da construção de software e centra-se nas questões técnicas como desenhar, codificar, testar, etc. A dimensão da gestão do projecto trata do modo de planear e controlar adequadamente, não apenas as actividades de engenharia, como igualmente as interacções com todos os stakeholders clientes, fornecedores, equipa, sponsors, gestores funcionais, etc., de modo a cumprir os objectivos do projecto em termos de âmbito, custo, prazo e qualidade. Se um projecto for pequeno digamos, uma equipa de 1 ou 2 pessoas a trabalhar durante 2 ou 3 semanas, poderá ser executado de um modo algo informal. O plano do projecto poderá ser um correio electrónico ( ) especificando a data de entrega e, eventualmente, alguns marcos (milestones) intermédios. Os requisitos poderão ser comunicados através de uma nota, ou mesmo verbalmente, e os produtos intermédios por exemplo, documentos do desenho poderão ser elaborados em computadores portáteis pessoais. No entanto, estas técnicas informais não são aplicáveis a projectos de maior dimensão, em que podem trabalhar muitas pessoas por um período de vários meses a situação mais comum na maioria dos projectos de software comercial. Nesses projectos, cada tarefa de engenharia deve ser cuidadosamente elaborada seguindo metodologias bem testadas e os produtos intermédios devem ser adequadamente documentados, de modo a poderem ser revistos por outras pessoas. As tarefas do projecto devem ser cuidadosamente planeadas e distribuídas, e depois monitorizadas à medida que o projecto é executado. Por outras palavras, para executar com sucesso projectos maiores é importante aumentar a formalidade e o rigor ao longo destas duas dimensões. A formalidade exige o uso de processos bem definidos para a realização das várias tarefas, de modo a que o resultado se torne mais dependente da aptidão do processo FCA Editora de Informática 321

2 Gestão de Projectos de Software (process capability). O emprego de abordagens quantitativas no processo, através do uso de métricas adequadas, permite melhorar a formalidade. Mas o que é um processo? Tecnicamente, um processo para uma tarefa compreende uma sequência de passos, que deverão ser seguidos para executar essa tarefa. Quando trabalhamos para construir um produto, ou sistema, é importante seguir uma série de passos previsíveis um roteiro que nos ajude a criar um resultado oportuno e de elevada qualidade. Deste modo, na engenharia de software, um processo é mais do que uma sequência de passos ele encapsula aquilo que engenheiros e gestores de projecto aprenderam acerca da execução de projectos de sucesso. Através do processo, os benefícios da experiência são conferidos a todos os indivíduos, incluindo os recém- -chegados à organização. No contexto deste livro, a expressão processo designa uma estrutura ou modelo para as tarefas exigidas na construção de um sistema de software de elevada qualidade 90. O processo é adaptado pelo gestor de projecto e pelos engenheiros de software, de acordo com as suas necessidades. Quem pediu o software tem igualmente um papel a desempenhar no processo de desenvolvimento. Ao nível de detalhe, o processo adoptado depende do tipo de software que se está a construir. Um dado processo poderá ser adequado para a criação de software para um sistema de pilotagem de uma aeronave, ao passo que se exige um processo totalmente diferente para o desenvolvimento de um website. Como é que podemos saber que fizemos a escolha certa? Existe um certo número de mecanismos de avaliação do processo, que habilitam as organizações a determinar a maturidade do seu processo de software. No entanto, os melhores indicadores da eficácia do processo utilizado são a qualidade, oportunidade e viabilidade de longo prazo do produto construído Visão Global do Desenvolvimento de Software A engenharia consiste na análise, desenho, construção, verificação e gestão de entidades técnicas (ou sociais). Independentemente da entidade alvo do processo de engenharia, é necessário colocar um conjunto de questões e obter respostas para elas [Pressman, 2000]: Qual é o problema a ser resolvido? Quais são as características da entidade que é usada para resolver o problema? Como é que a entidade (e a solução) vai ser conhecida? Como é que a entidade vai ser construída? Que abordagem será usada para descobrir os erros cometidos no desenho e construção da entidade? 90 Ver Glossário. 322 FCA Editora de Informática

3 Engenharia de Software Como é que a entidade irá ser suportada no longo prazo, quando forem solicitadas correcções, adaptações e melhorias pelos utilizadores da entidade? Neste livro concentramo-nos numa única entidade o software. Para desenvolver software de forma adequada, é necessário definir um processo de engenharia. Neste ponto, vamos considerar as características genéricas de qualquer processo de desenvolvimento. Mais adiante neste capítulo, falar-se-á de modelos de processo específicos Fases do Desenvolvimento O trabalho associado à engenharia do software pode ser dividido em três fases genéricas, independentemente do domínio aplicacional, da dimensão e da complexidade do projecto. Cada uma dessas fases trata uma, ou mais, das questões enunciadas atrás. A fase de definição concentra-se em o quê. Isto é, durante a fase de definição o engenheiro de sistemas procura identificar a informação a ser processada, as funções e desempenho pretendidos, o comportamento expectável para o sistema, as interfaces a estabelecer, as restrições ao desenho e os critérios de validação exigidos para definir um sistema de sucesso. São identificados os requisitos chave e do software. Embora os métodos aplicados durante a fase de definição variem de acordo com o paradigma (ou combinação de paradigmas) da engenharia de software aplicado, três grandes tarefas ocorrem do mesmo modo: A engenharia de sistemas ou de informação; O planeamento do projecto de software; A análise de requisitos. A fase de desenvolvimento concentra-se no como. Isto é, durante o desenvolvimento o engenheiro de software procura definir o modo como os dados estão estruturados; as funções vão ser implementadas numa arquitectura de software; as interfaces irão ser caracterizadas; o desenho irá ser traduzido numa linguagem de programação (ou numa linguagem não procedimental) e os testes irão ser realizados. Os métodos aplicados durante a fase de desenvolvimento variam, embora devam ocorrer sempre três tarefas de cariz técnico: O desenho do software; A codificação; Os testes do software. A fase de suporte concentra-se na correcção de erros e nas adaptações necessárias para acompanhar a evolução do software e do negócio do cliente. Durante a fase de suporte é possível encontrar quatro tipos de alterações [Pressman, 2000]: Correcções mesmo que se implementem as melhores actividades de garantia da qualidade, há sempre uma possibilidade de o cliente/utilizador descobrir defeitos no software. A correcção desses defeitos é efectuada durante a actividade de manutenção correctiva; FCA Editora de Informática 323

4 Gestão de Projectos de Software Adaptações o ambiente original para o qual o software foi desenvolvido (processador, sistema operativo, regras do negócio, características externas do produto, etc.) é passível de alterações, ao longo do tempo. A modificação do software para acomodar alterações no ambiente externo é realizada pela actividade de manutenção adaptativa; Melhorias à medida que o software é utilizado, o cliente/utilizador reconhece funções adicionais que lhe irão fornecer benefícios. A manutenção evolutiva estende as funcionalidades do software para além dos requisitos funcionais originais; Prevenção como o software se deteriora com as alterações que lhe vão sendo introduzidas, é necessário efectuar uma manutenção preventiva que permita ao software servir as necessidades dos seus utilizadores finais. Em essência, a manutenção preventiva efectua alterações aos programas, de modo a que eles sejam mais facilmente alterados, adaptados e melhorados. Para além destas actividades de suporte, os utilizadores de software exigem um suporte continuado. É frequente a implementação de assistentes técnicos, help desks telefónicos e websites específicos da aplicação, como parte desta base de suporte. É igualmente frequente a realização entre 6 e 9 meses após a o início da operação de uma auditoria pós-implementação, para verificar se o sistema de software satisfaz todos os requisitos e expectativas que presidiram à sua concepção e desenvolvimento. A Figura 22.1 mostra como as várias fases genéricas enunciadas se sucedem, do ponto de vista da engenharia do software. Actualmente, uma crescente população de sistemas administrativos herdados pelas empresas denominados, na literatura anglo-saxónica, de legacy systems 91 está a forçar muitas companhias a empreenderem estratégias de reengenharia de software. A reengenharia de software, num sentido global, é considerada, muitas vezes, como parte da reengenharia de processos empresariais [Dickinson, 1995]. As fases e tarefas associadas, descritas na visão global do processo de desenvolvimento de software, são complementadas por um conjunto de actividades envolventes, que incluem: Gestão do risco; Gestão da qualidade; Gestão da configuração; Monitorização e controlo do projecto; Revisões formais; Preparação e produção da documentação. 91 Ver Glossário. 324 FCA Editora de Informática

5 Engenharia de Software Definição Engenharia Preparar dados de teste Análise de requisitos Desenvolvimento Preparar instalação do software Codificação Testes Instalação Auditoria pós- -implementação Suporte Operação Figura 22.1 Fases genéricas do desenvolvimento de software Modelo Genérico do Processo de Desenvolvimento Um processo de desenvolvimento de software pode ser caracterizado como se mostra na Figura Estrutura comum do processo de desenvolvimento Actividades envolventes Actividades de estrutura Conjuntos de tarefas Tarefas de engenharia de software Marcos e produtos Pontos de garantia da qualidade Figura 22.2 O processo de desenvolvimento de software Adaptado de: [Pressman, 2000]. FCA Editora de Informática 325

6 Gestão de Projectos de Software Ao definir-se um pequeno número de actividades que são aplicáveis a todos os projectos de software, independentemente da respectiva dimensão e complexidade, estabelece-se uma estrutura comum do processo de desenvolvimento: Conjuntos de tarefas (task sets) cada conjunto é composto por tarefas de engenharia de software, milestones do projecto, produtos intermédios e pontos de garantia da qualidade, que permitem a adaptação das actividades de estrutura às características do projecto de software e aos requisitos da equipa de projecto; Actividades envolventes, como a garantia da qualidade do software, a gestão da configuração do software e as medidas envolvem o modelo de processo. Estas actividades são independentes de qualquer das actividades da estrutura e ocorrem ao longo de todo o processo. Deve seleccionar-se uma estrutura de processo comum que esteja sintonizada com o produto, com as pessoas e com o projecto. Nos anos mais recentes, tem havido uma ênfase significativa na maturidade do processo. O SEI desenvolveu um modelo abrangente baseado num conjunto de capacidades de engenharia do software que devem estar presentes à medida que as organizações atingem diferentes níveis de maturidade do processo do software. Para determinar o estado actual de maturidade do processo de qualquer organização, o SEI usa um mecanismo de avaliação que resulta num esquema de graduação com cinco pontos. Este esquema determina o ajustamento com o CMMI. No Capítulo 2 este assunto foi tratado com o necessário detalhe Modelos de Desenvolvimento Clássicos O objectivo de um modelo do processo de desenvolvimento é proporcionar, ao projecto, uma estrutura que reduza os riscos [Miguel, 2002b]. Um projecto sem estrutura é impossível de gerir não pode ser planeado, não pode ser estimado, não pode ter marcos definidos, o seu progresso não pode ser monitorizado e não podem ser feitas quaisquer promessas, ao cliente, sobre o seu custo, ou a sua qualidade. Um modelo do processo fornece uma estrutura, desenhada com o objectivo de reduzir o risco e a incerteza, e de aumentar a governabilidade do processo de desenvolvimento. Projectos diferentes possuem requisitos distintos. Se estivermos a desenvolver um pacote de software, o processo a seguir será distinto do usado para desenvolver um produto específico destinado a um cliente concreto. Existirão, evidentemente, similaridades subjacentes nos dois processos, mas as diferenças são suficientemente grandes para justificar uma distinção entre os dois tipos de desenvolvimento. Todos os riscos ultrapassar o orçamento, produzir o sistema errado, produzir um sistema que nunca funcione advêm da incerteza, ou da falta de conhecimento, sobre o sistema a ser desenvolvido. No entanto, quando empreendemos um projecto de desenvolvimento de software, queremos garantir que a exposição aos vários tipos de riscos é mantida a um nível considerado aceitável. O paradigma seguido para o desenvolvimento de software o modelo do processo de desenvolvimento deve, por 326 FCA Editora de Informática

7 Engenharia de Software isso, ter em consideração o grau de incerteza presente no início e dar ao projecto uma estrutura que reduza os riscos ou custos de possíveis falhas. Um modelo do processo de desenvolvimento a adoptar engloba os processos, métodos, ferramentas e fases genéricas descritos no início deste capítulo. A escolha de um modelo é baseada na natureza do projecto e da aplicação, nos métodos e ferramentas a serem utilizados e nos produtos e controlos exigidos. É possível caracterizar qualquer desenvolvimento de software como um anel de resolução de problemas (Figura 22.3), constituído por quatro fases: Descrição da situação actual; Definição do problema (identificação do problema concreto a resolver); Desenvolvimento da solução (aplicação de uma dada tecnologia para resolver o problema); Implementação da solução (entrega da solução a quem a solicitou). Definição do problema Situação actual Desenvolvimento da solução Implementação da solução Figura 22.3 Anel de resolução de um problema As fases genéricas do desenvolvimento de software enunciadas no ponto ajustam- -se facilmente a estas fases da resolução de problemas. Nos pontos seguintes deste capítulo irão descrever-se resumidamente os principais modelos do processo de desenvolvimento Modelo em Cascata A primeira abordagem ao desenvolvimento de software foi apresentada, em Agosto de 1970, por Winston Royce, na conferência do WESCON 93 [Royce, 1970]. 93 Convenção anual, de carácter científico, patrocinada pela IEEE. FCA Editora de Informática 327

8 Gestão de Projectos de Software Este modelo de processo, conhecido vulgarmente por modelo em cascata (Figura 22.4), propõe uma abordagem sistemática, linear e sequencial ao desenvolvimento de software. Embora neste modelo estivessem previstos feedback loops, representados pelas setas a tracejado da Figura 22.4, a grande maioria das organizações que o aplicam tratam-no de forma estritamente linear. Requisitos do utilizador Requisitos do software dos programas Codificação Testes Operação Figura 22.4 Modelo de processo em cascata Segundo este modelo, o desenvolvimento de software é constituído por um conjunto de actividades executadas de forma sequencial e sistemática, que se iniciam ao nível do sistema de informação (requisitos do utilizador) e prosseguem com as fases de requisitos do software, desenho, desenho dos programas, codificação, testes e operação (onde se processa o suporte). Vamos analisar cada uma das fases propostas pelo modelo: Requisitos do utilizador Requisitos do software Trata-se de uma fase fundamentalmente de engenharia e modelação do sistema de informação empresarial. O software é sempre um subconjunto de um conjunto (sistema) maior; por isso, o trabalho inicial consiste no estabelecimento das necessidades e requisitos globais de informação da organização e na subsequente atribuição de um subconjunto ao software. Estamos a falar de planeamento estratégico de sistemas de informação. O processo de determinação dos requisitos é, de seguida, intensificado, concentrando-se especificamente no software a construir. É necessário que os engenheiros de sistemas (analistas) compreendam bem o domínio aplicacional nas suas diversas vertentes informação, funções, comportamento, desempenho e interfaces. Esta fase, denominada igualmente de desenho lógico, visa modelar uma solução de um modo independente da tecnologia, isto é, baseada nas funções a informatizar e não na tecnologia em que o sistema será implementado. Inclui os modelos dos processos e dos dados. 328 FCA Editora de Informática

9 Engenharia de Software dos programas Codificação Testes Operação Esta fase, designada também por desenho físico, visa modelar a solução tecnológica para o problema e é um processo com múltiplos passos, que se concentra em quatro atributos de um programa de software estrutura dos dados, arquitectura do software, interfaces e algoritmos. O desenho dos programas traduz os requisitos num modelo de software cuja qualidade pode ser avaliada antes de se proceder à codificação. O desenho físico tem de ser traduzido para uma linguagem própria da máquina. Se o desenho dos programas for suficientemente detalhado e for usada uma ferramenta I-CASE 94, é possível gerar o código de uma forma automática (mediante geradores de código). Os testes iniciam-se após o código ter sido escrito. Os testes concentram-se na lógica interna do software (programas bem feitos?) e nas funções externas (satisfazem os requisitos do utilizador?). Após ser aceite pelo utilizador, o software tem de ser instalado no ambiente operacional para que foi construído. No entanto, após a instalação haverá sempre lugar a alterações ao software, devido quer a erros que passaram na malha dos testes, quer a alterações ao ambiente de negócio que o software visa servir, quer a alterações no ambiente tecnológico subjacente (hardware, sistema operativo, etc.). Essas alterações são efectuadas no âmbito do suporte e manutenção ao sistema, após a instalação. Este modelo é o mais amplamente utilizado na engenharia do software 95. No entanto, é alvo de algumas críticas: Não reconhece explicitamente a necessidade de revisão, isto é, retornar a fases anteriores e refazer coisas, à luz da informação obtida durante o desenvolvimento informação acerca daquilo que o utilizador quer, como o desenho se deve comportar, como o Sistema de Gestão de Bases de Dados (SGBD) deve ser usado, etc.; Durante o desenvolvimento, têm de ser tomadas muitas decisões, que podem conduzir a um certo número de caminhos e resultados possíveis. O modelo simples não reconhece isto. Por exemplo, dependendo da análise dos requisitos do cliente, pode decidir-se por uma de três alternativas: Desenvolver o sistema, de raiz; Refazer um sistema existente; Adquirir um pacote de software que forneça a maioria das funcionalidades exigidas Ver Glossário. Algumas metodologias de desenvolvimento de sistemas, como a reputada Structured Systems Analysis and Design (SSADM) desenvolvida para o governo britânico, têm subjacente este modelo de processo. FCA Editora de Informática 329

10 Gestão de Projectos de Software Esta simples decisão pode ter três resultados substancialmente diferentes; É muitas vezes difícil ao cliente/utilizador expressar, de forma explícita, todos os seus requisitos. O modelo em cascata, por ser sequencial e linear, tem dificuldade em acomodar a incerteza existente no início da maioria dos projectos; O utilizador tem de esperar, por vezes bastante tempo, até lhe ser entregue uma versão operacional de software. O actual ritmo de mudança dos negócios não é compatível com esse compasso de espera (quando o sistema é disponibilizado, há o sério risco de os requisitos iniciais se terem alterado substancialmente). Embora cada um destes argumentos seja bem real, este modelo de processo constituiu um feito notável para a época e ajudou a dar uma estrutura ao desenvolvimento do software, servindo ainda hoje o seu objectivo, em muitos aspectos Modelo em V O modelo em V do processo de desenvolvimento foi desenvolvido originalmente na Alemanha, em 1989, pela empresa tecnológica alemã IABG 96, por encomenda do Departamento Federal de Tecnologia e Aquisições para a Defesa da Alemanha. Actualmente, está consubstanciado num modelo de processo de desenvolvimento de software ao nível da Comissão Europeia denominado Euromethod 97. À semelhança do paradigma anterior, este modelo encara o desenvolvimento de software como um processo sequencial, constituído por duas grandes etapas (ou duas pernas, como num V) a etapa de especificação e a etapa de verificação e validação. A Figura 22.5 mostra esquematicamente este modelo 98. Etapa de especificação Especificação de requisitos Especificação detalhado Plano de testes de aceitação Plano de testes de integração Plano de testes de integração de subsistemas Codificação e testes de módulos e unidades Sistema operacional Testes de aceitação Testes de integração Testes de integração de subsistemas Etapa de verificação e validação Figura 22.5 Modelo em V do processo de desenvolvimento de software Em [Miguel, 2002b] pode ver-se uma descrição mais detalhada deste modelo. 330 FCA Editora de Informática