Orientação a Objetos

Métodos Ágeis: É Importante a Certificação?

g2996Neste artigo vou abordar a importância da certificação em métodos ágeis. O uso de métodos ágeis como uma abordagem para gerenciamento de projetos tem aumentado dramaticamente nos últimos anos. O Gartner prevê que os métodos ágeis serão utilizados em 80% de todos os projetos de desenvolvimento de software.

Uma pesquisa feita pelo PMI mostrou que o uso de práticas ágeis tem aumentando drasticamente ao longo dos anos. Além disso, a pesquisa demonstra o valor que métodos ágeis podem ter na redução de defeitos do produto, melhorando a produtividade da equipe, melhoria na entrega e aumento do valor comercial.

O PMI-ACPSM está posicionado para reconhecer e validar o conhecimento desta importante abordagem. Com a disseminação do gerenciamento de projetos e do constante desenvolvimento de suas ferramentas, os profissionais da área vem se confrontando com um mercado próspero–porém muito complexo.

Devido ao crescimento desse mercado ocorreu também a expansão de diversos cursos de especialização na área de gerenciamento de projetos, praticamente em todas as cidades de médio/grande porte existem dezenas desses cursos. Tendo em vista à evolução do gerenciamento de projetos, o PMI, reconhecendo as necessidades do mercado, oferece diferentes certificações, entre elas a PMI –Agile Certified Pratictioner (PMI-ACP) resultado do ambiente de negócios dinâmico em que hoje as diferentes organizações atuam.

O aumento do número de cursos por um lado proporciona o fomento da área e a formação de massa crítica, porém a falta de padronização e muitas vezes a dissonância com as práticas do Guia PMBOK® criam dúvidas sobre a qualidade de muitos cursos e consequentemente sobre o conhecimento de alguns profissionais.

A grande necessidade de ganhar competitividade estimula as empresas a operar em mercado mais amplos, cooperando e competindo para melhorar sua qualidade e preço, isso gera muitos gastos e para compensar os mesmos, há uma grande necessidade em agregar valor à empresa. Essa realidade vivida pelo setor mais tradicional do gerenciamento de projetos se adéqua melhor quando se utiliza o método ágil, por esse setor ser relativamente novo quando comparado ao gerenciamento de projeto tradicional.

Pensando um pouco sobre a questão do desenvolvimento, esse desenvolvimento se faz presente em diversas áreas do conhecimento técnico e assim, são utilizadas certificações profissionais, pois essas representam o reconhecimento da habilidade e experiência no uso das técnicas e aplicação de conhecimentos, assim, mantendo um diferencial e adicionando confiabilidade ao currículo de cada profissional. Deve ser visto em seu sentido mais amplo a comprovação formal dos conhecimentos, habilidades, atitudes e capacidade do profissional, requeridos para a execução de uma determinada atividade.

As melhores práticas do gerenciamento de projetos difundidas e consolidadas, em sua forma tradicional, começaram a serem questionadas. Em uma área do gerenciamento de projetos envolvida intensamente com desenvolvimento tecnológico de software como o gerenciamento ágil de projeto, as mudanças técnicas são constantes e extremamente rápidas.

Para atender as demandas desses projetos tecnológico o gerenciamento ágil de projetos utiliza ferramentas que focam as entregas ao invés das extensas documentações.

Onde estão os valores e princípios?

Para os Valores, temos:

  • Indivíduos e interações mais que processos e ferramentas;
  • Software em funcionamento mais que documentação abrangente;
  • Colaboração com o cliente mais que negociação de contratos;
  • Responder a mudanças mais que seguir um plano;

Para os Princípios, temos:

  • Maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado;
  • Mudanças nos requisitos são bem vindas, mesmo tardiamente no desenvolvimento;
  • Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente;
  • Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo;
  • Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
  • Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho;
  • O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face;
  • Software funcionando é a medida primária de progresso;
  • Os processos ágeis promovem desenvolvimento sustentável;
  • Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
  • Contínua atenção à excelência técnica e bom design aumenta a agilidade;
  • Simplicidade — a arte de maximizar a quantidade de trabalho não realizado — é essencial;
  • As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis;
  • Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo;

O PMI apresenta uma certificação (como citada anteriormente), que cumpre o propósito de padronizar e disseminar o gerenciamento ágil de projetos, reunindo as seguintes exigências de conhecimentos práticos e teóricos dos certificados: educação secundária (ensino médio ou equivalente) ou superior, 2.000 horas de trabalho em projetos adquiridos nos últimos 5 anos, 1.500 horas de trabalho em projetos -usando técnicas ágeis -adquiridos nos últimos 2 anos, 21 horas de treinamento em Gerenciamento Ágil de Projetos.

