Software

O impacto do software nas organizações modernas

Mais do que nunca, aplicações computacionais têm o poder até mesmo de decidir o rumo de negócios e empresas inteiras. As vantagens de negócio que a adoção de modernizações computacionais podiam trazer até eram vistas como um diferencial há alguns anos, mas hoje essas vantagens são praticamente pré-requisitos para o sucesso dos negócios. Por exemplo: é praticamente inconcebível que uma plataforma de serviços hoje não tenha um app disponível na Google Play e na App Store (por mais que em algumas situações, o app seja somente uma “casca” para o site da aplicação). Isso traz para um “poder” enorme para os desenvolvedores de software, fomentando o surgimento de técnicas e frameworks que implementam as filosofias ligadas à governança de TI (como ITIL, por exemplo). Mas, será que nós como profissionais da área de desenvolvimento de software, temos o conhecimento do poder e das consequências que nosso trabalho pode trazer?

Gerenciamento de projetos - Fundamentos
Curso de Gerenciamento de projetos - Fundamentos
CONHEÇA O CURSO

O poder que um software tem na história de uma organização

Software de fato pode decidir as estratégias e o futuro de uma organização, tanto para o bem como para o mal: existem vários exemplos para ambas as situações.

O Nubank, por exemplo, hoje é um dos unicórnios brasileiros muito por causa da facilidade e desburocratização que ele trouxe no que diz respeito ao acesso a serviços financeiros… E muito do sucesso do Nubank se deve às ferramentas computacionais envolvidas, como o aplicativo. Ele é um exemplo excelente de como software bem feito pode tornar uma empresa competitiva e inovadora frente o mercado. Hoje, o Nubank tem valor estimado de mercado na casa dos US$ 10 BI.

Infelizmente, também temos vários exemplos ruins. O mais recente envolve a Boeing e seu avião 737 MAX. Devido a problemas de projeto e, principalmente, falhas no MCAS (um dos softwares centrais de controle do 737 MAX) fez com que 346 pessoas morressem em 2 acidentes envolvendo a aeronave. Após os acidentes e as constatações de falhas no software, a maioria das agências reguladoras de aviação espalhadas pelo mundo proibiu o tráfego de aeronaves do referido modelo por precaução. O resultado destes eventos: além da impossibilidade trágica de reverter os efeitos dos dois acidentes, a Boeing amarga o pior prejuízo da história, de cerca de US$ 2,9 BI, prejuízo decorrente de correções que estão em curso no software do 737 MAX e manutenção em solo de centenas de aeronaves do modelo, além do cancelamento de contratos milionários de aquisição do modelo problemático e o crescimento de sua concorrente direta no mercado, a Airbus. E ainda existe o prejuízo realizado à imagem da Boeing, prejuízo este que talvez nunca seja revertido.

Nas duas situações, existe um elemento preponderante tanto para o sucesso quanto para o fracasso: o software. Nas duas situações, foi um programa computacional, escrito por profissionais da área de desenvolvimento de software, que ditou se uma empresa chegaria a se tornar um dos primeiros unicórnios brasileiros e virar símbolo de inovação ou se ia matar mais de 300 pessoas inocentes. Software no mundo atual é algo da mais alta grandeza de importância e deve ser levado muito a sério, principalmente pelas empresas que buscam alinhar tecnologia com seu mercado para se destacarem e se tornarem mais competitivas. Software bem feito e governança de TI hoje não são luxos: são mais do que obrigações para que as empresas se mantenham vivas no mercado atual.

Desenvolvedores precisam entender que seu papel em uma organização é de altíssima importância

Com os exemplos acima, conseguimos evidenciar um ponto: desenvolvedores são peça-chave no sucesso de qualquer organização moderna. E quem trabalha com desenvolvimento precisa ter essa consciência e dar o devido valor a este papel. Já passamos do tempo em que ter software dentro de uma organização era luxo: hoje é mais do que obrigação. E as organizações não podem se dar ao luxo de terem softwares que funcionam “mais ou menos”, pois falhas geram despesas, perda de receita e queda de competitividade no mercado. Precisamos ter consciência de que os software e os profissionais envolvidos na criação são protagonistas nas empresas hoje. As empresas que não possuem este comportamento podem ter sérios problemas de sustentabilidade em uma era tão digital como a que vivemos.

