CADERNOS DE ENGENHARIA DE SOFTWARE

CADERNO 1

INTRODUÇÃO À ENGENHARIA DE
SOFTWARE

PAULO CÉZAR STADZISZ

DAINF – Departamento de Informática
UTFPR – Universidade Tecnológica Federal do Paraná

1º Edição - 2021
NOTA SOBRE ESTA EDIÇÃO

Esta é a primeira edição do Caderno 1 – Introdução à Engenharia de Software da série Cadernos

de Engenharia de Software, produzida no DAINF – Departamento Acadêmico de Informática – da
UTFPR. Este caderno, junto com os demais da série, tem por objetivo compor um material didático
de apoio ao ensino das disciplinas de Engenharia de Software nos cursos de graduação e de pós-
graduação em computação da UTFPR.

O conhecimento recolhido neste caderno origina-se dos livros clássicos e introdutórios de Engenharia
de Software, de publicações científicas produzidas pela comunidade nacional e internacional de
computação, de publicações técnicas oriundas de empresas e associações de software, das pesquisas
em Engenharia de Software conduzidas na própria UTFPR e da experiência do autor atuando no
mercado de desenvolvimento software e como pesquisador. Destaca-se, como fonte de informação,
o SWEBOK V3.0 – Guide to the Software Engineering Body of Knowledge (Swebok, 2014).
Trata-se de um documento produzido pelo IEEE Computer Society com uma grande reputação na
definição dos conhecimentos fundamentais e consolidados da área de engenharia de software.

Neste primeiro caderno, aborda-se uma introdução à Engenharia de Software. O objetivo é apresentar
ao leitor uma visão precisa do que representa esta área de conhecimento, sua importância e problemas
existentes, de forma a desenvolver no leitor uma capacidade crítica sobre o tema. Uma atenção
especial é dada pelo autor a este caderno pelo fato de que a Engenharia de Software é, frequentemente,
mal entendida por profissionais de outras áreas, levando a um mal aproveitamento de seu potencial
em empreendimentos de desenvolvimento de sistemas de computação.

Prof. Dr. Paulo Cézar Stadzisz

Autor

2 Caderno 1 - Introdução à Engenharia de Software UTFPR

SUMÁRIO

NOTA SOBRE ESTA EDIÇÃO ........................................................................................................................ 2

ENGENHARIA DE SOFTWARE COMO UMA ÁREA DE CONHECIMENTO ........................................... 5
Nascimento da Engenharia de Software ......................................................................................................... 5
Categorização da Engenharia de Software ..................................................................................................... 8
Definição de Engenharia de Software .......................................................................................................... 11
IMPORTÂNCIA DA ENGENHARIA DE SOFTWARE .............................................................................................. 12
Engenharia de Software x Desenvolvimento de Software ........................................................................... 12
ABRANGÊNCIA E VALOR DA ENGENHARIA DE SOFTWARE ........................................................................... 13
PROBLEMAS DA ENGENHARIA DE SOFTWARE ................................................................................................. 15
BAIXA PRODUTIVIDADE ................................................................................................................................ 15
PRAZOS LONGOS .......................................................................................................................................... 16
ALTOS CUSTOS .............................................................................................................................................. 17
BUSCA CRESCENTE POR QUALIDADE............................................................................................................ 18
AUMENTO DA COMPLEXIDADE .................................................................................................................... 19
FALTA DE MÃO DE OBRA QUALIFICADA ....................................................................................................... 20
PERSPECTIVA HISTÓRICA E FUTURA ................................................................................................................. 21
EVOLUÇÃO DA DEMANDA x EVOLUÇÃO DA OFERTA DE SOFWTARE ........................................................... 21
CONCEITUAÇÃO DE SOFWTARE ....................................................................................................................... 25
CONCEITO DE SOFWTARE BASEADO NA SUA COMPOSIÇÃO ....................................................................... 25
CONCEITO DE SOFWTARE BASEADO NO SEU PAPEL .................................................................................... 27
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................................. 28
ANEXO I – TABELA DE PESOS DAS ÁREAS DE CONHECIMENTO de COMPUTAÇÃO .......................................... 29

3 Caderno 1 - Introdução à Engenharia de Software UTFPR

CADERNOS DE ENGENHARIA DE SOFTWARE

CADERNO 1

INTRODUÇÃO À ENGENHARIA
DE SOFTWARE

“Bill Curtis has said that in a room full of expert software designers,
if any two agree, that’s a majority!” (Glass, 2001).

Em 2018 comemoramos o 50o aniversário da Engenharia de Software, demonstrando que essa não é,
exatamente, uma nova área de conhecimento. Mesmo com esta história de décadas, a compreensão
sobre seu real significado e papel nem sempre estão claros para todos os profissionais de computação
e de outras áreas relacionadas, levando a um mal uso de suas potencialidades.

Neste caderno, busca-se apresentar os conceitos fundamentais de Engenharia de Software para que o
leitor adquira uma clareza sobre o tema, podendo tirar o melhor proveito desta área de conhecimento,
mas, também, tendo ciência das limitações existentes. Leituras complementares são recomendadas ao
longo do texto para os leitores que desejem esclarecer ou estender o estudo.

Boa leitura e bem-vindo(a) ao tema!

4 Caderno 1 - Introdução à Engenharia de Software UTFPR

ENGENHARIA DE SOFTWARE COMO UMA ÁREA DE CONHECIMENTO

A Engenharia de Software está diretamente associada aos empreendimentos mais modernos

e desafiadores da sociedade, notadamente àqueles que, independentemente de porte,
requerem uma abordagem sistemática para o desenvolvimento das soluções computacionais
envolvidas. Software é algo que permeia quase a totalidade das atividades humanas na
sociedade contemporânea e, assim, a Engenharia de Software reveste-se de um valor
significativo na maioria dos setores econômicos e sociais e está intimamente ligada à
inovação tecnológica. Neste capítulo, discute-se, resumidamente, como a Engenharia de
Software evoluiu de um conjunto de técnicas para uma área de conhecimento em si, dentro
da grande área de computação.

NASCIMENTO DA ENGENHARIA DE SOFTWARE

Os primeiros computadores foram desenvolvidos a partir do início da década de 40, como o

CNC (Bell´s Lab), o Z3 (Konrad Zuse), a British Bombe (British Tabulating Machine
Company), ABC (Iowa State College), Mark 1 (IBM e Harvard) e ENIAC (University of
Pennsylvania). O desenvolvimento da programação logo acompanhou a evolução dos
computadores, a partir do primeiro computador eletrônico com instruções armazenadas em
memória RAM desenvolvido em 1948 na Universidade de Manchester e denominado Small-
Scale Experimental Machine (SSEM). O primeiro programa de vinte linhas para este
computador foi escrito pelo matemático inglês Tom Kilburn.

Figura 1: Imagem do computador ENIAC (1946).

5 Caderno 1 - Introdução à Engenharia de Software UTFPR

A evolução dos computadores e da programação se acelerou ao longo da década de 50.
Kathleen Booth desenvolveu a linguagem Assembly em 1950, visando simplificar a
programação de computadores. Também nesta época, a americana Grace Hopper
desenvolveu o primeiro compilador para uma linguagem baseada na língua inglesa. Ela
contribuiu para popularizar o conceito de “linguagens de programação independentes de
máquina”, que levou ao desenvolvimento de linguagens mais modernas como COBOL,
FORTAN e BASIC, ao final dos anos 50 e início dos anos 60.

O termo “software” foi cunhado por um dos mais renomados estatísticos americanos,
chamado John Wilder Tukey, em 1958. Ele foi professor na Universidade de Princeton e
pesquisador nos Laboratórios Bell da AT&T, tendo desenvolvido teorias sobre análise de
dados e computação de séries de dados. Já neste ano, Tukey afirmava que “Hoje, é (o
software) no mínimo tão importante quanto o hardware de válvulas, transistores, fios, fitas e
similares.”, destacando o papel determinando que o software já representava.

