Diagramas UML 2.0

Abaixo vamos descrever resumidamente os diagramas oferecidos pela UML, o objetivo de tantos diagramas é oferecer múltiplas visões do sistema a ser modelado. A utilização de diversos diagramas permite que falhas possam ser descobertas nos diagramas anteriores, diminuindo assim a ocorrência de erro na fase da modelagem dos sistemas.

Diagrama de Caso de Uso: Este é o diagrama mais popular, e pelo fato do mesmo ser mais informal é amplamente utilizado na fase de levantamento e analise de requisitos. Neste diagrama devemos procurar identificar os atores e os serviços que compõe o sistema. Nele deve der descritas todas as opções que o sistema disponibilizará para os atores.

Diagrama de Classes: Este diagrama define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos possuídos por cada classe, além de estabelecer como as classes se relacionam e trocam informações entre si.

Diagrama de Objetos: Este diagrama fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo.

Diagrama de Estrutura Composta: Este diagrama é utilizado para modelar Colaborações. Uma colaboração descreve uma visão de um conjunto de entidades que cooperam entre si para executar uma função especifica.

Diagrama de Seqüência: Este diagrama identifica o evento gerador do processo modelado, bem como o ator responsável por este evento, e determina como o processo deve se desenrolar e ser concluído por meio do envio de mensagens, que em geral disparam métodos entre os objetos.

Diagrama de Comunicação: As informações mostradas neste diagrama são praticamente as mesmas mostradas no Diagrama de Seqüência, porém com um enfoque diferente, visto que este diagrama não se preocupa com a temporalidade do processo, concentrando-se em como os objetos estão vinculados e quais mensagens trocam entre si durante o processo.

Diagrama de Máquina de Estado: Este diagrama procura acompanhar as mudanças sofridas nos estados de uma instancia de uma classe de um Caso de Uso ou mesmo de um subsistema. Basicamente demonstra qual caso de uso instancia um determinado método de uma classe.

 Diagrama de Atividades: Este diagrama se preocupa em descrever os passos a serem percorridos para a conclusão de uma atividade especifica, podendo, no entanto modelar um processo completo. Este diagrama é baseado em Redes de Petri.

Diagrama de Interação: Este diagrama é uma variação do Diagrama de Atividade que fornece uma visão ampla dentro de um sistema ou processo de negocio, costuma englobar diversos tipos de diagramas de interação para demonstrar um processo geral.

Diagrama de Componentes: Este diagrama é amplamente associado à linguagem de programação que será utilizada para desenvolver o sistema modelado. Este diagrama pode ser utilizado para modelar o código-fonte, os módulos executáveis de um sistema, a estrutura física de um banco de dados ou mesmo os componentes necessários para a construção de interface.

Diagrama de Implantação: Este diagrama determina as necessidades de hardware do sistema, as características físicas como: servidores, estações, topologia e protocolos de comunicação, ou seja, todo aparato físico sobre qual o sistema deverá ser executado.

Diagramas de Pacotes: Este diagrama tem por objetivo representar os subsistemas ou submódulos englobados por um sistema de forma a determinar as partes que o compõem.

Diagrama de Tempo: Este diagrama és utilizado para demonstrar o tempo de resposta a eventos externos e também utilizado para demonstrar a mudança de um estado de um objeto.

Levantamento de Requisitos

Após entendido entre as partes sobre a visão macro do sistema (postado em Visão Geral do Sistema), deve-se então partir para o levantamento e a documentação dos requisitos (funcionais e não - funcionais). Neste ponto deve ser documentado tudo que o sistema deve fazer e sobre qual condição o sistema deve fazer.

As duas grandes categorias dos requisitos são os seguintes:
 * Requisitos Funcionais: corresponde a listagem de tudo que o sistema deve fazer.
* Requisito Não-Funcionais: são restrições colocadas sobre como o sistema deve realizar seus requisitos funcionais.

