O que é a Análise de Viabilidade de um Projeto?

Basicamente, a análise de viabilidade de um projeto consiste numa avaliação feita a partir de

ferramentas e técnicas a fim de verificar a disponibilidade de recursos financeiros, físicos e
oportunidades de ganhos em determinadas atividades. A partir desse estudo, é possível traçar o tempo
de retorno do investimento de maneira a estimar o quanto o mesmo é válido.

Qual a Importância da Análise de Viabilidade de um Projeto?

Listei abaixo os principais tópicos que tornam essa análise fundamental para que se verifique a
viabilidade dos projetos a serem desenvolvidos.

Precisão das Informações

A análise de viabilidade exige precisão nos dados, de maneira que as respostas obtidas nas previsões
se mostrem exatas ou muito próximas da realidade. Ter esses dados em mãos é muito importante para
que o projeto saia do papel.

Planejamento Eficiente

Para que se possa fazer uma análise completa, é essencial que haja a definição das problemáticas a
serem sanadas, bem como dos objetivos esperados. Então, quando se faz essa análise também se
têm, consequentemente, melhores soluções para eventuais problemas que venham a surgir.

Projeções Claras

A linha-guia de uma análise de viabilidade de um projeto é trabalhar com a coleta e verificação de

dados para fazer projeções. A ideia é ter em mãos a informação financeira sobre quanto se poderá
ganhar e em quanto tempo.

-------------------------------------------------------------------------------------------------------------------------------------------

O que significa Orientação a objetos?

Orientação a objeto é um conceito que está relacionado com a ideia de classificar, organizar e abstrair
coisas. Veja a definição formal:

"O termo orientação a objetos significa organizar o mundo real como uma coleção de objetos que
incorporam estrutura de dados e um conjunto de operações que manipulam estes dados."

Vamos falar uma linguagem mas simples para isto vamos para um ambiente que você conhece bem: A
sua casa!

Agora vamos olhar a sua estante , o seu guarda-roupa , o seu armário, a sua cozinha. Em todos estes
lugares você classificou coisas no seu domínio e, somente de olhar para eles você já sabe relacionar a
classificação que utilizou em cada um deles e como classificou as coisas que estão neste lugares.

Na estante você agrupou e organizou os livros , no guarda roupa suas camisas, calças, meias, ternos,
etc. Todos os objetos que você classificou nestes lugares foram organizados baseado em alguma
concepção que você possuía sobre eles.

No contexto orientado a objeto a estante, o armário, a cozinha são chamados de classes.

No contexto de software podemos dizer que:

Uma classe é um gabarito para a definição de objetos. Através da definição de uma classe, descreve-se
que propriedades -- ou atributos -- o objeto terá.

Uma classe mantém dois elementos importantes: estrutura e comportamento.

Uma estrutura representa os atributos que descrevem a classe.

Um comportamento representa os serviços que a classe suporta.

Na 'classe' do seu guarda-roupa, uma camisa amarela pode ser colocada em uma outra classe. A
'classe' camisa.

Cada camisa tem uma estrutura que é: a textura, a cor, o tamanho e o modelo.

Cada camisa tem um comportamento que é: ordenar, rasgar, desbotar.

Se você concordar que existe uma classe camisa. Vai concordar que existem diversos tipos de camisas
com suas características, ou seja , existem diversos objetos camisas que podem ser criados a partir da
classe camisa. Daí temos o conceito de objetos:

O conceito de orientação a objetos é abordado desta mesma maneira sempre. No contexto do software
podemos então dizer que:

É através de objetos que (praticamente) todo o processamento ocorre em aplicações desenvolvidas

com linguagens de programação orientadas a objetos.

Primeiro você classifica e abstrai os elementos no sistema para proporcionar uma certa ordem, e, ao
fazer isto você define uma classe;

Feita a definição da classe você pode criar objetos desta classe. (instanciar)

Vou citar aqui o exemplo clássico da planta de uma casa.

● A Classe seria um gabarito (como uma planta de uma casa)

● O objeto é concretização do gabarito (casas feitas a partir da mesma planta)

Quando levamos estes conceitos para as linguagens de programação nada se altera.

Existem alguns conceitos básicos que estão vinculados ao conceito de orientação a objetos. São eles:

● Herança
● Encapsulamento
● Polimorfismo

A herança permite implementar a funcionalidade a sua classe de tomar emprestado o resto da estrutura
e comportamento de classes de nível mais alto.

Pensemos na classe carro.

Esta classe define os comportamentos e atributos de um carro; E existem atributos que serão comum a
todos os carros.