Isso tudo precisa despertar em quem trabalha com software a consciência de que um poder tão grande que acaba sendo depositado traz também responsabilidades enormes. E, por isso, a correta capacitação técnica é tão exigida pelas empresas hoje. E quando citamos “capacitação técnica”, nem falamos necessariamente sobre o domínio de linguagens, frameworks e bibliotecas: estamos falando do domínio de aspectos fundamentais da computação, como estruturas de dados, algoritmos e tópicos de rede. É obrigação de qualquer desenvolvedor moderno entender o que é um algoritmo de complexidade ciclomática O(nˆ2), a diferença na utilização de um vetor ou de uma lista duplamente ligada ou os aspectos semânticos do protocolo HTTP, pois são tópicos que impactam diretamente em manutenibilidade e qualidade do código e, consequentemente, do software, que é um dos elementos centrais das organizações modernas. E quem trabalha com desenvolvimento de software precisa parar de ignorar este ponto e criticar empresas que, durante as entrevistas, pedem tópicos ditos “teóricos” ao invés de focarem em codificação. No mercado atual, por mais “torto” que pareça, quem se destaca não é quem sabe de cor a sintaxe de uma função built-in no JavaScript, e sim quem sabe o que é idempotência em métodos HTTP ou quando uma pilha deve ser utilizada no lugar uma lista convencional.

As empresas também precisam entender que software é um elemento central nos dias atuais

Da mesma maneira que os desenvolvedores precisam ter cada vez mais consciência da importância de seu papel em uma organização, as próprias organizações precisam entender que elas precisam de software e de profissionais de desenvolvimento para se manterem dentro da “revolução digital”. Empresas que não apresentem uma infraestrutura tecnológica mínima correm o sério risco de serem engolidas por outras empresas ou, pior ainda: serem completamente ignoradas. Um exemplo mais direto: é impossível imaginar hoje uma empresa, por menor que seja seu porte, sem um site institucional… Da mesma maneira que é impossível imaginar, por exemplo, uma empresa de mídia sem um aplicativo para acesso a seu conteúdo ou um carro que não tenha nenhuma interface digital mínima (como bluetooth ou até mesmo uma simples porta USB no sistema multimídia). E, para a adoção dessa infraestrutura tecnológica, não existe outra saída: é necessário investimento por parte das empresas, quer seja no que diz respeito à parte técnica ou à parte pessoal e gestão de profissionais. E neste ponto, a palavra “investimento” cai muito bem: software hoje é investimento, não despesa.

Existem vários exemplos de empresas que não se atentaram adequadamente à importância que aplicações computacionais e tecnologia poderiam ter sem seu negócio. Um exemplo é a famosa Kodak, que já foi líder absoluta no mercado de fotografias, mas até hoje tenta se recuperar plenamente do procesos de falência encerrado em 2013 e retornar aos tempos áureos das décadas de 80 e 90. A Kodak não se atentou à migração para o formato digital que o mercado fotográfico começou a adotar na década de 90 e acabou sendo engolida por dezenas de empresas que perceberam as tendências que começavam a ser adotadas. Algumas destas empresas que perceberam este movimento foram a a Canon e a Nikon, empresas estas que hoje são consideradas as líderes neste mercado.

Gerenciamento de Projetos - Avançado
Curso de Gerenciamento de Projetos - Avançado
CONHEÇA O CURSO

Outro exemplo de empresa que não tratou software como deveria foi a própria Boeing no projeto do 737 MAX. A Boeing adotou a estratégia de terceirizar o desenvolvimento do MCAS, que é um dos principais softwares de controle do avião (conforme vimos no tópico inicial deste artigo). Esta estratégia foi adotada principalmetne por duas razões: para que, em tese, ficasse pronto mais rapidamente e para cortar custos. No final, boa parte do MCAS do 737 MAX foi desenvolvida por profissionais recém-graduados contratados por um custo muito menor pelas empresas que foram contratadas pela Boeing para o projeto. Alguns dos profissionais que atuaram nesse projeto ganhavam o equivalente a US$ 9, segundo relatos anônimos obtidos pelas investigações, segundo o Business Insider! O resultado da subestimação da importância do MCAS para o projeto e a vontade maior de economizar resultaram no que foi mostrado no primeiro tópico deste artigo: mais de 300 pessoas inocentes mortas e o maior prejuízo da companhia na história.

Da mesma maneira que desenvolvedores precisam ser muito conscientes de sua importância dentro de uma organização, as empresas também precisam sempre se atentar ao fato de que sua equipe de TI pode fazer com que estas lucrem milhões de dólares ou amarguem processos e a falência.