Durante a produção de uma documentação deve-se sempre ter em mente que os documentos gerados devem sempre ter o objetivo de ajudar a desenvolver um sistema com maior eficiência e eficácia. Existem muitas abordagens sobre análise e engenharia de requisitos, nos próximos posts vamos demonstrar um exemplo de processo prático de documentação de requisitos.

Caso você tenha duvidas ou não concorde comente o post para que possamos ampliar este ponto de discussão, e fiquem atentos para a continuidade do assunto.

O que é CobiT ?

COBIT (Control Objectives for Information and related Technology) é uma ferramenta (Framework) que auxilia no gerenciamento e controle das iniciativas de TI nas empresas é um guia para a gestão de Tecnologia da Informação.

O ponto central é o gerenciamento da informação com os recursos de TI para garantir o negócio da empresa baseado nos recursos de controle de objetivos, um framework (modelo), mapas de auditoria, ferramentas de implementação e um guia de técnicas de gerenciamento.

As práticas de Gestão baseadas no Cobit fornece métricas para a avaliação de resultados orientando para um melhor gerenciamento de processos do negócio, portanto, o Cobit fornece uma política clara para o controle de TI e o alcance das metas da organização.

O CobiT é orientado ao negócio, fornece informações detalhadas para gerenciar processos baseados em objetivos de negócios e é projetado para auxiliar três audiências distintas: 

• Gerentes que necessitam avaliar o risco e controlar os investimentos de TI em uma organização.
• Usuários que precisam ter garantias de que os serviços de TI que dependem os seus produtos e serviços para os clientes internos e externos estão sendo bem gerenciados.
• Auditores que podem se apoiar nas recomendações do CobiT para avaliar o nível da gestão de TI e aconselhar o controle interno da organização.

 O CobiT está dividido em quatro domínios: 

• Planejamento e organização;
• Aquisição e implementação;
• Entrega e suporte;
• Monitoração;

Cada domínio cobre um conjunto de processos para garantir a completa gestão de TI, somando 34 processos:
Planejamento e Organização: 

• Define o plano estratégico de TI;
• Define a arquitetura da informação;
• Determina a direção tecnológica;
• Define a organização de TI e seus relacionamentos;
• Gerencia os investimento de TI;
• Gerencia a comunicação das direções de TI;
• Gerencia os recursos humanos;
• Assegura o alinhamento de TI com os requerimentos externos;
• Avalia os riscos;
• Gerencia os projetos;
• Gerencia a qualidade;

Aquisição e implementação:

• Identifica as soluções de automação;
• Adquire e mantém os softwares;
• Adquire e mantém a infra-estrutura tecnológica;
• Desenvolve e mantém os procedimentos;
• Instala e certifica softwares;
• Gerencia as mudanças;

Entrega e suporte:

• Define e mantém os acordos de níveis de serviços (SLA);
• Gerencia os serviços de terceiros;
• Gerencia a performance e capacidade do ambiente;
• Assegura a continuidade dos serviços;
• Assegura a segurança dos serviços;
• Identifica e aloca custos;
• Treina os usuários;
• Assiste e aconselha os usuários;
• Gerencia a configuração;
• Gerencia os problemas e incidentes;
• Gerencia os dados;
• Gerencia a infra-estrutura;
• Gerencia as operações;

Monitoração 

• Monitora os processos;
• Analisa a adequação dos controles internos;
• Prove auditorias independentes;
• Prove segurança independente;

Este post trouxe noções básicas sobre o COBIT, para quem pretende se aprofundar no assunto é importante estudar detalhadamente todos os seus processos, para facilitar o estudo, comentem nossos posts e colocaremos informações relevantes sobre o assunto discutido.

Dicas para Levantamento de Requisitos

Neste post vamos dar algumas dicas sobre levantamento de requisitos, quais são as informações que o analista especificador deve saber sobre o projeto e para isso existem algumas perguntas que devemos fazer aos clientes quando estamos numa reunião.

