Introdução à engenharia de software

O que é a Engenharia de Software?

A Engenharia de Software abrange um processo, um conjunto de métodos (práticas) e um leque de ferramentas que possibilitam aos profissionais desenvolverem software de altíssima qualidade (PRESSMAN; MAXIM, 2016). 

Fonte: Shutterstock.

Deseja ouvir este material?

Áudio disponível no material digital.

Convite ao estudo

Aqui estamos na primeira unidade do nosso livro. Como não poderia deixar de ser, o caminho que tomaremos para o início de nossos estudos será o da abordagem introdutória da disciplina e, nesse sentido, trataremos, na primeira seção, os aspectos gerais da Engenharia de Software, seus princípios e o ciclo de vida pelo qual passa um produto até que ele esteja pronto para ser comercialmente viável. Depois, na segunda seção da unidade, teremos oportunidade de conhecer metodologias mais atuais e mais ágeis de desenvolvimento, com ênfase para o Extreme Programming, o Scrum e algumas ferramentas que tornam viáveis sua aplicação. Por fim, será pelo conteúdo desenvolvido na terceira seção que entenderemos os meios usados por uma equipe de desenvolvimento para compartilhar e controlar versões de um produto que conjuntamente desenvolvem.

Com o bom aproveitamento deste conteúdo, você conhecerá os fundamentos da Engenharia de Software e o modelo de desenvolvimento que, de uma forma ou de outra, inspirou e serviu como base para os demais modelos que vieram depois dele. Mais uma importante contribuição desta unidade em seu desenvolvimento será dada pelo conteúdo relacionado às metodologias ágeis, bem mais adequadas às demandas atuais de desenvolvimento e preparadas para atribuir ao cliente sua verdadeira importância no processo de criação de um produto que, afinal de contas, será direcionado às suas próprias necessidades.

Assim, a capacidade de bem aplicar os fundamentos de Engenharia de Software, o domínio das metodologias ágeis e a correta utilização de mecanismos de controle de versões de um produto são os resultados que esta unidade pretende ajudá-lo a atingir. Com sua dedicação aos estudos e o adequado aproveitamento do material didático colocado à sua disposição, esses objetivos serão atingidos, sem dúvida. Bom trabalho e sigamos adiante!

Praticar para aprender

Caro aluno, iniciamos esta etapa com um necessário registro temporal: a Engenharia de Software nem sempre foi como a conhecemos hoje, tendo sido necessário considerável esforço para que os profissionais com ela envolvidos a estruturassem como um dos mais importantes ramos da Computação. Seus métodos precisaram passar pelo polimento do tempo para se tornarem bem formatados e úteis para a criação de artefatos de software de qualidade e duradouros. Mesmo com o elevado grau de transformação pelo qual vem passando essa disciplina, algumas práticas permanecem em uso apesar das adaptações e melhorias que vêm acontecendo. Um bom exemplo é a metodologia tradicional de desenvolvimento, criada nos primeiros anos de existência da Engenharia de Software e que ainda baseia muitos procedimentos de software. Como não poderia deixar de ser, a metodologia tradicional será abordada nesta primeira seção, juntamente com os princípios, desde sempre, norteadores da Engenharia de Software.

Você foi contratado por uma pequena empresa de desenvolvimento para atuar como engenheiro de software júnior e, logo nas primeiras semanas de trabalho, deparou-se com um cenário em que não havia um procedimento definido de criação ou manutenção dos produtos de software. Cada componente de dado projeto mantinha uma forma particular de desenvolvimento e de registro das alterações feitas nos produtos e, embora trabalhassem em equipe, não havia papéis definidos entre os integrantes de cada empreitada. Como era de se esperar, esse cenário de ausência de procedimentos e de papéis definidos reprimia o crescimento da empresa, fato que vinha causando frustração generalizada na organização.

Você deverá propor soluções que melhorem a dinâmica e o clima da empresa, incluindo o estabelecimento de uma metodologia de trabalho (executado em duas etapas) e um procedimento de versionamento dos produtos que cada equipe estava construindo.