Como quintuplicar a produtividade no desenvolvimento de software?

Desenvolvimento de software é algo complexo, mesmo para quem está desenvolvendo. É algo que, durante o processo de encontrar sua melhor maneira de ser produtivo, você acaba se debatendo com suas próprias escolhas.

Existem muitas maneiras de se definir o que é um software, mas particularmente eu gosto dessa: um software é uma sequência de instruções escritas por um programador, para executar uma ou mais funções, otimizando assim algo que previamente era manual ou não existia.

Veja, se grande parte do meu trabalho como desenvolvedor é otimizar processos, a minha rotina de trabalho também costuma ser como um protótipo de software.

Isso se transforma em uma rotina estruturada, ou, ao menos, uma maneira estruturada de como resolver um problema. Vou contar um pouco do meu processo de construção de software/trabalho e como desenvolvi hacks para ser mais produtivo ao longo do tempo.

Vou contar um pouco da minha experiência para tentar ajudá-lo(a) a otimizar a sua. Vamos lá!

Python - Fundamentos
Curso de Python - Fundamentos
CONHEÇA O CURSO

Comece de maneira gradual

Dificilmente consigo acordar e codar alguma coisa. Normalmente eu preciso que meu cérebro ligue os motores de maneira processual, um passo de cada vez.

No entanto, penso que isso não pode ser um processo que leva várias horas, então eu tomo um caminho gradual, mas rápido, para que esse processo ocorra.

Ao abrir minha máquina para programar eu começo geralmente pela leitura dos meus cards do Trello, nosso reservatório de tasks infinito onde sempre pode se tirar algo da cartola. Eu uso Trello, mas essa dinâmica aplica-se a qualquer ferramenta de gestão de projetos.

A leitura me ajuda a pensar nas tasks que vão ser executadas no dia. É um processo rápido. Ao ler rapidamente os títulos dos cards eu já sei o que devo fazer, quando fazer e como fazer, em sua grande maioria.

Após isso eu começo pelas tasks mais simples, coisas que são rápidas, mas me farão emergir no processo de pensar em software.

Um exemplo disso é executar alguns scripts para transferir dados de usuários, dar update em alguma informação no banco, ou refatorar algum trecho simples de código.

Leitura recomendada:
Por que a comunicação em TI é um negócio tão importante?

Coding Hard

É hora de codar. Mas como saber no que eu começo primeiro?

Para executar as tasks mais complexas, eu as separo em 2 tipos:

  1. As que são relativamente rápidas e as que são de longo prazo. As tasks complexas são aquelas que envolvem mais de uma parte do sistema, que têm alto impacto, em que é preciso prever muitas coisas antes de se começar a executar;

  2. Normalmente minha prioridade começa com as tasks que posso fazer em 1-2 horas. Elas permitem imprimir ritmo no desenvolvimento e fazem com que minha cabeça entre no modo foco.

Durante esse período normalmente não respondo e-mails, não olho o Slack, não faço nada que me faça perder a linha de pensamento. O porquê disso é simples, vamos imaginar a seguinte situação:

2.1 Usuário vai entrar na tela de login e nesse momento informo ao banco que ele está ativo
2.2 O banco guarda essa informação e ativa uma trigger para que daqui a 30 minutos um alerta seja enviado a esse usuário
2.3 Se o usuário entrou na tela 1 o alerta será x. Se entrou na tela 2 o alerta será Y, mas apenas depois de 30 minutos
2.4 Caso o usuário entre na tela 3 o tempo de alerta deve ser reduzido para 15 minutos

Pronto.

Imagine que pensei nas linhas gerais de como a task vai ser feita e, quando estou no meio da segunda instrução, paro para responder e-mails ou fazer outras coisas. O que ocorre?

Posso simplesmente esquecer que já fiz algo ou deixei de fazer algo. Por isso manter uma linha única de pensamento é importante quando estamos codando.

É preciso se ter em mente o tempo todo os passos que foram ou não executados. Caso você esqueça onde estava, todo o ciclo recomeça. “Será que setei o tempo certo na tela 1? Fiz o tempo de maneira diferente para a tela 3?” E então começa um processo de revisão da sua linha de pensamento.