Nos dez anos a seguir, a computação continuou a evoluir rapidamente e a demanda por
software se acelerou ainda mais. As empresas passaram a buscar cada vez mais softwares e
com funções cada vez mais extensas e complexas. Criou-se, assim, uma grande pressão sobre
a jovem indústria de software, o que revelou graves problemas na capacidade de produzir
software na época. A esta dificuldade em escrever programas computacionais úteis e
eficientes dentro dos prazos e orçamentos requeridos deu-se o nome de “Crise de Software”
ou, ainda, “Software Gap”. Este termo foi cunhado pelos participantes da primeira NATO
Software Engineering Conference ocorrida em 1968 na Alemanha (Report NATO, 1968)
(ilustração na figura a seguir).

Figura 2: Conferência da NATO na Alemanha (1968).

6 Caderno 1 - Introdução à Engenharia de Software UTFPR

 Fonte: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/index.html

A Crise de Software caracterizou-se por um conjunto de problemas enfrentados pela

indústria de software, incluindo:

• Projetos sendo realizados com custos além do planejado

Planejava-se um orçamento para o projeto, estimando-se os prazos e recursos, mas na
execução do projeto, os custos ultrapassavam o que estava planejado por
desconhecimento das dificuldades reais que se apresentariam.

• Projetos sendo realizados com prazos além do estipulado

As estimativas de prazos eram frequentemente ultrapassadas, pois era comum
subestimar-se o tempo necessário para o desenvolvimento do software.

• Ineficiência dos softwares produzidos

Muitos softwares, ao final, não apresentavam o desempenho esperado pelos clientes.

• Baixa qualidade dos softwares produzidos

Muitos softwares produzidos descontentavam os clientes pelas falhas de
funcionamento que ocorriam frequentemente.

• Falha dos softwares produzidos em atender aos requisitos

Muitos softwares, ao final do desenvolvimento, não entregavam as funcionalidades
esperadas aos clientes.

• Projetos não-gerenciáveis e código difícil de manter

Muitos projetos eram desenvolvidos de forma caótica, baseada unicamente no talento
e experiência dos profissionais, sem que se pudesse gerenciar adequadamente o
desenvolvimento, produzindo, assim, códigos mal estruturados e de difícil
manutenção ao longo de sua vida útil.

• Softwares nunca entregues

Não era raro que um projeto se iniciasse e nunca tivesse um término, pois entrava em
um ciclo sem fim de correções e adaptações em razão da combinação dos problemas
anteriores.

Todos estes problemas mostram que se estava um momento grave no final dos anos 60. Além
das tecnologias terem muitas limitações, a indústria de software era pouco profissional e,
assim, tinha dificuldade em atender as demandas de um marcado em franco crescimento.
Além dos problemas citados, surgia um outro grave problema ou, na verdade, se agravava
um problema existente, que era consequência dos demais: a industrial de software não era
capaz de gerar uma oferta de software que atendesse a demanda existente e crescente.

7 Caderno 1 - Introdução à Engenharia de Software UTFPR

Estes problemas foram entendidos como compreensíveis para uma nova área de
conhecimento, nascida recentemente. Porém, os problemas eram graves demais, exigindo
uma mudança de atitude sobre como desenvolver softwares. Embora alguns especialistas
considerassem que a produção de software estaria dentro do domínio da matemática, acabou-
se criando um consenso de que ela estaria mais alinhada com a engenharia em razão de seu
compromisso de entrega de algo para atender à necessidade de um demandante (i.e., um
cliente).

Para fazer frente às dificuldades existentes e que caracterizaram a “crise de software”, foi
idealizada a Engenharia de Software. Esta nova engenharia foi “oficializada” na conferência
da NATO realizada em 1968, citada anteriormente.

CATEGORIZAÇÃO DA ENGENHARIA DE SOFTWARE

Embora alguns cursos de graduação incluam a Engenharia de Software como uma ou mais
matérias de sua grade curricular, ela não é meramente uma disciplina. A existência destas
matérias em cursos de computação é justificada, uma vez que todo desenvolvedor de software
deveria ter conhecimento dos fundamentos de Engenharia de Software para poder aplicá-los
em suas atividades. A Engenharia de Software também não deve ser confundida com uma
“atividade” que é realizada durante um desenvolvimento de software. Inclusive, não é
incomum ouvir-se, inapropriadamente, referências como “na primeira fase do projeto vamos
fazer a engenharia de software e depois ...”. Este tipo de interpretação, possivelmente, vem
de uma visão fragmentada da Engenharia de Software, focando algumas atividades
características com a modelagem e especificação, e entendendo que ela se limita a isso.

Na verdade, a Engenharia de Software é bem mais do que uma matéria ou atividade. Ela é
uma área inteira de conhecimento, ou seja, ela existe por si própria, como um condensado
coeso de conhecimentos, uma formação e atividade profissional específicas.

• Área de conhecimento

A grande área de conhecimento dentro da qual está a Engenharia de Software é a área de

Computação (Computing, em inglês). Segundo a ACM (Association for Computing
Machinery), a computação pode ser definida como a área que compreende atividades
orientadas a objetivos que requeiram, se beneficiem ou criem computadores. Assim, a
computação inclui o projeto e construção de sistemas de hardware e software para um
conjunto ilimitado de propósitos e cobre os conhecimentos de Engenharia de Software.

Até os anos 90, Engenharia de Software ainda era considerada um conjunto de técnicas
recomendadas para enfrentar os problemas encontrados pelos desenvolvedores. Na década
de 90, começou-se a enxergar a Engenharia de Software como uma área de conhecimento

8 Caderno 1 - Introdução à Engenharia de Software UTFPR

própria, exigindo um profissional com uma formação específica. Isso ficou caracterizado
pela proposta curricular desenvolvida e apresentada pela ACM e IEEE em 2004 (ACM/IEEE,
2004) para formação de profissionais nesta área.

No Brasil, a área de Engenharia de Software foi considerada consolidada em 2012 pelo

Conselho Nacional de Educação (CNE) que incluiu o curso de Engenharia de Software nas
Diretrizes Curriculares Nacionais da área de Computação, aprovadas pelo CNE em 2012
(MEC, 2012) e homologadas pelo Ministro da Educação em 2016. A Sociedade Brasileira de
Computação (SBC) inclui, também, a Engenharia de Software em seus referenciais de
formação para os cursos de graduação em computação (SBC, 2017). Os primeiros cursos em
Engenharia de Software surgiram no Brasil a partir de 2008 na UNB, UFG, UFC, UFRN,
UNIPAMPA e UFAM, além de outros mais recentes.

Ainda no Brasil, em 2018 o Conselho Federal de Engenharia e Agronomia (CONFEA) que

atua junto com os CREAs, emitiu a RESOLUÇÃO nº 1.100 pela qual discrimina as atividades
e competências profissionais do engenheiro de software e insere o respectivo título na Tabela
de Títulos Profissionais do Sistema Confea/Crea, para efeito de fiscalização do exercício
profissional. Na prática o Confea regulamenta a profissão de Engenheiro de Software e
determina que o engenheiro de software integrará o grupo ou categoria Engenharia, na
modalidade Eletricista. Segundo a legislação brasileira o Confea tem autoridade para isso,
em razão da denominação de “engenharia” desta área de conhecimento. Por outro lado, a
resolução é bastante superficial e traz uma interpretação bem limitada desta área de formação.
A associação da Engenharia de Software à modalidade Eletricista também não faz sentido
dentro da visão que já se desenvolveu na comunidade nacional e internacional, tampouco tem
relação com os currículos já aplicados em universidades no Brasil.