Considerando a urgência dessas providências e a pouca maturidade do pessoal em atuar em conformidade com modelos e padrões, você optou por implementar, como sua primeira ação, o modelo tradicional de desenvolvimento, conhecido também como ciclo de vida clássico ou modelo em cascata. Sendo assim, ficou estabelecido que a execução do próximo projeto assumido pela empresa seria de acordo com esse modelo e, para que isso fosse possível, você deveria explicar à equipe cada etapa do modelo em cascata.

Seu desafio é o de preparar uma apresentação (em PowerPoint ou outra ferramenta similar), com no mínimo oito lâminas, contendo a visão geral de cada etapa deste modelo, incluindo os objetivos de cada um deles. Considere que essa apresentação é direcionada à equipe de profissionais que comporá o próximo projeto da organização e que seu conteúdo deve ser bastante didático e objetivo.

Mãos à obra.

Coloque todo seu foco nesta primeira seção e bom trabalho!

conceito-chave

A Engenharia de Software é uma daquelas disciplinas que nos surpreendem o tempo todo. Dinâmica por natureza, ela vem agregando elementos ao seu rol de temas, vem refinando e agilizando seus processos e, com efeito, contribuindo de forma inestimável para o desenvolvimento da Computação, entendida aqui como uma ciência. Encontrar um conceito definitivo para Engenharia de Software é, portanto, uma tarefa cujo resultado pode se apresentar ligeiramente obsoleto em um momento seguinte. Essa sua inclinação à constante mutação, no entanto, não a transforma em uma disciplina incompreensível e sem um nexo conceitual definido.

Definição de Engenharia de Software

A literatura nos oferece diversas definições para a Engenharia de Software, desde as sucintas até as mais elaboradas. Porém, a grande maioria utiliza-se de termos como procedimentos, métodos e ferramentas para indicar uma natural convergência: a qualidade do produto a ser desenvolvido. Se o resultado da aplicação de procedimentos, métodos e ferramentas não for uma entrega de qualidade, de pouco terá valido todo o esforço em adotá-los. Como primeiro passo, convém conhecermos a definição para Engenharia de Software dada por um importante autor dessa área.

Ao analisarmos uma definição, devemos considerar a natureza absolutamente dinâmica da Engenharia de Software, conforme já mencionamos. Com o passar dos anos, a importância que um programa de computador assumiu na vida das pessoas e em seus negócios foi sensivelmente alterada e a necessidade por qualidade e agilidade nas entregas cresceu na mesma proporção, o que acabou justificando o surgimento de novos meios de desenvolvimento de software. Dominar conceitos da Engenharia de Software é um caminho seguro para o estabelecimento de práticas consoantes com as necessidades da organização em que o profissional de TI está inserido.

Via de regra, aquele que domina um conceito é capaz de adaptá-lo às suas necessidades ou as da organização em que atua, sem o risco de esvaziar sua essência. Por isso, uma melhor definição do conceito de Engenharia de Software pede o detalhamento dos termos que o compõem. O termo “Engenharia” está relacionado ao projeto e à manufatura de um artefato e, desde já, ressaltamos a importância dos requisitos e das especificações do artefato nesse contexto. Por não possuir uma forma física, um programa de computador não passa por processo de manufatura tradicional, conforme o conhecemos no meio industrial. Além disso, a produção de programas de computador possui situações bastante particulares, que requerem soluções especializadas e, portanto, diferentes daquelas adotadas em um processo fabril.

Avançando para o próximo termo, temos uma definição satisfatória para software como:

1. Instruções que, quando executadas, produzem a função desejada.
2. Estruturas de dados que possibilitam os programas manipularem a informação;
3. E documentação relativa ao sistema.

Esses três elementos são, de fato, a matéria-prima para a Engenharia de Software, que é definida pelo IEEE Computer Society como a aplicação de uma abordagem sistemática, disciplinada e quantificável de desenvolvimento, operação e manutenção do software, além do estudo dessas abordagens (IEEE, 2004).

Princípios da Engenharia de Software