Os conceitos Ágeis através de diferentes métodos e processos, foram sendo incorporados no gerenciamento de projetos e sua utilização aplicada em diversas organizações. Não poderia deixar de adicionar ao texto, as principais vantagens do gerenciamento ágil de projetos:

  • Retorno mensurável do investimento mais cedo, entrega iterativa de incrementos dos produtos;
  • Alta visibilidade do andamento do projeto, permite a identificação precoce e resolução ou monitoramento de problemas;
  • Envolvimento contínuo do cliente em todo o ciclo de desenvolvimento do produto;
  • Melhoria na satisfação e motivação dos times de desenvolvimento do projeto;
  • Poder ao proprietário da empresa para tomar decisões necessárias para atingir as metas;
  • Adaptação à evolução das necessidades de negócio, dando mais influência sobre as mudanças de requisitos;
  • Redução dos resíduos do produto do processo;
  • Maior pontualidade na entrega. Estimativas mais realistas, clientes mais envolvidos e satisfeitos

A intensiva competitividade na área de desenvolvimento de software faz com que as empresas busquem sempre o aperfeiçoamento de seus serviços para poder vencer a concorrência. Prazo e qualidade, além é claro de melhor aceitação e adaptação a mudanças são importantes diferenciais que podem ser atingidos utilizando-se metodologias ágeis de desenvolvimento. Embora não seja a solução para todos os problemas, a metodologia ágil mostra uma maneira de trabalhar bastante organizada e iterativa, podendo inclusive contribuir para um ambiente de trabalho mais amigável, portanto é uma boa opção para se obter os diferencias desejados.

Em um mundo qualificado pelo desenvolvimento tecnológico e pela dispersão do uso de software em praticamente todas as áreas do conhecimento humano, faz-se necessário um novo tipo de gestão para os projetos.

O mundo hoje depende de projetos e, para muitas organizações, são eles que garantem o dia de amanhã e permite-lhes sobreviver e crescer.Assim sendo, os métodos ágeis veem respondendo de forma positiva a essas necessidades, por focar os esforços da equipe no produto final e nas necessidades do cliente, relevando à segundo plano o processo de documentação exaustivo. Uma vez que as empresas estejam ao par de tais metodologias e as principais ferramentas utilizadas na Gestão de Projetos aprendido na prática o que tange às certificações, então será possível um maior alcance nas credenciais e certificações.

O PMI veem trabalhando para criar um padrão para os métodos ágeis através do PMI-ACP Examination Content Outline e da certificação PMP-ACP. Outro ponto relevante do PMP-ACP é a re-certificação, a qual difunde as práticas do gerenciamento ágil e estabelece a necessidade de constante aprimoramento dos profissionais certificados.

Espero que tenham gostado do artigo.

Márcio Pulcinelli @ OminaVIncit


Referências:

[1] LEFFINGWELL, Dean and MUIRHEAD, Dave, Tactical Management of Agile Development: Achieving Competitive Advantage. 2004. Boulder, Colorado

[2] SOARES, Michel dos Santos, Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Unipac-
Universidade Presidente Antônio Carlos, Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete

[3] Agile Manifesto, Disponível em http://agilemanifesto.org/

[4] SCHWABER , Ken, What Is Scrum?

[5] www.scrumalliance.org

[6] PMI. Profissional Certificado em Métodos Ágeis.Disponível em:http://brasil.pmi.org/brazil/CertificationsAndCredentials/PMI-ACP.aspx/.


SharePoint – Desenvolvimento em Camadas

Neste artigo vou demonstrar como desenvolver um aplicativo usando o ambiente SharePoint 2010.

Usarei um exemplo bem simples para ilustrar a questão da arquitetura e como desenvolver de forma nativa, sem necessidade de utilização de banco de dados externo a nossa aplicação.

Vou assumir como premissa que você ja tenha o ambiente SharePoint 2010 assim como o Visual Studio 2010 ou o Visual Studio 2012 instalado e configurado.

Utilizarei uma abordagem simples em 3 camadas para a arquitetura da aplicação.

A aplicação que será desenvolvida, será um “web diário“. A aplicação em si não é relevante (crie a sua própria), o que é importante neste artigo, é entender como desenvolver nativamente em SharePoint.

Então vamos por a mão na massa.

Para baixar o projeto Login to view.

 

A estrutura da nossa aplicação deverá ficar conforme a imagem abaixo:

 

image