Para se produzir as tasks de longo prazo é necessário quebrá-las em pequenas etapas, dificilmente é possível ficar 8 horas ininterruptas desenvolvendo. Bugs surgem, pessoas falam com você, outras tasks são priorizadas e por aí vai.

Por isso é um processo que exige a quebra. Exige que você determine quando cada etapa será executada para que diariamente você progrida dentro da task.

Leitura recomendada:
Como se destacar na carreira de TI?

Java - Fundamentos
Curso de Java - Fundamentos
CONHEÇA O CURSO

As pausa são importantes para a produtividade

Algo que já vi ser bem comum entre programadores — talvez seja para outras áreas também — é o tempo necessário para “resetar” o cérebro.

Ao finalizar tasks complexas, onde você levou sua mente a pensar na otimização de um processo específico, normalmente você precisa “não pensar” durante algum tempo.

O que quero dizer com isso? Se pensei na otimização de um processo de candidatos dificilmente é possível, no instante seguinte, pensar em um código para empresas.

Isso porque a mente está “contaminada”, pensando ainda em otimizações e melhorias do processo que você acabou de criar.

É preciso esvaziar a mente antes de colocar outra idéia no forno para iniciar um novo processo de desenvolvimento, por isto as pausas entre uma task e outra são importantes.

Leitura recomendada:
As certificações para programadores mais importantes do mercado.

Afinal, como ser produtivo(a) no Desenvolvimento de Software?

E quando acaba essa sequência “colocar” coisas na caixa, “tirar” da caixa, “descansar”, “colocar” outro no lugar? Para a maioria dos Desenvolvedores que conheço a resposta é nunca.

Ao se deparar com problemas, normalmente eles são jogados em processos de background na sua mente e ficam produzindo idéias de maneira passiva.

Acredito que muitos Desenvolvedores — senão todos — já se depararam com uma idéia no meio da noite, acordaram e escreveram um trecho de código.

Ou já teve uma elucubração no meio da mesa do jantar, ou enquanto estava vendo sua série da Netflix.

Acredito que esse processo de nunca parar de pensar sobre os problemas técnicos ou sobre software em longo prazo é danos.

Talvez fique aqui a minha hipótese do porquê tantos Desenvolvedores curtem tanto fazer algo fora do serviço que atraia 100% do foco.

Como jogar algo ou estar imerso dentro de uma série.

Esse tipo de atividade simplesmente força sua mente a se desligar do mundo do software e é essencial para resetar sua mente e dar tempo para você ter novas idéias de maneira fresca e descansada.

Esse era um pouco do meu ciclo enquanto era 100% Desenvolvedor dentro da GeekHunter.

Hoje, assumindo a área de gestão, esse fluxo mudou um pouco, porém a essência ainda é a mesma.

Cada Desenvolvedor tem sua particularidade na hora de programar, mas acredito que existam muitas similaridades entre todos quando se trata do nível de foco necessário para desenvolver.

Espero ter ajudado. Até a próxima!

JavaScript Básico
Curso de JavaScript Básico
CONHEÇA O CURSO

Esse post foi desenvolvido pela GeekHunter

Para que serve um framework?

A utilização de frameworks já está inclusa no dia a dia de muitos desenvolvedores. O principal benefício que faz muitos desenvolvedores utilizarem frameworks é o poder de reutilização de estruturas de código, poupando horas de desenvolvimento e fazendo com que os desenvolvedores possam focar no que é de fato importante e que agrega valor ao negócio com relação ao software que está sendo desenvolvido.

Laravel - Framework PHP (Parte 1/3)
Curso de Laravel - Framework PHP (Parte 1/3)
CONHEÇA O CURSO

O que vem a ser um framework?

Um framework é uma estrutura-base que contém um conjunto de funções e componentes pré-definidos, funções e componentes estes que se relacionam para disponibilizar funcionalidades específicas ao desenvolvimento de software. Estas funções e componentes genéricos pré-prontos agilizam o processo, poupam tempo e evitam retrabalho para o desenvolvedor.

Os frameworks podem ser criados ou pela própria comunidade ou por empresas mantenedoras de uma linguagem ou ambiente de desenvolvimento, como a Microsoft e a Oracle.

Por que utilizar um framework?

O foco principal de um framework é a reusabilidade. Você pode utilizar um framework para desenvolver várias aplicações, reaproveitando estas estruturas pré-disponibilizadas para lidar com tarefas repetitivas ou que são comuns em vários tipos de sistemas (como, por exemplo, a funcionalidade de autenticação). Nesse exemplo, você não precisa dedicar tempo para desenvolver a funcionalidade de login, já que existem frameworks já testados para essa finalidade. Além disso, se necessário, você pode personalizar estes componentes pré-disponibilizados de acordo com as demandas do projeto em questão.