Formada a base conceitual da disciplina, avançamos agora para elementos que costumamos chamar de princípios da Engenharia de Software justamente por darem uma feição própria a ela e por suportarem suas práticas. São esses princípios que ajudam a estruturar os processos e a padronizar as soluções propostas por esse ramo da Computação. Eles foram propostos pelo SWEBOK (Software Engineering Body of Knowledge ou Conjunto de Conhecimentos de Engenharia de Software), que se trata de uma importante publicação do IEEE na área.

O primeiro princípio proposto pelo IEEE (2004) foi o da organização hierárquica, o qual estabelece que os componentes de uma proposta de solução ou a organização de elementos de um problema devem ser apresentados em formato hierárquico, em uma estrutura do tipo árvore, com quantidade crescente de detalhamento nível após nível.

A formalidade pode ser apontada como o próximo princípio e ela estabelece que a resolução de um problema deve seguir uma abordagem rigorosa, metódica e padronizada. Depois, como terceiro princípio, vale mencionar a completeza, que estabelece a necessidade de que se verifique cuidadosamente se todos os elementos de um problema foram levantados e se a solução proposta os contempla por completo.

O IEEE (2004) sugere como próximo princípio aquele conhecido como dividir para conquistar e a justificativa para sua criação é simples: fica intelectualmente inviável encarar um problema complexo (e a construção de um sistema é um problema complexo!) sem que ele seja dividido em partes menores, independentes e, portanto, mais facilmente gerenciáveis. Essa é a lógica subjacente à criação de soluções modulares.

O princípio da ocultação estabelece que, ao conceber uma solução modular, cada módulo tenha acesso às informações necessárias para seu funcionamento, o que significa ocultar informações não essenciais. Já o princípio da localização aponta para a necessidade de se colocar juntos os itens relacionados logicamente em um sistema e, pelo princípio da integridade conceitual, o engenheiro de software deve seguir uma filosofia e uma arquitetura de projeto coerentes (IEEE, 2004).

A publicação SWEBOK (IEEE, 2004) ainda aborda alguns outros princípios, incluindo a abstração, a qual determina a atenção do engenheiro de software a elementos com afinidade a um problema particular, isolando-os de outros elementos relacionados a outros tipos de problemas. Difícil de entender? Então pense na abstração como a aplicação prática da capacidade de um profissional em concentrar-se em aspectos essenciais para a resolução de um determinado problema, deixando para outro momento os problemas relacionados ou de importância secundária.

O Software

Agora que você já teve contato os pilares da Engenharia de Software, vale focarmos naquele que é seu objeto principal: o software.

Os conteúdos aos quais os autores se referem são dados e informações geradas conforme a execução do programa acontece. Já as informações descritivas referem-se à documentação do programa, necessária para referência e manutenção futura. Por meio dessa definição, é possível entender que o software não se resume ao programa executável.

Um dos elementos que contribui para tornar o software uma criação de natureza única é o fato de que ele é um produto e, ao mesmo tempo, o veículo usado para a distribuição desse produto. Embora o papel do software tenha passado por mudanças significativas a partir da metade final do século XX, ele se consolidou como um elemento indispensável em nossos dias e se firmou como o responsável por fazer transitar mundo afora o bem mais precioso que possuímos, que é a informação (PRESSMAN, MAXIM, 2016).

Quando colocamos o conceito de software em palavras simples e objetivas e o abordamos como um produto comercialmente viável, a compreensão de suas funções pode soar bastante simples. Esse fato tem o potencial de nos dar a falsa impressão de que criá-los também seja uma atividade sem complexidade e que “sentar e programar” seja uma solução sempre viável. Mas, em sentido contrário, desenvolver produtos de software tem deixado de ser uma atividade artesanal e empírica e tem se tornado sistemática, organizada e baseada em métodos, muito por conta da evolução da Engenharia de Software. No entanto, logo em seus primeiros anos, a produção de software enfrentou tempos turbulentos, com tarefas em que a incerteza era fator preponderante e os resultados dos esforços de criação de um artefato poderiam ser empreendidos em vão.

