Introdução à Engenharia de Software

9cm x 24cm

14,5mm

16,7cm x 24cm

16,7cm x 24cm

9cm x 24cm

Sérgio Guerreiro

Sérgio Guerreiro As ações que executamos ao longo do nosso dia a dia passam, inevitavelmente, de forma direta ou indireta, pela utilização de aplicações de software. Neste contexto complexo em que estamos inseridos, o estudo e a compreensão da dinâmica de funcionamento da engenharia de software são fundamentais para suportar a conceção, a implementação e a operacionalização da maior parte dos processos de negócio empresariais em empresas públicas ou privadas.

C

M

Aprenda os passos do desenvolvimento de um compilador. Todo o processo é exemplificado, em C e Java, para uma linguagem de exemplo simples, com recurso às ferramentas lex, yacc, antlr e burg.

Y

CM

MY

CY

CMY

K

Aprenda as regras e boas práticas na análise, conceção e desenvolvimento de aplicações orientadas pelos objetos, através de vários projetos de software e exercícios analisados e implementados em Java.

Este livro, com múltiplos exemplos práticos, apresenta as bases e os conceitos que permitem compreender e aplicar as várias fases do desenvolvimento iterativo de uma boa interface utilizador.

Destinado aos estudantes do Ensino Superior nas disciplinas de Engenharia de Software, Análise de Sistemas de Software, Gestão de Projetos, entre outras, e a todos os profissionais envolvidos em projetos de desenvolvimento de software, como por exemplo gestores de projeto, programadores, testers, analistas, arquitetos de software ou operadores, este livro é ainda acessível a todas as pessoas interessadas em conhecer os conceitos essenciais usados pela indústria contemporânea do desenvolvimento de software.

Esta obra disponibiliza ainda a correspondência dos principais termos técnicos entre o português europeu, o português do Brasil e o inglês.

Etapas do processo de desenvolvimento de software.

Casos práticos que facilitam a compreensão da matéria através de casos reais do quotidiano.

Este livro apresenta-nos:

. . . . . . . .

A engenharia de software; Os processos de desenvolvimento de software ; A gestão do processo de desenvolvimento de software – a etapa transversal; A engenharia de requisitos – a etapa de comunicação; A análise e desenho do produto de software – a etapa conceptual; A codificação do produto de software – a etapa tecnológica; A verificação e validação por testes ao produto de software; A manutenção do produto de software.

Sérgio Guerreiro

Uma obra que ajuda estudantes e profissionais a compreenderem os sistemas de gestão de bases de dados relacionais. Com apresentação dos conceitos fundamentais, inclui variados exemplos e exercícios.

Este livro apresenta: por um lado, a conceptualização dos fundamentos da engenharia de software, em que os conceitos são explicados, integrados e relacionados com o intuito de facilitar a comunicação entre as empresas e os seus intervenientes (programadores, gestores, analistas de negócio, entre outros); por outro, exibe uma perspetiva prática que permite concretizar estes conceitos na realidade industrial, à qual é exigida a disponibilização de produtos de software eficazes e eficientes.

Professor Auxiliar convidado na Universidade Lusófona de Humanidades e Tecnologias e na Universidade da Beira Interior, lecionando unidades curriculares de Engenharia de Software, de Sistemas de Informação e de Programação. Possui experiência profissional em gestão de projetos de software de grande escala na área das telecomunicações.

Doutorado em Engenharia Informática e de Computadores pelo Instituto Superior Técnico da Universidade de Lisboa na área de Sistemas de Informação.

Os interesses de investigação relacionam-se com Engenharia Empresarial, Arquitetura Empresarial, Ontologias Empresariais e Processos de Decisão em Transações de Negócio.

Objetivos e desafios colocados à engenharia de software.

ISBN 978‐972‐722‐795‐2

9 789727 227952

ÍNDICE GERAL PREFÁCIO ...................................................................................................................................................................................................XI 1.

A ENGENHARIA DE SOFTWARE

1

1.1

INTRODUÇÃO ....................................................................................................................................................................... 2

1.2

A QUALIDADE ..................................................................................................................................................................... 5

1.3

PROBLEMAS .........................................................................................................................................................................6

1.4

1.5

1.3.1

A COMUNICAÇÃO ENTRE OS INTERVENIENTES ....................................................................................6

1.3.2

A ALTERAÇÃO DE REQUISITOS AO LONGO DO TEMPO ................................................................... 7

1.3.3

O TEMPO NECESSÁRIO PARA PRODUZIR PRODUTOS COM QUALIDADE ................................ 9

DESAFIOS ............................................................................................................................................................................. 10 1.4.1

A ADAPTABILIDADE NO SOFTWARE ........................................................................................................ 10

1.4.2

PROCESSOS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE ...................................................... 18

1.4.3

ENGENHARIA DE DESENVOLVIMENTO GUIADA POR MODELOS ................................................ 18

1.4.4

ARQUITETURAS DE SOFTWARE ORIENTADAS A SERVIÇOS........................................................ 19

1.4.5

A PROLIFERAÇÃO DAS APLICAÇÕES MÓVEIS ................................................................................... 22

O IMPACTO DA ENGENHARIA DE SOFTWARE NA ORGANIZAÇÃO ......................................................... 23

EXERCÍCIOS .................................................................................................................................................................................... 26 2.

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 2.1

29

INTRODUÇÃO ..................................................................................................................................................................30

2.2 INTERVENIENTES ............................................................................................................................................................. 32 2.3 PROBLEMAS E DESAFIOS ........................................................................................................................................... 33 2.4 ENQUADRAMENTO DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ............................... 36 2.5 PROCESSOS DE DESENVOLVIMENTO CLÁSSICOS DE SOFTWARE.........................................................38 2.5.1

EM QUEDA DE ÁGUA MODIFICADO (WATERFALL) ...........................................................................39 2.5.1.1

DESCRIÇÃO .........................................................................................................................................39

2.5.1.2

VANTAGENS .......................................................................................................................................40

2.5.1.3 DESVANTAGENS ..............................................................................................................................40 2.5.2 POR PROTÓTIPOS .............................................................................................................................................. 41 2.5.2.1