• Engenheiro de software

O profissional que exerce a Engenharia de Software, pois seguiu uma formação específica
nesta área de conhecimento, denomina-se “Engenheiro de Software”. Entretanto, não é
incomum que empresas e outras instituições façam um uso mais “popular” desta
denominação, fazendo referência a desenvolvedores com outras formações em computação
(ou até sem formação superior) como se fossem engenheiros de software também ou como
se esse fosse um cargo (e não uma formação). Talvez, elas procurem, com isso, valorizar ou
modernizar determinado cargo ou função em computação. Entretanto, dado que existe
oficialmente a formação superior em Engenharia de Software no Brasil (reconhecida pelo
MEC, SBC e CREA), esse uso popular da denominação de engenheiro de software é
incorreto e deveria ser evitado, inclusive para se evitar o mal entendimento desta
denominação e confusão com relação às atribuições deste profissional.

• Relacionamento com outras áreas

9 Caderno 1 - Introdução à Engenharia de Software UTFPR

Como dito anteriormente, a Engenharia de Software é uma das seis áreas de conhecimento
dentro da Computação. Por consequência, ela possui grande relacionamento com as demais
áreas de computação. Não só a Engenharia de Software está relacionada com as demais áreas
porque deveria ser empregada em todos os desenvolvimentos de software, mas há também
um relacionamento em termos dos conhecimentos envolvidos na formação dos profissionais.
Muitos conhecimentos são comuns às seis áreas, porém a ênfase dada a estes conhecimentos
varia. A melhor evidência para isso são os currículos de referência da ACM e IEEE. A tabela
no Anexo I deste caderno mostra o peso dado aos conhecimentos, dentro de cada categoria
de conhecimentos, para cada uma das seis áreas de formação em computação. Os pesos
indicados em verde mostram as ênfases de cada área. Nota-se que a Engenharia de Software
tem ênfases bem destacadas que a diferenciam das demais áreas como aquelas na categoria
“4 – Software Development”.

Figura 3 – Posicionamento da Engenharia de Software nas cinco camadas de conhecimento em

computação. Fonte: (Impagliazzo, 2017).

A figura 3 também ilustra graficamente as ênfases próprias da Engenharia de Software

(Impagliazzo, 2017). A elipse representa a área de cobertura da Engenharia de Software
relativa às cinco camadas ou extratos de conhecimento da computação. A Engenharia de
Software cobre praticamente a totalidade dos conhecimentos de “desenvolvimento de
software”, além de boa parcela de “tecnologias de aplicação” e “infraestrutura de sistemas”.
Por outro lado, ela, praticamente, não se relaciona com as camadas organizacional e de
hardware. No eixo horizontal, diferencia-se uma abordagem mais teórica (ou mais focada em
princípios e inovação) mais à esquerda e uma abordagem mais aplicada (ou relacionada à

10 Caderno 1 - Introdução à Engenharia de Software UTFPR

entrega e configuração de soluções) mais à direita. No caso da Engenharia de Software, ela
contempla ambos, teoria e aplicação, nas três camadas em que atua.

DEFINIÇÃO DE ENGENHARIA DE SOFTWARE

Segundo a ISO/IEC/IEEE, a Engenharia de Software é definida como “A aplicação de uma

abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação
e manutenção de software; ou seja, a aplicação de engenharia à software” (Swebok,
2014).

O termo “sistemática” indica que as atividades em Engenharia de Software são desenvolvidas

segundo um método, uma organização ou uma ordenação, de maneira a garantir que haja
conhecimento e controle sobre o que se está fazendo e por quê. Trata-se de uma abordagem
típica das engenharias pela qual procura-se ser meticuloso e rigoroso na execução das tarefas.
Ser sistemático garante, também, que se siga padrões e que as tarefas possam ser otimizadas
e repetidas. O termo “disciplinada” significa que as atividades em Engenharia de Software
são pautadas em técnicas ou métodos dando clareza e precisão sobre o que se está realizando.
Por fim, o termo “quantificável” indica a necessidade de se poder medir o que é feito
empregando métricas ou indicadores, como por exemplo, controlar o tempo gasto em cada
tarefa realizada, medir o atingimento dos objetivos e metas, e mensurar a qualidade do que
foi produzido.

Na segunda parte da definição do Swebok é dito “a aplicação da engenharia à software”, pois

esta afirmação resume a intenção da Engenharia de Software que é trazer a abordagem de
engenharia à produção de software, com tudo o que se conhece de rigor das engenharias em
geral.

Um aspecto importante não ficou explícito na definição do Swebok. Trata-se da evolução da

própria Engenharia de Software. É papel da Engenharia de Software, não só aplicar uma
abordagem de engenharia ao desenvolvimento de software, mas também investigar novas
formas de evoluir estas abordagens ou meios (e.g., modelos, técnicas, ferramentas) e
atividades para melhoria da eficiência e eficácia no desenvolvimento de software. Portanto,
também há um aspecto investigativo na Engenharia de Software que é desenvolvimento por
meio de pesquisas científicas e tecnológicas nas universidades, centros de pesquisas e nas
próprias empresas de tecnologia. Na UTFPR, por exemplo, existem alguns grupos de
pesquisa em Engenharia de Software que investigam meios mais efetivos para especificação
de requisitos, novos paradigmas de software, melhorias de processos de desenvolvimento,
novas técnicas de testes, entre outros temas.

11 Caderno 1 - Introdução à Engenharia de Software UTFPR

IMPORTÂNCIA DA ENGENHARIA DE SOFTWARE

A Engenharia de Software tem um papel significativo na área de computação e tem um

compromisso importantíssimo na busca da maior capacidade possível de oferta de software
à sociedade. Obviamente, a importância da Engenharia de Software tem relação com o valor
que o software tem para as pessoas, empresas e governos, como é discutido nesse capítulo.

ENGENHARIA DE SOFTWARE X DESENV OLVIMENTO DE SOFTWARE

Não raro, os termos “Engenharia de Software” e “desenvolvimento de software” são usados

como se fossem sinônimos. Esse é um mal entendimento dos termos, pois, como já discutido
em seções anteriores, a Engenharia de Software é uma área de conhecimento contemplando
a formação e atuação específica de um profissional denominado engenheiro de software. O
“desenvolvimento de software”, por sua vez, refere-se à atividade de produção de um novo
software, envolvendo a sua especificação, projeto, construção e verificação. A Engenharia
de Software representa o conhecimento em termos de abordagens existentes, alternativas de
linguagens de modelagem e programação, técnicas de projeto e construção, arquiteturas e
modelos e técnicas de testes, processos, entre outros. Esses conhecimentos são usados quando
se for produzir (ou seja, desenvolver) um novo software ou evoluir um software existente em
uma nova versão. Enquanto a Engenharia de Software é exercida pelo engenheiro de
software, a atividade de desenvolvimento de software pode ser realizada por qualquer
profissional de qualquer área ou, até mesmo, por não profissionais (como estudantes, hobistas
e entusiastas). Em geral, a expectativa maior é de que profissionais de computação sejam os
principais desenvolvedores de software, mas profissionais das áreas tecnológicas, como
engenheiros eletricistas e em eletrônica, engenheiros civis e mecânicos, engenheiros de
automação e mecatrônica, poderiam, também, participar desta atividade. Mesmo
profissionais de áreas não tecnológicas, como médicos, advogados, administradores e
economistas, poderia se iniciar em atividades de desenvolvimento de software.

Pode-se entender que em todo desenvolvimento de software há a aplicação de Engenharia de