Um exemplo: a Microsoft tem o .NET Framework, que disponibiliza componentes pré-configurados para rodar aplicativos em diferentes plataformas. Se você vai criar uma aplicação web, por exemplo, você não precisa desenvolver toda a estrutura necessária para lidar com requisições HTTP (que é uma tarefa repetitiva): basta você criar uma classe que estenda a clases Controller e… Pronto! Você já tem automaticamente uma classe que consegue lidar com requisições HTTP.

Bootstrap 4 - Básico
Curso de Bootstrap 4 - Básico
CONHEÇA O CURSO

Existem diversos frameworks para as mais diferentes linguagens e plataformas, seja desktop, web ou mobile, tanto com relação ao front-end quanto ao back-end. Devemos escolher os frameworks corretos para cada tipo da aplicação, para que ele realmente ajude no objetivo final.

Ao final, podemos concluir que um framework é um facilitador para o desenvolvedor chegar no resultado final que ele deseja – que é o desenvolvimento de uma aplicação, poupando tempo e esforço de desenvolvimento.

Dicas para manter seu código limpo e legível

Atualmente, o mercado exige que os desenvolvedores não “programem” simplesmente. Muitas empresas desejam profissionais que possuem domínio de boas práticas e noções de arquitetura – o famoso “código limpo”. Muitas vezes, podemos até pensar: “não… as empresas desejam apenas que o software funcione”. A curto prazo pode até ser real esta afirmação, mas quando falamos sobre médio e longo prazo, que é quando certos problemas começam a aparecer, é que os débitos técnicos (os trechos de código que foram mal escritos ou funcionalidades que não foram implementadas da maneira correta) voltam para nos assombrar.

O famoso “código limpo” (ou “clean code”) é um estilo de desenvolvimento que tem como foco a escrita de código claro, conciso e de fácil manutenção posterior. Profissionais que se atentam a essas práticas costumam ser vistos de maneira diferente quando seu código é analisado em uma entrevista de emprego. Ter o código limpo e bem escrito facilita a leitura e é importante para o aumento da qualidade do software. Se você não se preocupa com isso, fatalmente, até mesmo em um curto prazo, você mesmo pode não entender seu próprio código! A situação piora ainda mais quando um desenvolvedor vai tentar entender o código de outra pessoa, ainda mais se for em uma empresa que tenha alta rotatividade na equipe (o que é uma situação bem comum nas empresas de software aqui no Brasil). As consequências desse tipo de situação são claras: perde-se muito tempo com a manutenção do software, gerando muitas vezes até mesmo situações de retrabalho.

A adoção de práticas de “clean code” acaba auxiliando a resolver estes pontos. Porém, ainda podemos obter outros benefícios através da adoção destas práticas: mais do que garantir a qualidade do código e do software, a adoção de práticas de “código limpo” trazem também maior produtividade, por consequência direta ao fato de que um software com qualidade exige menos processos de manutenção e, quando esta é necessária, o esforço a ser realizado acaba se tornando muito menor do que o usual.
Abaixo, descrevemos alguns tópicos comuns no que diz respeito ao “clean code”.

Escreva métodos curtos

Um método deve ser escrito de uma forma que qualquer pessoa que “bata o olho” entenda o que ele faz. Métodos demasiadamente extensos certamente não ajudam neste ponto. Alguns livros de arquitetura de software pregam que um método deve ter no máximo 15 linhas, embora até 25 linhas seja tolerável, caso seja muito necessário.

Utilize nomes de variáveis e métodos claros e bem definidos

Os nomes de variáveis e métodos devem ser precisos, claros e diretos, passando diretamente a ideia do que ele faz. Não tenha medo de escrever um nome grande caso seja necessário. Um nome bem descritivo irá possibilitar uma melhor compreensão e, posteriormente, uma melhor manutenção do código. Antes termos uma variável chamada valorTotalNotaFiscal do que valTot. A grande maioria das ferramentas de desenvolvimento hoje em dia oferecem a funcionalidade de autocomplete, o que invalida a justificativa de que “perdemos tempo ao digitar nomes de variáveis e métodos muito grandes” para não utilizarmos nomes mais diretos para nossas estruturas de código.
Vale lembrar que nomes de métodos sempre deve ter nomes de verbos, já que são criados para executar algum procedimento. No caso de classes, deve-se usar substantivos no singular.