DESCRIÇÃO .......................................................................................................................................... 41

2.5.2.2 VANTAGENS ....................................................................................................................................... 42 2.5.2.3 DESVANTAGENS .............................................................................................................................. 42 2.5.3 DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES ..................................................................................43 2.5.3.1 DESCRIÇÃO .........................................................................................................................................43 2.5.3.2 VANTAGENS...................................................................................................................................... 45 2.5.3.3 DESVANTAGENS ............................................................................................................................. 45 2.5.4 ESPIRAL ................................................................................................................................................................ 45 2.5.4.1 DESCRIÇÃO ........................................................................................................................................ 45 2.5.4.2 VANTAGENS ....................................................................................................................................... 47 2.5.4.3 DESVANTAGENS .............................................................................................................................. 47

© FCA – EDITORA DE INFORMÁTICA

V

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

2.5.5 ESPIRAL COMBINADA COM A ABORDAGEM WIN-WIN ................................................................... 48 2.5.5.1 DESCRIÇÃO ......................................................................................................................................... 48 2.5.5.2 VANTAGENS ...................................................................................................................................... 48 2.5.5.3 DESVANTAGENS .............................................................................................................................. 49 2.5.6 INCREMENTAL..................................................................................................................................................... 49 2.5.6.1 DESCRIÇÃO ......................................................................................................................................... 49 2.5.6.2 VANTAGENS ...................................................................................................................................... 50 2.5.6.3 DESVANTAGENS .............................................................................................................................. 50 2.5.7 ESPIRAL COMBINADA COM A ABORDAGEM A COMPONENTES .................................................51 2.5.7.1

DESCRIÇÃO ...........................................................................................................................................51

2.5.7.2 VANTAGENS ...................................................................................................................................... 52 2.5.7.3 DESVANTAGENS .............................................................................................................................. 52 2.5.8 ETAPAS CONCORRENTES ............................................................................................................................. 52 2.5.8.1 DESCRIÇÃO ......................................................................................................................................... 52 2.5.8.2 VANTAGENS ...................................................................................................................................... 53 2.5.8.3 DESVANTAGENS .............................................................................................................................. 53 2.6 PROCESSOS DE DESENVOLVIMENTO ÁGEIS DE SOFTWARE ................................................................... 53 2.6.1

PROGRAMAÇÃO EXTREMA.......................................................................................................................... 57 2.6.1.1

DESCRIÇÃO ......................................................................................................................................... 57

2.6.1.2

VANTAGENS ...................................................................................................................................... 59

2.6.1.3

DESVANTAGENS .............................................................................................................................. 59

2.6.2 MODELAÇÃO ÁGIL ............................................................................................................................................ 60 2.6.2.1

DESCRIÇÃO ......................................................................................................................................... 60

2.6.2.2 VANTAGENS ........................................................................................................................................61 2.6.2.3 DESVANTAGENS ................................................................................................................................61 2.6.3 PROCESSO UNIFICADO DA IBM RATIONAL .......................................................................................... 62 2.6.3.1

DESCRIÇÃO ......................................................................................................................................... 62

2.6.3.2 VANTAGENS ...................................................................................................................................... 63 2.6.3.3 DESVANTAGENS .............................................................................................................................. 63 2.6.4 SCRUM .................................................................................................................................................................... 64 2.6.4.1 DESCRIÇÃO ......................................................................................................................................... 64 2.6.4.2 VANTAGENS ...................................................................................................................................... 64 2.6.4.3 DESVANTAGENS .............................................................................................................................. 64 EXERCÍCIOS ................................................................................................................................................................................... 66 3.

GESTÃO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE: A ETAPA TRANSVERSAL 3.1

69

INTRODUÇÃO ..................................................................................................................................................................... 70

3.2 O PLANEAMENTO DO PROJETO ...............................................................................................................................77 3.3 AS MÉTRICAS .................................................................................................................................................................... 83 3.3.1

MÉTRICAS PARA A ANÁLISE E DESENHO DO PRODUTO DO SOFTWARE ............................ 83

3.3.2 MÉTRICAS PARA OS TESTES ...................................................................................................................... 87 3.3.3 MÉTRICAS PARA A MANUTENÇÃO .......................................................................................................... 88 3.4 A GESTÃO DO RISCO ..................................................................................................................................................... 89 3.5 A GESTÃO DAS CONFIGURAÇÕES E DAS VERSÕES ..................................................................................... 90

VI

© FCA – EDITORA DE INFORMÁTICA

ÍNDICE GERAL 3.6 A GESTÃO DA EQUIPA DE DESENVOLVIMENTO ...............................................................................................90 3.7 NORMALIZAÇÕES E BOAS PRÁTICAS DA IEEE ................................................................................................... 91 3.7.1

A NORMA IEEE 15939 ...................................................................................................................................... 91

EXERCÍCIOS ....................................................................................................................................................................................96 4.

ENGENHARIA DE REQUISITOS: A ETAPA DE COMUNICAÇÃO 4.1

99

INTRODUÇÃO .....................................................................................................................................................................99

4.2 OS INTERVENIENTES ENVOLVIDOS ..................................................................................................................... 105 4.3 PROBLEMAS .................................................................................................................................................................... 105 4.4 ATIVIDADES MAIS RELEVANTES NO DESENVOLVIMENTO DE REQUISITOS................................ 107 4.5 SOLUÇÕES ........................................................................................................................................................................ 108 4.5.1

A REPRESENTAÇÃO DE REQUISITOS .................................................................................................... 108

4.5.2 A PROTOTIPAGEM .......................................................................................................................................... 109 4.5.3 OS CASOS DE USO ........................................................................................................................................... 110 4.5.4 AS FIGURAS DENSAS ...................................................................................................................................... 112 4.6 AS NORMALIZAÇÕES E BOAS PRÁTICAS ........................................................................................................... 113 EXERCÍCIOS .....................................................................................................................................................................................117 5.

ANÁLISE E DESENHO DO PRODUTO DE SOFTWARE: A ETAPA CONCEPTUAL 5.1

