sexta-feira, 29 de outubro de 2010

Certificação SCRUM

Para falarmos um pouco mais sobre certificações vamos dar uma dica sobre a certificação CSD (Certified Scrum Developer). A certificação CSD chegou ao Brasil em outubro de 2010 através da parceria Massimus (http://massimus.com) e Kleer (http://www.kleerer.com). Esta certificação visa validar o conhecimento dos profissionais na aplicação de práticas avançadas em engenharia ágil.
O Scrum é fundamentado na teoria que o controle de processos pode variar de acordo com as experiências cotidianas emprega uma abordagem iterativa e incremental para aperfeiçoar as previsões e controlar os riscos. É baseado em três pilares: Transparência, Inspeção e Adaptação. Scrum é baseado nas melhores práticas aceitas pelo mercado, utilizadas e provadas por décadas.

Nos próximos post vamos tratar melhor desta metodologia.

Caso você tenha duvidas ou não concorde comente o post para que possamos ampliar este ponto de discussão.

quinta-feira, 28 de outubro de 2010

Certificações para UML

Há algum tempo vejo muitas pessoas se perguntando sobre quais são as certificações existentes referente à UML, e se as mesmas são aceitas no mercado.
Para sanar essas dúvidas, abaixo iremos mostrar as certificações existentes.

A OMG - (Object Management Group) é a entidade mantedora na UML, a mesma disponibiliza 3 níveis de certificação OMG - UML:
 >> Fundamental (Um membro de uma equipe de desenvolvimento UML deve ter o conhecimento e habilidades para adquirir esta certificação.)
 >> Intermediate (Um membro sênior ou líder de grupo de uma equipe de desenvolvimento UML deve ter o conhecimento e habilidades para adquirir esta certificação.)
 >> Advanced (Um responsável técnico de um projeto de desenvolvimento UML deve ter o conhecimento e habilidades para adquirir esta certificação.)

A IBM lançou uma certificação (000-486 Object-Oriented Analysis and Design with UML Test) também referente à UML, mas para você que está interessado nesta certificação, a mesma possui 2 pré-requisitos.
É necessário que o profissional tenha essas duas certificações abaixo primeiro:
00-833   - Object Oriented Analysis and Design - Part 1 (Analysis)
00-834   - Object Oriented Analysis and Design - Part 2(Design)

Atualmente o mercado tem reconhecido os profissionais que estão apresentando certificações nas suas áreas de atuação, mas no futuro isso será bem mais explorado, hoje os profissionais têm utilizado as certificações como um diferencial perante o mercado. Temos que utilizar as certificações para agregar conhecimento e para aplicarmos de maneira mais eficiente o que aprendemos nos projetos que estarão sendo desempenhados.
Documentar as fases do projeto é algo essencial, mas as empresas ainda estão amadurecendo essa idéia, então cabe ao profissional indicar as melhores ferramentas para tal e demonstrar os ganhos com esse feito.
Mandem mais duvidas e comentem os posts....isso é importante para podermos estar divulgando mais assuntos interessantes para as pessoas que têm interesse em aprender mais.

PMBOK - Nove áreas de conhecimento e suas fases.

O PMBOK é um conjunto de melhores práticas em gestão de projetos ou gerência de projetos que foi publicado pelo PMI (Project Management Institute). Estas práticas são compiladas na forma de um guia, chamado de Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK.
Abaixo vou descrever em tópicos quais são as fases do projeto e suas áreas de conhecimento, segundo o PMBOK 4º Edição.
·         Fases do Projeto
o   Iniciação
o   Planejamento
o   Execução
o   Monitoramento e Controle
o   Encerramento
·         Nove áreas de Conhecimento
o   Integração (Neste momento as cinco fases do projeto estão presentes)
o   Escopo (As fases presentes são Planejamento / Monitoramento e Controle)
o   Tempo (As fases presentes são Planejamento / Monitoramento e Controle)
o   Custo (As fases presentes são Planejamento / Monitoramento e Controle)
o   Qualidade (As fases presentes são Planejamento / Execução / Monitoramento e Controle)
o   Recursos Humanos (As fases presentes são Planejamento / Execução)
o   Comunicação (As fases presentes são Iniciação / Planejamento / Execução / Monitoramento e Controle)
o   Riscos (As fases presentes são Planejamento / Monitoramento e Controle)
o   Aquisições (As fases presentes são Planejamento / Execução / Monitoramento e Controle / Encerramento)
Para quem tem o interesse de se aprofundar no assunto e tirar a certificação, devem ir atrás do PMP (Project Management Professional) - Programa de Certificação Profissional, neste link pode-se obter mais informações: http://www.pmisp.org.br/cert_pmp.asp
Nos próximos posts estaremos abrindo o conteúdo de cada fase do projeto e a importancia da participação das áreas de conhecimento.

Visão Geral do Sistema

Continuando a linha de pensamento do post anterior vamos neste texto falar um pouco mais sobre o inicio de levantamento de requisitos.
Quando iniciado o levantamento de requisitos de um sistema é sempre necessário vê-lo como um todo, é impossível em um primeiro momento se atentar a detalhes do aplicativo que será desenvolvido, o primeiro passo a ser seguido é sempre de entender o sistema de forma macro, e depois de entendido o conceito separá-lo, usando sempre a filosofia de Jack "Vamos por partes".
Na concepção da documentação do sistema é importante que a sua primeira parte seja sempre composta de uma visão geral sobre o sistema, (em alguns casos este tópico é chamado de sumário executivo) que deve ser um texto corrido sem a necessidade de nenhuma estrutura em especial, nele deve conter a principal idéia do cliente sobre o sistema.
A criação de uma visão geral deve ser feita sempre após conversar com o cliente e usuários, o analista deve ter em mente que este documento descreve as principais preocupações dos clientes.
Abaixo segue o exemplo de uma visão geral de um sistema de locadora

SISTEMA DE VIDEO LOCADORA [1]

Visão Geral do Sistema

É proposto o desenvolvimento de um sistema de controle de vídeo locadora, que vai informatizar as funções de empréstimo, devolução e reserva de fitas. O Objetivo de o sistema á tonar mais rápido o processo de empréstimo e garantir melhor segurança, ao mesmo tempo possibilitar melhor controle das informações por parte da gerencia.
Deverão ser gerados os seguintes relatórios: empréstimos por clientes, empréstimos por fitas e empréstimos por mês.
O sistema deverá calcular automaticamente o valor dos pagamentos a serem efetuados em cada empréstimo, inclusive multas e descontos devidos.
A impossibilidade de efetuar um pagamento deve deixar o cliente suspenso, ou seja, impossibilitando de tomar emprestadas novas fitas até saldar a divida.


Espero que o exemplo acima tenha deixado mais claro o objetivo de ser criada uma visão de documento, a documentação desta visão pode ser alterada durante o processo de desenvolvimento dos outros passos da documentação, mas ela é sempre importante para que seja dado o primeiro passo em relação à documentação dos desejos do cliente.
Caso você tenha duvidas ou não concorde comente o post para que possamos ampliar este ponto de discussão.
Seguindo o pensamento que a UML hoje é considerada a melhor prática de modelagem de sistema de informação vamos continuar postando aqui informações e dicas sobre este maravilhoso mundo.

[1] Wazlawick, Raul Sidnei. – Analise e Projeto de Sistemas de informação Orientada a Objetos. Editora Campus.

quarta-feira, 27 de outubro de 2010

Ferramentas Free para Modelagem

No post de dicas rápidas vamos mostrar aqui algumas ferramentas free, a idéia é que possamos ao decorrer dos posts aprendermos juntos. Vamos as ferramentas Modelagem, seguem alguns exemplos:

Jude: que hoje é conhecida como Astah é na nossa opnião uma das ferramentas free mais completas para a documentação no padrão UML, esta ferramenta possui a versão free, que pode ser baixada em seu site após um pequeno cadastro na mesmo. http://jude.change-vision.com/jude-web/download/index.html

Posseidon: Esta ferramenta disponibiliza a vesão Community Edition de forma free e também em seu site é possivel baixar a versão completa para ser utilizada por 30 dias (trial). http://www.gentleware.com/downloadcenter.html

ArgoUML: Ferramenta CASE em Java para design orientado a objetos. http://argouml.tigris.org/

Dia: Ferramenta que realiza muitas das mesmas funções que o Microsoft Visio. http://projects.gnome.org/dia/

StarUML:  Ferramenta para diagramação dos artefatos UML.  http://staruml.sourceforge.net/en/

Em breve vamos falar mais sobre as ferramentas mais relevantes no mercado, inclusive as ferramentas pagas.

Requisitos Funcionais X Não Funcionais

A especificação de requisitos na nossa opinião é a tarefa mais importante na fase de análise de um sistema, pois um requisito mal identificado/especificado produzem falhas e um grande risco no prazo do projeto, pois geraria retrabalho e atrasos.

Lembrando que para se ter um bom levantamento que requisitos, o analista deverá saber separar o que o cliente deseja, do que realmente o cliente necessita para o seu negócio.

Os requisitos podem ser classificados em 2 tipos: Requisitos Funcionais e os Requisitos Não Funcionais.

Os requisitos funcionais são aqueles que descrevem o comportamento do sistema e suas ações para cada entrada, ou seja, são as funcionalidades que o sistema deve ter (O que o sistema faz).Não existe muito um modelo de perguntas para realizar esse levantamento, pois depende muito do negocio do cliente, mas duas perguntas essenciais não poderão faltar, que são:

1. O que o sistema deverá fazer?
2. Quais as suas funcionalidades? (Detalhes todas as funcionalidades)

Os Requisitos não-funcionais são aqueles que descrevem as qualidades do sistema (como o sistema é).
Segue abaixo algumas perguntas para identificação de requisitos não funcionais:

1.Quantos usuários vão utilizar o sistema a ser desenvolvido?
2.Desse número de usuários, quantos  utilizarão o sistema simultaneamente?
3.Dos relatórios previstos, quais podem ser gerados por processamento batch e quais devem ser online ?
4.Qual o tipo de acesso da aplicação, via intranet ou via internet ?
5.Qual o perfil dos usuários que vão acessar a aplicação? Possuem conhecimento de internet? São usuários avançados?
6.É desejável que a maior parte das funcionalidades da aplicação possam se acessadas via teclado (sem auxilio do mouse)?
7.A aplicação deve ser compatível com quais versões do browser e/ou sistema operacional?
8.Quais os padrões de implementação esperados? Os desenvolvedores podem escrever o código em qualquer idioma? Podem utilizar qualquer banco de dados e qualquer tecnologia?
9.Qual a segurança esperada para o trafego de dados?
10.Toda comunicação entre o servidor e o browser tem que ser criptografada usando SSL? Será adquirido o certificado SSL? Ou a aplicação não tem dados sensíveis e confidenciais / vai ser executada em uma rede segura?


Fiquem atentos para os próximos post , pois ainda iremos detalhar mais sobre este assunto, mostrando exemplos e aplicações do dia a dia.

terça-feira, 26 de outubro de 2010

O que é um requisito?

Existem diversas definições, mas acreditamos que o requisito sirva para determinar o motivo pelo qual o sistema deva existir. Algo que defina a necessidade do software que estará sendo desenvolvido.
Para suprir esta necessidade temos que definir os requisitos de negócio, os requisitos funcionais, os requisitos não-funcionais, as regras de negócio do sistema e suas restrições.
Importante: Se os requisitos relevantes não forem identificados e tratados da maneira correta, pode-se gerar um grande esforço de retrabalho no desenvolvimento do software.

Nos próximos pots...traremos as definições dos tipos de requisitos acima citados...fiquem ligados!

Descrição rápida sobre UML

A UML (Unified Modeling Language) foi criada em 1995 por 3 grandes cabeças que são, Grady Booch, James Rumbaugh e Ivar Jacobson.
A UML nada mais é do que uma linguagem visual utilizada para facilitar a comunicação, a especificação do produto, diagramação dos artefatos, a fim de obter controle do sistema que estará sendo construído.
O objetivo da UML é disponibilizar aos usuários uma linguagem visual e expressiva focado no desenvolvimento orientado a objetos, onde este deve ser independente da linguagem de programação, isso quer dizer que não existe uma relação direta com o tipo de linguagem que será utilizada para o desenvolvimento do software que esta sendo especificado, lembrando que esta linguagem deve ser atualizada conforme novas necessidades sejam descobertas, é importante que o especificador defina e utilize as melhores práticas de modelagem.
A UML esta na versão 2.0 e os seus diagramas estão divididos entre as categorias estáticas e dinâmicos, que são:
  • Estáticos:
    • Diagrama de Classes;
    • Diagrama de Pacotes;
    • Diagrama de Objetos;
    • Diagrama de Componentes;
    • Diagrama de Composição Estrutural / Estrutura Composta;
    • Diagrama de Distribuição / Implantação / Instalação;
  • Dinâmicos:
    • Diagrama de Casos de Uso;
    • Diagrama de Seqüência;
    • Diagrama de Atividades;
    • Diagrama de Comunicação / Colaboração;
    • Diagrama de Estados / Máquina de Estados;
    • Diagrama de Integração Geral;
    • Diagrama de Tempo / Diagrama de Sincronismo;
Fiquem atentos, nos próximos posts disponibilizaremos os significados de cada diagrama.