Separação clara de responsabilidades entre métodos e classes (Single Responsability Principle – SRP)

Um método deve desempenhar apenas uma tarefa. O Single Responsability Principle, ou Princípio da Responsabilidade Única, é um de cinco princípios para utilização de boas práticas de codificação chamados S.O.L.I.D. Este princípio define que cada estrutura de código, seja uma classe ou um método, deve possuir apenas uma única responsabilidade, ou seja: cada estrutura deve fazer uma única coisa.
Tome cuidado também com a justificativa de uma classe. Os métodos existentes de uma classe devem estar alinhados com sua definição. Não adianta colocarmos um método chamado acelerar() dentro de uma classe chamada Mesa, sendo que quem acelera é um Carro.

Desenvolvedor PHP Sênior
Formação: Desenvolvedor PHP Sênior
Nesta formação você aprenderá aspectos avançados da linguagem PHP e de seu ecossistema, conhecimentos essenciais para se tornar um desenvolvedor diferenciado, e com isso, você terá conhecimento para desenvolver aplicações PHP usando as práticas mais modernas do mercado.
CONHEÇA A FORMAÇÃO

Cuidado com a quantidade de parâmetros que os métodos recebem!

Quanto menos parâmetros um método receber, mais legível ele será. Sempre garanta que os parâmetros que um método recebe são de fato necessários. Quando uma quantidade muito grande de parâmetros for necessária, tente utilizar design patterns como o builder ou, pelo menos, agrupar esta quantidade de parâmetros em uma especificação de objeto a ser repassado como parâmetro único para o método.

Cuidado com o overpattern!

Design patterns são legais, desde que utilizados da maneira correta. Quando os design patterns são aplicados da maneira incorreta ou utilizados em conjunto de maneira complicada por pura “satisfação técnica pessoal”, estes acabam mais atrapalhando do que ajudando, já que a utilização de design patterns acaba por trazer uma certa complexidade ao código. Por isso, para evitarmos futuros débitos técnicos, é essencial que essa complexidade oriunda com a aplicação de um ou mais patterns seja devidamente justificada.

Para avaliar se você deve aplicar ou não um conjunto de design patterns, lembre-se sempre de um princípio chamado K.I.S.S. – Keep It Short and Simple, ou Mantenha Isso Pequeno e Simples (ainda existem algumas variações sob essa sigla). Sempre escreva suas estruturas de código da maneira mais direta e simples, aplicando simplesmente os patterns que são de fato necessários para a situação. Não crie débitos técnicos desnecessários por sofrer antecipadamente: escreva trechos de código claros e concisos que, quando necessário, possam ser modificados para estruturas e patterns mais complexos de maneira tranquila.

Entre um desenvolvedor que sai aplicando técnicas como DDD, CQRS, Event Sourcing e uma variedade de patterns gigantesca para um simples cadastro de uma entidade que nem tem relacionamentos e um desenvolvedor que utiliza patterns mais simples como o Repository e o Service Pattern, pode ter certeza que o mercado de maneira geral irá dar a preferência para o segundo desenvolvedor. E isso não o define com menos habilidades técnicas que o primeiro desenvolvedor – muito pelo contrário: o segundo desenvolvedor provavelmente possui um nível de maturidade maior que o permite calcular bem os benefícios de cada abordagem em diferentes situações.

Ciclo de vida do software: por que é importante saber?

Quando pensamos no desenvolvimento de um software queremos ir logo para a parte do desenvolvimento em si. Porém, certas etapas são importantes de serem realizadas antes de colocar a mão na massa. O ciclo de vida do software é um deles pois engloba desde o planejamento inicial até a sua entrega. Veja nesse artigo um pouco sobre ele e a sua importância.

O que vem a ser o ciclo de vida?

O ciclo de vida de um software é uma estrutura que indica processos e atividades envolvidas no desenvolvimento, operação e manutenção de um software, abrangendo de fato toda a vida do sistema. Neste ciclo, existem modelos que definem como o software será desenvolvido, lançado, aprimorado e finalizado. A escolha desse modelo, que definirá a sequência de etapas das atividades, é feita entre o cliente e a equipe de desenvolvimento e várias coisas podem impactá-la, como negócio, tempo disponível, custo, equipe etc. A ordem das fases é que vai definir o ciclo de vida do seu software.