119

INTRODUÇÃO ..................................................................................................................................................................... 119

5.2 SISTEMAS DE INFORMAÇÃO E PRODUTO DE SOFTWARE.......................................................................... 121 5.3 A ANÁLISE ESTRUTURADA ........................................................................................................................................ 121 5.3.1

ESPAÇO DE ESTADOS ................................................................................................................................... 122

5.3.2 ESPAÇO DE FLUXO DE DADOS .................................................................................................................. 123 5.3.3 ESPAÇO DE TRANSIÇÃO DE ESTADOS..................................................................................................124 5.3.4 DICIONÁRIO DE DADOS .................................................................................................................................124 5.4 A ANÁLISE ORIENTADA A OBJETOS ....................................................................................................................125

UNIFIED MODELING LANGUAGE.................................................................................................................125 5.4.2 OMG SYSTEMS MODELING LANGUAGE ................................................................................................ 127 5.5 O DESENHO ARQUITETURAL DO SOFTWARE................................................................................................... 127 5.4.1

5.5.1

MODELO-VISTA-CONTROLADOR .............................................................................................................. 132

5.5.2 ARQUITETURA ESTRATIFICADA............................................................................................................... 133 5.5.3 ARQUITETURA REPOSITÓRIO .................................................................................................................... 135 5.5.4 ARQUITETURA CLIENTE-SERVIDOR.........................................................................................................136 5.5.5 ARQUITETURA ENCAMINHAMENTO E FILTRAGEM .......................................................................... 137 5.6 A ANÁLISE DAS TRANSAÇÕES DE NEGÓCIO ORGANIZACIONAIS COMO APROXIMAÇÃO AO PRODUTO DE SOFTWARE ............................................................................................................................. 138 5.6.1

BUSINESS PROCESS MODEL AND NOTATION ................................................................................... 139

5.6.2 ARCHIMATE .......................................................................................................................................................... 141 5.6.3 DESIGN & ENGINEERING METHODOLOGY FOR ORGANIZATIONS .............................................142 EXERCÍCIOS ...................................................................................................................................................................................152 6.

CODIFICAÇÃO DO PRODUTO DE SOFTWARE: A ETAPA TECNOLÓGICA 6.1

153

INTRODUÇÃO ................................................................................................................................................................... 154

© FCA – EDITORA DE INFORMÁTICA

VII

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

6.2 AS NORMAS DE CODIFICAÇÃO................................................................................................................................. 161 6.3 AS TÉCNICAS DE CODIFICAÇÃO .............................................................................................................................. 163 6.3.1

AS ESTRUTURAS DE CONTROLO.............................................................................................................. 163

6.3.2 O CÓDIGO FONTE OFUSCADO .................................................................................................................... 166 6.4 A DOCUMENTAÇÃO DO CÓDIGO FONTE ............................................................................................................. 168 6.5 A GESTÃO DAS VERSÕES DO CÓDIGO FONTE................................................................................................ 169 EXERCÍCIOS .................................................................................................................................................................................. 172 7.

VERIFICAÇÃO E VALIDAÇÃO POR TESTES AO PRODUTO DE SOFTWARE: A PROVA DE FOGO

175

7.1

INTRODUÇÃO .................................................................................................................................................................... 176

7.2

A VERIFICAÇÃO ............................................................................................................................................................... 181

7.3 A VALIDAÇÃO ................................................................................................................................................................. 182 7.4 OS TESTES ........................................................................................................................................................................ 183 7.4.1

A GESTÃO DAS VERSÕES DOS TESTES...............................................................................................188

7.5 INTEGRAÇÃO DE CONCEITOS ...................................................................................................................................189 7.5.1

DINÂMICA DE TRABALHO DAS EQUIPAS DE TESTE ....................................................................... 190

7.5.2 SEMEAR FALTAS .............................................................................................................................................. 191 EXERCÍCIOS .................................................................................................................................................................................. 192 8.

MANUTENÇÃO DO PRODUTO DE SOFTWARE: ALÉM DO DESENVOLVIMENTO 8.1

195

INTRODUÇÃO .................................................................................................................................................................... 196

8.2 OPERAÇÃO DO PRODUTO DE SOFTWARE......................................................................................................... 197 8.3 INTERVENIENTES ENVOLVIDOS.............................................................................................................................. 197 8.4 FORMAÇÃO DOS INTERVENIENTES ......................................................................................................................198 8.5 MANUTENÇÃO DO SISTEMA ..................................................................................................................................... 199 8.5.1

MANUTENÇÃO PREVENTIVA ...................................................................................................................... 201

8.5.2 MANUTENÇÃO CORRETIVA......................................................................................................................... 201 8.5.3 MANUTENÇÃO ADAPTATIVA ................................................................................................................... 202 8.5.4 MANUTENÇÃO DE APERFEIÇOAMENTO ............................................................................................. 202 8.6 AS NORMALIZAÇÕES E BOAS PRÁTICAS ........................................................................................................ 203 EXERCÍCIOS ................................................................................................................................................................................ 205 A.

CASO DE ESTUDO – FORMETIS B.V. A.1

207

INTRODUÇÃO ...................................................................................................................................................................207

A.2 FASES DO PROJETO ................................................................................................................................................... 208 A.3 RESULTADOS ................................................................................................................................................................. 209 QUESTÕES DO CASO DE ESTUDO..................................................................................................................................... 210 B.

CASO DE ESTUDO – TEORIA DOS SISTEMAS NORMALIZADOS B.1

211

INTRODUÇÃO ......................................................................................................................................................................211

B.2 OS TEOREMAS DOS SISTEMAS NORMALIZADOS ......................................................................................... 212 B.3 OS ELEMENTOS DOS SISTEMAS NORMALIZADOS ....................................................................................... 212 B.4 RESULTADOS DE IMPLEMENTAÇÃO DE UM SN DE GESTÃO DE ORÇAMENTOS ................................... 214 QUESTÕES DO CASO DE ESTUDO..................................................................................................................................... 217 VIII

© FCA – EDITORA DE INFORMÁTICA

ÍNDICE GERAL C.