De acordo com Schach (2009), na década de 1960, alguns atores do processo de desenvolvimento de software cunharam a expressão “crise do software” na intenção de evidenciar o momento adverso que a atividade atravessava. Em seu sentido literal, crise indica estado de incerteza ou declínio e, de fato, esse era o retrato de um setor inapto a atender a demanda crescente por produção de software, a qual entregava programas que não funcionavam corretamente, construídos por meio de processos falhos e que não podiam passar por manutenção facilmente. Além disso, a incerteza causada pela imprecisão nas estimativas de custo e de prazo afetava a confiança das equipes e principalmente dos clientes.

Era fato comum naquela época a precariedade na comunicação entre cliente e equipe de desenvolvimento, e essa realidade contribuía para que a qualidade do levantamento dos requisitos fosse perigosamente baixa, acarretando consequentes incorreções no produto final. Trataremos mais adiante do termo “requisito”, mas já convém defini-lo como uma condição para se alcançar certo fim (REQUISITO, 2001). O cenário era ainda agravado pela inexistência de métricas que retornassem avaliações seguras dos produtos entregues pelos desenvolvedores. Uma pergunta do tipo “o produto que entregamos está adequado às demandas do cliente?” poderia não ser respondida com segurança.

Quando, apesar das adversidades, o programa era entregue, o processo de implantação tendia a ser turbulento, já que raramente eram considerados os impactos que o novo sistema causaria na organização. Treinamentos aos usuários após a implantação não era atividade prioritária e o fator humano era ignorado com frequência, gerando insatisfações nos funcionários impactados. Por fim, há que se considerar a dificuldade em se empreender manutenção nos produtos em funcionamento, normalmente ocasionados por projetos mal elaborados.

Mitos sobre desenvolvimento de software

Conforme nos ensinam Pressman e Maxim (2016), daquela época ficaram alguns mitos sobre o desenvolvimento de um software. Embora os profissionais atuais estejam mais capacitados a reconhecê-los e a evitarem seus efeitos, ainda é necessário dar atenção a eles. Trataremos de dois deles aqui.

Mitos de gerenciamento

Sob pressão, gestores podem apoiar-se em crenças relacionadas ao gerenciamento de seus projetos de software. Um mito bastante comum é que um livro repleto de práticas e padrões vai ser instrumento suficiente para o sucesso da empreitada, bastando segui-lo à risca. O questionamento necessário à validade de tal livro é sua completude e adequação às modernas práticas da Engenharia de Software. Outro mito comum é que, mediante atraso em uma entrega, a inclusão de mais desenvolvedores no projeto ajudaria a evitar atraso maior. Por fim, é perigosa a crença de que, ao terceirizar o desenvolvimento de um produto, a empresa que o terceirizou pode deixar a cargo do terceiro todo o desenvolvimento, sem necessidade de gerenciá-lo (PRESSMAM, MAXIM, 2016).

Mitos dos clientes

Aqui, os autores destacam crenças relacionadas ao papel e ao comportamento dos clientes em um projeto. Segundo um dos mitos, basta ao cliente fornecer uma definição geral dos objetivos do software para que seja possível iniciar sua elaboração. Na verdade, a realidade é que a definição mais clara e mais completa possível dos requisitos é o caminho mais seguro para o bom início de um projeto (PRESSMAM, MAXIM, 2016).

Modelo cascata 

Para o bem do futuro da Computação como uma atividade humana viável, uma metodologia estável e bem estruturada de desenvolvimento de software deveria ser criada. A resposta da comunidade ligada ao software, então, veio através do modelo em cascata, também conhecido como modelo tradicional, o qual ainda é utilizado para desenvolvimento de produtos de software. Ele descreve, por meio de etapas bem definidas, o ciclo que o software cumprirá durante o período compreendido entre sua concepção e sua descontinuidade.

O ciclo de vida natural de um software, de acordo com Resende (2005), abrange as seguintes fases: concepção, construção, implantação, implementações, maturidade, declínio, manutenção e descontinuidade. Essas fases são mais comumente descritas como fase de requisitos, projeto, implementação, teste e manutenção. A Figura 1.1 mostra o esquema geral das fases do modelo cascata.

Observe que uma fase do processo depende do artefato gerado pela fase anterior. Um artefato nesse contexto não é exatamente um produto de software acabado. As setas de retroalimentação, dispostas no sentido contrário à cascata, indicam a possibilidade de retornos às fases anteriores, considerando a ocorrência de falhas. A volta a uma fase anterior serve, em tese, para sanar problemas que, se levados adiante, acarretariam mais prejuízo ao desenvolvimento.