As rodas e o motor são atributos comuns a qualquer carro. Já uma Ferrari possui atributos que somente
ela possui : o seu alto valor por exemplo.

A definição formal seria:

Herança é um mecanismo que permite que características comuns a diversas classes sejam agrupadas
em uma classe base, ou superclasse. A partir de uma classe base, outras classes podem ser
especificadas. Cada classe derivada ou subclasse apresenta as características (estrutura e métodos) da
classe base e acrescenta a elas o que for definido de particularidade para ela

Encapsular significa "ocultar informações" ele define que cada objeto contém todos os detalhes de
implementação necessários sobre como ele funciona e oculta os detalhes internos sobre como ele
executa os serviços.

Quando você acelera um carro você está enviando uma mensagem ao motor do carro usando o
acelerador e o carro sabe que tem que acelerar.

Você não precisa saber como é feita a aceleração no motor você apenas pisa fundo no acelerador, a
implementação de como é feita a aceleração esta encapsulada do cliente.

Polimorfismo significa muitas formas , na orientação a objetos você pode enviar uma mesma mensagem
para diferentes objetos e fazê-los responder da maneira correta. Você pode enviar a mensagem de dar
marcha-ré para cada objeto semelhante a um carro e cada um vai se comportar de maneira diferente
para atender a sua solicitação.

Uma definição mais formal diria:

"Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse
podem invocar métodos que têm a mesma identificação (assinatura) mas comportamentos distintos,
especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da
superclasse"

Procurei ser o mais didático e simples possível.

Pensar em orientação a objetos realmente não é fácil e também não é a panacéia universal.

Exemplos de linguagens de programação:

Muitas das linguagens de programação mais utilizadas atualmente (talvez a maioria) são multi-
paradigma com suporte à POO. C++, C#, VB.NET, Java, Object Pascal, Objective-C, Python,
SuperCollider, Ruby e Smalltalk são exemplos de linguagens de programação orientadas a objetos.
ActionScript, ColdFusion, Javascript, PHP (a partir da versão 4.0), Perl (a partir da versão 5), Visual
Basic (a partir da versão 4), VimL (ou Vim script) são exemplos de linguagens de programação com
suporte a orientação a objetos. Vivace[3] é um exemplo de linguagem sem suporte à POO.

-------------------------------------------------------------------------------------------------------------------------------------------

“O que é Orientação a Objetos? Por que preciso tanto saber sobre isso?”
Essa é uma dúvida muito comum entre iniciantes no mundo do desenvolvimento de software.

Isso porque, quando falamos em desenvolvimento de software e seus paradigmas, existe uma
sequência de aprendizado natural:

1. Programação Imperativa
2. Programação Orientada a Objetos
3. Programação Funcional

Não que isso seja uma regra fixa e imutável, mas na maioria das vezes é a curva de aprendizado de um
desenvolvedor de sucesso. E, programação orientada a objetos (popularmente conhecida como
POO), como você pode ver, ocupa um papel central nesse processo.

Aí você me pergunta: “Por que!?”

Pois então, é exatamente sobre isso que irei falar nesse post, para assim, te ajudar a posicionar a sua
carreira profissional de acordo com todo esse cenário do mercado de programação.

Portanto, nesse post irei explicar o que é Programação Imperativa e, obviamente, o que é
Programação Orientada a Objetos. Para finalizar, pretendo deixar claro o porquê de POO ser tão
importante no mercado de desenvolvimento de software atual.

Programação imperativa

A Programação Imperativa é aquela que 99.99% dos desenvolvedores aprendem em seus primeiros
contatos com a área de programação. Geralmente, você aprende esse paradigma através de um curso
online como o da Becode ou na própria faculdade, digamos em um curso de Sistemas de Informação
(ou qualquer outro similar), onde a primeira disciplina provavelmente será “Algoritmos Estruturados ou
fundamentos da programação”.

Nessa etapa, o aluno irá ver os conceitos iniciais e extremamente importantes, geralmente pautados no
“Portugol” ou, muitas vezes, na Linguagem C.

Isso é muito comum, pois linguagens como a C possuem em seu cerne o paradigma de
desenvolvimento imperativo, ou seja, todo aplicativo/algoritmo é desenvolvido pensando-se em uma
série de etapas que o software deve cumprir para atingir o seu objetivo.

Um exemplo clássico disso seria pensarmos quais são as etapas para a troca de uma lâmpada? De
forma bem sucinta, podemos enumerar:

1. Desligar o interruptor;
2. Pegar uma escada;
3. Montar a escada;
4. Subir na escada;
5. Desenroscar a lâmpada queimada;
6. Descer da escada;
7. Jogar a lâmpada queimada no lixo;
8. Pegar uma lâmpada nova;
9. Subir na escada;
10. Rosquear a nova lâmpada;
11. Descer da escada;
12. Ligar o interruptor para verificar se a nova lâmpada acende.
Simples não é? 12 passos.

Claro, para a grande maioria dos casos, você pode chegar a uma mesma solução executando passos
diferentes, dependendo da sua escolha. Como, por exemplo, já levar a lâmpada boa quando subir a
primeira vez na escada. É justamente isso que torna a computação algo muito divertido, visto que
podemos chegar a resultados idênticos, por diferentes caminhos.

Enfim, a Programação Imperativa, em resumo, é isso, um passo-a-passo (uma sequência lógica)

para se chegar a um objetivo final.

Essa etapa é natural e muito importante na formação de um desenvolvedor. Portanto, não deve ser
atalhada!

Programação Orientada a Objetos (POO)

Após o aprendizado da Programação Imperativa, geralmente, adquirido através de aulas de introdução

à programação, fundamentos de programação, algoritmos, etc. O desenvolvedor novato percebe que
muitas das ferramentas e linguagens atuais (Java, Ruby, Python e entre outras), são linguagens que
utilizam, além do paradigma de programação imperativa, o paradigma Orientado a Objetos.

Isso, a princípio pode parecer ruim, “mais uma coisa para aprender”, mas na verdade é o que vai
permitir o desenvolvedor “subir de nível”. Agora, sabendo POO, o desenvolvedor poderá resolver os
mesmo problemas utilizando, não somente o passo-a-passo tradicional, mas também uma modelagem
do problema de uma forma mais natural/real.

Vejamos o mesmo exemplo para trocar de uma lâmpada, agora usando a Programação Orientada a
Objetos (POO). A primeira coisa a fazer é pensarmos em classes. Em outras palavras, coisas
envolvidas no estudo de caso (trocar uma lâmpada):

❏ Pessoa, Lâmpada, Escada, Bocal da Lâmpada, Interruptor.

Definido isso, podemos combinar suas características e ações. Por exemplo: “uma Pessoa pega uma
Lâmpada boa”.

Apenas esse fato de dizer que a “Pessoa” “pega” “Lâmpada” “boa” já nos diz muita coisa, pois tudo
isso pode ser modelado usando o paradigma de Orientação a Objetos. Em outras palavras, tudo não
passa de modelar Objetos que possuem ações e características.

Em nosso caso, “Pessoa” seria uma classe/objeto, “pega” seria uma ação da “Pessoa”, “Lâmpada”
seria uma outra classe/objeto e “boa” seria o estado/característica/atributo da “Lâmpada”.

Por que é tão importante!?

Então, essa pergunta pode ser respondida em duas etapas: linguagens de programação e
valorização no mercado profissional

1º ponto: Linguagens de Programação

Irei te lançar um desafio…

● Acesse o ranking da TIOBE, um dos rankings de linguagens de programação mais conceituados

e confiáveis;
● Confira as linguagens que ocupam as primeiras posições do ranking;
● Agora acesse o Wikipédia e procure características sobre essa linguagem.
● Eis o que em 90% dos casos você irá encontrar:

“Essa linguagem de programação é baseada no paradigma orientado a objetos”

Sim, exato! Hoje em dia, o mercado de programação é dominado pelo paradigma orientado a objetos.
Em outras palavras, é raro você trabalhar com uma linguagem de programação atual que não suporte
POO. Sendo assim, fica claro o meu 1º ponto:

Saber POO não é um capricho, mas sim uma exigência do mercado.

[easy-tweet tweet=”Saber POO não é capricho, mas sim uma exigência do mercado.” user=”becodett
@jackson_pires” hashtags=”POO” template=”light”]

2º ponto: Valorização profissional

Aí você pode tentar desconstruir a minha abordagem anterior com o seguinte argumento:

“Eu sei programar em ‘linguagem Orientada a Objetos’, mas não domino os fundamentos de POO”

Claro, isso é possível. Contudo, provavelmente você não estará utilizando o melhor que aquela
linguagem de programação tem a oferecer.

Resumindo, existem dois tipos de desenvolvedores: aqueles que fazem e aqueles que fazem e
sabem o que estão fazendo (teoria + prática).

O primeiro é aquele que provavelmente aprendeu a programar totalmente na prática, sem uma base
teórica de qualidade, o que não está errado, mas também não estará em suas plenas capacidades
profissionais.