CASO DE ESTUDO – SIGCOG C.1

219

INTRODUÇÃO ....................................................................................................................................................................219

C.2 O PRODUTO CREWS BASEADO EM INTELIGÊNCIA ARTIFICIAL E INVESTIGAÇÃO OPERACIONAL..... 220 C.3 RESULTADOS DE IMPLEMENTAÇÃO ..................................................................................................................... 221 QUESTÕES DO CASO DE ESTUDO ................................................................................................................................... 223 D.

CASO DE ESTUDO – CONTROLO DE ACESSO BASEADO EM PAPÉIS D.1

225

INTRODUÇÃO .................................................................................................................................................................. 225

D.2 O MODELO CONCEPTUAL ......................................................................................................................................... 225 D.3 RESULTADOS DE IMPLEMENTAÇÃO ....................................................................................................................227 QUESTÕES DO CASO DE ESTUDO ................................................................................................................................... 228 E.

CASO DE ESTUDO – FRULACT E.1

231

INTRODUÇÃO .................................................................................................................................................................... 231

E.2 DESCRIÇÃO DA ORGANIZAÇÃO DO PROJETO ............................................................................................... 233 E.3 RESULTADOS.................................................................................................................................................................. 234 QUESTÕES DO CASO DE ESTUDO ................................................................................................................................... 235 LISTA DE SIGLAS

237

GLOSSÁRIO DE TERMOS PORTUGUÊS EUROPEU / PORTUGUÊS DO BRASIL / INGLÊS

239

ÍNDICE REMISSIVO

241

© FCA – EDITORA DE INFORMÁTICA

IX

PREFÁCIO O autor desta obra pedagógica, introdutória à Engenharia de Software, foi meu aluno em todos os graus académicos por que passou: Licenciatura (LEIC), Mestrado (MEIC) e Doutoramento (DEI), outorgados pelo Técnico, onde tenho o privilégio de ser docente há já mais de 44 anos.1 Para além disso fui seu orientador na tese de mestrado em Engenharia Informática e Computadores e co-orientador, muito activo, no seu Doutoramento.

Tenho pois a pretensão de conhecer razoavelmente a pessoa do Professor Sérgio Guerreiro e sobretudo, estar muito familiarizado com a forma como pensa e como trabalha.

Exercendo funções docentes na Universidade Lusófona de Humanidades e Tecnologias e na Universidade da Beira Interior, onde tem ministrado um leque muito diversificado de disciplinas, vejo com gosto que não descura nem menoriza o seu papel pedagógico, e sei que é cuidadoso na sua relação com os alunos.

O surgimento deste livro apareceu-me pois como algo de natural na progressão e maturação da sua carreira académica. Se por um lado está muito activo e inovador na recente área de “Enterprise Engineering”, onde se situa cientificamente a sua tese de doutoramento, e nesse contexto permanece ligado às suas bases de informática industrial, e aos aspectos do controlo dinâmico de sistemas, nomeadamente informáticos e organizacionais, por outro não descura o “pão com manteiga” da actividade de um engenheiro informático que envolve sempre em maior ou menor grau, e em várias capacidades, desde a postura do “techie nerd” que adora programar e tem dificuldades em falar com humanos, até ao frio profissional “gestor de projectos” e ao elegante e perfumado “arquitecto de sistemas”, o domínio intelectual e conceptual do que envolve programar e desenvolver um sistema de software.

A experiência profissional anterior do Sérgio Guerreiro, associada às suas duras vivências como aluno de Engenharia Informática do Técnico, a considerável prática docente que acumulou nos últimos anos, proporcionam uma base muito realista e cheia de bom senso, que se traduz na organização e nos conteúdos deste texto introdutório.

Um aspecto em particular quero realçar neste Prefácio, o qual passará provavelmente despercebido se não for devidamente sinalizado, como me proponho fazer aqui.

Quase sem se dar por isso, o autor introduz pela primeira vez em Portugal um tema de enorme relevância ao qual os académicos nacionais da área de Engenharia de Software têm continuado a dar provas de ignorar totalmente: Os Sistemas Normalizados e em particular, o Software Normalizado.

Este tema é introduzido num caso de estudo, o CASO B, de uma forma pedagogicamente suave, e em linha com os vectores fundamentais do desenvolvimento desta obra.

Mas tomem nota: Este tema, estes Sistemas Normalizados e em particular o Software Normalizado vai revolucionar a Engenharia de Software nas suas bases construtivas elementares, de forma idêntica à que os sistemas microelectrónicos revolucionaram nas décadas de 70 e 80 toda a construção dos sistemas electrónicos anteriormente construídos a partir de componentes discretas segundo topologias fixas “hardwired” e a partir dessa época a partir de módulos normalizados cujas funcionalidades eram adaptáveis, variando consoante os parâmetros que neles eram “escritos”, isto é, o software.

O presente livro foi escrito ao abrigo do Novo Acordo Ortográfico. Contudo, por opção do prefaciador, este texto foi redigido na antiga ortografia.

© FCA – EDITORA DE INFORMÁTICA

XI

INTRODUÇÃO À ENGENHARIA DE SOFTWARE À ENGENHARIA DE SOFTWA Prevejo que daqui a alguns anos, este pioneirismo “pedagogicamente suave” do Sérgio venha a ser reconhecido pela comunidade académica nacional. E que os seus alunos aproveitem a oportunidade e desenvolvam com antecipação competências nesta área, que os diferenciará do resto dos engenheiros de software e irá dar origem, na minha opinião, a toda uma nova “indústria de software” com pequenas empresas high-tech que trabalharão para o mercado global.

Lisboa, 14 de Dezembro de 2014 José Tribolet Professor Catedrático do IST

XII

© FCA – EDITORA DE INFORMÁTICA

1 A ENGENHARIA DE

SOFTWARE

O presente capítulo enquadra a origem da engenharia de software, identifica a sua utilização nas organizações, introduz a qualidade como objetivo para a execução das atividades, apresenta os principais problemas sentidos e os desafios que estão hoje em dia a ser lançados nesta área científica.