• Nós devemos nos atentar ao que o cliente quer receber (que produtos);
• Devemos saber quais serão os benefícios gerados em estar desenvolvendo este projeto, o que motivou o início deste projeto;
• Devemos documentar o histórico do projeto, se é um projeto existente que irá sofrer melhorias;
• Devemos nos preocupar com as áreas impactadas, quais áreas que utilizarão a solução proposta;
• Este projeto proposto será utilizado para uma solução interna ou externa, se algum parceiro irá utilizar desta solução;
• Definir o escopo é a parte mais importante e nele deve conter os limites de entrega do projeto, o conjunto detalhado das suas funcionalidades e as características da demanda;
• Devemos nos preocupar com os itens que ficarão fora do escopo que poderá impactar o projeto em palta, mas que não está previsto pelo cliente como item da demanda;
• Devemos saber qual é a necessidade de desenvolvimento e qual a solução a ser adotada;
• Se existir parametrização para o requerimento do projeto, estes devem ser informados;
• Devemos nos preocupar com as informações técnicas do projeto, isto é, caso exista troca de arquivo com alguma entidade externa, descrever as informações que deverão constar para esta entidade;
• Outro ponto importante é saber quais são os requerimentos não-funcionais, que são:
• Informações sobre Hadware / Software - existe alguma necessidade de hardware especial, é necessário algum terminal, leitora de código de barras e etc;
• Informações sobre Interface com Usuário - saber se existe alguma interface com o usuário fora do padrão da empresa solicitante;
• Informações sobre Integração - verficar se existe integração com outros sistemas, se existir qual é a tecnologia de transferência, este projeto depende de informações provenientes de outros sistemas, existe integração com parceiros, fornecedores, clientes e etc;
• Devemos saber se existe arquivos que serão gerados a patir do sistema a ser desenvolvido, qual é o seu formato e se este arquivo será transmitido para alguma área ou aplicativo e se existir é necessário saber de que forma isso irá ocorrer;
• É importante saber se o seu projeto necessitará de relatórios, se for necessário é importante levantar quais as informações que deverá constar no relatório e qual é a periodicidade do mesmo;
• Outro item importante é pegar os pontos de contatos, pois são eles que tirarão as dúvidas que surgirão enquanto for construída a especificação funcional;

No post de hoje montamos um check list que poderá ser utilizado na maioria dos levantamentos de requisitos de sistemas, o ideal é que os itens da lista sejam sempre questionados por parte do analista ao cliente solicitante. Caso você tenha alguma duvida / sugestão ou não concorde fale com a gente através dos comentários.

 

Aguardamos sua opinião.

ITIL - O que é ? Quais os seus benefícios ?

Neste post abordaremos um assunto que esta em alta no momento, que é o ITIL (Information Technology Infrastructure Library), que foi desenvolvido no final dos anos 1980 pela CCTA (Central Computer and Telecommunications Agency) e atualmente está sob custódia da OGC (Office for Government Commerce) da Inglaterra que são seus criadores. O ITIL foi criado a partir de pesquisas realizadas por Consultores, Especialistas e Doutores.

O ITIL é basicamente um conjunto de boas práticas a serem aplicadas na infraestrutura, operação e manutenção de serviços de tecnologia da informação (TI), de modo a garantir os níveis de serviço acordados com os clientes internos e externos. O ITIL™ é composto por módulos, onde os mais importantes são o “”IT Service Support”" e o “”IT Service Delivery”".

Vejam quais são os benefícios de aplicar o ITIL.

·     Fortalecimento dos Controles e da Gestão dos ambientes de TI;

·     Orientação a processos, a fim de minimizar o tempo de execução e distribuição de serviços;

·     Minimizar a indisponibilidade dos recursos e sistemas de tecnologia da informação, que são causados por falhas no planejamento das mudanças e implantações em TI;

·     Otimizar a satisfação dos usuários internos e clientes com relação à disponibilidade e qualidade dos serviços de TI;

·     Redução dos custos operacionais de TI;

·     Reconhecimento da capacidade de gerenciamento pelos acionistas, colaboradores e clientes;

Service Support (ITIL V2)

Os processos desta área e seus objetivos são:

·     Gerenciamento de incidentes – reduzir o tempo de indisponibilidade (downtime) dos serviços;

