Orientação a Objetos: princípios de OO para arquiteturas robustas

quinta-feira, 8 de maio de 2014

"Este artigo aborda conceitos de orientação a objetos que permitirão ao leitor desenvolver código com maior qualidade visando maior reutilização, menos defeitos, design mais simples e melhor separação de responsabilidades. Para isto, são apresentadas interpretações dos conceitos fundamentais da orientação a objetos que servirão como alicerce para o aprofundamento nos conceitos de design que nortearão o desenvolvimento de aplicações mais robustas."

Este é o resumo do artigo Orientação a Objetos: princípios de OO para arquiteturas robustas.

O artigo, do qual eu e da Cristina Cerdeiral somos autores provavelmente será do interesse de todos que utilizam orientação a objetos foi publicado na edição 127 da revista Java Magazine, de distribuição nacional e não aborda nada específico de Java nem apresenta código Java algum, sendo assim bastante útil a desenvolvedores de outras tecnologias (a exemplo de outros artigos deste blog).

A página na qual assinantes podem ler online permite ler uma parte inicial:

"No nosso cotidiano, usamos generalizações todo o tempo. A generalização é um mecanismo extremamente útil que nos permite fazer referência a um grupo de indivíduos de uma determinada população através de suas características comuns.
Por exemplo, ao referenciarmos os alunos de uma turma através do nome da turma, estamos utilizando a característica daquelas pessoas serem alunos e a participação em um determinado grupo como características comuns. É muito mais simples do que enumerar todos, um a um, pelo nome.
Assim, recorremos a duas generalizações (“alunos” e a participação em uma turma específica) para “delimitar” o universo de indivíduos a que estamos nos referindo.(...)"


Boa leitura a todos.

Bookmark and Share

Workshop de Melhoria de Processos de Serviços baseado no modelo MPS.

quarta-feira, 23 de abril de 2014

Para quem não conhece o Modelo MPS para Serviços, vale a pena ir ao workshop. O Modelo MPS apresenta algumas diferenças (inclusive conceituais) em relação ao ITIL, é compatível com o modelo CMMI for Services e pode ser utilizado para avaliação dos processos das empresas em níveis de capacidade e maturidade exatamente como o MPS Software e o CMMI Software com a vantagem de contar com profissionais habilitados e altamente capacitados em várias cidades brasileiras, inclusive no Rio de Janeiro como a COPPE/UFRJ e a Implementum que estão realizando o workshop.

É uma excelente oportunidade e estudantes contam com desconto de mas de 50%.


Abraço a todos!

Bookmark and Share

Curso de Introdução - Melhoria de Processo de Software - Rio de Janeiro

quarta-feira, 20 de novembro de 2013

Pessoal, segue o anúncio do curso de introdução ao MPS.BR.

Se quiserem saber mais sobre o MPS.BR, acessem http://www.softex.br/mpsbr.

O Gleison, instrutor deste curso, é muito experiente, já deu este curso inúmeras vezes e explica com muita clareza.

... e tem desconto significativo para estudantes! :-D


Abraço a todos!

Bookmark and Share

WBS automática do cronograma do MS Project

sexta-feira, 8 de março de 2013

A WBS (Work Breakdown Structure) é a decomposição de um projeto em componentes menores, os produtos de trabalho. Pode ser feita orientada a produto, na qual são detalhados os componentes a serem construídos ou de processo, na qual são detalhadas as atividades a serem executadas no projeto. A EAP (Estrutura Analítica do Projeto, em português) é um diagrama útil na gerência do projeto para visualizar o que deve ser feito de maneira estruturada.

Neste artigo demonstro como criar uma automaticamente em qualquer ferramenta do MS Office (versão 2007 ou superior) a partir do cronograma do MS Project.

Bookmark and Share

Metas e alinhamento com os objetivos estratégicos

quarta-feira, 7 de novembro de 2012


Sua empresa divulgou o resultado do planejamento estratégico. Um plano com objetivos e metas. E você com isso?

Diariamente boa parte dos trabalhadores chegam ao seu local de trabalho, executam suas atividades e vão embora. A grande maioria não se pergunta a relevância das suas atividades ou das atividades que delega a outros. Algumas vezes estes são os próximos "recursos disponibilizados para o mercado" como ouvi de uma colega. O objetivo deste artigo é fazer com que você não faça parte deste grupo.
 
Toda empresa bem administrada tem um objetivo a ser atingido. Para isto, são traçadas metas em um plano, o plano estratégico. Estas metas são a definição da estratégia que a empresa espera seguir para atingir estes objetivos. Atualmente é muito comum se falar de "alinhamento com os objetivos estratégicos" mas pouca gente sabe alinhar de verdade o seu trabalho com os objetivos da organização que, por isto, acabam não sendo atingidos.

Bookmark and Share

Introduzindo novas tecnologias

quarta-feira, 30 de março de 2011

Em conversa recente com amigos, levantamos a dificuldade de se introduzir novas tecnologias, como um novo ambiente ou uma nova linguagem de programação em uma organização. A questão não se resume a problemas técnicos, mas a problemas pessoais, barreiras psicológicas, etc.

Por exemplo, se uma pessoa se considera em uma zona de conforto (por exemplo, se ela domina bastante uma linguagem de programação popular) pode haver uma certa resistência em colocá-la para aprender uma nova tecnologia (como outra linguagem de programação).

Para resolver problemas como estes, há diversos tipos de abordagens, envolvendo, inclusive, tirá-la da zona de conforto. No entanto, o propósito deste post é discutir questões organizacionais e levantar 5 pontos interessantes para definir uma estratégia para a introdução de novas tecnologias, mais especificamente, de uma nova linguagem de programação, na esperança de que alguns destes pontos possam ser úteis inclusive em outros contextos.