A engenharia de software engloba não só os aspetos tecnológicos da programação de aplicações mas também os vários aspetos sociais com que está relacionada, a conceptualização do funcionamento dos sistemas, os princípios das bases de dados e das redes de computadores, os princípios de gestão, a gestão da equipa, os testes e os ambientes de produção. O objetivo de toda esta integração de conceitos é oferecer soluções de dimensão significativa, por exemplo, ambientes móveis distribuídos, ambientes web: de outra forma, soluções que sejam oferecidas para múltiplos utilizadores em detrimento de aplicações instaladas em monoposto. É também uma consideração relevante notar que os conceitos hoje introduzidos na engenharia de software tiveram a sua origem na tecnologia. Foi o desenvolvimento de linguagens de programação do tipo imperativo, por exemplo, em primeira instância, o COBOL, o BASIC ou o ASSEMBLY, que permitiram disponibilizar pequenos programas aos utilizadores que, conjugados com o crescimento acelerado do desenvolvimento tecnológico ao nível do hardware, conduziu por sua vez ao crescimento dos projetos em engenharia de software em termos de domínio e de negócio.

Posteriormente as linguagens de programação de nova geração baseadas em modelos orientados a objetos acrescentaram novas capacidades de abstração. Hoje em dia os modelos de arquitetura de software permitem um desacoplamento entre os conceitos fundamentais que um sistema de software suporta e a sua implementação tecnológica. É esta a principal motivação desta área. A engenharia de software tem já algumas décadas de crescimento em termos de conhecimento, o que significa que é apresentado hoje um conjunto significativo de conhecimentos vastos que têm de ser compreendidos e relacionados entre si. As referências clássicas de Pressman (2002), Sommerville (2011) e SWEBOK (2004) são incontornáveis e consensuais apresentando uma exposição extensa de conceitos neste domínio.

O presente livro usa uma estratégia de apresentação de conceitos de forma individual, definindo cada um deles isoladamente e usando descrições textuais e exemplificação. Cada

© FCA – EDITORA DE INFORMÁTICA

1

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

tema da engenharia de software é apresentado por cada um dos capítulos. Ao longo do texto, as relações entre eles vão sendo progressivamente clarificadas e expandidas.

1.1 INTRODUÇÃO A engenharia de software é um importante suporte para o desenvolvimento do crescimento da economia global eletrónica em que estamos inseridos. As ações mais ínfimas ao longo do nosso dia a dia passam inevitavelmente, de forma direta ou indireta, pela utilização de aplicações de software. Por exemplo, as aplicações disponíveis por internet, por telemóvel, por televisão, no pagamento de bilhetes de transporte, etc.

Neste contexto, a engenharia de software revela-se de particular importância para suportar a conceção, a implementação e a operacionalização da maior parte dos processos de negócio empresariais de empresas privadas ou públicas. O resultado final oferecido pela engenharia de software são justamente aplicações de software. É, por isso, muito pertinente o investimento nesta área de conhecimento com o objetivo inicial de dominar a sua semântica específica. A tecnologia é necessária e fundamental como ferramenta de desenvolvimento de aplicações; contudo, além da tecnologia, existe um manancial de conceitos que têm de ser percebidos, integrados e relacionados para facilitar a comunicação entre as empresas, os programadores, os gestores e os analistas de negócio.

Por outro lado, a engenharia de software potencia também a procura de novas formas de perceber e desenhar as organizações inseridas na economia global eletrónica. São os processos de negócio que permitem que, mediante uma comunicação entre diferentes pessoas e máquinas, uma organização possa produzir novos produtos e/ou serviços, tangíveis e intangíveis. Para isso, é crucial o domínio completo das tecnologias de informação e de todo o conhecimento detalhado do processo de desenvolvimento de software, para permitir a disponibilização de novos produtos e serviços baseados em aplicações de software. Por estas razões, a engenharia de software está hoje no caminho crítico para o desenvolvimento sustentado numa economia global e eletrónica, devendo grande parte da capacidade produtiva de um país estar alicerçada nesta área do conhecimento.

Em termos gerais, a Engenharia define-se por Pressman (2002) nestes termos: “na sociedade moderna, o papel da engenharia é fornecer sistemas e produtos que melhoram os aspetos materiais da vida humana, tornando assim a vida mais fácil, menos perigosa, mais segura e mais agradável.”

No contexto específico do software, a utilização de teorias e de metodologias apresentadas pela engenharia de software permite obter serviços, sistemas e produtos que têm como objetivo oferecer um benefício à vida dos diferentes utilizadores finais, satisfazendo as necessidades impostas pelos clientes.

Desde a definição do glossário standard de terminologias IEEE 610.12 (1990) que a engenharia de software se define como: 2

© FCA – EDITORA DE INFORMÁTICA

A ENGENHARIA DE SOFTWARE n

n

1

A aplicação de uma abordagem sistemática, disciplinada e quantificável, para o desenvolvimento, operação e manutenção do software; isto é, a aplicação da engenharia ao software; O estudo das abordagens sistemáticas, como enunciado no ponto anterior.

Por um lado, a aplicação de software é o produto final que se pretende que seja produzido pela engenharia de software. Do ponto de vista do engenheiro de software, o produto final é um programa, dados ou um documento. Um produto é único, uma vez que, no final do projeto, deverá existir uma aplicação executável que será invocada em um ou mais computadores. Esta aplicação representa uma instância única desta ocorrência no mundo, sem a qual o processo de desenvolvimento de software não atinge o seu objetivo primordial. Por outro lado, do ponto de vista do utilizador, o produto final é a informação resultante que, de algum modo, torna melhor e mais fácil o seu mundo.

Conceito Produto (product, ing. / produto, br.)

O produto final obtido pela engenharia de software representa um programa, dado ou documento que é produzido após execução de um processo de desenvolvimento. É o resultado da execução de um processo de desenvolvimento complexo onde interagem e cooperam diversos intervenientes.