Software em algum grau. Sempre que um desenvolvedor aplica algum método ou técnica
(mesmo que parcialmente) na especificação, projeto, construção ou teste do software, ele está
empregando a engenharia de software. Por outro lado, uma utilização profissional (no sentido
de ser sistemática, padronizada e planejada) implica um uso mais intenso e organizado dos
instrumentos de Engenharia de Software em uma proporção adequada às características de
cada desenvolvimento.

12 Caderno 1 - Introdução à Engenharia de Software UTFPR

Embora o exercício da atividade de desenvolvimento de software seja bastante aberto, pela
inexistência de regulamentação da atividade, há domínios que possuem exigências que
limitam quem pode atuar no desenvolvimento. Há setores, como o elétrico, aeronáutico,
médico e de transporte, que devem seguir normas e eventuais certificações e, assim, os
profissionais de desenvolvimento devem ter uma sólida formação em engenharia de software,
entre outras.

ABRANGÊNCIA E VALOR DA ENGENHARIA DE SOFTWARE

A Engenharia de Software se aplica a qualquer desenvolvimento de software, de pequeno a

grande, de simples a complexo, e de corriqueiro a crítico. É verdade, entretanto, que quanto
maior, mais complexo e crítico um software é, mais importante é o emprego rigoroso da
Engenharia de Software. Em termos de abrangência, a Engenharia de Software é tão
abrangente quando a própria aplicação de software, acompanhando todo desenvolvimento de
software em todas as áreas econômicas, governamentais, sociais e pessoais. Praticamente,
não há área de atividade humana que não se beneficie de software nos dias atuais e, como
discutido anteriormente, a demanda por software é crescente.

O valor do software está diretamente relacionado como sua importância ou impacto para
quem o utiliza ou dele se beneficia. Na esfera de uso pessoal, é flagrante o quanto o uso de
diferentes softwares faz parte do cotidiano atual de uma grande parte da humanidade. Por
meio do uso de PCs, notebooks, tablets e smartphones, usuários pessoais utilizam dezenas de
softwares no seu cotidiano agilizando atividades (e.g. movimentações bancárias, acesso a
serviços como transporte e compras), controlando tarefas ou obrigações (e.g., contas a pagar,
finanças e agenda), interagindo com outras pessoas (e.g., troca de mensagens, inter-
relacionamentos, bate-papo, posts) e se entretendo (e.g., games, músicas, vídeos). No âmbito
empresarial, as aplicações de software são incontáveis abrangendo a gestão da empresa,
atividades de marketing e comercial, além das ferramentas ligadas às atividades produtivas,
de todos os tipos e nas mais diversas áreas de atividade comercial, de serviços e industrial.
Pode-se afirmar que empresas deficitárias de software são empresas em desvantagem
marcante frente a seus concorrentes, pois não conseguem alcançar o mesmo desempenho,
qualidade e agilidade. Destacam-se, também, no setor empresarial, as instituições financeiras
que desde cedo buscaram a informatização de seus serviços. Estas instituições operam,
basicamente, com informações em grandes volumes e, atualmente, elas são completamente
inviáveis sem o uso maciço de software. No setor governamental, vê-se, também, grandes
investimentos em desenvolvimento contínuo de novos softwares para melhorar o controle e
eficiência dos serviços públicos. A maior parte das operações tributárias, por exemplo, é
informatizada no Brasil, desde a emissão de notas e cupons fiscais interligados em tempo
real com os servidores da receita estadual e federal, até os controles de declarações de

13 Caderno 1 - Introdução à Engenharia de Software UTFPR

impostos das empresas e de pessoas físicas. Muitos dos serviços públicos são, também
acessíveis via portais (i.e., software) na internet.

A Engenharia de Software se aplica ao desenvolvimento de qualquer tipo de software para

qualquer área de aplicação. Ele visa prover aos desenvolvedores meios de se alcançar maior
produtividade, qualidade, segurança e eficiências da produção de software com o objetivo de
se poder oferecer softwares adequadas às demandas atuais.

14 Caderno 1 - Introdução à Engenharia de Software UTFPR

PROBLEMAS DA ENGENHARIA DE SOFTWARE

Apesar de toda a proeminência da indústria de software e das novidades tecnológicas

frequentes em termos de novas ferramentas, linguagens de programação, bibliotecas e
frameworks usados por engenheiros, analistas e programadores, o desenvolvimento de
software ainda enfrenta problemas graves como relacionado a seguir.

BAIXA PRODUTIVIDADE

Apesar dos avanços, o desenvolvimento de software continua a ser uma atividade difícil
intelectualmente para o ser humano e que exige grande esforço, concentração e talento dos
profissionais. A concepção de soluções, a criação de arquiteturas para as soluções que
otimizem a estrutura e forma de operação do software, a elaboração da lógica e, por
consequência, dos algoritmos necessários à realização das tarefas desejadas e a codificação
dos programas continuam a ser atividades árduas que exigem um tempo considerável de
reflexão e síntese. Cada novo componente, função ou instrução afeta o conjunto do software,
criando interdependências e alterando a dinâmica do software. Assim, o profissional de
desenvolvimento precisar continuamente atento à medida que constrói a solução e define sua
estrutura e lógica de operação. Como consequência destas dificuldades, o desenvolvimento
de software é lento, levando a uma baixa produtividade pois cada desenvolvedor produz
poucas dezenas de linhas de código (i.e., linhas especificadas, projetadas, programadas e
testadas) por dia.

A evolução da Engenharia de Software ao longo de seus mais de 50 anos ajudou a melhorar

a forma de desenvolvimento de software com ganhos de produtividade. Por exemplo, a
produtividade (i.e., o número de linhas produzidas por tempo) de um programador FORTAN
seguramente era consideravelmente maior do que a de um programador ASSEMBLY no
início dos anos 70. Entretanto, não se viu saltos importantes de produtividade no
desenvolvimento de software nas últimas décadas, sugerindo que se alcançou uma certa
estagnação na facilidade ou capacidade de se produzir software. Novas tecnologias de
desenvolvimento (e.g., novas linguagens de modelagem e programação, compiladores e
ambientes de desenvolvimento), têm trazido muito pouca contribuição para o aumento da
produtividade.

De certa forma, a baixa produtividade de desenvolvimento de software está relacionada com

a forma que a computação tomou ao longo das décadas. Basicamente, a maneira como os
computadores modernos operam é análoga àquela dos computadores originais. Utiliza-se
uma memória para armazenar um conjunto de instruções (i.e., programa) que é percorrido

15 Caderno 1 - Introdução à Engenharia de Software UTFPR

executando-se cada instrução, uma a uma, na ordem estabelecida, podendo acessar dados de
entrada, processá-los e produzir dados ou ações de saída. As linguagens existentes, em geral,
foram concebidas para seguir este modelo de computação e impõem ao desenvolvedor que
ele siga estritamente esta forma sequencial de pensar e estruturar a lógica dos softwares. O
autor deste caderno considera que, mantendo-se este modelo de computação, não há
perspectivas de melhoras substanciais na produtividade de desenvolvimento de software.

PRAZOS LONGOS

Dado que o desenvolvimento de software é uma tarefa relativamente lenta (i.e., de baixa
produtividade), o tempo de desenvolvimento tende a ser, naturalmente, longo. Se um
desenvolvedor produz poucas dezenas de linhas por dia e se o software pretendido possuirá
dezenas ou centenas de milhares de linhas, é fácil perceber que os empreendimentos
facilmente se estendem por muitos meses ou anos. Uma alternativa, visando encurtar os
prazos, seria aumentar o número de profissionais na equipe, de forma que mais pessoas,
produzindo pouco cada uma, gerem muitas linhas de código ao final. Na verdade, essa é a
única alternativa para enfrentar este problema de prazos longos. Porém, esta estratégia
merece atenção, pois o incremento de mais profissionais não aumenta proporcionalmente a
produção de software. Há, inclusive, uma frase ilustrativa que diz que “Nove mulheres não
fazem um bebê em um mês.”. O fato é que aumento da equipe gera dificuldades crescentes
de comunicação, sincronização e gerenciamento dos trabalhos das pessoas, reduzindo a
produtividade de cada indivíduo. A tabela a seguir ilustra, com dados de um estudo feito pela
IBM, o impacto da ampliação da equipe de desenvolvimento na produtividade dos
desenvolvedores. Embora a ampliação da equipe seja uma alternativa possível para redução
de prazo, deve-se cuidar de bem balancear o tamanho máximo da equipe e bem organizar a
distribuição e controle das atividades realizadas por todos para que a produtividade média
seja razoável.