Vamos criar nosso projeto. Com o Visual Studio aberto, clicamos em New Project (conforme imagem abaixo).

image

Em seguida será aprestada a tela para criação do projeto. Vamos preencher conforme a imagem a seguir:

image

Depois de preenchido o nome do projeto e clicado em “OK”, o Visual Studio vai iniciar o Wizard de criação de um projeto de Visual Webpart novo.

Neste Wizard, dizemos em qual o servidor do Sharepoint vamos utilizar para desenvolvimento, selecionamos “Deploy as a farm solution” e clicamos em Finish.

image

 

Assim que o Visual Studio terminar de gerar o projeto, teremos a seguinte configuração no nosso projeto:

image

Vamos renomear a Webparte que tem o nome de “VisualWebPart1” para “WPDiario” e dentro da pasta Features vamos renomear a “Feature1” para “FTDiario”. Não vou entrar em detalhes sobre a questão das Features neste artigo.

Agora, vamos criar a estrutura de pastas para a nossa aplicação.

Clique com  o botão direito sobre o projeto “WebDiario” e clique em Add -> New Folder e coloque o nome de “DAL” na pasta criada. Repita este procedimento para criar as pastas “BUS”, “ENT”, “USR”.

Após a criação de todas as pastas, arraste a webpart “WPDiario” para dentro da pasta “USR” conforme a imagem abaixo:

image

Vamos agora criar uma classe Diário para cada uma das camadas envolvidas na nossa aplicação:

Daremos os seguintes nomes para as classes:

Na pasta BUS: DiarioBus.cs

Na pasta DAL: DiarioDal.cs

Na pasta ENT: DiarioEnt.cs

Ficamos com a nossa aplicação da seguinte forma:

image

 

Agora que já temos a estrutura do projeto pronta para codificar, vamos criar a lista no SharePoint, que servirá como uma tabela de banco de dados para a nossa aplicação.

Vamos abrir o site onde estamos trabalhando nossa aplicação SharePoint. No meu caso, estou usando um site criado zerado e com o padrão de layout do sharepoint conforme imagem abaixo.

image

 

Vou partir da premissa que você sabe criar uma lista no sharepoint e já vou apresentar a lista pronta. Só para exclarecer, estou usando um “Custom List” com o nome de “LST_Diario”.

image

Uma vez que já temos nossa lista criada, podemo voltar para o Visual Studio e começar a codificar nosso projeto.Data

Vamos começar a codificar pela classe de entidade, pois precisamos mapear os atributos entre a lista do sharepoint “LST_Diario” e a classe de entidade “DiarioEnt.cs”.

Abrimos então o arquivo DiarioEnt.cs e adicionamos as linhas de código abaixo:

image

 

Após criarmos nossa classe de entidade que mapeia a lista do sharepoint, vamos codificar a classe “DiarioDal” da camada de dados “DAL”.

Implementarei inicialmente um método listar simples sem filtros. Não é uma boa prática, pois trará todos os dados da lista, mas para fins de exemplo está bom.

image

 

Uma vez a camada de dados pronta, podemos então implementar a camada de negócios “BUS”.

No nosso caso abaixo, não farei nenhum tratamento com regra de negócio, mas como manda a regra, eu tenho que sempre passar pela camada de negócio para chegar a camada de usuário, por isso , nosso método de negócio será somente uma chamada a classe de dados e retorno da lista conforme abaixo.

A modelagem mais adequada para a questão das listas seria ter uma classe DiárioEnt e uma classe ItemDiarioEnt, mas para simplificação do exemplo estou adotando a própria classe de DiarioEnt para listar seus itens.

Classe de negócio “DiarioBus” fica da seguinte forma:

image

 

Vamos agora codificar nossa Webpart. Vamos clicar em WPDiario e entrar no modo de design. Vou adicionar um objeto “botão” e um “GridView”.

O Botão tem como objetivo chamar o método da camada de negócio e o GridView exibirá os dados da lista.

O exemplo deverá ficar da seguinte forma:

image

Vamos dar um duplo clique no botão e iniciar a codificação da chamada ao método de negócio.BUS

 

image

Assim que tivermos codificado nosso exemplo, podemos fazer o Deploy para fazer o teste com nossa webpart. Lembre-se de adicionar algums itens na lista do sharepoint, caso contrário, não haverá retorno devido ao fato de não haver registro na lista do sharepoint.

Adicionei 3 linhas de registro para testar a aplicação.

SNAGHTML14c0b24b

Com a nossa webpart publicada, podemos acessar a página do sharepoint para testar nossa aplicação.

A página deverá ficar com a seguinte cara:

SNAGHTML14e0989d

Depois que clicamos no botão “Carregar Grid” nossa aplicação vai na lista do SharePoint buscar as informações da lista conforme a imagem abaixo.

SNAGHTML14e20387

 

Espero que tenha gostado do artigo.

Qualquer consideração que deseje fazer, entre em contato.

Márcio Pulcinelli.


Diagrama de Atividades e Sua Utilização

UML---HighLembro-me que uns anos atrás, quando comecei a estudar a UML, os diagramas de atividade não eram muito bem compreendidos pela maioria dos analistas. Era como se aquela peça tivesse sido colocada no lugar de algo que não pertencia ao quebra cabeças da UML, entretanto depois de algum tempo quebrando a cabeça para entendê-lo, passou a ser uma das peças mais importantes para a fase após a identificação dos requisitos do sistema.

Mas então, o que é e para que é usado o diagrama de atividades? É fácil de entender, que uma atividade é um determinado estado de estar fazendo alguma coisa em um determinado momento no tempo. E aqui pode ser usado como um processo do nosso dia-a-dia (mundo real). Como, por exemplo, pedir uma pizza por telefone, ou uma execução sistêmica (processo de software) tal como a execução de uma rotina em C++/Java/C# e etc. para calcular distâncias orbitais entre os planetas, calcular o imposto de renda e etc.

O diagrama de atividades foi criado para descrever a sequência de atividades, tendo também suportes para comportamentos condicionais e paralelismo. Os comportamentos condicionais são delineados pelos desvios chamados de “branches” e pelas intercalações chamadas de “merge”.

Um “branche” é uma transição de entrada, que deve ser única, com várias transições de saídas. É importante observar, que somente uma transição de saída pode ser tomada por vez, de modo que a operação deve ser mutuamente exclusiva. Exemplo, a utilização de [else] como uma sentinela indica que a transição “else” deverá ser usada se a condição for falsa.

image

Um “merge” tem múltiplas transições de entrada e somente uma única saída. Sendo assim, um “merge” marca o final de um comportamento condicional iniciado pelo “branche”. Gosto sempre de frisar que não é necessário explicitar o losango para desvios e intercalações, uma atividade pode ter múltiplas transições de saída e múltiplas transições de entrada, por isso, use o losango se você desejar deixar claro cada desvio e intercalação em relação as regras de negócio.

Para efetuar o comportamento paralelo usa-se Separações “Forks” e Junções “Joins”. Vamos primeiro falar das separações e em seguida das junções.

Um “Fork” tem uma transição de entrada e diversas transições de saída (ao menos duas). Quando acionamos uma transição de entrada, ou seja, executamos um trigger, todas as transições de saída podem ser executadas em paralelo (não quer dizer que elas serão executadas simultaneamentes).

image

Isso significa dizer que a sequência entre elas não é relevante. Quando você tem uma separação (Fork), o que importa são os caminhos individuais de cada uma das separações. Um exemplo seria, no caso de dois departamentos de uma empresa trabalhando para entregar um determinado produto ao cliente, ou seja, um departamento poderia estar trabalhando na embalagem do produto enquanto outro poderia estar trabalhando na emissão da nota fiscal.

É importante dizer que o diagrama de atividades permite que se escolha a ordem que se vai executar as atividades. Ele determina as regras essenciais de sequência que devem ser seguidas. Um fluxograma, por exemplo, não tem habilidade para lidar com processos e atividades em paralelo. O que é de grande importância para a modelagem de regras de negócios.

Existe uma linha de modelagem de requisitos que troca as descrições de casos de uso por diagramas de sequencia. Eu inclusive vejo com bons olhos esse formato de trabalho, uma vez que substitui conteúdo textual, muitas vezes ambíguo, pro uma linguagem formal e gráfica, evitando erros de conceito e ainda agilizando o processo no momento de se alterar um determinado requisito de negócio que está obsoleto.

Ainda citando a utilidade dos diagramas de atividade, eles são muito úteis para modelar programas (rotinas) que fazem uso de mult-thread ou processamento paralelo, ainda mais nos dias de hoje em que temos processamento em grid, cloud computing, processadores com multicores e etc. Cada vez mas se faz necessário modelos para processamento paralelo, e é aí que os diagramas de atividade ganham mais força.

Para finalizar o comportamento de uma separação (“Fork”) é preciso sincronizar cada uma das separações que foram abertas. Apresentamos este conceito com a junção (“Join”). Com a Junção, a transição seguinte só ocorre quando todos os estados nas transições de entrada tenham completado suas atividades passando assim ao próximo estágio do fluxo.