Para produzir determinado produto de software, há vários caminhos que podem ser executados. O que se pretende transmitir como segundo objetivo da engenharia de software é que esse caminho seja otimizado para atingir o produto final com a utilização mínima de recursos. Esta otimização contempla a gestão eficiente dos recursos disponíveis no projeto, considerando todas as restrições que são habitualmente apresentadas, para que o projeto seja realizado da forma mais rápida e com menor consumo de recursos. As restrições que são tipicamente colocadas a um gestor de projeto são: n

n

n

Os requisitos apresentados pelos clientes e utilizadores finais, que representam as necessidades de negócio a automatizar por via de um sistema de software; Os recursos (por exemplo: custos financeiros, recursos humanos, recursos físicos, logística, etc.), que representam as ferramentas necessárias para que o processo de desenvolvimento seja executado; O tempo, que evolui a um ritmo constante e não controlável.

Este livro decompõe o ciclo de vida dos processos de desenvolvimento de software conhecidos pela indústria da engenharia de software e que têm solidez científica e profissional, tanto pelo aspeto inicial de um desenho de software que cumpra as necessidades impostas pelos clientes e utilizadores finais como pelas etapas de verificação e de validação que têm obrigatoriamente de estar incluídas no processo de desenvolvimento © FCA – EDITORA DE INFORMÁTICA

3

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

para garantir que a qualidade desejada é atingida. Desta forma, cada uma das etapas dos processos de desenvolvimento será subdividida em diferentes aspetos. Obviamente que na realidade a integração e a ocorrência das etapas acontece na prática do dia a dia do engenheiro de software de forma articulada, não de forma isolada.

Contudo, para fins de exposição dos conceitos, pretende-se em primeiro lugar dominar completamente as etapas de forma individual para, de seguida, ser possível integrá-las. É também relevante notar que os processos de desenvolvimento de software usam os métodos, técnicas e ferramentas já conhecidos da engenharia informática e de computadores, a qual está fortemente alicerçada nas linguagens de programação.

Necessita, porém, de definir novos modelos que sejam abstratos, mas precisos o suficiente, para que seja possível especificar, projetar, implementar e manter sistemas de software, compatíveis com equipas de desenvolvimento de grande dimensão.

Em termos de classificação funcional, os processos de desenvolvimento dividem-se hoje em dia em dois principais grupos: n

n

Os processos de desenvolvimento clássicos, que definem uma sequência de etapas, estática e que satisfaz exclusivamente os requisitos identificados. Assume-se que é possível identificar totalmente as necessidades para o produto de software final; Os processos de desenvolvimento ágeis, em oposição aos processos de desenvolvimento clássicos, têm a preocupação de avaliar constantemente o que está a ser feito e verificar se está correto. Caso não esteja, então devem fazer-se mudanças que tenham como objetivo garantir que a qualidade do produto final está a ser cumprida. Estas ações devem acontecer de forma contínua ao longo de todo o processo de desenvolvimento. Como exemplo da flexibilidade pretendida, os processos de desenvolvimento ágeis assumem que a escrita dos programas possa iniciar-se sem que o levantamento de requisitos esteja totalmente fechado.

Comparando estes dois processos de desenvolvimento, é missão dos ágeis acomodar melhor as mudanças que são impostas pelas pressões constantes do ambiente envolvente, por exemplo, dos mercados concorrenciais, das alterações de requisitos, das necessidades dos utilizadores, etc.

Salienta-se que, além dos aspetos técnicos (por exemplo, as bases de dados, as redes de computadores, as linguagens de programação, etc.), a engenharia de software integra os aspetos tecnológicos da computação com os fatores sociais e humanos para a construção final de sistemas de software. De outra forma, a engenharia de software envolve conceitos retirados tanto das hard sciences1 como das soft sciences.

1 As ciências são comumente divididas em duas categorias: hard sciences e soft sciences. Hard sciences é um termo usado para descrever certos aspetos das ciências naturais ou ciências físicas, porque podem ser observadas de forma mais precisa do que as soft sciences. As hard sciences são normalmente suportadas por experimentação, métodos empíricos ou dados quantificáveis. Seguem também um processo científico rigoroso e focam-se na precisão e objetividade. Soft sciences é um termo usado por oposição às hard sciences; sendo também científicas, não permitem a reprodução dos dados experimentais nem uma explicação matemática para os fenómenos. As ciências sociais e humanas, por exemplo, a psicologia, a sociologia e as ciências da organização, são normalmente incluídas nas soft sciences.

4

© FCA – EDITORA DE INFORMÁTICA

3 GESTÃO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE: A ETAPA TRANSVERSAL Neste capítulo identificam-se e exemplificam-se os conceitos fundamentais para compreender o papel crucial que a gestão tem no processo de desenvolvimento de software.

As atividades de gestão são transversais à execução do processo de desenvolvimento e têm como objetivo garantir que as qualidades desejadas para o produto e para o processo são atingidas. Exemplos de abordagens de gestão de projetos usadas mundialmente são o PMI (2013) e o PRINCE2 (2013).

Neste capítulo, para contextualizar os conceitos de gestão, recorre-se aos conceitos clássicos da teoria de controlo de sistemas dinâmicos (Bertalanffy, 1969; Franklin et al., 2009; Ribeiro, 2002) tais como a observação, a decisão, a ação e os padrões de ciclos de controlo. Com esta abordagem explicam-se, de forma detalhada, os componentes essenciais de gestão necessários, identificando-se ainda os seus benefícios.

A abordagem conceptual seguida por este capítulo está intimamente relacionada com os conceitos de engenharia. O objetivo é permitir definir técnicas de gestão que tenham conhecimento e sejam informadas sobre as atividades reais executadas pelas equipas de desenvolvimento. Esta capacidade de conhecer detalhadamente as atividades executadas permite que sejam definidas soluções de gestão alinhadas com a realidade da engenharia de software, em detrimento de abordagens comportamentais ou estatísticas, que são insuficientes para capturar toda a complexidade envolvida num projeto de desenvolvimento de software.