Tabela 1 – Relação entre o tamanho da equipe e a produtividade.

Fonte: Ganssle, 2008

Tamanho do Projeto: homens/mês Produtividade: linhas de código/mês

1 439
10 220
100 110
1000 55

De qualquer maneira, desenvolver softwares (notadamente softwares maiores) não é uma

atividade breve. O tempo envolvido tende a ser longo e é normal trabalhar-se com

16 Caderno 1 - Introdução à Engenharia de Software UTFPR

cronogramas de muitos meses ou anos. Estes prazos longos têm, entretanto, várias
consequências graves. Prazos longos implicam que uma demanda de software de hoje só será
atendida com o produto acabado meses ou anos mais tarde. Há, portanto, o risco de que a
utilidade imaginada para o software já não seja a mesma na data da entrega do software, pois
a demanda pode mudar ou evoluir durante seu desenvolvimento. Dito de outra forma, prazos
longos podem levar à perda de “janelas de oportunidades”, ou seja, havia uma oportunidade
de se vender e usar um determinado software em um certo período, mas, passado este
período, aquela oportunidade pode deixar de existir. Por exemplo, em um certo período, as
pessoas poderiam estar interessadas em softwares para compras remotas por causa da
pandemia de 2020. Passada esta condição, o interesse das pessoas por tal software poderia
diminuir ou deixar de existir, pois as causas podem ter desaparecido. Outro aspecto ruim dos
prazos longos de desenvolvimento é que o cliente relata uma demanda hoje, mas que só será
suprida um bom tempo depois. Durante este período de espera, o cliente ficará desprovido
da solução e sofrerá as consequências desta falta do software. Este “sofrimento” pode ter
vários significados conforme a natureza da demanda, mas pode representar perdas financeiras
prolongadas, insatisfação de usuários e clientes, perdas de mercados para concorrentes, entre
outros efeitos graves.

ALTOS CUSTOS

O desenvolvimento de software é, frequentemente, um empreendimento de alto custo, pois

são necessários vários (ou muitos) profissionais, com qualificação, trabalhando durante
vários meses (ou anos). Some-se a isso, ainda, a necessidade de uma infraestrutura de suporte
também custosa, envolvendo computadores e ferramentas de desenvolvimento (e.g., software
de modelagem, simulação, compilação e testes). Por exemplo, o desenvolvimento de
software pequeno, a ser feito por três desenvolvedores em um período de 12 meses (incluindo
a especificação, projeto, codificação e testes), facilmente teria um custo na casa de R$
300.000,00. Incluindo-se impostos, margem de lucro e despesas administrativas, pode-se
alcançar um preço de R$ 400.000,00 para este software. Nota-se que apesar de ser um
software pequeno, um preço deste nível pode ser considerado muito caro e, até, inviável para
muitos consumidores.

Quando se considera softwares de médio e grande porte, os custos (e, consequentemente, os

preços) avançam para a casa de milhões ou muito milhões de reais. Por exemplo, um software
de gestão de RH de algum ministério público federal custaria algo em torno de 100 milhões
de reais (baseado em um caso real divulgado, com uma equipe de 100 profissionais atuando
durante 5 anos). O desenvolvimento de softwares maiores envolve custos ainda mais
elevados, como foi o caso do jogo Diablo 3 que envolveu uma equipe de 2 mil pessoas

17 Caderno 1 - Introdução à Engenharia de Software UTFPR

(segundo informações do casting do jogo) a um custo de 250 milhões de dólares (segundo
informações não oficiais na internet).

O custo de desenvolvimento de um software depende de vários fatores, entre eles: seu

tamanho, sua complexidade, sua confiabilidade, suas restrições de tempo real e suas
concorrências de tarefas. Segundo Jack Ganssle (Ganssle, 2008), alguns tipos de software
(em especial ele se refere à firmware) são “a coisa mais cara do universo”, querendo dizer
que nenhum outro empreendimento humano alcança valores tão altos para seu
desenvolvimento. Ele cita, como exemplo, o modelo de avião de caça americano F-22, cujo
preço estimado é de 333 milhões de dólares por unidade, dois quais a metade é custo de
software.

Embora altos preços possam representar um grande atrativo para a indústria de software e
profissionais envolvidos, há consequências muito negativas nesta questão. Quanto maior o
custo de um software, mais difícil se torna a aquisição pelos consumidores e, por
consequência, menos consumidores são capazes de adquirir o software. Assim, softwares
mais caros são limitados a consumidores com maior poder aquisitivo, como grandes
empresas, criando uma espécie de “elitização de software”. Empresas menores, com menor
capacidade de investimento, tendem a não serem capazes de se equipar com software de
gestão, de produção e, mesmo, softwares embarcados em seus produtos, dos quais
precisariam para crescer ou competir em boas condições no mercado. De forma análoga, na
esfera governamental, cidades, estados e nações com menor capacidade de investimento,
também, sofrem com a falta de software, incapazes de adquirirem ou desenvolverem
softwares que agilizem e deem confiabilidade e eficiência aos serviços públicos realizados.
Desta forma, pode-se afirmar que o alto custo de software tem sido um impeditivo para
acelerar a modernização, ampliar a eficiência e melhorar a qualidade de vida na sociedade
atual.

BUSCA CRESCENTE POR QUALIDADE

No passado, a existência de falhas (ou seja, baixa qualidade) nos softwares utilizados pelas
pessoas e empresas era, até certo ponto, tolerada, dada a “urgência” que se tinha em utilizá-
los. Também, o senso crítico não era tão bem desenvolvido nos consumidores, que
consideravam que algumas falhas de software seriam “normais”, pois software era algo ainda
recente e se entendia que em novas versões dos produtos as falhas seriam corrigidas.
Gradualmente, os consumidores foram se tornando mais exigentes e críticos com relação à
qualidade dos softwares entregues. Atualmente, falhas de software não mais toleradas,
criando grande irritação nos usuários.

18 Caderno 1 - Introdução à Engenharia de Software UTFPR

A questão é que não existe mágica em desenvolvimento de software para que se produza
software de maior qualidade evitando falhas em seu funcionamento ou no que ele entrega de
valor aos usuários. Para se alcançar softwares de maior qualidade é necessário investir mais
tempo em seu desenvolvimento. As especificações devem ser feitas com mais atenção, com
mais revisões e utilizando técnicas mais elaboradas, levando a um maior tempo e quantidade
de horas dedicadas. O projeto do software deve ser conduzido de maneira mais aprofundada,
com maior atenção à concepção da arquitetura do software e estudando com maior rigor a
estruturação e comportamento esperado do software nos seus diferentes modos de operação
e condições, levando a um maior tempo e quantidade de horas dedicadas. A codificação dos
programas deve ser mais precisa, atrelada ao projeto técnico desenvolvido e aplicando
métodos e ferramentas de forma disciplinada, levando a um maior tempo e quantidade de
horas dedicadas. Finalmente, a verificação do software de ser feita de maneira mais
sistemática, planejando-se os testes e inspeções necessários e aplicando técnicas e
ferramentas apropriadas, levando a um maior tempo e quantidade de horas dedicadas.

