Antes de iniciar a leitura, saiba que parte deste material foi retirado do site da revista Veja no artigo “Quer ganhar mais? Seja um craque de TI“.

As médias salariais apresentadas estão disponíveis na 38° edição da Pesquisa Salarial e de Benefícios da empresa Catho Online, grande empresa da área de recrutamento e seleção. Segundo a Catho, os dados são atualizados a cada 3 meses e a pesquisa utiliza-se de uma metodologia exclusiva, sendo a única respondida por profissionais de todo Brasil. Esta edição conta com mais de 260 mil respondentes de mais de 21 mil empresas em mais de 4 mil cidades.

Atenção:

Abaixo seguem as médias das 15 principais áreas de TI nas cinco regiões brasileiras: norte, nordeste, centro-oeste, sudeste e sul.

Administração de Banco de Dados

Administração de Redes

Arquitetura da Informação

Conteúdo Web

Criação Web

E-commerce

Negócios web

Processamento de Dados

Programação

Qualidade de Software

Segurança da Informação

Sistemas
Responsável pelo planejamento, desenvolvimento e implantação de projetos de TI dentro de uma empresa

Suporte Técnico em Informática

Tecnologia da Informação (subárea)
Engloba as divisões de informática, implantação de sistemas da informação, consultoria de sistemas da informação, planejamento, organização e controle administrativo.

Web Development

A etapa de testes no processo de desenvolvimento de software ainda é vista com olhos ruins por muita gente. Na verdade, isso existe pelo conflito de interesses: os desenvolvedores de um lado, querendo mostrar que o seu programa é isento de falhas, e a equipe de QA do outro, buscando a qualquer custo encontrar falhas no sistema.

Mesmo que de certa forma tenhamos que trabalhar esses conflitos, é importante ter outra equipe que teste o que foi desenvolvido. Como já disseram por aí, “não existe filho feio para a mãe”, e o programador tem um tendência natural a achar que tudo que desenvolveu está perfeito.

Contudo trabalhar com somente com uma equipe pode não resolver todos os problemas. Ainda que essa seja boa o suficiente para cumprir o seu papel, o usuário é o verdadeiro tester, já que é quem usará o programa no dia-a-dia. Com a ideia do usuário como tester surgem dois conceitos, chamados de Teste Alfa e Teste Beta.

O Teste Alfa  é aquele realizado no ambiente do desenvolvedor, mas pelo usuário final do programa. Já o Teste Beta é realizado no ambiente do cliente, sem a presença do desenvolvedor, aonde o próprio cliente relata quais são erros observados que serão posteriormente corrigidos.

Os testes de software podem ainda ser classificados quanto a  técnica utilizada. Dentre eles os principais são:

Existe ainda a Técnica Baseada em Erros, que se baseiam na inclusão de erros propositais (artificiais) como forma de revelar erros existentes previamente (naturais).

Por fim, lembre-se: bons testes de software são aqueles que apresentam maior probabilidade de revelar erros ainda não descobertos!

Veja perfil e 26 post(s)

Uma tarefa muito difícil no momento de montar a loja virtual é definir a plataforma de e-commerce. Nem sempre o novo lojista tem um plano de negócios bem elaborado e não faz ideia das dimensões do novo negócio.

Como escolher a plataforma adequada sem ter ideia da capacidade de venda?

Realmente não é uma tarefa fácil, mais difícil ainda é trocar de plataforma depois que a loja está vendendo. É quase como você tentar passar de um carro para o outro, em pleno movimento.

É muito comum os lojistas começarem com uma ferramenta menor, sem flexibilidade e mais barata. No decorrer do negócio percebe-se que poderia vender muito mais se tivesse uma plataforma melhor, e, nesse momento, chega a hora da troca da plataforma.

Quando se inicia o processo de troca, é praticamente como se estivesse começando do zero, sendo necessário planejamento, pessoas especializadas e muito esforço. Veja os pontos críticos deste processo:

1 – Gerenciar o projeto. Um dos pontos mais críticos de todo o processo, pois a troca da plataforma significa começar de novo, exigindo o gerenciamento como um novo projeto. É necessário entender quais as atividades e seus responsáveis, lembrando que sempre são várias empresas envolvidas.

