Alguns Fundamentos da Engenharia de Software
O que é Engenharia de Software?
É
a mesma coisa que Ciência da Computação? Ou é uma entre muitas
especialidades da Ciência da Computação? Ou dos Sistemas de Informação,
ou do Processamento de Dados, ou da Informática, ou da Tecnologia da
Informação? Ou é uma especialidade diferente de todas as anteriores?
Na
maioria das instituições brasileiras de ensino superior, o conjunto de
conhecimentos e técnicas conhecido como Engenharia de Software é
ensinado em uma ou duas disciplinas dos cursos que têm os nomes de
Ciência da Computação, Informática ou Sistemas de Informação. Raramente,
em mais disciplinas, muitas vezes opcionais, e muitas vezes oferecidas
apenas em nível de pós-graduação. Algumas instituições oferecem cursos
de pós-graduação em Engenharia de Software, geralmente no nível de
especialização.
O
uso do termo para designar uma carreira profissional também não é muito
comum, mesmo em organizações que produzem grande quantidade de
software, ou até naquelas em que o desenvolvimento de software é
atividade fim. Programas e exames de certificação em Engenharia de
Software são pouco conhecidos, ao contrário do que acontece com algumas
linguagens e tecnologias usados por esses profissionais.
Em
outros países, a situação é um pouco diferente. Algumas universidades
americanas oferecem programas de graduação, mestrado e doutorado na
área. O IEEE (Institute of Electrical and Electronics Engineers), principal organização internacional de profissionais de Engenharia Elétrica, através da Computer Society, que forma o seu ramo em Computação, oferece a qualificação de Profissional Certificado para o Desenvolvimento de Software.
Ciência, Engenharia e Valor
Sem
pretender fazer distinções definitivas, vamos explorar o que dizem os
dicionários. O Dicionário Aurélio Eletrônico V.2.0 assim define Ciência e
Engenharia:
Ciência
- Conjunto organizado de conhecimentos relativos a um determinado
objeto, especialmente os obtidos mediante a observação, a experiência
dos fatos e um método próprio.
Engenharia
- Arte de aplicar conhecimentos científicos e empíricos e certas
habilitações específicas à criação de estruturas, dispositivos e
processos que se utilizam para converter recursos naturais em formas
adequadas ao atendimento das necessidades humanas.
Vê-se
que, pelas definições acima, a Ciência focaliza acumulação do
conhecimento através do método científico, com base em experimentos e
observações. Já a Engenharia aplica esses conhecimentos “ao atendimento
das necessidades humanas”. Embora o conhecimento seja certamente uma
necessidade humana, trata-se de uma entre várias outras, sejam
necessidades materiais, como alimentação, moradia, segurança, ou
imateriais, como afeição ou auto-estima. A tudo aquilo que satisfaz a
necessidades, atribui-se um valor. A Engenharia está, portanto, ligada à
noção de valor, e a Engenharia de Software busca gerar valor com o
processamento de informação. A noção de valor tem muitas conseqüências
práticas importantes, e, de fato, a teoria conhecida como “Engenharia de
Software Baseada em Valor” representa uma importante escola de
pensamento dentro da área.
Arte, Técnica, Artesanato, Indústria?
Outros
termos constantes da definição de Engenharia podem ser explorados de
várias formas, com conseqüências interessantes. Por exemplo, é usada a
palavra “Arte”, que o mesmo dicionário define como a “capacidade que tem
o homem de pôr em prática uma idéia, valendo-se da faculdade de dominar
a matéria”, ou “a utilização de tal capacidade, com vistas a um
resultado que pode ser obtido por meios diferentes”. Na Engenharia de
Software, a matéria dominada pelas faculdades humanas consiste em
máquinas de processamento da informação, devidamente configuradas e
programadas. Nesse sentido, os conceitos de “Arte” e “Técnica” são bem
próximos; aliás, a palavra grega techné significa, exatamente, Arte.
O
termo “Arte” abre outras discussões. Não poucos programadores se
consideram como artistas, no sentido de praticantes das Belas Artes, e
valorizam critérios estéticos na criação de seus programas. Isso pode
ter conseqüências boas e ruins, do ponto de vista de gerar valor. Por um
lado, a busca da elegância pode levar à economia e simplicidade de
formas, fazendo com que resultados de melhor qualidade sejam obtidos de
maneira mais produtiva. E, principalmente, levando a escrever programas
que possam ser mais facilmente reutilizados, mantidos e expandidos. Por
outro lado, a auto-satisfação do programador pode ter como preço os
interesses de quem está pagando pelo trabalho dele, ou de quem o usará.
Seja, por exemplo, produzindo programas que ninguém entende, senão o
próprio autor (e, depois de certo tempo, nem ele mesmo). Seja, como
outro exemplo, introduzindo funções que o autor achou interessantes, mas
não são realmente necessárias, nem foram solicitadas.
E
muito próxima de “Arte” está a palavra “Artesanato”, que lembra
produção caseira, em pequena escala, sem a utilização de métodos
industriais, que são caracterizados pela padronização e pela repetição.
E, realmente, parece mais difícil aplicar esses métodos industriais na
confecção de software, do que nos ramos da engenharia do mundo material.
Nestes, as leis físicas impõem limites claramente visíveis ao que pode
ser feito. Na Engenharia de Software, a criatividade não é limitada por
leis físicas, e sim pela capacidade humana de entender e dominar a
complexidade.
Mas
não se pode escapar do fato de que a Engenharia de Software tem que
resolver muitos problemas de ordem industrial. Raramente é possível
construir software profissional sem envolver equipes, às vezes de
dezenas ou até centenas de pessoas; raramente é possível trabalhar na
área sem a pressão de prazos e orçamentos apertados; freqüentemente
defeitos de software podem acarretar prejuízos vultosos, e, em certos
casos, até riscos à vida humana; muitas vezes empreendimentos de
software são afetados por um contexto econômico, político ou social.
Produtos e Ciclos de Vida
A
íntima relação entre a Engenharia de Software e a noção de valor
significa que essa profissão trata o software como produto. Estão fora
do escopo da Engenharia de Software programas que são feitos com
objetivo exclusivamente lúdico: a diversão do programador. Estão fora de
seu escopo também pequenos programas descartáveis, feitos por alguém
apenas para resolver um problema dessa pessoa, e que não serão
utilizados por outros. Mas, se um desses programas interessar a outras
pessoas, e assim passar a ter valor, aparecerão demandas para melhorar
suas qualidades, aumentar suas funções, prolongar sua vida. E aparecerá
quem esteja disposto a investir nisso, com a expectativa de ganhar
dinheiro. Nesse momento, o programa entrou no escopo da Engenharia de
Software e se tornou um produto. Muitos dos produtos de software mais
usados seguiram esse caminho.
Todo
produto tem usuários: aqueles que efetivamente usam o produto. Alguns
produtos são feitos por encomenda de um cliente: aquele que pagará por
sua produção. Outros, chamados de produtos de prateleira, são vendidos
no mercado aberto, a quem se interessar. Neste caso, quem faz o papel do
cliente é quem define que recursos e funções se esperam do produto;
talvez um departamento de vendas, ou de marketing, ou de definição de
produtos de uma organização, ou até, para produtos menores, os próprios
desenvolvedores, colocando o chapéu de investidores de risco. E existem
todos os casos intermediários, em que um produto parcialmente pronto é
completado, adaptado ou incrementado, por encomenda de um cliente.
Como todo produto industrial, o produto de software tem seu ciclo de vida:
· ele é concebido para tentar atender a uma necessidade;
· é especificado, quando essas necessidades são traduzidas em requisitos viáveis;
· é desenvolvido, transformando-se em um conjunto formado por código e outros itens, como modelos, documentos e dados;
· passa por algum procedimento de aceitação e é entregue a um cliente;
· entra em operação, é usado, e sofre atividades de manutenção, quando necessário;
· é retirado de operação ao final de sua vida útil.
O ciclo de vida compreende muitas atividades, que são assunto das diferentes áreas da Engenharia de Software. A Figura 1 mostra um modelo do ciclo de vida do software, usando a notação conhecida como UML (Unified Modeling Language).
Essa notação é usada para descrever muitos aspectos diferentes do
desenvolvimento de software, inclusive as seqüências de atividades que
compõem esse desenvolvimento. O tipo específico de diagrama que é
mostrado na figura é o Diagrama de Atividades, que representa uma
evolução dos tradicionais fluxogramas, usados pelos programadores há
décadas.
É
interessante observar que a codificação, que representa a escrita final
de um programa em forma inteligível para um computador, é apenas uma
pequena parte do ciclo de vida. Muitas pessoas, inclusive alguns
profissionais da informática, acham que a codificação é a única tarefa
de um engenheiro de software.
Figura 1. Modelo UML do ciclo de vida do software
Nos
Diagramas de Atividades da UML, a bolinha cheia representa Início; a
bolinha com um anel adicional representa fim; cada retângulo simples de
cantos arredondados representa uma ação, ou seja, uma atividade simples,
da qual não mostram detalhes; cada seta representa uma transição entre
atividades; as barras paralelas representam início e término de
atividades executadas em paralelo; um retângulo de cantos arredondados
com detalhes internos representa uma atividade estruturada, que é
composta de outras atividades.
Projetos, Atividades e Estruturas Analíticas
Normalmente,
o software é desenvolvido dentro de projetos. Todo projeto tem uma data
de início, uma data de fim, uma equipe e outros recursos. O responsável
por um projeto é chamado de gerente de projeto. O trabalho realizado
dentro de um projeto pode ser descrito por um conjunto de atividades,
que podem possuir relações de dependência, paralelismo, e decomposição
em atividades mais elementares, como no diagrama da Figura 1.
As
atividades são delimitadas por marcos, isto é, pontos que representam
estados significativos do projeto. Geralmente, os marcos são associados a
resultados concretos: documentos, modelos ou porções do produto, que
podem fazer parte do conjunto prometido aos clientes, ou ter apenas
utilização interna ao projeto. O próprio produto é um resultado concreto
associado ao marco de conclusão do projeto, que pode ser utilizado
sozinho, ou como componente de um sistema.
O PMI (Project Management Institute)
é uma organização internacional, com seções em muitos países, inclusive
o Brasil, que tem o objetivo de promover e difundir boas práticas de
gestão de projetos. Para isso, administra programas de certificação de
profissionais nessa área, e publica o guia conhecido PMBOK (Project Management Body of Knowledge).
Nesse
guia, define-se um projeto como um empreendimento temporário realizado
para criar um produto, serviço ou resultado distinto. Um produto, por
sua vez, é definido como um objeto produzido, quantificável e que pode
ser um item final ou um item componente. Uma atividade é definida como
um componente de trabalho realizado durante o andamento de um projeto.
Os
relacionamentos entre as atividades que compõem um projeto são
mostrados em uma estrutura analítica, que o PMBOK define como uma
decomposição hierárquica orientada à entrega do trabalho a ser executado
pela equipe do projeto, para atingir os objetivos do projeto e criar as
entregas necessárias. Estruturas analíticas de projeto podem ser
apresentadas de muitas maneiras. Diagramas de atividade são uma das
representações mais usadas atualmente. Outro tipo de representação usual
é fornecida por planilhas e cronogramas, como aqueles que são
produzidos pela ferramenta Microsoft Project (Figura 2).
Figura 2. Cronograma de um projeto.
Modelos de Referência e Fatores de Produção
O
PMBOK é um exemplo de modelo de referência: uma estrutura de
conhecimento que organiza conceitos, práticas e padrões de uma área. No
caso do PMBOK, a área focalizada é a gestão de projetos de qualquer
natureza, cobrindo assuntos como integração, escopo, tempo, custos,
qualidade, recursos humanos, comunicações, riscos e aquisições.
Outro modelo de referência importante na Engenharia de Software é o CMMI (Capability Maturity Model Integration), que foi formulado pelo Software Engineering Institute da Carnegie-Mellon University.
O CMMI foi encomendado e patrocinado pelo Departamento de Defesa
americano, popularmente conhecido como Pentágono, que o utiliza para
avaliação da capacidade de seus fornecedores de software. Sendo o
Pentágono provavelmente a maior organização compradora de software do
mundo, o CMMI tem grande aceitação da indústria americana de software, e
considerável influência no resto do mundo. A rigor, suas práticas não
são restritas à indústria de software, podendo ser aplicadas ao
desenvolvimento de outros tipos de produtos.
Os conceitos do CMMI têm raízes em comum com o PMBOK, como se pode observar pela similaridade das definições que adota:
Produto - Resultado que se pretende entregar a um cliente ou usuário.
Projeto
- Conjunto gerido de recursos inter-relacionados, que entrega um ou
mais produtos a um cliente ou usuário, com início definido e que,
tipicamente, opera conforme um plano.
Estrutura analítica do projeto - Um arranjo dos elementos do trabalho e dos relacionamentos deles entre si e com o produto final.
Ao
contrário do PMBOK, o CMMI não se limita aos conhecimentos sobre gestão
de projetos. Cobre também áreas técnicas, e focaliza principalmente a
aplicação dos processos ao desenvolvimento de produtos. Um processo,
segundo o IEEE, é uma seqüência de passos executados com um determinado
objetivo; segundo o PMBOK, é um conjunto de ações e atividades
inter-relacionadas, realizadas para obter um conjunto especificado de
produtos, resultados ou serviços.
Um
projeto representa a execução de um processo, e um processo é uma
receita que é seguida durante a realização um projeto; em outras
palavras, o projeto é o empreendimento que concretiza uma abstração, que
é o processo. Não se deve confundir um processo (digamos, uma receita
de bolo) com o respectivo produto (o bolo) ou com a execução do processo
através de um projeto (a confecção de um bolo por determinada pessoa,
em determinado dia).
Processos,
pessoas e tecnologia constituem os fatores de produção, que determinam o
grau de sucesso dos projetos, ou seja: se eles conseguem entregar um
produto de qualidade suficiente, dentro de um prazo aceitável e com
custos viáveis. Portanto, desses fatores dependem a rentabilidade e a
sobrevivência das organizações produtoras.
Para
muitos profissionais, a tecnologia é o fator mais atraente; muitas
vezes, há um otimismo exagerado quanto aos resultados da aplicação de
novas tecnologias. Entretanto, tecnologias aparentemente promissoras
podem levar para um beco sem saída, e, às vezes, tecnologias
consideradas inferiores pelos especialistas lançam raízes permanentes,
graças a forças de mercado. Além disso, a tecnologia só se paga quando
colocada nas mãos de pessoas capacitadas, trabalhando dentro de
processos adequados. Toda introdução de nova tecnologia tem uma curva de
aprendizado: as pessoas precisam ser treinadas, cometem inicialmente
muitos erros e, por isso, podem até se tornarem menos produtivas,
durante algum tempo. Algumas tecnologias mais complexas só se pagam
depois de muitos projetos.
Investir
na capacitação das pessoas é certamente necessário. Entretanto, formar
pessoas é difícil, caro e demorado. Recrutar pessoas capacitadas também:
não há sinais de que a oferta de pessoas com alta qualificação no
desenvolvimento de software venha a se igualar à demanda, em futuro
próximo. Além disso, muitas pessoas produzem menos que a sua capacidade
permitiria, por falta de liderança, por deficiência de ferramentas e
suporte, ou por inadequação de processos.
Dos
investimentos nos fatores de produção, os investimentos nos processos
são geralmente aqueles que podem trazer retorno em prazo mais curto.
Processos também não fazem milagres, mas a melhoria dos processos
costuma trazer benefícios em prazos relativamente curtos, como é
ilustrado por inúmeros relatos de experiência publicados. No mínimo,
contribuem para reduzir o desperdício e o retrabalho, o que geralmente
já traz ganhos muito significativos.
A
melhoria dos três fatores (tecnologias, pessoas e processos) também
requer seu próprio processo: ela deve ser feita em etapas bem-definidas e
controladas, para que as organizações, em prazos relativamente curtos,
possam avaliar se seu investimento está tendo o retorno esperado. E a
principal contribuição de modelos de referência como o CMMI é indicar o
caminho das pedras e o mapa da mina: onde a experiência coletada indica
que o investimento em melhorias é mais rentável, em cada passo da
evolução das organizações.
Conclusão
A
Engenharia de Software visa à criação de produtos de software que
atendam as necessidades de pessoas e instituições e, portanto, tenham
valor econômico. Para isso, usa conhecimentos científicos, técnicos e
gerenciais, tanto teóricos quanto empíricos. Ela atinge
seus objetivos de produzir software com alta qualidade e produtividade
quanto é praticada por profissionais treinados e bem informados,
utilizando tecnologias adequadas, dentro de processos que tirem proveito
tanto da criatividade quando da racionalização do trabalho.
0 comentários