Desta forma, é fácil constatar que um software de maior qualidade significa um software cujo
desenvolvimento é mais longo e cujo custo é maior. Ou seja, o consumidor que deseja
qualidade deverá pagar por esta qualidade. Existe uma relação não proporcional entre a
qualidade desejada para o software e o esforço de desenvolvimento (e, consequentemente,
seu custo), pois quanto maior o nível de qualidade desejado, muito maior será o custo do
produto. Como exemplo, no desenvolvimento de software aeronáutico considera-se que o
desenvolvimento de um software com qualidade máxima (em termos de segurança às
pessoas) exige um esforço (ou seja, tempo e custo) de oito vezes o que seria exigido para o
mesmo software com exigência mínima de qualidade (em termos de segurança). Neste setor,
a prática demonstrou que para garantir certo nível de qualidade é necessário investir o dobro,
triplo ou até oito vezes mais esforço no desenvolvimento pois o aumento do nível de
qualidade para um software reduz muito sua produtividade.

Desta forma, quando se inicia o desenvolvimento de um novo software é essencial que se

determine o nível de qualidade requerido pelo cliente para o produto final. O objetivo da
equipe de desenvolvimento deveria ser o de se alcançar o “mínimo de qualidade” que
satisfaça o cliente para, com isso, minimizar o esforço de desenvolvimento (e, por
consequência, seu prazo e custo). É preciso que os clientes tenham consciência do quanto
custa a qualidade de um produto para que possam definir qual nível de qualidade, de fato, é
necessário. Falhas na identificação do nível de qualidade adequado para um produto e
mercado levam a softwares caros demais, a projetos entregues muito tardiamente, ou a
frustações com a baixa qualidade e utilidade que o software entrega.

AUMENTO DA COMPLEXIDADE

19 Caderno 1 - Introdução à Engenharia de Software UTFPR

A complexidade de um software, em termos das dificuldades técnicas em desenvolvê-lo por
causa das exigências do mercado, tem crescido ao longo das décadas. Os clientes buscam,
cada vez mais, software com mais funcionalidades, com melhor desempenho, com
funcionalidades mais sofisticadas e “inteligentes”, com interfaces mais ergonômicas, entre
outras exigências crescentes. Da mesma forma, os fornecedores de software impulsionam
uma maior complexidade dos softwares visando se destacar dos concorrentes criando
software com um número maior funcionalidades e com sofisticação. Como consequência, os
softwares têm se tornado mais complexos e, assim, o esforço de desenvolvimento também
têm se tornado maior.

No presente, continua a aumento da pressão do mercado e concorrentes por softwares com

mais funcionalidade, mais eficientes, mais ergonômicos e com mais funcionalidades
“inteligentes” e úteis. As empresas devem ser capazes, então, de entregar softwares que
respondam a estas expectativas, mas isso ocorre ao custo de uma queda na produtividade e
de um aumento nos custos e prazos. A tendência deve continuar mesma para os próximos
anos, ou seja, o mercado tende a sempre desejar softwares mais sofisticados, aumentando a
sua complexidade e, portanto, os esforços de desenvolvimento.

FALTA DE MÃO DE OBRA QUALIFICADA

Para resolver ou minimizar os problemas citados anteriormente é essencial se dispor de

profissionais qualificados para o desenvolvimento de software. Esses profissionais são
técnicos e graduados em computação que atuam com o desenvolvimento de software. No
Brasil há um número significativo de cursos técnicos e de graduação em escolas públicas e
privadas que formam esses profissionais. Estimativas da Brasscom (Associação Brasileira
das Empresas de Tecnologia da Informação e Comunicação), por exemplo, mostram que as
instituições brasileiras de ensino formam em torno de 46 mil profissionais por ano com perfil
tecnológico, mas que esse número é insuficiente, gerando um déficit da ordem de 24 mil
especialistas por ano.

Esta falta de mão de obra qualificada, não é exclusividade no Brasil. Países desenvolvidos
têm uma falta ainda maior de recursos humanos, pois eles possuem um rol ainda maior de
empresas de tecnologia e de desenvolvimento de software.

Dado que o crescimento demográfico está estagnado na maioria dos países desenvolvidos,
uma alternativa para fazer frente a falta de mão de obra no setor seria atrair pessoas de outras
áreas para atuar com tecnologias e, mais especificamente, com o desenvolvimento de
software. Outra alternativa, seria importar pessoas de outros países ou regiões.

20 Caderno 1 - Introdução à Engenharia de Software UTFPR

PERSPECTIVA HISTÓRICA E FUTURA

EVOLUÇÃO DA DEMANDA X EVOLUÇÃO DA OFERTA DE SOFWTARE

A computação não nasceu como uma descoberta a partir de algum novo princípio. Na
verdade, ela foi construída, com os meios que se pode encontrar na época, visando atender a
uma necessidade muito significativa da época e que estava sobre grande pressão. Entre outras
necessidades de modernização de governos e grandes empresas, havia também a pressão do
pós-guerra nos anos 40. O conflito mundial mostrou o grande valor estratégico de se poder
dispor de informações de forma rápida para a tomada de decisões e do grande valor
operacional de se poder automatizar diferentes tipos de máquinas.

Em resposta a esta demanda crescente se fez grandes investimentos para se conceber e

construir as primeiras máquinas programáveis de processamento de dados em “alta”
velocidade, que foram batizadas de computadores. Os primeiros computadores foram
rapidamente aplicados em tarefas urgentes na época pelo setor de defesa, financeiro,
governamental e grandes corporações. Assim, parte da demanda mais urgente foi atendida,
mas, ao mesmo tempo, criou-se com estas novas máquinas uma expectativa ainda maior
sobre os novos potenciais dos computadores para muitos outros usos. Deu-se, desta forma,
início ao uma corrida para produzir software visando atender a demanda crescente.

Um balanço feito em 1968 (The Crisis Report) mostrou que a oferta era muito deficitária
frente à demanda crescente e que o “problema” de não se conseguir ofertar software na
proporção da demanda existente no início da computação só se agravou nos anos 50 e 60,
levando a uma situação de crise. Podemos entender por “crise” uma situação em que um
“problema” persiste e só aumenta ao longo de um certo período de tempo.

Na Figura 4, pode-se observar, de forma aproximativa, na parte mais à esquerda que o

crescimento da demanda (linha tracejada) supera continuamente o crescimento da oferta
(linha contínua) de software até o final dos anos 60. Nesta condição, a diferença entre as duas
curvas (também chamada “Gap”) aumenta continuamente. Com a criação da Engenharia de
Software, nesta época, houve uma profissionalização do desenvolvimento de software cujo
objetivo, entre outros, era de reduzir o gap entre oferta e demanda de software. Observando
a parte intermediária do gráfico na Figura 4, observa-se que o crescimento da oferta avança
com as novas tecnologias e novas abordagens de desenvolvimento até os 90. Porém, percebe-
se que neste período a demanda também cresce, mas em uma velocidade ainda maior. Ou

21 Caderno 1 - Introdução à Engenharia de Software UTFPR

seja, mesmo com os avanços em Engenharia de Software e com todas as muitas tecnologias
criadas nos anos 70, 80 e 90, a crescimento em produtividade da oferta não conseguiu seguir
a velocidade de crescimento da demanda. Desta forma, a crise de software não se resolveu e
sim piorou neste período, levando a uma situação mais grave que pode ser denominada de
“caos”. De fato, em 1995 foi publicado, pelo The Standish Group International (SGI), um
estudo a respeito das falhas em projetos de software, dos fatores destas falhas e de como
reduzi-las (SGI, 1995). O estudo mostrou um cenário muito ruim, que os autores
denominaram de uma situação de “caos” dada sua gravidade. Segundo este estudo, apenas
9% dos projetos em grande empresa obtiveram sucesso (i.e., foram concluídos no prazo e
dentro do orçamento), contra 16.2% e 28% em médias e pequenas empresas,
respectivamente. O relatório aponta, também, que em torno de 30% dos projetos sofreram
desvios e acabaram sendo cancelados antes de sua conclusão. Estes problemas, por
consequência, produziram como efeito uma menor capacidade de oferta de software ao
mercado, ampliando o gap com relação à demanda por software.