Existem vários motivadores para que uma organização resolva adotar uma nova tecnologia. Entre eles, a exigência de um projeto específico ou de um cliente importante ou até uma meta organizacional. Estes cenários tem suas peculiaridades e devem ser exploradas de forma diferenciada.

Se um projeto específico deve ser feito com uma tecnologia diferente da que a equipe está acostumada a trabalhar, pode ser conveniente, para reduzir os riscos do projeto, investir em treinamentos, contratar gente especializada ou encontrar algum colaborador que detenha conhecimento suficiente e possa dedicar atenção suficiente à equipe do projeto. Após a conclusão do projeto e seu período de manutenção, a mesma demanda por aquela tecnologia pode não ser mais necessária e evoluções podem ser feitas por membros da equipe que adquiriram conhecimento através do primeiro projeto.

Diferentemente deste cenário, a de exigência de um cliente importante ou uma meta estratégica da organização são questões mais duradouras e mais impactantes na organização pois outros futuros projetos serão garantidamente construídos sobre a nova base tecnológica.

O início de todo projeto já traz suas próprias complicações. Todos os envolvidos estão se familiarizando com os objetivos do cliente, com os padrões do projeto, sua arquitetura, suas funcionalidades e restrições. Além da própria curva de aprendizado do projeto, trazer uma nova linguagem de programação traz as curvas de aprendizado do ambiente de desenvolvimento e da linguagem em si, além de bibliotecas e frameworks de terceiros, sem as quais se torna muito custoso desenvolver softwares profissionalmente.

Assim, iniciar com uma equipe inexperiente um projeto com tantas novidades pode ser bastante caótico. Enquanto uma organização pode achar que um projeto pequeno pode ser utilizado, vale lembrar que um atraso de 1 semana em um projeto de 1 mês é muito pior que um atraso de 2 semanas em um projeto de 6 meses. Por outro lado, passar 2 meses na construção de um projeto para descobrir que é inviável na tecnologia escolhida pode inviabilizar o projeto completamente.

Então, quais ações poderiam ser adotadas para minimizar o impacto da introdução de uma nova tecnologia, como uma linguagem de programação?

Minha primeira sugestão é simples:

Quando se trata de atingir um objetivo/meta organizacional, o custo deve ser organizacional e o treinamento da equipe deve ser encarado da mesma forma: como um investimento para se atingir um objetivo.
Logo, pode ser contratado um treinamento, uma consultoria especializada para coaching/mentoring ou tentar orientar o aprendizado individual dos colaboradores.
Uma forma simples de fazer isto é a minha primeira proposta:

1- Alocar pequenas tarefas para cada colaborador.
Por exemplo, um fica responsável por configurar o ambiente e documentar de forma que outros consigam fazê-lo. Outro configura de acordo com o conhecimento registrado e cria uma projeto de exemplo, como o famoso "hello world", registrando seu aprendizado. Um terceiro pode implementar algo simples, como um cadastro de usuários, e um quarto, um sistema de login.
Através de atividades simples e pequenas, pode-se construir e incrementar o conhecimento organizacional, levando à minha segunda proposta.

2- Projeto startup.
Um projeto configurado com algumas funcionalidades simples e comuns pode ser replicado para servir como ponto de partida para outro projeto. Além de servir como exemplo, pode já trazer algumas funcionalidades comuns já implementadas, bastando fazer pequenos ajustes. Isto diminui o tempo e custo do projeto, compensando pelos gastos no aprendizado. Como outros projetos serão feitos na mesma tecnologia, a cada projeto, uma parte deste investimento será retornado.
Um projeto interno também pode ser utilizado se for considerado que seu investimento trará retorno para organização, no entanto, às vezes vale mais a pena escolher um pacote de funcionalidades comuns que irão se repetir em projetos externos ao invés de escolher um projeto interno com muitas especificidades.

3- Investigar, no início do projeto, como resolver as partes mais complicadas, as que se julga serem mais difíceis de serem feitas.
Muitas vezes pode-se descobrir frameworks ou bibliotecas que sozinhos ou combinados podem resolver o problema de forma satisfatória, no entanto, pode-se descobrir que tudo terá que ser construído do zero ou que esta é a forma mais apropriada para aquele cenário. Saber disto no início do projeto ajuda a determinar se a escolha da tecnologia foi adequada, se as necessidades serão atendidas e a minimizar o impacto destes riscos. Também, resolver estas questões pode trazer uma sensação de confiança e tranquilidade à equipe, o que pode ajudar a garantir o sucesso do projeto e até animá-los no aprendizado da nova tecnologia.

4- Escolher o cliente é tão importante quanto escolher o projeto.
Alguns clientes são mais tolerantes a pequenos atrasos que outros, alguns podem aceitar compensações (como uma ou outra funcionalidade extra) ao contrário de outros. Às vezes esta questão tem que ser levada em consideração na escolha de um primeiro projeto em uma nova tecnologia.

5- Rever o plano de implantação com antecedência.
Se a sua organização não tem um plano de implantação mas mesmo assim irá implantar o projeto, convém não só fazer um teste da implantação antes do primeiro release como documentar os passos tomados e as dificuldades encontradas, para que no momento do primeiro release, tudo siga suavemente. Isto é importante tanto para a moral da equipe, em saber que o primeiro release foi implantado e está funcionando corretamente quanto para que não se virem noites tentando resolver problemas de última hora, o que pode inclusive afetar a imagem da organização para o cliente.

Abraço a todos!

Bookmark and Share

O diferencial Ágil

sábado, 5 de fevereiro de 2011

Desenvolvimento iterativo e incremental em ciclos curtos. Só isso?

Bookmark and Share

 
addthis_config = { data_ga_tracker: pageTracker }