Nesta lição, você terá a oportunidade de aprender um pouco sobre metodologias de projetos, o que são, quais existem e quando devem ser aplicadas. Atualmente, as empresas têm investido muito em profissionais que possuem habilidades nesta área, pois a metodologia está relacionada ao padrão, e, quando há um padrão no desenvolvimento de produtos e serviços, a qualidade tende a ser superior.
Introduziremos, brevemente, conceitos sobre diferentes metodologias para que, em lições posteriores, você possa compreender, a fundo, as principais e mais utilizadas metodologias de projeto de desenvolvimento de sistemas do mercado. Você, também, terá contato com alguns conceitos básicos que utilizaremos ao longo das lições subsequentes, como: padrões de projetos (Design Patterns), refatoração (Refactoring), padronização de código, boas práticas de codificação e documentação de código.
Em lições anteriores, comentei sobre a concorrência de empresas na área de tecnologia e mencionei, brevemente, o quesito qualidade, que se inicia na coleta dos requisitos, mas não para por aí. Para a garantia de um software ou serviço ser entregue com qualidade, aplicar a metodologia adequada fará toda a diferença, pois ela norteará, inclusive, as entregas.
Atualmente, existem diversas metodologias para desenvolvimento de software. Mas qual devo aplicar em cada projeto? Este é um ponto delicado, pois nenhuma metodologia é ruim, mas aplicar a incorreta também é. Para que isso não aconteça, mostrarei, de forma simples, essa documentação técnica, lembrando sempre que o simples não significa que é fácil ou deve ser deixado de lado. Normalmente, o sucesso de um projeto mora nos detalhes.
Você sabia que pode aplicar algumas dessas metodologias de software para organizar seus estudos e seu dia a dia? Quando temos nossas tarefas organizadas, tornamo-nos menos ansiosos e mais produtivos, pelo fato de organizarmos os itens e os priorizarmos.
Como parte de um processo seletivo de uma empresa, você recebe uma situação que precisa de uma proposta de resolução. Caso a sua proposta seja a mais criativa/ousada e aplicável, você avançará para a próxima etapa do processo. Pensemos no período de pandemia, em que diversas regras foram aplicadas quanto à circulação de pessoas e aos horários de funcionamento de atividades comerciais em todos os lugares do mundo. Isso implicou maior demora no atendimento em filas de supermercados, ocasionando aglomerações (até mesmo preocupantes, devido à situação pandêmica).
Antes da pandemia, na cidade onde moro, Curitiba, uma pessoa, ao ir ao supermercado, levava em torno de 60 minutos (entrar no estabelecimento, escolher os itens, passar no caixa para pagamento e sair do local). Com a redução do horário de funcionamento dos supermercados, mais pessoas, muitas vezes, da mesma família, passaram a ir a esses tipos de estabelecimento em vários dias da semana e horários do dia, por medo de escassez de produtos. Isso gerou demora extra nas filas de caixas e, até mesmo, nas gôndolas, ao escolher os produtos. Outro problema surgiu: as pessoas que continuaram a trabalhar, mesmo com horários reduzidos, não conseguiam ir ao supermercado nos horários em que ele estava aberto, no entanto precisavam de alimentos e produtos de higiene, assim como todas as outras pessoas.
O que você analisaria e quais soluções poderia propor para que o atendimento fosse mais rápido e todas as pessoas pudessem ter acesso aos itens do supermercado?
Quando há uma metodologia para processos, de atendimento ou funcionamento de um software, a chance de ocasionar problemas, erros, é bem menor. Um dos caminhos seria você fazer um fluxograma da situação atual (a que o problema ocorre), analisar os pontos de possíveis causas dos problemas citados e, então, propor soluções.
Como estamos falando de metodologia, muito provavelmente, ela possa ser utilizada por empresas de outros ramos, pois, normalmente, o fluxo de atendimento em estabelecimentos comerciais de venda de itens é similar. Uma maneira de documentar a situação atual e propor melhorias é por meio da UML (Linguagem de Modelagem Unificada). Para a melhoria dos processos identificados como problemáticos, utilizam-se as metodologias ágeis, que podem ser utilizadas tanto para o desenvolvimento de software quanto para o aprimoramento de processos.
Nesse momento, veremos, de maneira mais profunda, as metodologias tradicionais e as metodologias ágeis. Resumidamente, metodologias tradicionais foram as primeiras que existiram, tendo como características básicas serem mais rígidas e controladas. Por sua vez, as metodologias ágeis, que surgiram recentemente, são voltadas à flexibilidade e à adaptabilidade de processos e estratégias. Mas é claro que, mesmo tendo características diferentes, elas possuem o mesmo fim: a padronização e a melhoria da qualidade do produto.
As metodologias auxiliam na padronização do desenvolvimento de software, desde o começo do projeto, passando pelo desenvolvimento e testes, até a entrega final. Você já parou para pensar que, quando uma pessoa constrói uma casa, o primeiro passo, geralmente, é elaborar o projeto dela? Após a aprovação do projeto da casa, a construção é iniciada. E de um prédio? Ocorre da mesma forma, inclusive, são feitos vários projetos, dentre eles, o estrutural, o hidráulico e o arquitetônico. A finalidade desses projetos é entregar o produto (a casa ou o prédio, conforme exemplos citados) no tempo esperado, com o menor prejuízo e maior ganho possível.
Antes de aprofundar a discussão acerca das metodologias, é importante que você compreenda algumas siglas que fazem parte do cotidiano da Análise e Projeto de Sistemas. Vamos a elas:
Dentro de metodologias tradicionais, temos a UML (Unified Modeling Language, ou Linguagem de Modelagem Unificada) e a CASE (Computer Aided Software Engineering, ou Engenharia de Software Assistida por Computador).
A UML é uma linguagem padrão para elaboração da estrutura de projetos de software, podendo ser utilizada para visualização, especificação, construção e documentação de artefatos que façam uso de sistemas complexos de software (BOOCH, 2012). Na UML, a representação gráfica é feita por meio de diagramas, e estes são divididos em duas categorias, os estruturais — que são a parte estática do sistema — e os comportamentais — que são a parte mais dinâmica dos sistemas.
Os diagramas estruturais compreendem: Diagrama de Classes, Diagrama de Componentes, Diagrama de Objetos, Diagrama de Pacotes, Diagrama de Estruturas Compostas, Diagrama de Implantação, Diagrama de Perfil. Os diagramas comportamentais compreendem: Diagrama de Casos de Uso, Diagrama de Atividades, Diagrama de Máquina de Estados, Diagrama de Interação, Diagrama de Comunicação, Diagrama de Sequência e Diagrama de Tempo.
Uma ferramenta CASE quer dizer Engenharia de Software com o auxílio do computador, ou seja, ela possibilita apoiar atividades de processo de software, tais como análise de requisitos, modelagem de sistemas, depuração e testes. Geralmente, esse tipo de ferramenta possui um gerador de código, que, a partir de um diagrama (modelo gráfico), gera, automaticamente, o código fonte.
Nesse momento, é muito importante que você entenda a diferença entre interativo e iterativo. Vamos aos significados: iterativo é algo repetido, indica ações repetitivas, e interativo refere-se à interação, ou seja, a possibilidade de o indivíduo interagir com o emissor (MICHAELIS, [2023a], [2023b]). Logo, dizemos que a metodologia interativa possibilita aperfeiçoamentos sucessivos do software até a sua entrega, não necessitando que ele seja feito por completo para que, então, as alterações sejam realizadas. No entanto, para que isso ocorra, é necessário compreensão crescente do problema, devido aos ajustes e aos aperfeiçoamentos do desenvolvimento incremental em vários ciclos.
Envolvendo esta metodologia, temos RUP (Rational Unified Process) e MSF (Microsoft Framework Solutions), mantidos pela Microsoft. O RUP utiliza uma abordagem de orientação a objetos em sua concepção, e sua documentação é feita com notação UML. Geralmente, projetos feitos com esse tipo de metodologia são desenvolvidos em alguma linguagem de orientação a objetos, como Java ou C++. Já o MSF, segundo a Microsoft (2015, on-line): "É uma abordagem adaptável que visa a entrega bem-sucedida de soluções de tecnologia com maior rapidez, número reduzido de pessoas e menor risco, possibilitando resultados de maior qualidade. O MSF ajuda as equipes a especificar diretamente as causas mais comuns de falhas em projetos de tecnologia, melhorando as taxas de sucesso, a qualidade da solução e o impacto nos negócios".
Este conceito surgiu no mercado, há alguns anos, com o objetivo de entregar aos clientes produtos com maior agilidade e qualidade e tornar seu desenvolvimento mais flexível, a fim de que o cliente receba “partes” funcionais do produto e consiga utilizá-las sem prejuízo, antes mesmo de o produto ficar pronto em sua totalidade. Isso foi uma grande evolução, pois processos, antes, mais rígidos, agora, são facilitados.
Existem diversas metodologias nesse eixo, em especial, apresentarei XP (Extreme Programming) e FDD (Feature Driven Development).
Um dos modelos ágeis mais conhecidos, esta metodologia utiliza abordagem orientada a objetos. Nesse modelo, o contexto ocorre em torno de quatro atividades essenciais: 1) Planejamento; 2) Projeto; 3) Codificação; e 4) Teste. Uma característica e, até mesmo, uma curiosidade relacionada a esse modelo é que, preferencialmente, trabalha-se em duplas, em que uma pessoa, iniciante, programa e outra, mais experiente, revisa a codificação, os pontos positivos no desenvolvimento da equipe e a qualidade do código fonte gerado.
Este modelo significa Desenvolvimento Guiado por Características cuja característica, feature, é uma função acordada em reunião com o cliente, que pode ser desenvolvida, testada e implementada em duas semanas, aproximadamente. As características são pequenos blocos de funcionalidades, e os envolvidos (cliente, desenvolvedores e usuários) têm maior entendimento e controle do processo como um todo. Isso facilita o desenvolvimento do projeto e proporciona a satisfação do cliente, pois recebe, periodicamente, partes funcionais do produto.
Quando você lê o termo padrão de projeto, tenha em mente que são padrões reutilizáveis, seja de design, seja de projetos. Ou seja, se é possível reutilizar algo que já existe, a produtividade aumenta, pois não é necessário “reinventar a roda”. Ainda é possível citar, como benefícios de utilizar padrões de projetos, a organização e a manutenção deles, além da facilidade nas discussões técnicas. Esses padrões de projetos são utilizados no mundo inteiro, então, independentemente de onde você trabalhe, será um diferencial para seu currículo. Os padrões de projetos foram agrupados em três tipos (GAMMA, 1995):
Creational: os padrões desta categoria fornecem meios para criar e instanciar objetos, encapsulando a lógica deles.
Structural: padrões responsáveis pela composição estrutural dos objetos. Aqui, o conceito de herança pode ser utilizado para definir como a classe é estruturada, mantendo flexibilidade de comportamento.
Behavioral: esta categoria é responsável por focar na comunicação entre os objetos.
A utilização de padrões, no desenvolvimento de projetos e sistemas, é entendida como boa prática no desenvolvimento de software, veja algumas dessas práticas:
Utilizar técnica de engenharia de requisitos: coleta de requisitos bem-feita.
Avaliar líderes: a avaliação dos líderes serve de apoio para direcioná-los em atividades mais desafiadoras e motivadoras, aumenta a sinergia da equipe e até o espírito de inovação, que é essencial atualmente.
Utilizar ferramentas de gerenciamento de projetos: organizar entregas, tarefas, responsabilidades.
Utilizar métodos ágeis: qualidade e agilidade na entrega.
Utilizar protótipos: encurta a distância entre o que o cliente precisa e o que a equipe de desenvolvimento entendeu que ele deseja. Os protótipos podem ser simples, como um rascunho feito em papel, ou, até mesmo, com arquivos executáveis em que o cliente faz a validação, inclusive, das ações dentro do sistema.
A refatoração é o processo de alterar a parte interna do software sem que isso afete comportamentos externos. Essa ação tem por objetivo apenas a melhoria do código fonte. Acredito que, aqui, você deve estar se perguntando: por que alguém deveria refatorar o código de um sistema que já está pronto e funcionando? Veja alguns dos motivos:
Melhoria contínua do projeto: conforme novas funcionalidades são adicionadas ao software, geralmente, por pessoas diferentes da equipe, a estrutura do código é alterada e perde sua originalidade.
Fácil entendimento do software, assim, quando necessário alterar algo nele, a leitura e o entendimento do código, além de serem possíveis, serão rápidos e eficazes.
Procura de bugs (termo utilizado para erros de código ou problemas no software).
Programação mais rápida, pois, com um código limpo, sem bugs e organizado, o processo de entendimento do software não é lento.
A documentação de código, ou seja, tudo o que acompanha o software — seus modelos de projeto (diagramas) e requisitos —, e, é claro, os comentários de código fonte são muito importantes em inúmeros aspectos. A documentação de código fonte serve para orientar os programadores, normalmente, descreve o que a funcionalidade deve fazer, para que serve a variável criada, por exemplo.
Veja, na Figura 3, um exemplo de comentário em um documento HTML. Este ponto é importante, pois, dependendo da linguagem de marcação ou programação que estiver utilizando, o comentário é inserido de forma diferente, então, conhecer os comandos de comentário da ferramenta é essencial.
Nesta lição, você aprendeu diversos conceitos e siglas da área de Análise e Projeto de Sistemas. Sei que parece muita coisa e bastante confuso, mas não se preocupe, porque detalharemos essas abordagens em lições posteriores. Aqui, apenas apresentei conceitos que são fundamentais dentro da área que você está estudando (Análise e Projeto de Sistemas). Nas próximas lições, você aprenderá como utilizá-las e em que momento. Confie em mim!
Essas discussões iniciais são importantes, porque as empresas utilizam muito essas metodologias, sejam tradicionais, sejam ágeis. Você pode visualizar essa utilização de metodologias verificando as siglas que você estudou nos perfis de vagas de emprego no LinkedIn (rede social profissional utilizada internacionalmente).
Coletar, corretamente, os requisitos, aplicar metodologias e padrões nos projetos bem como boas práticas na programação, além de facilitar a vida da próxima pessoa que for alterar seu código, proporcionará maior qualidade ao seu software.
Clique aqui, teste seus conhecimentos sobre esta lição e confirme sua participação nesta disciplina!
BOOCH, G. UML: Guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2012.
GAMMA, E. et al. Design Patterns. Elements of Reusable Object-Oriented Software. 1. ed. Estados Unidos: Addison-Wesley, 1995.
MICHAELIS. Iterativo. [2023a]. Disponível em: https://michaelis.uol.com.br/busca?r=0&f=0&t=0&palavra=iterativo. Acesso em: 9 fev. 2023.
MICHAELIS. Interativo. [2023b]. Disponível em: https://michaelis.uol.com.br/busca?r=0&f=0&t=0&palavra=interativo. Acesso em: 9 fev. 2023.
MICROSOFT. Visão geral da Microsoft Solutions Framework (MSF). 10 jun. 2015. Disponível em: https://docs.microsoft.com/pt-br/previous-versions/jj161047(v=vs.120)?redirectedfrom=MSDN. Acesso em: 9 fev. 2023.