image

Sempre as separações (“Forks”) e junções (“Joins”) devem se completar, ou seja, sempre que houver uma separação, uma junção deverá ocorrer em algum momento futuro. Existem algumas exceções para essa regra, mas basicamente essa é a regra da utilização de “Forks” e “Joins”.

Existe a possibilidade de adicionar ainda um thread condicional ao seu diagrama. Esse tema é um pouco complexo e deve ser muito bem pensado quando for modelado, mas é basicamente o seguinte: existe uma exceção para a regra de que todos os estados de entrada de um “Fork” devem ter suas atividades finalizadas antes que o “Join” possa ser efetuado. Aí que entra o thread condicional, você pode adicionar uma condição para um thread saindo de um “Fork”. Observe que se a condição para esse thread for falsa, esse thread é completado no que tange a junção (“Join”). Apresento abaixo um exemplo de Thread condicional para ilustração do que foi dito.

image

Outro conceito importante dos diagramas de atividade é a decomposição de uma atividade. Uma atividade pode e (dependendo do caso) deve ser decomposta para melhor entendimento das atividades que a compõe. Esta questão da decomposição das atividades fica a cargo do analista de negócios/sistemas, pois depende do grau de granularidade que se deseja obter na analise destes requisitos. Um exemplo que poderia ser dado para ilustrar é o de uma atividade de Entrega que pode ser decomposta em Entrega Regular e em Entrega Expressa. Dentro da ativdade “Entrega” detalha-se a atividade apresentando as sub-atividades pertencentes àquela atividade macro.

image

No próximo artigo abordarei mais dois conceitos: Concorrência Dinâmica e Raias (Swimlanes). O mais importante aqui (neste artigo) é entender que o diagrama de sequência é uma ferramenta bastante poderosa e sua aliada quando se fala em analise de sistema e negócio. Você pode (e deve) usá-la para analisar uma caso de uso, para compreender um determinado workflow, descrever um determinado algoritmo complicado e também lidar com aplicações de processamento paralelo.


Espero que tenham gostado do artigo.

Márcio Pulcinelli @ OminaVincit!


Breve introdução sobre Orientação a Objetos

A Orientação a Objetos foi inicialmente concebida na década de 70 ainda na área acadêmica. A partir da década de 80 começou a ser adotada no lugar da analise essencial, tomando maior vulto nos anos 90.

Se fizermos uma comparação entre o modelo estruturado e o orientado a objetos, temos que o paradigma estruturado trata de funções e procedimentos aplicados a dados, enquanto que o paradigma orientado a objetos trata de dados e comportamentos como pode ser visto na imagem abaixo.

Paradigma Estruturado x Orientado a Objetos

De qualquer forma, a orientação a objetos não elimina a programação estruturada, no sentido de que dentro de cada um dos métodos (que definem o comportamento de um objeto) exposto na classe, temos rotinas estruturadas de software.

Exemplo: Comandos While, For, Next e toda a programação convencial da linguagem de programação adotada.

O que então são classes e objetos?

Classes e Objetos – constituem a unidade de representação de dados para esse paradigma. Ambas mantém uma relação muito próxima entre si.

Podemos pensar na Classe como o modelo ou mesmo o molde de uma roupa ou de uma peça de metal, e nos objetos como as peças prontas feitas de matéria prima.

Conforme a imagem abaixo, podemos ver a Classe como o molde e os relógio criados como os objetos da classe.

Classes

Classes definem novos tipos de dados, tal como structs de C ou registers de Pascal. A partir de novos tipos de dados torna-se mais fácil organizar a aplicação em questão.

Objetos

Um objeto é uma instância de uma classe, ou seja, um exemplar do conjunto de objetos que seguem os moldes daquela classe.

Atributos

Atributos – são os “campos” que contém as informações daquela classe.  Ao conjunto de atributos preenchidos de um objeto damos o nome de “estado do objeto”.

Existem atributos de classe e atributos de instância.

Métodos

Métodos – definem o comportamento dos objetos definidos pela classe.

Por comportamento entendemos o conjunto de reações ou atividades que os objetos podem desempenhar.

Exemplo: Classe Avião, método decolar, método pousar, etc…

Métodos podem ter parâmetros de entrada e retorno.

Através dos métodos podemos atingir uma das principais características da orientação a objetos. O encapsulamento, que é a capacidade de esconder do mundo exterior as estruturas internas de uma classe.

O encapsulamento define que os atributos só são acessados através de métodos o que evita o acoplamento.

Conceitos Chave

• Classe
• Objeto
• Atributo
• Método
• Instância