2 – A migração de dados dos produtos, geralmente, é um passo extenso e delicado, pois muito provavelmente os dados que estão na antiga plataforma não seguem o mesmo modelo para o cadastro da ferramenta nova. Neste momento será feito o trabalho de re–cadastro, análise das imagens e adequação do conteúdo.

3 – A migração dos dados dos pedidos quase nunca é possível, muitas vezes devido às diferenças nos modelos entre as plataformas. Porém, se o lojista tiver um ERP integrado, esse problema é minimizado.

4 – É necessário pensar na integração com a nova loja, pois demanda tempo e dinheiro. Muitas vezes o lojista inicia a implantação de um ERP adequado ao negócio, fazendo assim com que a troca da plataforma se transforme ainda mais em um projeto complexo.

5 – Trabalhar a equipe para aprender a manusear na nova ferramenta e colocá-los na mesma sintonia da empresa não é uma tarefa simples. Toda mudança gera um desconforto e aumento de trabalho.

6 – E o cliente que acessa essa nova loja? Ele precisa ser comunicado da mudança para minimizar o risco de estranhar sua primeira visita e não realizar a compra.

7 – SEO (Search Engine Optmization) – Dependendo da tecnologia da nova plataforma, será necessário começar do zero. Isso mesmo, tudo que estava feito na ferramenta anterior poderá se perder. É claro que com uma boa plataforma e com uma integração bem trabalhada, rapidamente será possível recuperar e melhorar.

8 – Por último, o ponto que geralmente gera mais conflitos: o alinhamento de expectativas. O lojista não imagina todo o trabalho que terá e se depara com todas as dificuldades citadas acima e, ainda, pode passar por um período de queda no faturamento, mesmo com consciência de que a nova ferramenta trará mais lucro a médio e longo prazo.

Na maioria dos casos em que as empresas querem manter ou acelerar seu crescimento, trocar para uma nova plataforma não é uma opção. Portanto, o ideal é fazer uma escolha assertiva desde o início de sua operação de comércio eletrônico para não ter que passar pelo trauma da troca.

* Carolina Soares é Consultora de Vendas da VTEX (www.vtex.com.br )

Os mitos de software são “falsas verdades” que existem no mundo da indústria de software. Tanto jovens engenheiros quanto pessoas mais experientes tendem a acreditar neles, distorcendo a verdadeira face do processo de engenharia. Os mais comuns são:

Desenvolvimento não é uma receita de bolo! Os clientes são diferentes, os projetos são diferentes, os programadores são diferentes, as prioridades dependem do projeto. Basicamente, TUDO é diferente. Não pense que um site de ecommerce que você desenvolveu para a empresa X valerá para a empresa Y, e vice-versa. O planejamento é fundamental e só então você poderá levantar os requisitos necessários e trabalhar em cima de um novo projeto.

Por mais que exista o conceito de “Fábrica de Software” não podemos pensar no processo de desenvolvimento como uma linha de produção. Ao se inserir um programador em um projeto, ele levará algum tempo para se familiarizar com o código e com o que está sendo feito, para então, começar de fato a produzir. Outro grande pecado que muitos gestores comentem é tratar o programador como “pedreiro”, como um “peão”. Se o o desenvolvedor não entende nada do processo da empresa para o qual está desenvolvendo, tenha certeza que não poderá contribuir da melhor maneira possível. Mais um vez, quero frisar: Desenvolvimento não é linha de produção. Alocar programadores para resolver um problema de cronograma poderá surgir efeito contrário, causando mais problemas!

Quando um projeto é muito trabalhoso, requer know-how maior do que a sua equipe possui ou o cronograma está apertado, muitos optam pela terceirização achando que esta é uma garantia de tranquilidade e nenhum trabalho. Contudo, tome cuidado: Se a empresa X contratou você, você é o responsável pelo trabalho que está entregando. Ou seja, qualquer problema será um problema seu também! A maioria das empresas terceiriza o serviço, mas ao comprar o código, fica responsável por suas manutenções. Aí fica a pergunta: A terceirização fez o serviço direito? Comentou o código? Documentou o que foi feito? Sua equipe tem pessoal para trabalhar nesse código? Pense bem antes de terceirizar algo que não poderá trabalhar bem no futuro. É melhor recusar um projeto do que faze-lo mal feito.

