Agradecimentos
Gostava de agradecer ao Prof. José Luís Mota Pereira pelo seu apoio, paciência e sugestões; à minha esposa Cidália que já jamais desistiu de me apoiar e aos meus pais por todas as oportunidades que sempre me proporcionaram. A todos o meu muito obrigado, sem vocês este trabalho não teria sido possível.
Resumo
A indústria de desenvolvimento de software é uma força económica importante, na sociedade moderna. O software encontra-se presente em inúmeros sistemas e produtos com quem interagimos diariamente. A pressão da procura de software incentivou a investigação de novos métodos e técnicas que permitissem melhorar a qualidade do software desenvolvido, nasceu assim a disciplina da Engenharia de Software.
Os projectos de software modernos, devido à sua complexidade e dimensão, são desenvolvidos por equipas de profissionais. As equipas são a organização humana que permite a execução de projectos que seriam inviáveis através do esforço individual. No entanto, o trabalho em equipa é mais complexo de coordenar do que o trabalho individual. A eficácia de uma equipa é determinada pela facilidade com que os seus membros comunicam, colaboram e coordenam o seu trabalho.
O ambiente de suporte ao desenvolvimento de software definido neste trabalho é composto por duas tecnologias (workflow e groupware). A tecnologia de workflow será responsável pela coordenação do trabalho suportando a definição e execução de processos. A tecnologia de groupware fornecerá à equipa de projecto as funcionalidades de comunicação e colaboração necessárias para a execução do trabalho.
Não existe um modelo único ideal de organização de uma equipa e do seu esforço, desta forma o ambiente de suporte definido será capaz de suportar as diferentes configurações de equipas e de processo.
Abstract
The software development industry is an important economic driver. Software is a part of many systems and products, which we use and interact with daily. The growing global demand for software pushed the development of new methods and practices allowing the improvement of the developed software quality. These methods and practices became know as Software Engineering.
Modern software projects, due to their complexity and size, are developed by teams of software engineers. Teams are the human work organization that makes feasible efforts far beyond the capacity of one person. However, teamwork coordination is far more difficult than a single person effort. The team’s effectiveness is determined by how easy the members communicate, collaborate and coordinate their work.
The software development environment specified in this work é made of two different technologies (workflow and groupware). Workflow technology is used to support work coordination and process definition and execution. Groupware technology allows the team members to communicate easily and efficiently.
There are several possible ways of organizing a software team and its work, this demands that the software development environment has to be able to support effectively all the possible team configurations and processes.
Índice
1 Introdução...1
1.1 Motivação...1 1.2 Enquadramento ...1 1.3 Objectivos...2 1.4 Estrutura do trabalho...22 Engenharia de software...5
2.1 Processo de desenvolvimento de software ...7
2.2 Modelos de processos de software...9
2.2.1 Queda de água (waterfall)...10
2.2.2 Modelo da entrega incremental...11
2.2.3 Espiral...12
2.3 Processos ágeis de desenvolvimento de software...14
2.3.1 Extreme Programming...14
2.4 Actividades da engenharia de software...18
2.4.1 Engenharia de requisitos...18
2.4.2 Concepção do software...23
2.4.3 Construção do software ...25
2.4.4 Validação do software ...27
3 Equipas de desenvolvimento de software...29
3.1 Porquê uma equipa de desenvolvimento de software? ...29
3.2 Equipas eficazes de desenvolvimento de software...30
3.3 Características de uma equipa eficaz...33
3.4 Organização da equipa de software ...35
3.5 Tipos de equipas ...39
3.5.1 Equipa co-localizada...39
3.5.2 Equipa co-localizada a trabalhar em turnos ...40
3.5.3 Equipas virtuais ...40
3.6 Comunicação...43
3.7 Colaboração...45
3.8 Coordenação...47
4.1 Contexto de desenvolvimento de software...51
4.2 Requisitos do processo ...52
4.3 Requisitos do trabalho em equipa ...53
4.4 Uma primeira arquitectura abstracta do sistema ...55
4.5 Requisitos do sistema...57
4.5.1 Explicação dos requisitos de workflow ...57
4.5.2 Explicação dos requisitos de groupware...58
5 Sistemas de gestão de workflows ...59
5.1 Sistemas de gestão de workflows...59
5.2 Evolução dos sistemas de workflow...61
5.3 Conceitos de workflow ...62
5.3.1 Como se articulam estes conceitos? ...63
5.3.2 Exemplo de um processo de desenvolvimento de software ...64
5.4 Classificação de sistemas de workflow ...66
5.5 Arquitectura de um sistema de workflow ...66
5.5.1 Interface 1 – Interface de definição de workflow ...68
5.5.2 Interface 2 – Interface com aplicações cliente...69
5.5.3 Interface 3 – Interface de invocação de aplicações...70
5.5.4 Interface 4 – Interface com outros sistemas de workflow...71
5.5.5 Interface 5 – Interface com ferramentas de controlo e monitorização ...71
5.6 A modelação do processo ...72
5.6.1 Modelação de processos em sistemas de workflow...73
5.6.2 Dimensões descritivas da modelação de um processo...74
5.7 Execução de workflows...74
5.7.1 Modelo de execução baseado num scheduler...75
5.7.2 Garantias de execução de um workflow...75
5.8 Workflows dinâmicos...77
5.9 Arquitectura de um sistema de execução de workflows ...78
6 Groupware... 81
6.1 O que é o groupware?...81
6.2 Groupware no desenvolvimento de software ...83
6.3 Emergência do groupware...83
6.4 Classificação das aplicações de groupware...84
6.5.1 Colaboração ...86 6.5.2 Comunicação ...87 6.5.3 Coordenação...89 6.6 Sistemas de groupware...91 6.6.1 Correio electrónico ...92 6.6.2 Vídeo-conferência...92
6.6.3 Gestão electrónica de documentos...93
6.6.4 Mensagens instantâneas ...93
6.6.5 Fóruns de discussão...94
6.6.6 Agendas electrónicas partilhadas ...94
6.6.7 Sistemas de suporte a reuniões electrónicas e decisões em grupo...95
6.6.8 Sistemas de edição em grupo...95
7 Ambiente de suporte ao desenvolvimento de software ...97
7.1 Diferentes configurações de uma equipa de software...97
7.2 Ambiente de suporte ao desenvolvimento de software...100
7.3 Ambiente para equipas co-localizadas ...101
7.4 Ambiente para equipas em turnos...102
7.5 Ambiente para equipas distribuídas a trabalhar no mesmo turno...103
7.6 Ambiente para equipas distribuídas a trabalhar em diferentes horários...105
8 Conclusões ... 107
Índice de figuras
Figura 1 – Modelo queda de água ...10
Figura 2 – Modelo entrega incremental...11
Figura 3 – Comunicação horizontal na equipa...44
Figura 4 – Comunicação vertical na equipa ...45
Figura 5 – Sistema de suporte a metodologias clássicas ...55
Figura 6 – Sistema de suporte a metodologias ágil...56
Figura 7 – Processo de desenvolvimento de software ...65
Figura 8 - Processo de desenvolvimento de software modificado...65
Figura 9 – Arquitectura referência de um sistema de workflow...67
Figura 10 – Interface de intercâmbio de definições de processos...69
Figura 11 – Interface com Aplicações Cliente...70
Figura 12 – Interface com outros sistemas de workflow...71
Figura 13 – Interface com aplicações de administração ...72
Índice de tabelas
Tabela 1 – Características de eficácia/ineficácia de equipas...34
Tabela 2 – Características de uma equipa eficaz ...35
Tabela 3 – Classificação de equipa de desenvolvimento de software...39
Tabela 4 – Requisitos de um sistema de suporte ao desenvolvimento de software ...57
Capítulo 1
1 Introdução
1.1 Motivação
A escolha do tema de dissertação relacionado com a utilização de tecnologias de workflow e de groupware para suportar o desenvolvimento de software em equipa, deve-se ao facto de o software possuir actualmente um papel de enorme importância na nossa sociedade e economia e no entanto, o seu desenvolvimento continuar a ser afectado pelos mais diversos problemas.
De acordo com a minha experiência e conhecimento constato que os projectos de software continuam a ser realizados de forma pouco organizada e com uma elevada taxa de insucesso. São raros os projectos de software que cumprem os prazos e custos orçamentados e produzem software de qualidade.
Julgo, portanto, importante entender o contexto e os factores que determinam o sucesso e qualidade do desenvolvimento de software e procurar definir um sistema que facilite todo o processo de produção.
Dada a ênfase colocada no processo de software e na colaboração eficiente entre os membros da equipa, como elementos determinantes do sucesso dos projectos, tornava-se importante determinar até que ponto as tecnologias de workflow e de groupware podem ser adoptadas para suportar e melhorar o desenvolvimento de software em equipa.
1.2 Enquadramento
Vivemos na sociedade da informação, marcada pelo uso intensivo e crescente da tecnologia. O software é a “alma” de inúmeros sistemas e produtos e a sua procura mundial continua a crescer.
A industria de software é uma área de conhecimento intensivo onde o factor preponderante de sucesso são as pessoas. O sucesso dos projectos de software está intimamente relacionado com a capacidade das equipas de desenvolvimento colaborarem, comunicarem e coordenarem o seu trabalho ao longo de todas as fases do projecto.
Neste contexto de grande importância económica e social do software é muito relevante estudar e definir ferramentas que facilitem e potenciem a eficácia das equipas de projecto.
O ambiente de suporte desenvolvimento de software definido nesta tese procura responder aos requisitos do trabalho de uma equipa de software recorrendo às tecnologias de workflow e groupware.
1.3 Objectivos
O objectivo principal desta dissertação é a especificação da arquitectura de um sistema de trabalho colaborativo de apoio ao desenvolvimento de software em equipa. Este objectivo principal implica a prossecução dos seguintes objectivos:
• Identificar as necessidades associadas ao desenvolvimento de software em equipa, nas suas várias configurações espaço/tempo;
• Descrever as potencialidades das tecnologias de workflow e de groupware e as vantagens quando adoptadas num contexto de desenvolvimento de software;
• Estabelecer os requisitos de uma plataforma de trabalho colaborativo, integrando tecnologias workflow e groupware, capaz de fornecer as facilidades adequadas à gestão e ao desenvolvimento de software em equipa.
1.4 Estrutura do trabalho
A presente dissertação decompõe-se em várias áreas, inicia-se no capítulo 2, com a descrição do contexto moderno de desenvolvimento de software e uma análise dos problemas e factores que determinam a qualidade do software. É descrita a área da engenharia de software e as duas grandes abordagens ao processo de desenvolvimento de software. A primeira abordagem foca-se no processo e entende-o como o factor primordial na determinação do sucesso dos projectos de software. A segunda abordagem entende que a concepção e implementação de software é um esforço colectivo, complexo e criativo e portanto factor determinante, da qualidade do software, são as pessoas e eficiência com que colaboram entre si.
O capítulo 3 foca-se na análise das equipas de desenvolvimento de software. As equipas são a organização dos recursos humanos dos projectos de software. Uma equipa
permite alcançar objectivos impossíveis individualmente, mas também colocam desafios de coordenação. Procura-se descrever os mecanismos e os factores que determinam a eficácia de uma equipa.
Com base no conhecimento descrito nos capítulos 2 e 3, o capítulo 4 consolida um conjunto de requisitos de um possível sistema de suporte ao desenvolvimento de software em equipa. É apresentada uma primeira arquitectura abstracta recorrendo às duas componentes tecnológicas: workflow e groupware.
O capítulo 5 descreve a tecnologia dos sistemas de gestão de workflow. São descritas as evoluções tecnológicas que impulsionaram o seu aparecimento. Este capítulo descreve os conceitos base para entender um sistema de workflow. É apresentada uma arquitectura genérica de um sistema de workflow.
O capítulo 6 aborda a segunda componente tecnológica de um possível sistema de suporte ao desenvolvimento de software em equipa, o groupware. É apresentada a evolução tecnológica que impulsionou o desenvolvimento de aplicações de groupware. As ferramentas de groupware procuram apoiar e tornar mais eficiente o trabalho colaborativo. São apresentadas algumas aplicações de groupware que podem ser úteis para o desenvolvimento de software em equipa.
O capítulo 7 descreve a arquitectura de um possível ambiente de apoio ao desenvolvimento de software em equipa, baseado em tecnologias de workflow e groupware. São apresentadas variações do sistema para os quatros tipos de equipas possíveis. A dissertação termina com a elaboração de um conjunto de conclusões do estudo.
O capítulo 8 termina a tese com a enumeração de um conjunto de conclusões e a descrição de possíveis trabalhos futuros.
Capítulo 2
2 Engenharia de software
As tecnologias de informação e comunicação (TICs) revolucionaram profundamente a forma como trabalhamos, comunicamos e colaboramos. O ritmo de inovação tecnológica das TICs continua a ser acelerado, permitindo ganhos consideráveis de desempenho e produtividade. Estas vantagens conduziram-nos a uma sociedade cada vez mais dependente de complexos sistemas de software [Brereton99] [Boehm00].
O software tornou-se um elemento chave e diferenciador de inúmeros produtos e organizações. Os sistemas de software são fundamentais para o sucesso e funcionamento das organizações e para o progresso da investigação científica e técnica [Marquis06][Sagheb02]. A sua utilização está hoje disseminada por todo o mundo e virtualmente todas as economias dependem, em maior ou menor grau, de sistemas informáticos [Sommerville01,pag.4]. A procura mundial de software continua a crescer diariamente [Sagheb02] aumentando a pressão sobre os fornecedores que se vêem na necessidade de produzir sistemas mais complexos, com qualidade e em prazos mais curtos. Pressman resume assim a importância do software [Pressman00, pag.3]:
“O software tornou-se uma força motriz, é ele o motor que suporta os processos de tomada de decisão. O software está na base da moderna investigação científica e na resolução de complexos problemas de Engenharia. O software é o factor diferenciador dos produtos modernos e dos serviços. O software está incorporado em todo o tipo de sistemas, sejam eles: transportes, médicos, telecomunicações, militares, processos industriais, entretenimento, …a lista é quase interminável. O software é virtualmente omnipresente no mundo moderno e (…) tornar-se-á o catalisador de novos avanços em todos os campos do saber”
Apesar das constantes evoluções tecnológicas e dos inúmeros progressos na área da engenharia de software, o cenário actual de desenvolvimento de software continua a ser caracterizado por uma elevada taxa de insucesso dos projectos informáticos.
Desenvolver um projecto de software é um empreendimento complexo que envolve várias pessoas com perfis e competências distintas. Frederick Brooks no seu livro The Mythical Man-Month descreve como esse esforço se pode transformar numa autêntica “luta num pântano” [Brooks75, pag.4-9]. É fácil um projecto descarrilar quando o trabalho da equipa não é planeado, coordenado e gerido convenientemente e de acordo com os objectivos do projecto.
Apesar das evoluções ao nível dos processos, técnicas e tecnologias de desenvolvimento, o grau de sucesso dos projectos de software continua longe do ideal, e são frequentes as críticas à sua falta de qualidade [Boehm00]. Kraul citando Blazer descreve o software desenvolvido como não fiável, entregue fora dos prazos, difícil de manter, ineficiente e dispendioso [Kraul95]. Continuam, ainda hoje, a colocar-se os seguintes dilemas aos projectos de software [Pressman00, pag.5]:
• Porque demora tanto tempo o desenvolvimento de software? • Porque são tão elevados os custos do seu desenvolvimento?
• Porque não é possível descobrir e eliminar todos os seus erros antes da sua entrega ao utilizador final?
• Porque continua a ser tão difícil medir o progresso do desenvolvimento de software?
A engenharia de software pretende dar uma solução aos problemas dos projectos de software através da aplicação dos princípios e abordagens da Engenharia. Ela preocupa-se com todos os aspectos da sua produção, desde as primeiras etapas de especificação do sistema até à sua manutenção. Segundo Pressman a engenharia de software define-se como [Pressman00, pag.18]:
1. A aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento, operação e manutenção de software;
2. O estudo das abordagens descritas no ponto 1.
Na opinião de Sommerville a engenharia de software tem duas grandes preocupações [Sommerville01, pag.7]:
• A disciplina da engenharia. Os engenheiros constroem sistemas que funcionam, para o efeito eles recorrem a teorias, métodos e ferramentas apropriadas. Durante o esforço de Engenharia procura-se sempre descobrir qual a melhor solução para os problemas, mesmo quando não existem teorias e métodos adequados. O esforço de Engenharia deve ter em conta os constrangimentos financeiros e organizacionais;
• A engenharia de software abarca todos os aspectos da produção de software, não se preocupando apenas com a actividade de desenvolvimento de software, mas também com as actividades de gestão do projecto e de desenvolvimento de ferramentas, métodos e teorias de suporte à produção de software.
O objectivo final é a produção de software de qualidade respeitando as restrições orçamentais e temporais do projecto. Para esse efeito a engenharia de software advoga que a melhor abordagem consiste na adopção de um processo adequado ao projecto e ao seu contexto. O desenvolvimento de software deve ser um esforço organizado e disciplinado, pois a abordagem do programador individual que vai escrevendo código, já não é compatível com o nível de complexidade e de qualidade exigido.
2.1 Processo de desenvolvimento de software
Existem vários processos de desenvolvimento possíveis que definem abordagens e estratégias distintas para um projecto. A motivação para a adopção de um processo de software nasce da convicção que a qualidade do produto final está intimamente ligada ao seu processo de produção, logo a adopção de um processo adequado resultará num desenvolvimento mais eficiente e eficaz [Fugetta00].
Esta é uma abordagem mais clássica, têm surgido novas teorias que advogam que os ciclos de desenvolvimento modernos são hoje incompatíveis com processos formais muito burocráticos. Estas abordagens defendem o uso de processos denominados ágeis, com ciclos de desenvolvimento mais curtos, menos formalismos e uma maior interacção entre a equipa e o cliente.
Apesar das duas correntes, clássica ou ágil, um processo de desenvolvimento caracteriza-se por um conjunto de actividades e produtos resultantes, cujo resultado final é o software [Sommerville01, pag.8]. O processo de desenvolvimento de software define quem faz o quê, quando o faz e como o executa [Fayad97].
2.1.1.1 Actividades genéricas da engenharia de software
Embora não exista um processo de software detalhado e universal, é possível classificar o trabalho de engenharia efectuado em quatro grandes actividades. Estas actividades são comuns a todos os processos [Sommerville01, pag.4-41] [Pressman00, pag.3-47]:
1. Análise dos requisitos. Esta é a fase em que as funcionalidades e restrições do
software são definidas, em que os analistas procuram entender as necessidades do cliente e especificá-las. O objectivo é obter um entendimento mais global e completo dos requisitos do sistema. A preocupação é determinar: qual a informação a processar, as funcionalidades e desempenho requeridos, o comportamento esperado do sistema, as interfaces necessárias, as restrições à concepção e quais os critérios de validação do sistema. Os requisitos chave do sistema são identificados, no entanto os métodos aplicados durante esta fase variarão consoante o paradigma adoptado. Durante esta fase ocorrerão as actividades: engenharia do sistema, planeamento do projecto de software e análise de requisitos. O sucesso desta etapa é fundamental para o sucesso final do sistema.
2. Concepção e desenvolvimento do software. Nesta fase o software que obedece às
especificações de requisitos do sistema é concebido e desenvolvido. São definidos os modelos e estruturas de dados, a forma de implementação dos módulos e funções do sistema, são caracterizadas as interfaces, decide-se como se transformará o desenho do sistema numa linguagem de programação e a especificação dos testes a realizar.
3. Validação do software. Esta fase consiste na validação do software desenvolvido
com o objectivo de assegurar a sua qualidade e o cumprimento dos requisitos do utilizador. São executados testes dos módulos que garantam a qualidade dos vários componentes do sistema. São também realizados testes do sistema que permitem avaliar a correcta integração dos vários módulos e assegurar o cumprimento geral dos requisitos.
4. Evolução do software. O software após estar em produção não é imutável havendo
a necessidade de o alterar, para que obedeça a novos requisitos do negócio, para o aperfeiçoar e para corrigir possíveis erros que escaparam à fase de testes. Pressman define quatro tipos de mudança que podem ocorrer durante esta fase [Pressman00]:
a. Correcção. Mesmo adoptando as melhores práticas de verificação da
qualidade do software, é provável o cliente encontrar defeitos no software. A actividade correctiva visa alterar o software para expurgá-lo dos defeitos;
b. Adaptação. Ao longo do tempo tanto a infra-estrutura tecnológica como os
requisitos de negócio vão-se modificando. A actividade de adaptação visa alterar o software para que ele comporte as alterações no seu ambiente externo;
c. Aperfeiçoamento. O uso do software leva os utilizadores a reconhecer a
necessidade de novas funcionalidades úteis. O aperfeiçoamento do software consiste na modificação do software para comportar estes novos requisitos;
d. Prevenção. O software deteriora-se com a mudança, e por isso, torna-se
necessário agir proactivamente para garantir que o software continue a satisfazer os seus utilizadores. Esta actividade também é designada de reengenharia de software.
Os processos de desenvolvimento de software cobrem estas quatro actividades genéricas, no entanto cada modelo de processo estabelece uma abordagem e estratégia distinta de desenvolvimento. Cabe ao gestor do projecto entender o seu contexto organizacional e as características do projecto e seleccionar o modelo de processo conveniente.
Um processo de software, embora normalmente encarados como especiais e únicos, são também processos [Fugetta00] e desta forma o projecto poderá beneficiar do recurso a tecnologias de workflow e de groupware. A componente de workflow permitirá modelar, controlar e executar um processo definido, atribuindo tarefas e controlando a sua execução. A tecnologia de groupware facilitará a interacção e colaboração do grupo de trabalho. O peso de cada componente na arquitectura de um hipotético sistema de suporte ao desenvolvimento de software variará consoante o processo adoptado.
2.2 Modelos de processos de software
O desenvolvimento de software consiste na resolução de problemas através de um sistema informático, este esforço deve seguir uma estratégia normalmente designada de modelo de processo de software ou paradigma. O objectivo de um modelo de processo de software é determinar a ordem das várias etapas de desenvolvimento de um sistema, a evolução e os critérios de transição de uma etapa para a seguinte.
Existem vários modelos de processos de software possíveis, nesta secção iremos abordar alguns exemplos representativos das duas abordagens, clássica ou ágil. O modelo do processo estabelece uma filosofia de desenvolvimento que deve ser compreendida pela equipa para que a sua aplicação seja bem sucedida.
2.2.1 Queda de água (waterfall)
O modelo em queda de água, também denominado de ciclo de vida clássico, é o mais antigo e mais utilizado paradigma de desenvolvimento. Este modelo sugere uma abordagem sistemática e sequencial ao desenvolvimento de software (ver Figura 1). Este processo inicia-se ao nível do sistema e evolui sequencialmente através da análise, concepção, implementação, teste e manutenção [Pressman00, pag.26-29].
Figura 1 – Modelo queda de água
O modelo em queda de água implica um desenvolvimento sequencial, isto é, inicia-se uma nova fase apenas quando a anterior está terminada. Quando uma fase termina, é normalmente produzido um conjunto de documentos que, após aprovação, constituem a base de trabalho da fase seguinte. O documento de especificação de requisitos produzido na fase de Análise de Requisitos serve de base de trabalho para os engenheiros do sistema que durante a fase de concepção irão delinear a sua arquitectura. Terminada a fase de concepção os programadores constroem o código do sistema respeitando a arquitectura definida na fase de Concepção. Quando a implementação do sistema está concluída inicia-se o esforço de validação do software, este trabalho constitui a fainicia-se de Testes. O processo termina com a colocação do sistema em produção e a sua disponibilização aos utilizadores finais. Análise de requisitos Concepção Implementação Testes Manutenção
O modelo queda de água apresentado implica uma sequência de trabalho linear, existem versões mais evoluídas do processo que permitem interacções entre as fases. Apesar de ser bastante adoptado são apresentadas algumas críticas ao modelo queda de água [Pressman00, pag.29]:
1. Os projectos dificilmente seguem o fluxo sequencial proposto pelo modelo. Apesar de o modelo poder acomodar interacção, fá-lo de forma indirecta, o que pode originar confusão na equipa de desenvolvimento.
2. É muitas vezes difícil o cliente conseguir explicitar todos os requisitos. Este modelo requer isto e tem dificuldade em acomodar a incerteza natural no início do projecto. 3. O cliente tem que ser paciente porque uma versão funcional do sistema apenas
estará disponível muito no fim do projecto.
2.2.2 Modelo da entrega incremental
O desenvolvimento de sistemas de software é um esforço complexo que evolui ao longo do tempo, muitas vezes o negócio e os requisitos do software alteram-se durante o projecto. Neste contexto de tempos de mercado muito exigentes, torna-se inviável entregar o sistema completo apenas no final do processo, é preferível disponibilizar mais rapidamente, ao utilizador, sistemas com funcionalidade limitada. Estes casos exigem a adopção de um processo concebido para lidar com a evolução do software ao longo do tempo.
O modelo da entrega incremental combina o modelo queda de água, aplicado repetidamente, com uma filosofia interactiva. Este modelo consiste na intercalação de vários ciclos de desenvolvimento desfasados, cada ciclo de desenvolvimento resulta numa entrega mais completa do sistema. [Pressman00, pag.34].
Figura 2 – Modelo entrega incremental
Análise Concepção Implementação Teste Entrega 1º incremento
Análise Concepção Implementação Teste Entrega 2º incremento
Quando se adopta este tipo de processo num projecto, o primeiro incremento consiste na entrega da funcionalidade básica do sistema, as outras funcionalidades são entregues em futuros incrementos.
A avaliação do sistema entregue no fim de um ciclo de desenvolvimento serve de base de trabalho para o planeamento da próxima fase. Este planeamento engloba a alteração do núcleo do sistema para melhor satisfazer as necessidades dos utilizadores e dotar o sistema de novas funcionalidades.
O modelo de entrega incremental tem a vantagem de permitir ao utilizador final contactar, mais rapidamente, com o software e avaliá-lo. Este modelo é também adequado quando os recursos do projecto são insuficientes para desenvolver uma versão completa num único ciclo de desenvolvimento. Cada ciclo de desenvolvimento neste modelo é mais curto e mais limitado logo requer menos recursos [Pressman00, pag.35].
2.2.3 Espiral
O modelo em espiral foi originalmente proposto por Boehm. Este é um modelo evolutivo do processo de desenvolvimento de software, o modelo em espiral conjuga a natureza iterativa da prototipagem com a abordagem mais controlada e sistemática do modelo do ciclo de vida [Pressman00, pag.35-40].
O modelo em espiral permite desenvolver rapidamente versões incrementais do software. As primeiras iterações da espiral podem produzir apenas um modelo ou protótipo, consoante se vão realizando mais iterações o software final torna-se mais complexo e completo.
Segundo Pressman, o modelo em espiral é composto por um conjunto de seis grandes áreas de actividade, a saber [Pressman00, pag.35-36]:
• Comunicação com o cliente é o conjunto de tarefas levadas a cabo com o objectivo de estabelecer uma comunicação efectiva com o cliente;
• Planeamento que compreende as tarefas de definição dos recursos a utilizar, os prazos e outra informação relacionada com o projecto;
• Análise de risco é o conjunto de tarefas executadas com o intuito de avaliar os riscos técnicos e de gestão;
• Engenharia engloba as tarefas levadas a cabo com o objectivo de construir uma ou mais representações da aplicação;
• Construção e disponibilização é o conjunto de tarefas que é necessário realizar para desenvolver, testar, instalar e fornecer apoio ao utilizador (por exemplo, documentação e formação);
• Avaliação do cliente engloba as actividades necessárias à obtenção de uma avaliação do cliente sobre o software entregue ou representações produzidas durante a fase de construção e disponibilização.
Cada uma destas áreas de actividade é composta por um maior ou menor número de tarefas consoante a complexidade e a dimensão do projecto de software. Projectos de software maiores contém um maior número de tarefas, o objectivo é atingir um nível mais elevado de disciplina.
A primeira iteração da espiral, efectuada pela equipa de desenvolvimento do software, resulta na produção de uma especificação do produto. As iterações seguintes são usadas para produzir um protótipo e versões mais completas do software. Cada iteração implica uma nova passagem pela fase de planeamento, desta forma é possível proceder aos ajustes necessários ao plano do projecto de software. O custo e os prazos vão também sendo ajustados de acordo com o feedback produzido pelo cliente.
Ao contrário dos modelos de processos clássicos que terminam quando o software é entregue ao cliente, o modelo em espiral pode ser adaptado para cobrir toda a vida do software.
Pressman defende que o modelo em espiral é uma abordagem realista ao desenvolvimento de projectos de grande dimensão porque o software evolui com o progresso do processo. O engenheiro de software e o cliente podem compreender e reagir melhor aos riscos. O modelo em espiral advoga o uso da prototipagem como uma medida eficaz para a redução do risco [Pressman00, pag.37].
Os modelos de processos de software analisados podem ser modelados e executados recorrendo a um sistema de workflow. No entanto, é impossível detalhar até à mais elementar tarefa um processo de software, este facto implica que o sistema de workflow adoptado deve ser capaz de lidar com processos dinâmicos. O trabalho de equipa desenvolvido pode ser facilitado com o recurso a ferramentas de groupware. A utilização de mensagens instantâneas para facilitar a comunicação entre os membros da equipa e os utilizadores, o uso de fóruns de discussão e de agendas de grupo para aumentar a visibilidade do trabalho executado e para a execução de tarefas são alguns exemplos de aplicações de groupware úteis ao desenvolvimento de software.
2.3 Processos ágeis de desenvolvimento de software
2.3.1 Extreme Programming
Extreme Programming (XP) é um dos novos processos ágeis de desenvolvimento de software. O XP é uma abordagem ao desenvolvimento de software adequada a equipas de dimensão pequena ou média [Smith01].
O conceito de XP foi proposto inicialmente por Kent Beck. O XP foi desenvolvido com o objectivo de satisfazer as necessidades de pequenas equipas co-localizadas de desenvolvimento de software envolvidas em projectos com requisitos vagos e em constante modificação [Newkirk02] [Smith01]. Esta abordagem coloca a ênfase no trabalho de equipa e no envolvimento do cliente durante todo o processo de desenvolvimento [Smith01].
A comunicação é fundamental num projecto de XP, é muito importante para o seu sucesso que se estabeleçam fluxos de comunicação entre o cliente e a equipa de desenvolvimento e entre os membros da equipa [Smith01]. O feedback sobre a evolução do processo é obtido recorrendo a testes frequentes, realizados desde muito cedo. Ao contrário dos processos de desenvolvimento mais clássicos que testam o sistema desenvolvido apenas nas fases finais do projecto, o XP procura rapidamente começar a testar o sistema desenvolvido.
O XP estabelece quatro valores que devem ser aplicados na execução das actividades de um processo de desenvolvimento de software, a saber [Newkirk02]:
• Comunicação – A comunicação é o aspecto mais importante num esforço de construção de software. Muitos dos problemas das equipas de desenvolvimento de software têm a sua origem numa comunicação deficiente entre os membros da equipa, os clientes e os gestores.
• Simplicidade – O objectivo é desenvolver sempre o software funcional e mais simples possível para o desenho actual do sistema. O programador não deve tentar antecipar o futuro na sua programação porque não é possível prever quais serão as alterações aos requisitos.
• Feedback – As actividades do XP estão concebidas com o intuito de fornecer um feedback frequente e atempado. Práticas de XP como: pequenas entregas, integração contínua e testes fornecem um feedback claro sobre o projecto.
• Coragem – O XP ao contrário de outras metodologias defende uma postura agressiva dos participantes no processo.
Existem cinco práticas fundamentais num processo de desenvolvimento de software de acordo com o XP. São elas: a programação em pares (pair programming), refactoring, teste, integração contínua e a concepção evolutiva do sistema [Smith01].
2.3.1.1 Programação em pares
A programação em pares é a prática em que dois programadores trabalham em conjunto no desenvolvimento de um módulo. Ambos os programadores vão repartindo entre si as tarefas de desenvolvimento do módulo. Esta equipa de duas pessoas normalmente divide-se da divide-seguinte forma: um membro faz a programação ou definição de casos de testes enquanto o segundo membro faz a revisão do trabalho executado e vai pensando em formas mais eficientes de codificação [Smith01].
A proximidade física entre os dois elementos e o foco num único módulo promove a discussão e a partilha de ideias. Verifica-se que o código desenvolvido em programação em pares possui uma menor taxa de defeitos, é mais compacto e satisfaz melhor as necessidades do cliente [Smith01].
A programação em pares pode ser potenciada e facilitada através do uso de ferramentas de groupware, por exemplo editores que permitam várias pessoas alterarem o mesmo código, fóruns de discussão que facilitem a discussão de ideias e mensagens instantâneas que facilitem a comunicação entre os dois membros. O uso de ferramentas de groupware possibilita a programação em pares mesmo que as duas pessoas estejam geograficamente distantes.
2.3.1.2 Refactoring
Refactoring é o esforço contínuo de concepção de um módulo com o objectivo de aproveitar melhor as técnicas de programação, criar módulos reutilizáveis mais simples e eficientes [Smith01].
O refactoring pode ocorrer em qualquer fase do processo de desenvolvimento. O esforço de redesenho dos módulos beneficia de técnicas de programação orientadas aos objectos e da utilização de padrões de programação. O objectivo do refactoring é desenvolver módulos com uma estrutura interna forte e consistente.
2.3.1.3 Testes
Os testes em XP implicam: testes dos módulos pelos seus programadores, testes funcionais realizados pelos utilizadores e o recurso a testes automáticos [Smith01]. O objectivo é produzir módulos livres de defeitos em cada nova versão do software.
Testar em XP envolve dois tipos de testes. O primeiro tipo de teste é o teste do módulo. Estes testes são concebidos pelos programadores que os desenvolvem para cada unidade que implementaram e são redefinidos e expandidos sempre que nova funcionalidade é introduzida [Smith01].
O segundo tipo de teste é o teste funcional. O objectivo do teste funcional é assegurar a correcta integração dos módulos e a satisfação dos requisitos do cliente. Estes testes são da responsabilidade dos utilizadores ou clientes.
A execução dos testes por parte dos utilizadores pode implicar a intervenção da equipa de desenvolvimento, seja para esclarecer dúvidas ou avaliar em conjunto com o cliente do normal funcionamento do sistema. As mensagens instantâneas e o correio electrónico são meios expeditos de comunicação entre os diversos intervenientes no processo.
2.3.1.4 Integração contínua
A integração contínua consiste na integração dos novos módulos desenvolvidos com o código já existente. A integração contínua possibilita a incorporação de novo código com o código já testado exaustivamente.
O uso de ferramentas de controlo de versões pode prestar uma enorme ajuda à gestão da mudança do software.
2.3.1.5 Concepção evolutiva
A concepção evolutiva implica que alterações ao desenho do software são introduzidas e implementadas rapidamente pelas equipas de programação. A equipa de programação define o objectivo da próxima iteração e implementa-a. A concepção evolutiva do software aumenta a velocidade do seu desenvolvimento e a sua flexibilidade. É possível desenvolver versões da aplicação e rapidamente introduzir mudanças que reflictam alterações nos requisitos.
As mudanças às especificações podem ser atribuídas à equipa responsável pelo seu desenvolvimento através de um sistema de workflow ou de um formalismo estabelecido pela equipa, como por exemplo o envio de um correio electrónico do chefe de projecto.
O XP é um processo ágil de desenvolvimento de software que se serve de técnicas evoluídas de programação e de uma organização do trabalho que permite uma rápida adaptação aos requisitos do cliente. O XP implica uma forte capacidade de comunicação entre os pares de programação, entre os clientes/utilizadores e a equipa de desenvolvimento e entre toda a equipa de desenvolvimento. O XP adequa-se ao
desenvolvimento de projectos de pequena dimensão em que os requisitos são vagos ou voláteis.
O XP tem características diferentes dos processos mais rígidos analisados previamente. Um sistema de apoio ao desenvolvimento de software baseado em XP poderá beneficiar do uso de componentes de workflow e groupware, no entanto o peso de cada uma destas componentes será distinto dos processos clássicos. Um método ágil como o XP requer uma maior presença de ferramentas de comunicação e de colaboração (groupware).
2.3.1.6 O processo XP
O ciclo de vida de um processo de XP é composto por cinco fases: exploração, planeamento, iterações para a versão final, passagem a produção, manutenção e morte [Abrahamsson02].
Durante a fase exploração o cliente escreve os vários casos que pretende ver contemplados na primeira versão do sistema. Cada caso descreve uma funcionalidade a ser adicionada ao sistema. Ao mesmo tempo a equipa de desenvolvimento investiga e familiariza-se com as ferramentas de desenvolvimento e as práticas que serão usadas no projecto. A tecnologia adoptada será testada e as várias arquitecturas do sistema exploradas com o objectivo de construir um protótipo. Esta fase tem a duração de algumas semanas a alguns meses.
A fase de planeamento estabelece a prioridade dos vários casos desenvolvidos pelo cliente e define quais irão integrar a pequena versão do sistema. Os programadores estimam o esforço necessário para cada caso e acorda-se um calendário de entrega. Este calendário normalmente não excede os dois meses.
A fase de iterações para a versão final do sistema consiste em várias iterações que decompõem a funcionalidade do sistema em pequenas partes a serem implementadas em intervalos de uma a quatro semanas. A primeira iteração cria um sistema com a arquitectura total. No fim de cada iteração são efectuados testes funcionais ao sistema.
A fase de passagem a produção implica a realização de novos testes e a verificação do desempenho do sistema a entregar ao cliente. Nesta fase podem surgir novas alterações tornando-se necessário decidir se as mesmas serão ou não englobadas nesta entrega.
A fase manutenção consiste num conjunto de actividades que têm como objectivo manter o sistema entregue em normal funcionamento em produção.
A fase de morte ocorre quando o cliente já não possui mais casos a implementar no sistema. Isto implica que o sistema satisfaça as necessidades do cliente. Nesta fase do processo XP é feita a documentação do sistema pois já não serão feitas alterações à
arquitectura e ao código do sistema. Esta fase pode também ocorrer se o sistema não se revela capaz de satisfazer os requisitos do cliente ou se está a tornar-se demasiado caro.
2.4 Actividades da engenharia de software
Entre os vários modelos de processo de software, todos eles advogam uma abordagem diferente ao esforço de conceber e programar software, no entanto existe um conjunto de actividades comuns a todos eles, a saber [Pressman00, pag.3-47] [Sommerville01, pag.43-68]: • Engenharia de Requisitos; • Concepção do software; • Construção do software; • Validação do software.
2.4.1 Engenharia de requisitos
Conceber um produto e garantir que ele é bem sucedido, implica um conhecimento preciso das características pretendidas pelos seus futuros utilizadores. O software não é uma excepção a esta regra, ao embarcar-se num projecto de desenvolvimento a primeira etapa consiste na identificação das funcionalidades pretendidas e das restrições aplicáveis ao software e ao seu processo de desenvolvimento.
Desenvolver software é uma tarefa mental, colectiva, criativa e complexa. O processo de concepção e de desenvolvimento de software pode ser árduo e recheado de complicados problemas técnicos, políticos e organizacionais; cabe ao engenheiro de software lidar e resolver todos estes desafios eficazmente.
Pressman citando Howard Baetjer descrevia assim o processo de desenvolvimento de software [Pressman00, pag.17]:
“O software tal como o capital é uma corporização de conhecimento, e porque esse conhecimento está inicialmente disperso, tácito, latente e incompleto em larga escala, o desenvolvimento de software é um processo de aprendizagem social. O processo é um diálogo em que o conhecimento que se deve tornar software é reunido e materializado numa aplicação. (…) É um processo iterativo em que cada ferramenta serve de meio de comunicação, e cada nova iteração permite levantar mais conhecimento útil das pessoas envolvidas”
A anterior citação demonstra a natureza mental, colectiva e social do trabalho de desenvolvimento de software, a importância e as dificuldades inerentes à obtenção do conhecimento necessário à sua correcta implementação. Evidencia a existência de diferentes intervenientes e partes interessadas em que cada uma delas possui uma parte do conhecimento total. Demonstra que é necessário atingir um entendimento global e completo do que se pretende, mas esse esquema mental do software só se atinge por etapas, em que se vai refinando o conhecimento obtido.
A engenharia de requisitos envolve a análise e a especificação dos requisitos do software. Esta fase estabelece a ponte entre os requisitos do sistema e a fase de concepção do software. Esta fase é vital para o sucesso final do projecto, no entanto o elevado volume de comunicação entre os intervenientes e a ambiguidade presente potencia as más interpretações e os desentendimentos entre os intervenientes [Pressman00, pag.250-257].
Num processo de desenvolvimento de software existem diversas partes interessadas e utilizadores finais. Todos eles possuem necessidades ou imposições que devem ser satisfeitas pelo software. Alguns exemplos típicos de fontes de requisitos são [Swebok04,pag.35]:
• Utilizadores. São as pessoas que vão utilizar o sistema. Os utilizadores do software são muitas vezes um grupo heterogéneo, composto por pessoas de diferentes funções e requisitos;
• Clientes. São as pessoas que patrocinaram o sistema ou que representam o mercado alvo do sistema;
• Analistas de mercado. Para produtos de venda em massa no mercado, não é possível interagir com o cliente final, nestes casos as pessoas do marketing substituem o cliente na determinação das funcionalidades requeridas do software; • Reguladores. Certas actividades económicas como a banca, os seguros, a
electricidade são reguladas. O software desenvolvido para estes sectores deve obedecer aos requisitos impostos pelas entidades reguladores;
• Engenheiros de software. Estas pessoas têm um interesse legítimo em beneficiar com o desenvolvimento do sistema e podem influenciar algumas decisões de arquitectura e concepção do software.
Para além destas fontes de requisitos humanas, alguns requisitos podem derivar de dispositivos ou outros sistemas com os quais o software deve interagir. Entender todos os
requisitos, de todos os interessados no sistema, e sistematizá-los é essencial para garantir o sucesso do software.
O levantamento dessas necessidades é um processo de comunicação entre as partes envolvidas. Um dos princípios base para um bom processo de engenharia de requisitos é uma boa comunicação entre as pessoas que vão desenvolver o sistema e os seus utilizadores [Swebok04, pag.36].
Não é possível assegurar um entendimento total, detalhado e preciso numa única etapa. Várias iterações serão necessárias e a cada nova iteração o conhecimento adquirido será refinado e surgirão novas dúvidas e inconsistências.
Esta é a actividade que mais contribui para o sucesso ou insucesso de um projecto de software, mas é também uma das mais difíceis de concretizar. Segundo Pressman, alguns dos problemas e obstáculos à engenharia de requisitos são [Pressman00, pag.252]:
• Problemas de âmbito. As fronteiras do sistema podem estar mal definidas ou os utilizadores/clientes podem especificar detalhes demasiados técnicos que podem confundir, em vez de clarificar, os objectivos do sistema.
• Problemas de entendimento. Os clientes/utilizadores não estão suficientemente certos daquilo que necessitam; possuem um fraco conhecimento das capacidades e limitações do seu ambiente computacional; não possuem um conhecimento completo do domínio do problema; têm dificuldades de comunicação com os engenheiros de software; omitem informação que consideram óbvia; especificam requisitos que entram em conflito com requisitos de outros utilizadores/clientes; desejam requisitos que são ambíguos ou não confirmáveis.
• Problemas de volatilidade. Os requisitos alteram-se ao longo do tempo.
É importante assegurar que especificação do sistema satisfaz cabalmente as necessidades dos seus utilizadores. A melhor solução, de acordo com Pressman, é a adopção de um sólido processo de engenharia de requisitos [Pressman00, pag.252].
2.4.1.1 O que é um requisito?
Requisitos são o conjunto das funcionalidades e condicionantes do sistema. No seu nível mais básico um requisito é uma propriedade que o software deve possuir para resolver um problema do mundo real [Swebok04, pag.33].
A engenharia de requisitos é o processo de procura, análise, documentação e verificação dessas funcionalidades e condicionantes [Sommerville01,pag.98]. Um dos
principais objectivos da engenharia de requisitos é determinar quais os componentes do sistema e os requisitos de cada desses componentes [Swebok04, pag.33-35].
Os requisitos do software podem ser especificados em diferentes níveis de detalhe. Em alguns casos os requisitos podem consistir numa descrição abstracta de alto nível de uma funcionalidade ou de uma restrição; noutros casos, um requisito pode ser uma descrição detalhada, ou matematicamente formal.
A existência de vários níveis de detalhe de requisitos é explicada pela necessidade de os comunicar de forma suficientemente abstracta e que não implique uma solução predefinida. As definições detalhadas dos requisitos servem para comunicar o que software irá fazer.
Alguns problemas que ocorrem durante o processo de engenharia de requisitos têm na sua origem a falha em distinguir entre os dois níveis de detalhe. Sommerville denomina como requisitos do utilizador todos os requisitos de abstractos e de alto nível e como requisitos de sistema os requisitos detalhados e formais [Sommerville01, pag.98-99].
Durante a fase de engenharia de requisitos pode ser útil produzir uma especificação do sistema. Esta especificação é orientada ao desenvolvimento do software e serve de ponte entre a actividade de engenharia de requisitos e a actividade de concepção do software.
A existência de níveis distintos de especificação dos requisitos permite comunicar a informação sobre o software a tipos diferentes de utilizadores. Os requisitos podem ser decompostos em:
• Requisito funcional. Um requisito funcional descreve uma determinada funcionalidade que deve ser implementada pelo sistema.
• Requisito não funcional. Um requisito não funcional é uma restrição ou condicionante da solução. Exemplos de requisitos não funcionais: desempenho do software, manutenção, segurança, fiabilidade, etc.
Processo de engenharia de requisitos
Conceber e implementar software que cumpra os requisitos do cliente implica que a equipa responsável pelo seu desenvolvimento seja capaz de proceder ao seu levantamento, análise e especificação.
O processo de engenharia de requisitos é o conjunto de actividades necessárias para a criação e manutenção do documento de especificação de requisitos do projecto. Segundo Sommerville um processo de engenharia de requisitos é composto por quatro grandes
actividades genéricas [Sommerville01, pag.122-145]: estudo de viabilidade, levantamento e análise dos requisitos, especificação e documentação dos requisitos e validação dos requisitos.
O estudo de viabilidade é a primeira actividade de um processo de engenharia de requisitos. Todos os projectos de novos sistemas devem iniciar-se pelo estudo de viabilidade. Do estudo de viabilidade deve resultar um documento aconselhando ou desaconselhando a continuação do projecto. O estudo de viabilidade deve responder as seguintes questões [Sommerville01, pag.123]:
1. O sistema contribui para a prossecução dos objectivos globais da organização? 2. O sistema pode ser implementado com a tecnologia actual respeitando o custo e
prazo estipulados?
3. O sistema pode ser integrado com outros em exploração?
A elaboração de um estudo de viabilidade implica a identificação e análise de informação e a sua consolidação num relatório. As fontes de informação úteis para o estudo de viabilidade são diversas e incluem: os gestores dos departamentos que utilizarão o sistema, os engenheiros de software, especialistas em tecnologia e os utilizadores finais [Sommerville01, pag.123].
Determinada a viabilidade do sistema, o processo de engenharia de requisitos avança para a identificação e análise dos requisitos. Durante esta fase a equipa de analistas de sistemas trabalha em conjunto com os utilizadores com o intuito de determinar: o domínio do software, as funcionalidades que ele deve fornecer, o desempenho requerido do sistema, as restrições de hardware, etc.
A identificação e análise dos requisitos envolve a participação de diferentes pessoas da organização, desde que elas possuam um interesse real directo ou indirecto no sistema em desenvolvimento. Esta fase é essencial para assegurar a qualidade do software final, no entanto é uma das fases mais complicadas do processo. São várias as razões que dificultam esta actividade [Sommerville01, pag.124]:
1. Os intervenientes muitas vezes não sabem exactamente o que pretendem do software, são apenas capazes de expressar os seus desejos muito genericamente; 2. Os intervenientes expressam os seus requisitos usando os seus próprios termos e
baseados no seu conhecimento implícito do negócio. A compreensão dos requisitos por parte dos engenheiros de software é dificultada porque eles não possuem o mesmo domínio do negócio;
3. Intervenientes diferentes possuem requisitos diferentes e expressam-nos distintamente. Os analistas de sistemas devem determinar todas as possíveis fontes de requisitos;
4. Factores políticos desempenham um papel importante nos requisitos do sistema. Alguns requisitos podem ser exigidos porque conferirão maior poder a um utilizador ou grupo de utilizadores;
5. O ambiente de negócio altera-se durante o processo de análise de requisitos levando inevitavelmente à redefinição das prioridades dos requisitos. Podem também surgir novos requisitos até ao momento desconhecidos ou não desejados.
Um processo de análise e de levantamento de requisitos é iterativo por natureza. A cada nova iteração o analista vai aperfeiçoando o seu entendimento do sistema, das necessidades e desejos dos clientes.
A fase engenharia de requisitos caracteriza-se por uma intensa comunicação entre diversos intervenientes, o recurso a ferramentas de groupware que facilitem a comunicação directa entre as pessoas e a ferramentas de estruturação e de registo de reuniões pode revelar-se bastante útil para o sucesso do projecto.
2.4.2 Concepção do software
A fase de concepção do software é executada após a fase de engenharia de requisitos. O processo de concepção do software é iterativo e consiste na tradução dos requisitos do software para representações que facilitem a sua codificação [Pressman00, pag.330-332].
Nesta fase do processo são definidas: a arquitectura, os módulos, as interfaces e outras características do sistema [Swebok04, pag.51-52]. Durante a fase de concepção do software os requisitos do sistema são analisados com o intuito de produzir uma especificação da arquitectura interna e da organização do sistema que permita a sua futura construção. O processo de concepção não é um processo rígido, mas baseia-se nas capacidades criativas, nas experiências passadas, na percepção do que é “bom software” e num compromisso total com a qualidade [Pressman00,pag.333]. A fase de concepção culmina com a definição da arquitectura do sistema.
O processo de concepção da arquitectura do software preocupa-se com a identificação dos seus principais componentes e das comunicações existentes entre eles. Sommerville citando Bass identifica as três vantagens da produção de uma arquitectura explícita do sistema [Sommerville01, pag.216]:
1. Comunicação com as partes interessadas. Uma representação de alto nível da arquitectura do software pode ser utilizada como base de discussão com todas as partes interessadas no software;
2. Análise do sistema. Definir uma arquitectura explícita do sistema nas primeiras etapas do desenvolvimento do software significa que algum esforço de análise foi levado a cabo pela equipa de desenvolvimento. As decisões de arquitectura tomadas terão um profundo impacto na capacidade do software responder a requisitos de desempenho, fiabilidade e facilidade de manutenção;
3. Reutilização em grande escala. Um desenho de um sistema é uma representação compacta e utilizável da organização de um sistema e das suas interacções. Esta arquitectura pode ser reutilizado noutros sistemas com requisitos semelhantes.
Durante o processo de concepção do software o sistema é decomposto em módulos e são definidas as funcionalidades de cada módulo e as interfaces entre os diferentes módulos do sistema. São produzidos modelos que definem a estrutura dos módulos do software e a estrutura dos dados. Embora cada projecto de software possua a sua própria abordagem ao processo de concepção do software é comum a execução das seguintes tarefas [Sommerville01, pag.216-217]:
1. Estruturação do sistema. O sistema é decomposto num conjunto de subsistemas em que cada subsistema é um módulo de software independente. São identificados os fluxos de comunicação entre os módulos;
2. Modelação do controlo. É estabelecido um modelo das relações de controlo entre as partes componentes do sistema;
3. Decomposição modular. Cada subsistema identificado é decomposto em módulos. O arquitecto de software define quais os tipos de módulos e as suas relações.
Estas actividades não são normalmente executadas em sequência, mas são antes intercaladas e refinadas. Uma decisão tomada numa fase pode influenciar ou implicar a redefinição dos resultados de outras fases.
A definição de uma boa arquitectura do software é um factor crítico de sucesso para um projecto de software [Buhrer03]. Num projecto de desenvolvimento de software não é possível validar a qualidade da arquitectura definida nas primeiras fases do processo,
em outras áreas de engenharia o engenheiro pode servir-se de teorias para validar a qualidade da sua concepção do sistema, mas num projecto de software isto só é possível nas fases de testes do software [Buhrer03]. Este facto implica que algum do trabalho executado durante a fase de concepção do sistema pode ter que ser revisto futuramente se os testes ao software demonstrarem que as decisões tomadas não são as mais adequadas.
2.4.3 Construção do software
Após as fases de engenharia de requisitos e de concepção do sistema é chegada a altura de proceder à sua construção. A construção do software é uma actividade fundamental do processo de engenharia de software porque o objectivo final do processo de desenvolvimento é produzir software de qualidade que satisfaça as necessidades do utilizador.
Baseando-se nos modelos e especificações produzidas nas fases anteriores, cabe agora aos engenheiros de software materializar esse conhecimento em software. No entanto, a fase construção do software não se limita a uma simples tradução das especificações para uma determinada linguagem de programação. Durante a fase de construção do software a equipa de programadores tem que lidar e resolver um conjunto de importantes problemas de engenharia.
A construção do software implica que os programadores sejam lógicos, precisos e exaustivos para que as suas representações sejam correctamente interpretadas e executadas pelo computador. É um diálogo que se estabelece entre a máquina fiável, sistemática e rápida a executar e o programador humano que é criativo e introduz novas formas de resolver os problemas.
A construção do software está intimamente relacionada com a concepção do sistema, as especificações produzidas pela fase de concepção do software são utilizadas como base para a construção do software. Após a decomposição do sistema em pequenos subsistemas inicia-se a fase da sua construção.
A fronteira entre a concepção do software e a fase da sua construção não é muitas vezes clara [Swebok04, pag.63]. Em primeiro lugar a construção do software é fortemente afectada pela dimensão do sistema a desenvolver. Um projecto pequeno pode não necessitar de uma fase explícita de concepção, no entanto um projecto de grandes dimensões pode implicar uma grande interacção entre as equipas de concepção e de construção do software. Em segundo lugar muitas das técnicas aplicadas durante a fase de concepção são também úteis durante a fase de construção, por exemplo a decomposição de
um problema em partes mais pequenas é muito utilizada na programação [Swebok04, pag.52]. Em terceiro lugar, as técnicas de concepção de sistemas são conjecturais e implicam uma determinada aproximação à resolução dos sub-problemas, essas aproximações podem revelar-se erradas durante a construção do software implicando a realização de acções correctivas.
A concepção e a construção do software requerem ambas competências de resolução de problemas, mas com ênfases diferentes. Na fase de concepção a ênfase é colocada na decomposição do sistema em módulos mais pequenos, enquanto na fase de construção o foco é colocado na capacidade de encontrar uma solução completa e funcional para o problema.
A construção do software pode ser manual ou automatizada. A construção manual do software é a forma mais habitual de implementar, significa que os problemas são resolvidos com o recurso a uma linguagem de programação que o computador pode executar. Os programadores devem ser pessoas com uma elevada capacidade analítica, capazes de decompor os problemas, e com a capacidade de antever como as suas implementações se modificarão com o tempo. A responsabilidade de implementar os módulos é distribuída pelos programadores. Cada programador tem a seu cargo a programação de um ou mais módulos usando como base a especificação produzida durante a fase de desenho do sistema. A construção automatizada consiste na utilização de geradores de código que aceleram o processo substituindo-se aos programadores.
Uma equipa de construção de software é normalmente composta por várias pessoas com competências técnicas relevantes nas tecnologias adoptadas no projecto. A responsabilidade pela divisão do trabalho pelos vários programadores é do chefe de projecto. Os programadores servem-se das especificações produzidas na fase de concepção para determinarem qual a melhor codificação para o módulo em causa. Os módulos codificados têm interacções e relações entre si, este facto implica que uma alteração no código de um módulo possa afectar seriamente o funcionamento de outros módulos. É muito importante que os programadores comuniquem entre si e estejam conscientes do impacto que o seu trabalho pode ter em outros módulos.
O esforço de construção do software é um trabalho criativo e colectivo, a qualidade do software desenvolvido implica competências técnicas adequadas dos elementos da equipa e capacidade de comunicação e colaboração.
Durante a execução das tarefas de codificação é normal surgirem ao programador dúvidas sobre algum aspecto do sistema. O correcto esclarecimento destas dúvidas
possibilita uma codificação de maior qualidade. É importante que qualquer membro da equipa seja capaz de comunicar directamente com a pessoa mais capaz de esclarecer a dúvida. As mensagens instantâneas e o correio electrónico podem revelar-se ferramentas muito úteis para o contacto directo com outros intervenientes no processo.
2.4.4 Validação do software
A validação do software é uma actividade essencial de um processo de engenharia de software porque de nada adianta desenvolver especificações detalhadas e produzir código muito elegante se o software final não cumpre os requisitos requeridos.
A validação do software consiste na avaliação da sua qualidade e indirectamente no seu aperfeiçoamento, através da identificação de falhas e da sua reparação [Swebok04, pag.73]. A importância das actividades de validação e teste do software não pode ser menosprezada. Pressman citando Deutsch refere-se à actividade de validação do software da seguinte forma [Pressman00, pag.426]:
“O desenvolvimento de sistemas de software envolve uma série de actividades produtivas em que as oportunidades de introdução de erros humanos são enormes. Os erros podem ocorrer no início do processo quando os objectivos do projecto são mal ou imperfeitamente definidos, podem também ocorrer na fase de desenho e implementação … dada a incapacidade humana de comunicar perfeitamente o desenvolvimento de software tem que ser acompanhado de uma actividade de validação do software.”
O software é o produto de um esforço humano realizado em equipa que como todos os empreendimentos humanos está sujeito ao erro, muitas vezes introduzido no software por falhas de comunicação entre os membros da equipa de desenvolvimento. As falhas de comunicação podem ser atenuadas ou eliminadas através da comunicação directa entre os membros da equipa e todos os intervenientes no processo de desenvolvimento. O uso de ferramentas de groupware pode ser útil para facilitar a comunicação entre as pessoas.
Porque o processo de desenvolvimento não é imune ao erro humano é necessário dotá-lo de actividades que permitam detectá-lo e corrigi-lo atempadamente. O esforço de teste e verificação do software denomina-se validação do software. Validação do software é o nome dado aos processos de análise e verificação que asseguram que um determinado software está conforme a sua especificação [Sommerville01, pag.420].
As actividades de validação e teste do software cobrem todo o ciclo de vida do processo, começam com a revisão dos requisitos e prosseguem para a validação da arquitectura e da implementação do software e incluem a realização de testes ao software.
A validação do software é realizada através da execução de um conjunto de testes que pretendem aferir o grau de conformidade do software com os requisitos e a sua qualidade. A fase de validação do software pode ser executada, em projectos de pequena dimensão, pela própria equipa que programou o sistema; no entanto em projectos de maior dimensão é comum possuir uma equipa de testes dedicada à validação do software. Entre a equipa de desenvolvimento do software e a equipa de testes estabelecem-se fluxos de comunicação e de trabalho, os módulos desenvolvidos têm que ser testados de acordo com as especificações e os resultados dos testes devem ser comunicados à equipa de desenvolvimento. Quando a execução de um teste detecta um erro no software isso implica que esse módulo terá que ser corrigido pelo programador ou equipa de programadores que o desenvolveu.