Como práticas clássicas de gestão do processo de desenvolvimento de software (Miguel, 2010) introduzem-se: (i) as técnicas de planeamento do projeto associadas à necessidade de obter estimativas; (ii) as principais métricas que permitem observar o desenrolar do processo de desenvolvimento; (iii) a gestão de risco, das configurações, das versões e da equipa como forma de otimizar a performance do processo de desenvolvimento; e (iv) a estimativa de esforço do processo de desenvolvimento.

© FCA – EDITORA DE INFORMÁTICA

69

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

3.1 INTRODUÇÃO Tal como apresentado no capítulo 2, num enquadramento de processo de desenvolvimento de software existem dois tipos de atividades: n

n

As atividades de execução, que são compostas pelas atividades que permitem a construção dos produtos, nomeadamente, a comunicação, o planeamento, a modelação do sistema, a implementação, a instalação, a formação e a manutenção; As atividades de suporte, que são compostas pelas atividades que auxiliam a obtenção de um melhor desempenho nas atividades de execução. Por exemplo, o acompanhamento e controlo do projeto, a gestão do risco, a garantia da qualidade do software, as revisões técnicas e formais, a medição, a gestão de configuração de software, a gestão da reutilização de componentes de software, e a preparação e produção do produto final.

As atividades de suporte, também denominadas atividades de gestão, estão embebidas no processo de desenvolvimento e são executadas em simultâneo com as atividades de execução. Na realidade, as etapas de gestão do processo de desenvolvimento de software não são mais do que um conjunto de etapas transversais executadas durante todo o processo de desenvolvimento. Significa isto que, ao longo de todo o tempo de execução das etapas de desenvolvimento de um projeto, deve sempre existir uma ou mais etapas em simultâneo que se preocupem com os aspetos de gestão do projeto.

Além disso, as atividades de suporte permitem fazer com que o processo de desenvolvimento seja mais robusto. Um projeto pode ser desenvolvido sem atividades de suporte, mas não é garantido que assim se cumpram os objetivos que são inicialmente impostos pelos clientes e utilizadores. Neste contexto, apresentam-se e detalham-se, neste capítulo, os mecanismos essenciais para garantir a qualidade na execução do produto de software.

Um qualquer sistema pode ser analisado segundo duas formas distintas: n

Por um lado, a perspetiva de construção (derivada da área da engenharia);

n

Por outro lado, a perspetiva comportamental (derivada da área da gestão).

A perspetiva de construção de um sistema preocupa-se com a visão mecanicista, o que envolve (i) os componentes existentes; e (ii) as interações que existem entre si. Por exemplo, no caso de um automóvel, quando este não funciona, é necessário que se faça depuração dos seus diferentes componentes (motor, transmissão, chassis, carroçaria, sistema elétrico, etc.) até que seja identificada uma ou mais peças danificadas. Para fazer esta depuração, o mecânico do automóvel tem de conhecer, ao mais ínfimo detalhe, os diversos sistemas existentes e as suas relações.

A perspetiva comportamental de um sistema preocupa-se em explicar como um sistema reage quando determinado estímulo é induzido. Por exemplo, também no caso de um automóvel, um condutor conduz sabendo que, se carregar no pedal do acelerador, anda

70

© FCA – EDITORA DE INFORMÁTICA

GESTÃO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

3

mais rápido, independentemente de todos os detalhes mecânicos e eletrónicos envolvidos, e que, se carregar no pedal do travão, o automóvel abranda.

Estas duas perspetivas são integradas no processo de desenvolvimento de software. O conhecimento oferecido pela perspetiva comportamental (estímulo/resposta) é insuficiente para controlar o processo de desenvolvimento, que é muito complexo e que requer detalhes adicionais tecnológicos (por exemplo, integração da tecnologia).

Contudo, por outro lado, também é verdade que o conhecimento detalhado oferecido pela perspetiva de construção não representa todo o sistema de software. Basta verificar que, se um automóvel for desmontado em milhares de pequenas peças, então, para fazer o processo inverso de reconstrução, são requeridos conhecimentos adicionais que expliquem o comportamento que cada peça tem no sistema como um todo.

Assim, a gestão do projeto de software tem a responsabilidade inicial de efetuar um planeamento completo do projeto que inclua todas as contribuições que a equipa de projeto inicialmente antevê para a sua conclusão com sucesso. Este planeamento inicial é obviamente apenas uma estimativa que se espera que seja cumprida. Contudo, durante a execução do projeto, ocorrem situações anómalas ou inesperadas, ou alterações que exigem que o planeamento inicial seja revisto.

De facto, o processo de desenvolvimento de software é um processo dinâmico que vai sucessivamente sofrendo múltiplas alterações ao longo do tempo, tanto por fatores endógenos1 quanto exógenos2. Alguns exemplos são: n

Alterações no ambiente envolvente: – Concorrência; – Legais; – Económicas.

n

Alterações de requisitos: – Funcionais; – Não funcionais; – Desenvolvimento.

n

Situações de exceção: – Emergências; – Desastres; – Eventos inesperados.

1 2

Fatores internos ao processo de desenvolvimento.

Fatores externos ao processo de desenvolvimento.

© FCA – EDITORA DE INFORMÁTICA

71

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

n

Sociais.

n

Comunicação.

n

Etnográficas.

Assim, quando se identifica que a gestão do projeto de desenvolvimento de software é responsável pela contínua revisão do plano de projeto em função da ocorrência de desalinhamentos da estimativa inicial, relaciona-se comummente este funcionamento ao controlo de sistemas dinâmicos.

Em específico, na área de controlo de sistemas dinâmicos, identificam-se três principais abordagens científicas: n

n

Analítica – Os sistemas de controlo analíticos são representados por formalizações matemáticas tanto para a modelação do modelo do processo a controlar bem como para o modelo do controlador. Nesta família de teorias é necessário modelar completamente o processo antes de desenhar o controlador (Brockett, 1993; Recht e D’Andrea, 2004).

Cibernética – Terminologia usada na década de 1970, para designar os controladores automáticos desenhados de forma independente da implementação em computadores. Contudo, a sua execução depende completamente dos computadores. São identificadas três diferentes classes de controladores cibernéticos: – Retirados da teoria de controlo clássico de sistemas (Franklin et al., 2009; Ogata, 1997; Ribeiro, 2002); – Sistemas inteligentes (Uraikul et al., 2004); – Baseados em agentes (Castro e Oliveira, 2011).