Se você é desenvolvedor já deve ter se deparado com um usuário que só queria um ajustizinho no sistema: “só adicione um botão que faça isso e busque aquilo e faça isso ficar cor de rosa e brilhar girando”. Sim, essas coisas acontecem! Ao se pensar em um software deve-se mapear o máximo possível de suas funcionalidades a serem desempenhadas. É claro que em um primeiro momento é difícil pensar em tudo, alguma coisa ou outra vai entrar como correção. Mas pensar em algo básico demais e querer enfeita-lo demais depois, envolve mais tempo e o pior: retrabalho! Desenvolvedores geralmente não gostam de destruir algo para faze-lo de outra forma, pois o cliente mudou de ideia. Aliás, ninguém gosta. Como eu disse, existem exceções, mas se você não entende de desenvolvimento e só gerencia o processo, não pense que os seus “detalhes” são realmente detalhes quando viram linhas de código!

Mais uma vez, se você não é desenvolver e não entende do processo, não julgue uma atualização como simples. Somente um programador poderá avaliar o quão simples uma alteração é – e muitas vezes, ela só vai realmente ter a ideia depois que estiver trabalhando com o código. Mesmo que você tenha uma boa equipe, modificações devem ser analisadas, discutidas com relação a sua viabilidade e testadas. Lembre-se sempre: alocar um programador requer algum tempo para que esse se familiarize com o que vem sendo feito. As coisas não são tão simples.

Esses dois tópicos são assutadoramente passados adiante e você já deve ter ouvido isso de alguém. Se um programa roda isso não garante que o seu trabalho está feito. Todo o processo de desenvolvimento deve buscar a qualidade e apenas funcionar não lhe garante isso – ou seja, o processo da avaliação de qualidade não se limita a essa etapa. O seu código é bem comentado? Está bem feito? Otimizado? A tecnologia utilizada é adequada? Os banco de dados estão otimizados? Sua relações foram criadas corretamente? A infraestrutura do cliente suporta o que está sendo desenvolvido? Se o seu sistema foi feito para suportar vários acessos, ele realmente suporta isso? Um programa é mais do que o executável. Você vende todo o processo.

Em alguns casos, o produto “palpável” que o cliente recebe é somente o executável. Em outros, trabalha-se com o código fonte e com a documentação. Contudo, independente do caso, lembre que, como foi dito no item anterior: Um programa é mais do que o executável. Você vende todo o processo de desenvolvimento. Por isso, deve-se pensar e faze-lo com perfeição.

Planejamento é fundamental! Muitas pessoas aindam confundem planejamento com “papelada” e estas estão terrivelmente enganadas! Mesmo trabalhando-se em um time Agile, planejar é fundamental! A documentação do projeto será trabalhada na melhor metodologia adotada mas um plano do que será feito deverá ser estudado antes de “colocar a mão na massa”. Somente com o estudo dos processos e necessidades do cliente você conseguirá criar um software que trabalhe com excelência!

Originalmente postado em Eu Faço Programas

Como o próprio título diz, esse post tem como função ser um guia rápido de consulta aos principais diagramas da UML. Serve, principalmente, para você que, como eu, não é lá muito fã de documentação mas precisa fazê-la, mesmo que em trabalhos da faculdade

Clique nas imagens para ampliá-las.

Representa o conjunto de comportamentos de alto nível que o sistema deve executar para um determinado ator. É o diagrama mais simples, e não há necessidade de grandes detalhamentos.

A figura acima ilustra um caso de uso geral, mas é recomendado que eles sejam desenvolvidos para cada cenário. As setas de includes e extends, indicam, respectivamente, obrigatoriedade e opção de se realizar determinada ação.

Representa uma coleção de classes e seus inter-relacionamentos.

Representa um retrato, em tempo de execução, dos objetos do software e seus inter-relacionamentos.

Representa uma coleção de objetos que trabalham em conjunto para atender algum comportamento do sistema.

Representa uma perspectiva, orientada por tempo, da colaboração entre os objetos.

Representa o fluxo de tarefas que podem ser executadas pelo sistema ou por um ator.

Representa um conjunto de estados que um objeto pode estar e os “gatilhos” que estimulam a transição do objeto de um estado para outro.

Representa uma coleção de componentes de software e seus inter-relacionamentos.

Representa uma coleção de componentes e mostra como esses são distribuídos em um ou vários nós de hardware.

Representa uma coleção de outros elementos de modelagem e diagramas.

Artigo postado originalmente em Eu Faço Programas