Já o segundo, além de programar, consegue abstrair os requisitos do mundo real para o software,
utilizando os conceitos de Orientação a Objetos no desenvolvimento do produto. A consequência
disso é a utilização das melhores práticas, um software mais duradouro em termos de manutenibilidade
e uma qualidade final de software superior.

Aí eu te pergunto, qual desenvolvedor será mais valorizado e possuirá mais chances de ter uma
carreira de sucesso? Aquele que sabe programar ou aquele que sabe programar e também entende
os paradigmas de programação

Acredito que você já saiba resposta. Este é o 2º ponto.

Resumindo…
Se programação orientada a objetos for uma novidade pra você, tenho certeza que mexeu com seus
neurônios, mas ao mesmo tempo te deixou na vontade de entender a fundo como tudo isso funciona.

Obviamente, em um artigo com poucas palavras é quase impossível explicar de forma clara o que vem
de fato a ser a POO. Por outro lado, fica claro também que conhecer esse paradigma faz parte da
evolução natural do desenvolvedor e fazer carreira nessa área depende também de ter ou não esse
conhecimento em seu sangue.

Mesmo com tantos percalços, o mais legal é que esse paradigma, depois de aprendido, pode ser
aplicado a qualquer linguagem de programação que o suporte.

-------------------------------------------------------------------------------------------------------------------------------------------

O que é UML (Unified Modeling Language)?

UML (Unified Modeling Language) é uma linguagem poderosa para comunicação em equipes de
produção de software

Basicamente, UML (Unified Modeling Language) é uma linguagem de notação (um jeito de escrever,
ilustrar, comunicar) para uso em projetos de sistemas.

Esta linguagem é expressa através de diagramas. Cada diagrama é composto por elementos (formas
gráficas usadas para os desenhos) que possuem relação entre si.

Os diagramas da UML se dividem em dois grandes grupos: diagramas estruturais e diagramas

comportamentais.

Diagramas estruturais devem ser utilizados para especificar detalhes da estrutura do sistema (parte
estática), por exemplo: classes, métodos, interfaces, namespaces, serviços, como componentes devem
ser instalados, como deve ser a arquitetura do sistema etc.

Diagramas comportamentais devem ser utilizados para especificar detalhes do comportamento do

sistema (parte dinâmica), por exemplo: como as funcionalidades devem funcionar, como um processo
de negócio deve ser tratado pelo sistema, como componentes estruturais trocam mensagens e como
respondem às chamadas etc.

UML deixa as coisas claras

UML ajuda muito a deixar o escopo claro, pois centraliza numa única visão (o diagrama) um
determinado conceito, utilizando uma linguagem que todos os envolvidos no projeto podem facilmente
entender.

Mas ajuda desde que utilizada na medida certa, ou seja, apenas quando realmente é necessário.

O maior problema na produção de software, a maior dor, em qualquer país do mundo, chama-se
comunicação ruim.

Para que serve?

O objetivo de um diagrama da UML é passar uma mensagem de maneira padronizada, onde todos os
receptores deste mensagem entendem o padrão usado.

É o famoso: “entendeu ou quer que desenha?”

 Imagine que numa mesma sala, sem internet e telefone,
estão três pessoas que só falam seu idioma nativo: um
chinês, um francês, e um brasileiro.

Nesta sala tem apenas papel e lápis. O francês quer um

café.

Qual será a maneira mais eficiente, considerando os

recursos disponíveis na sala, para o francês passar a
mensagem “quero um café”?

Talvez fazendo um desenho de uma xícara de café! 😉

Deixar isso claro, de maneira simples, objetiva,

transparente e pragmática, é comunicar-se bem.

Levando o raciocínio acima para projetos de software, a

UML deve ser utilizada para comunicar o que se quer e/ou como se quer, de maneira eficiente.

No passado utilizou-se UML muito para documentar software existente, fazer projeto preditivo de
sistema (ou seja, via diagrama documentar 100% do que deveria ser feito) etc. Isso quase nunca é
viável.

A UML serve para uma boa comunicação em equipes que produzem software, onde através do uso
de diagramas adotamos uma linguagem que todos entendem, para deixar claro o que deve ser feito.

Quando usar?

O uso de diagramas da UML deve ser feito quando:

● É necessário especificar o desejo do cliente que será materializado no software.

● Quando membros de uma equipe precisam ter uma visão única e padronizada sobre algo, seja
no contexto de escopo funcional (requisitos, estórias de usuário ou modelos de processo) e não
funcional (foco na arquitetura/estrutura do sistema e integrações)
● Comunicar para o mundo externo protocolos (contratos) de interfaces do sistema que devem ser
consumidas por terceiros ou ilustrar topologias arquiteturas físicas/lógicas.