Figura 4 – Evolução da demanda e oferta de software.

Nos anos 2000, a situação geral se manteve com a demanda crescendo continuamente e de
forma mais acelerada do que a oferta, ampliando, ainda mais, o gap existente. Os avanços
em Engenharia de Software e nas tecnologias de computação não conseguiram apresentar
maneiras substancialmente mais eficientes de se produzir software em grande escala. Pode-
se, inclusive, afirmar que esta “corrida” está perdida, pois não se vê algum caminho viável
para aumentar a oferta de software por meio de um aumento expressivo da produtividade de
desenvolvimento. Talvez estejamos enfrentando hoje uma consequência de decisões do

22 Caderno 1 - Introdução à Engenharia de Software UTFPR

passado e chegando a um beco sem saída da produção de software. Considere, por exemplo,
a baixa produtividade de programação. Ela se deve à dificuldade de construir códigos (i.e.,
algoritmos) usando as linguagens existentes (como Java e C#) porque estas linguagens
impõem uma forma de desenvolvimento basicamente sequencial em que o desenvolvedor é
responsável por garantir a consistência de todas as muitas partes do código para se atingir as
funcionalidades ao final. Esse é o mesmo princípio das linguagens do passado, quando a
pressão por produtividade era menor e essas linguagens eram consideradas razoáveis. O fato
é que herdamos esses modelos de programação que, cada vez mais, são insuficientes para as
necessidades atuais. Poderíamos pensar, então, em novas linguagens, mas devemos lembrar
que as linguagens são como são, pois elas precisam se adequar aos modelos de computação
atuais (i.e., a forma como os computadores estão estruturados e funcionam). Parece, então,
que o “beco sem saída” não é só de software, mas também de todo o modelo de computação
existentes que evoluiu desde as primeiras máquinas, mas sempre mantendo os mesmos
princípios.

Quando olhamos para os próximos 10 ou 20 anos, e considerando que continuaremos com

apenas poucos avanços marcantes em computação, o cenário que se apresenta é bem
perturbador. Como ilustra a Figura 4, o autor deste caderno entende que a demanda
continuará a crescer, pois a expectativa de sociedade por modernidade (leia-se, maior
quantidade e maior complexidade de software) não mostra sinais de se conter, ao contrário.
A sociedade em geral não sabe das dificuldades da indústria de software e, assim, continuará
a querer mais softwares e esperar por produtos mais complexos (i.e., com funcionalidades
mais sofisticadas) e de melhor qualidade (i.e., sem falhas, melhores de se usar e que
entreguem resultados de maior valor). Por outro lado, há a possibilidade de queda da oferta
de software ao longo das próximas década, ao invés de crescimento. Isso se deve ao fato de
que a produção de software depende da produtividade que a Engenharia de Software e as
tecnologias podem oferecer aos desenvolvedores e do número de desenvolvedores
disponíveis. A produtividade não deve crescer de maneira significativa nas próximas
décadas, com não cresceu nas décadas passadas. De forma consciente, o que podemos esperar
são apenas pequenos melhoramentos no desenvolvimento de software, levando a pequenos
ganhos de produtividades. Por outro lado, em relação ao número de desenvolvedores,
poderemos alcançar uma saturação na formação de profissionais, visto que o interesse dos
jovens pela área começa a se manter mais estável. A busca por candidatos que seguiriam
outros caminhos profissionais para convencê-los a vir para a computação não parece que
produzirá tanto efeito, mesmo com melhores salários e melhores condições de trabalho. A
atividade profissional em computação exige certo perfil dos indivíduos (e.g., capacidade de
concentração, determinação para enfrentar desafios, capacidade de adaptação, interesse por
novas tecnologias e persistência) que não são compatíveis ou do gosto de muitas pessoas.
Deve-se, também, considerar a evolução do crescimento demográfico no Brasil e no mundo.
Segundo o IBGE, o crescimento demográfico atual é baixo e a previsão é de que o Brasil
alcance a estagnação (e.g., crescimento zero) da população em 20 anos, com início do

23 Caderno 1 - Introdução à Engenharia de Software UTFPR

declínio populacional já em 30 anos. Em outros países desenvolvidos esta situação já foi
alcançada. Assim, não podemos contar que haverá mais pessoas e, portanto, um número
maior de desenvolvedores. Na verdade, esta variável só deverá diminuir. Por fim, a ideia de
importar pessoas de outros países não é ruim, mas é limitada em número e no tempo, pois os
países em desenvolvimento já descobriram que precisam preservar seus jovens para suas
demandas internas e começam a oferecer condições mais atrativas para permanência em seus
países de origem.

Como mostra a figura 4, a perspectiva é que o gap continue a avançar gerando mais pressão
sobre a indústria de software. Sem uma solução à vista, poderíamos dizer que estamos em
uma situação de “a espera de um milagre” na computação e Engenharia de Software. Por
“milagre” quer-se dizer encontrar uma outra forma de computação e de desenvolvimento de
software que permite altíssima produtividade dos profissionais.

24 Caderno 1 - Introdução à Engenharia de Software UTFPR

CONCEITUAÇÃO DE SOFWTARE

Intuitivamente, o significado de software parece ser bastante evidente, designando programas

para computadores. Inclusive, os profissionais de outras áreas fazem esta associação direta.
Neste capítulo, será feita uma discussão um pouco mais aprofundada a respeito deste
conceito, pois, para nós, (futuros) profissionais da área, não pode haver dúvidas sobre o que
estamos falando. Além disso, um entendimento equivocado do que é um software pode levar
a grandes dificuldades no seu desenvolvimento, na interação com o mercado consumidor e
na própria atuação do profissional da área de computação.

CONCEITO DE SOFWTARE BASEADO NA SUA COMPOSIÇÃO

Em uma visão simplista, costuma-se considerar software como sendo apenas o código ou
programa que comanda a execução de tarefas em um computador. Muitas vezes, inclusive,
“software” e “programa” são usados como sinônimos. Podemos nos questionar, de imediato,
se estamos falando de código fonte ou código objeto. Qual dos dois é o software? Na verdade,
ambos, pois trata-se do mesmo conhecimento, mas em duas linguagens diferentes e um está
diretamente relacionado ao outro. Entretanto, o código fonte é uma propriedade da empresa
produtora e costuma ficar resguardado de acesso por terceiro pois representa um capital
intelectual da empresa, enquanto, em geral, o código executável é licenciado para uso pelos
clientes mediante algum contrato. Assim, em uma visão de sua composição, um software
pode ser definido como um conjunto de programas fonte e seus respectivos programas
executáveis. Porém, esta é uma muito limitada. Em uma visão mais ampla (i.e., em uma visão
de produto), um software pode ser composto por outros componentes (também denominados
artefatos), além de seus programas, conforme listado a seguir.

• Especificações
Em todo desenvolvimento de software existe um conhecimento crítico a ser
construído que é a análise e especificação dos propósitos do software. Este
conhecimento pode ser documentado de diferentes formas como em documentos de
visão do produto e de especificação de requisitos. Estes documentos são parte
integrante de um software, pois, sem eles, o entendimento, a justificativa e parte da
existência do software se perde.

• Documentos Técnicos de Projeto

Como em todo projeto de engenharia, o desenvolvimento de um software envolve a

elaboração de um conjunto de documentos técnicos de projeto e construção do

25 Caderno 1 - Introdução à Engenharia de Software UTFPR

 produto, envolvendo modelos estruturais e funcionais, desenhos de arquitetura,
detalhamentos e dicionários de dados, entre outros. Estes documentos são parte
integrante do software, embora não sejam entregues ao cliente final. Eles são
mantidos e atualizados ao longo da vida útil do produto, permitindo o entendimento
e controle dos conhecimentos técnicos envolvidos.

• Planos e Resultados de Verificação

A qualidade de um software é avaliada por meio de um planejamento de verificação,
envolvendo a aplicação de técnicas de teste, inspeção e revisões. Ao longo da vida
útil do software, novas versões poderão ser produzidas exigindo a repetição das
verificações de qualidade, que devem ser mantidas e ajustadas.

• Gerência de Configuração (Configuration Management)

Todos os artefatos e conhecimento produzidos durante o desenvolvimento de um
software, incluindo os códigos, devem ser armazenados de forma controlada e as
diferentes configurações do software (composição dos módulos que formam as
diferentes versões), entre outros, devem ser adequadamente registradas, pois
representam o conhecimento de como gerar o código que é entregue ao mercado.

• Arquivos e Bases de Dados

Além de códigos, um software também envolve e contém estruturas externas de
armazenamento e gerenciamento de dados. Arquivos de dados de inicialização,
arquivo de variáveis persistentes, arquivos de scripts, arquivos e tabelas de dados de
referências e estruturas de banco de dados são exemplos de artefatos de dados usados
e que fazem parte da operação de um software.

• Registros de PI e Marcas
Dado que um software pode representar um bem e pode ser inovador, é possível haver
registros de propriedade ou marcas associados diretamente a ele e que fazem parte do
produto.

• Conhecimentos ou Ativos Intangíveis

Além do que foi relacionado, existem ainda outros componentes de caráter mais
intangível relacionados com software. Um grande exemplo é o conhecimento que
reside nos profissionais que desenvolvem e mantém o software. Parte deste
conhecimento não pode ser transferido para documentos técnicos, pois têm uma
forma mais abstrata como lembranças sobre as decisões tomadas, dúvidas que
surgiram e foram ou não sanadas, alternativas que foram escolhidas ou descartadas,
analogias feitas com experiências passadas, entre outros. Assim, a equipe de

26 Caderno 1 - Introdução à Engenharia de Software UTFPR

 desenvolvimento guarda uma parte do conhecimento do software e, portanto, de sua
composição.

CONCEITO DE SOFWTARE BASEADO NO SEU PAPEL

Uma outra forma de definir o que é um software seria explicar qual é seu papel ou sua
natureza em vez de citar sua composição. O termo software foi criado especificamente para
se referir aos programas que comandam as ações em um computador (ou seja, em um
equipamento eletrônico programável). Esse termo em inglês foi escolhido para fazer
oposição ao termo mais antigo “hardware” e que foi adotado em computação para se referir
à parte elétrica e eletrônica dos computadores. O prefixo “soft” em software se refere às
características de maleabilidade, flexibilidade ou remodelagem que se tem na programação
de computadores, pois softwares podem ser alterados ou substituídos mais facilmente se
comparados com o hardware de computadores. Assim, software seria a parte “maleável” dos
computadores, enquanto hardware representa a parte mais estável ou material de um
computador.

O termo “software” é largamente adotado mundialmente, inclusive no Brasil, e a palavra já

foi abrasileira fazendo parte dos dicionários da língua portuguesa (i.e., não há necessidade
de colocar o termo em itálico como se fosse uma palavra estrangeira e pode-se utilizá-la no
plural). Entretanto, existem outros termos equivalentes em outras línguas como no francês e
no português. Em francês, utiliza-se o termo “logiciel” para se fazer referência exatamente
ao que software significa e é o termo utilizado no cotidiano. Inclusive, a área de
conhecimento é denominada “Génie Logiciel” (i.e., Engenharia de Software). No português,
existe a palavra “logiciário” como tradução de software, mas também se encontra referências
à “logicial”, por influência francesa.

Os termos “logiciário” em português e “logiciel” em francês têm uma raiz interessante que é
o “logic”. Nas duas línguas desejou-se destacar essa correlação de software com lógica ou
com a parte lógica dos computadores. A lógica em computação pode ser entendida como o
raciocínio que governa alguma atividade e, portanto, pode-se entender que o software é quem
determinar esse raciocínio. Dizer que o software corresponde à parte lógica que define o que
um computador deve fazer se mostra como uma boa definição (melhor do dizer que é parte
maleável de computador). Além disso, deve-se lembrar que nem sempre a lógica que
comanda um computador é construída na forma de programas (i.e., conjunto de instruções
usando alguma linguagem de programação). Por exemplo, a tecnologia de lógica
configurável (e.g., FPGA) permite definir circuitos que comandam a lógica de
funcionamento de computadores (sem haver programas). Porém esse circuito seria
equivalente ao que um software faria se fosse utilizado um microprocessador e programas.

27 Caderno 1 - Introdução à Engenharia de Software UTFPR

REFERÊNCIAS BIBLIOGRÁFICAS

Swebok, 2014 Guide to Software Engineering Body of Knowledge, Ed. P. Bourque

e R. E. Fairley, IEEE Computer Society, 2014.
Glass, 2001 Glass, R. L., Frequently Forgotten Fundamental Facts about
Software Engineering, pg. 112, IEEE Software, May/June, 2001.
Report NATO, 1968 Report on a conference sponsored by the NATO SCIENCE
COMMITTEE, Garmisch, Germany, October, 1968.
Takada, 2020 Takada, S., Cuadros-Vargas, E., Impagliazzo, J. et al., Toward the
visual understanding of computing curricula. Education and
Information Technologies, 2020.
SBC, 2017 Zorzo, A. F., Nunes, D., Matos, E. S., Steinmacher, I., Leite, J. C.,
Araujo, R., Correia, R. C. M., Martins, S., Referenciais de Formação
para os Cursos de Graduação em Computação 2017. Sociedade
Brasileira de Computação (SBC). 153p, 2017.
Impagliazzo, 2017 Impagliazzo, J., Establishing Computing Curricula: An Evolving
Professional Endeavor, 2017.
ACM/IEEE, 204 Software Engineering 2004 Curriculum Guidelines for
Undergraduate Degree Programs in Software Engineering,
ACM/IEEE, 2004.
MEC, 2012 MEC. Parecer - Diretrizes Curriculares Nacionais para os cursos
de graduação em Computação, Parecer. 2012. Disponível em:
http://portal.mec.gov.br/index.php?option=com_docman&task=
doc_download&gid=11205&Itemid=.
CONFEA, 2018 RESOLUÇÃO nº 1.100, de 24 de maio DE 2018,
http://normativos.confea.org.br/ementas/visualiza.asp?idEmenta=
66199.
SGI, 1995 The Caos Report, The Standish Group International inc, 1995.
Ganssle, 2008 Ganssle, J., The Art of Designing Embedded Systemas, Newnes,
segunda edição, 2008.

28 Caderno 1 - Introdução à Engenharia de Software UTFPR

ANEXO I – TABELA DE PESOS DAS ÁREAS DE CONHECIMENTO DE COMPUTAÇÃO

Tabela de Pesos Relativos das Áreas de Conhecimentos de Computação (Takada,

2020)

A tabela a seguir relaciona as categorias e áreas de conhecimento (duas colunas da esquerda)

com os seis currículos em computação (demais colunas a direita), indicando para dada item
(linha) seu peso mínimo e máximo. As cores verde e azul destacam os mínimos e os máximos
pesos, respectivamente.

29 Caderno 1 - Introdução à Engenharia de Software UTFPR