·     Gerenciamento de problemas – minimizar o impacto no negócio dos incidentes e problemas causados pelos erros na infraestrutura de TI e prevenir incidentes recorrentes desses mesmos erros;

·     Gerenciamento de configuração – identificar e controlar os ativos de TI e itens de configuração (CIs) existentes na organização, estabelecendo o relacionamento dos mesmos aos serviços prestados;

·     Gerenciamento de mudanças – minimizar o impacto da mudança requerida para resolução do incidente ou problema, mantendo a qualidade dos serviços, bem como melhorar a operacionalização da infraestrutura;

·     Gerenciamento de liberações – prevenir a indisponibilidade do serviço, garantindo que as instalações de versões de hardware e software estejam seguras, autorizadas e devidamente testadas.

Service Delivery (ITIL V2)

Os processos desta área e seus objetivos são:

·     Gerenciamento de Nível de Serviços – garantir o acordo de nível de serviço (SLAs) previamente estabelecido entre o fornecedor e o cliente;

·     Gerenciamento Financeiro para TI – demonstrar ao cliente o custo real dos serviços prestados e gerenciá-los de forma profissional;

·     Gerenciamento de Disponibilidade – garantir a disponibilidade e confiabilidade dos recursos de TI, a fim de assegurar a satisfação do cliente e a reputação do negócio;

·     Gerenciamento de Capacidade – assegurar que a capacidade da infraestrutura de TI está adequada às demandas do negócio conforme a necessidade e no tempo esperado, observando sempre o gerenciamento do custo envolvido;

·     Gerenciamento de Continuidade de Serviços – atender todo o processo de gerenciamento da continuidade do negócio, assegurando que os recursos técnicos e sistemas de TI sejam recuperados quando requeridos, no tempo desejado.

Para aqueles que estiverem interessados, segue site oficial do ITIL http://www.itil-officialsite.com/home/home.asp

Esclarecendo o CRUD

Muitas pessoas iniciando em analise de sistemas, se deparam com a seguinte palavra "CRUD", neste post iremos mostrar o significado desta sigla onde que ela é usada nos diagramas de caso de uso.
CRUD tem como seu acrônimo de Create , Read , Update e Delete , ou seja,  as 4 operações básicas utilizadas em um banco de dados, como:
* Create = Insert;
* Read = Select;
* Update = Update;
* Delete = Delete;

Existem várias maneiras de se fazer um diagrama de caso de uso, num sistema existe muitas funções, vamos demonstrá-las abaixo:
 - Cadastrar Cliente
 - Excluir Cliente
 - Alterar Cliente
 - Consultar Cliente
Outra maneira de demonstrar as funções de um sistema usando a sintaxe CRUD, é - "Manter Cliente" - que contém as mesmas funcionalidades citadas acima, mas com uma notação diferente.
O importante é manter as quatro funções existentes em qualquer sistema que deverá ser construído pelo analista, se preocupando com as reais necessidades do cliente, outro ponto importante no CRUD é saber estimar o tamanho e a quantidade de horas de desenvolvimento.
Nos futuros posts, iremos abordar o tema de métricas utilizando o Use Case Point (UCP) que é utilizado para sistemas Orientados a Objetos, fiquem atentos!!!

Ciclo de vida Orientado a Objetos

Na década de 80/90 a grande evolução na área de analise de sistemas foram os estudos e implantação do conceito de analise orientada a objetos com o enfoque em dados, controles e processos onde se obtinha a seguinte definição:

      - DADOS: o que será utilizado para fazer;

      - CONTROLES: Quando será feito (resposta aos eventos);

      - PROCESSOS: O que será feito;

      - TECNOLOGIA: Recursos Operacionais;

      - PESSOAS: Número e Perfil.

Esta analise tem uma abordagem Bottom-up que segue os seguintes passos : Levantamento da Necessidade, Análise, Especificação, Projeto e Implementação.

As informações citadas acima são apenas um resumo do ciclo de vida OO, caso você tenha interesse em saber mais, comente nossos post, pois em breve iremos abortar mais profundamente este assunto.

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.

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.

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.

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.