Antes de terminarmos esta seção, vale a apresentação introdutória de cada uma das etapas do modelo em cascata, de acordo com Schach (2009):

• Requisitos: a fase de requisitos de software preocupa-se com a descoberta, a análise, a especificação e a validação das propriedades que devem ser apresentadas para resolver tarefas relacionadas ao software a ser desenvolvido. Fazem parte dos requisitos de um software suas funções, suas características, suas restrições e todas as demais condições para que ele exista e cumpra seu objetivo. O projeto de um software fica comprometido quando o levantamento dos requisitos é executado de forma não apropriada. Eles expressam as necessidades e as restrições colocadas num produto de software, as quais contribuem para a solução de algum problema do mundo real (SCHACH, 2009).
• Projeto: uma vez tratados os requisitos, o modelo nos leva ao desenho do produto. Se os requisitos nos mostram o que o sistema deverá fazer, o projeto deverá refletir como ele o fará. Por meio do projeto, os requisitos são refinados de modo a se tornarem aptos a serem transformados em programa. O trabalho principal de um projetista é o de decompor o produto em módulos, que podem ser conceituados como blocos de código, que se comunicam com outros blocos por meio de interfaces (SCHACH, 2009).
• Implementação: nessa fase, o projeto é transformado em linguagem de programação para que, de fato, o produto passe a ser executável. Como estratégia de implementação, a equipe poderá dividir o trabalho de forma que cada programador (ou um pequeno grupo deles) fique responsável por um módulo do sistema. Idealmente, a documentação gerada pela fase de projeto deve servir como principal embasamento para a codificação, o que não afasta a necessidade de novas consultas ao cliente e à equipe de projetistas (SCHACH, 2009).
• Testes: testar significa executar um programa com o objetivo de revelar a presença de defeitos. Caso esse objetivo não possa ser cumprido, considera-se o aumento da confiança sobre o programa. As técnicas funcional e estrutural são duas das mais utilizadas a fim de se testar um software. A primeira baseia-se na especificação do software para derivar os requisitos de teste e a segunda no conhecimento da estrutura interna (implementação) do programa (SCHACH, 2009).
• Manutenção: os esforços de desenvolvimento de um software resultam na entrega de um produto que satisfaça os requisitos do usuário. Espera-se, contudo, que o software sofra alterações e evolua. Uma vez em operação, defeitos são descobertos, ambientes operacionais mudam e novos requisitos dos usuários vêm à tona. A manutenção de software é definida como modificações em um produto de software após a entrega ao cliente a fim de corrigir falhas, melhorar o desempenho ou adaptar o produto ao um ambiente diferente daquele em que o sistema foi construído (SCHACH, 2009).

Esse foi o conteúdo que queríamos compartilhar nesta seção inicial. As informações compartilhadas aqui servirão como base para novos aprendizados e possibilitarão que comparações sejam feitas, sobretudo entre a metodologia em cascata (tida como tradicional) e a ágil, entendida como mais moderna.

Execute com atenção as atividades propostas e fique com a gente!

Faça valer a pena

referências

IEEE Computer Society. Guide to the Software Engineering Body of Knowledge. Piscataway: The Institute of Electrical and Electronic Engineers, 2004.

PRESSMAN, R. S., MAXIM, B, R.; Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. Disponível em: https://bit.ly/3r4DQ1i. Acesso em: 23 nov. 2020.

REQUISITO. In: HOUAISS, A, VILLAR, M. de S. Minidicionário Houaiss da Língua Portuguesa. Rio de Janeiro: Objetiva, 2001.

RESENDE, D. A. Engenharia de Software e Sistemas de Informação. 3. ed. Rio de Janeiro: Brasport, 2005.

SCHACH, S. R. Engenharia de Software: os paradigmas clássicos e orientados a objetos. 7. ed. São Paulo: McGraw-Hill, 2009.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011. Disponível em: https://bit.ly/34owzjb. Acesso em: 12 out. 2020.

WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsiever, 2013.