Symfony - Gerenciando aplicações com Symfony Flex
Curso de Symfony - Gerenciando aplicações com Symfony Flex
CONHEÇA O CURSO

Por que devo pensar nisso antes de desenvolver meu software?

Com um modelo de ciclo de vida você consegue ver a real necessidade do software e planejá-lo melhor. Imagina você entregar um software para um cliente, e posteriormente precisar lançar várias atualizações para corrigir falhas? A finalidade desse ciclo é encontrar erros o mais cedo possível, pois, além de garantir a qualidade do software, evita um custo maior caso um erro seja encontrado tardiamente. Com um melhor planejamento você pode, por exemplo, ter maior disponibilidade para melhorar o desempenho ou realizar alguma correção.

Quais são as etapas?

Existem 3 fases básicas de um ciclo de software: definição, desenvolvimento e operação.

1) Definição

Deve-se conhecer a situação atual e fazer a identificação do problema para buscar uma resolução do mesmo. É na definição que você fará a modelagem dos processos e a análise do sistema. O modelo de ciclo de vida é a primeira escolha a ser feita no processo de software.

2) Desenvolvimento

Esta etapa envolve atividades relacionadas a design, prototipagem, codificação, testes, entre outras atividades que forem necessárias, como por exemplo, a integração com um outro sistema. É importante ressaltar que essas atividades devem seguir o que foi descrito nas etapas anteriores, pois é aí que entra as regras de negócio.

3) Operação

Nesta etapa o software já estará em produção e você dará o devido suporte aos usuários e, claro, corrigir possíveis bugs que possam aparecer. Aí também entra a continuidade do software se for preciso, como atender novos requisitos, novas funcionalidades. Porém, tudo depende do modelo de ciclo de vida adotado pelo projeto.

Quais os modelos que podem ser utilizados?

Existem diversos modelos de ciclos de vida para o desenvolvimento de software como: cascata, incremental, espiral, evolutivo etc. Vamos abordar aqui alguns dos mais conhecidos e utilizados:

Modelo Cascata

O modelo cascata é um modelo tradicional que foi criado em 1966, porém, formalizado somente por volta de 1970. Este modelo define que as fases serão sequenciais, onde uma fase tem que estar completa antes de passar para a próxima.

Com isso, o processo é visto como um fluir constante para frente. Seu principal benefício é a facilidade de gestão do projeto. Já uma desvantagem desse modelo é a dificuldade de acomodar mudanças depois que o processo já está em andamento.

Modelo Evolutivo

Diferente do modelo em cascata, o modelo evolutivo tem a facilidade de mudanças e a possibilidade de oferecer novas funcionalidades naquele mesmo momento. É bastante indicado para sistemas de curto prazo ou sistemas pequenos e médios. É um modelo que possui grande interação com o usuário, porém, esse modelo tem a desvantagem de se ter dificuldade de estabelecer limites quanto ao escopo e tempo, o que demanda maior gerenciamento de projeto.

Modelo Incremental

Esse modelo foi criado como uma melhoria do modelo cascata e também é um modelo tradicional. Nesse modelo, o desenvolvimento é dividido em etapas, que produzirão o sistema até chegar a sua versão final.

Este é um modelo ideal caso os requisitos ainda não estejam tão claros. Por exemplo, se algum erro é cometido, apenas o último incremento será descartado. Além disso, como o foco é a entrega de cada incremento, a funcionalidade do sistema estará disponível mais cedo para o usuário.

Modelo Espiral

Nesse modelo o processo não é baseado em uma sequência de atividades com retorno. Nesse modelo, como o próprio nome diz, se baseia em uma espiral, onde cada volta nessa espiral representa uma fase no processo. Além disso, não existem fases fixas, essas voltas são escolhidas de acordo com o que é requerido. Uma desvantagem desse modelo é que ele é melhor aplicado somente em produtos internos da empresa.

Concluindo

Pudemos ver que utilizar um modelo de ciclo de vida é uma das melhores formas de garantir um bom alinhamento entre o desenvolvimento do software e a necessidade do usuário que irá utilizá-lo. Vimos também que não existe o modelo ideal, e sim o que é melhor aplicado para cada necessidade.

Laravel - Eloquent ORM
Curso de Laravel - Eloquent ORM
CONHEÇA O CURSO