n

Caixa fechada (black-box) – São sistemas de controlo que consideram os mecanismos de integração entre pessoas e máquinas, tendo em vista a otimização da performance da organização. São identificadas três diferentes classes de controladores organizacionais: – Gestão do conhecimento (Magalhães, 2005; Matos, 2006); – Homeostática (Jaeger e Baliga, 1985); – Orientado a dados (Force, 2001).

Visualmente, na Figura 3.1, apresentam-se os padrões clássicos para um sistema de controlo. Na parte superior (A), apresenta-se um sistema que não é controlado. A perturbação afeta sempre a saída entregue pelo sistema. Neste modelo, não é possível garantir o comportamento do sistema de saída.

A meio da Figura 3.1 (B), encontra-se um padrão de alimentação para a frente, que mostra que a entrada do sistema muda de acordo com a perturbação. Assim, a dinâmica específica do sistema não está incluída na ação de controlo.

72

© FCA – EDITORA DE INFORMÁTICA

GESTÃO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

3

Na parte inferior da Figura 3.1 (C), um padrão de controlo de retroalimentação calcula a entrada do sistema de acordo com o desalinhamento real obtido entre a saída e entrada.

Neste padrão, o cálculo de controlo de atuação toma em consideração a perturbação e a dinâmica do sistema. A saída do sistema depende da perturbação aplicada no sistema e sobre a própria dinâmica do sistema.

Para produzir resultados, todos os sistemas de controlo requerem as capacidades de observação e de atuação.

Perturbação

(A)

Saída

Entrada Sistema

Perturbação

(B) Alimentação para a frente

Saída

Entrada Sistema

Perturbação

(C) Saída

Entrada Sistema

Retroalimentação

FIGURA 3.1 – PADRÕES DE DESENHO DE UM SISTEMA DE CONTROLO: (A) SEM CONTROLO; (B) CONTROLO POR ALIMENTAÇÃO PARA A FRENTE; E (C) CONTROLO POR RETROALIMENTAÇÃO

A partir do padrão de retroalimentação da Figura 3.1, define-se, na Figura 3.2, um ciclo de controlo de um sistema dinâmico, com todos os seus componentes: a referência a ser seguida, a observação por intermédio de sensores, o controlador (que contem capacidades de decisão) e a ação de controlo.

Por exemplo, considerando o sistema de controlo de velocidade de um automóvel (sistema dinâmico na Figura 3.2) que permite que um veículo circule a uma velocidade

© FCA – EDITORA DE INFORMÁTICA

73

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

constante sem auxílio do condutor. Baseia-se na referência indicada pelo condutor, correspondente à velocidade de cruzeiro pretendida, para ir continuamente verificando se esta é igual, maior ou menor do que o valor indicado pelo velocímetro. Caso seja menor, então o controlador decide atuar no acelerador para que o veículo aumente a sua velocidade. Caso seja maior, então o controlador decide atuar no travão para que o veículo diminua a sua velocidade. Finalmente, caso seja igual, o controlador decide não fazer nada.

Perturbação

Referência

+

Ação de controlo

Erro Controlador

Saída do sistema Sistema dinâmico

–

Saída medida Sensor

FIGURA 3.2 – CICLO CLÁSSICO DE CONTROLO DE UM SISTEMA DINÂMICO: OBSERVAÇÃO, DECISÃO E AÇÃO

A observação define-se no contexto do controlo de sistemas dinâmicos (Ribeiro, 2002), da seguinte forma: “[…] Um sistema é completamente observável se cada variável de estado do sistema afeta alguma das saídas. Muitas vezes, é desejável obter informações sobre as variáveis de estado das medições das saídas e das entradas. Se qualquer um dos estados não pode ser observado a partir das medições das saídas, o estado é dito não observável e o sistema não é completamente observável ou simplesmente não observável […].”

Conceito Observação (observation, ing. / observação, br.)

Um sistema é completamente observável se cada variável de estado do sistema afeta alguma das suas saídas. No contexto da gestão de um processo de desenvolvimento, se existir alguma variável não observável então considera-se que o projeto é parcialmente observável.

A tomada de ação no projeto define-se como controlabilidade no contexto do controlo de sistemas dinâmicos (Ribeiro, 2002), assim: “... Um processo denomina-se totalmente controlável se cada variável de estado do processo for controlada para atingir um certo objetivo em tempo finito por um 74

© FCA – EDITORA DE INFORMÁTICA

INTRODUÇÃO À ENGENHARIA DE SOFTWARE

EXERCÍCIOS 5.1

Qual é a principal diferença entre o modelo de análise estruturado e a linguagem de especificação UML? Responda detalhadamente.

5.2

Indique pormenorizadamente as vantagens/desvantagens da ontologia DEMO e da linguagem de especificação BPMN, quando utilizadas para a modelação de transações de negócio de uma organização. Sugestão: fundamente a sua resposta baseando-se em exemplos de utilização de DEMO e de BPMN.

5.3

Identifique, de forma detalhada, os elementos constituintes do modelo de análise estruturada proposto por Pressman (2002).

5.4

Quais os objetivos do modelo de análise estruturada proposto por Pressman (2001)? Responda detalhadamente.

5.5

Qual é a diferença entre cardinalidade e modalidade no modelo Entidade-Relação (ER)? Aprofunde a sua resposta.

5.6

Desenhe um diagrama simplificado de Entidade-Relação (ER) que descreva os objetos, relações e atributos de um sistema de faturação de uma pequena empresa.

5.7

Desenhe um diagrama simplificado de Entidade-Relação (ER) que descreva os objetos, relações e atributos de um sistema web-based para processamento automático de encomendas numa loja de informática.

5.8

Quais são os principais diagramas disponibilizadas pela linguagem de especificação UML? Responda detalhadamente.

5.9

Quais as contribuições oferecidas pela linguagem de especificação SysUML? Responda minuciosamente.

152

© FCA – EDITORA DE INFORMÁTICA