Soluções        Serviços          Atendimento       Governo        Consultoria T.I      Treinamento
Software

Governança em T.I (Governança corporativa)

| Imprimir | PDF 

Governança corporativa (português brasileiro) ou governo das sociedades ou das empresas (português europeu) é o conjunto de processos, costumes, políticas, leis, regulamentos e instituições que regulam a maneira como uma empresa é dirigida, administrada ou controlada. O termo inclui também o estudo sobre as relações entre os diversos atores envolvidos (os stakeholders) e os objetivos pelos quais a empresa se orienta. Os principais atores tipicamente são os acionistas, a alta administração e o conselho de administração. Outros participantes da governança corporativa incluem os funcionários, fornecedores, clientes, bancos e outros credores, instituições reguladoras (como a CVM, o Banco Central, etc.) e a comunidade em geral.

Governança corporativa é uma área de estudo com múltiplas abordagens. Uma das principais preocupações é garantir a aderência dos principais atores a códigos de conduta pré-acordados, através de mecanismos que tentam reduzir ou eliminar os conflitos de interesse e as quebras do dever fiduciário. Um problema relacionado, entretanto normalmente tratado em outro fórum de discussão é o impacto da governança corporativa na eficiência econômica, com uma forte ênfase em maximizar valor para os acionistas. Há ainda outros temas em governança corporativa, como a preocupação com o ponto de vista dos outros stakeholders que não os acionistas, bem como o estudo dos diversos modelos de governança corporativa ao redor do mundo. Assim, o corporate governance (ou o governo das sociedades) é composto pelo conjunto de mecanismos e regras pelas quais se estabelecem formas de controle da gestão das sociedades de capital aberto, e onde se incluem instrumentos para monitorização e possibilidade de responsabilização dos gestores pelas suas decisões (ou actos de gestão). A governança corporativa visa diminuir os eventuais problemas que podem surgir na relação entre gestores e accionistas e, consequentemente, diminuir o risco de custos da agência.

Tem havido um renovado interesse no assunto de governança corporativa desde 2001, particularmente devido aos espetaculares colapsos de grandes corporações norte-americanas como a Enron Corporation e Worldcom. Em 2002, o governo federal norte-americano aprovou a Lei Sarbannes-Oxley, com o propósito de restaurar a confiança do público em geral na governança corporativa.

Índice

  • 1 Definição
  • 2 História
    • 2.1 As crises da governança
  • 3 As oito principais características da "boa governança"
    • 3.1 Participação
    • 3.2 Estado de Direito
    • 3.3 Transparência
    • 3.4 Responsabilidade
    • 3.5 Decisões orientadas para um Consenso
    • 3.6 Igualdade e inclusividade
    • 3.7 Efetividade e eficiência
    • 3.8 Suporte à auditoria fiscalizadora
  • 4 Referências
  • 5 Ligações externas
  • 6 Ver também

Definição

A Governança Corporativa visa a aumentar a probabilidade dos fornecedores de recursos garantirem para si o retorno sobre seu investimento, por meio de um conjunto de mecanismos no qual se inclui o Conselho de Administração.

O tema possui importância crescente, por ser bem difundida a hipótese de que a estrutura de governança afeta o valor da empresa.

A questão é descobrir se existe uma estrutura de governança corporativa "melhor" ou "ideal". Vários códigos de governança foram elaborados com esta intenção... No Brasil, destacam-se os códigos do Instituto Brasileiro de Governança Corporativa (IBGC) e da Comissão de Valores Mobiliários(CVM).

A governança é a capacidade das sociedades humanas para se dotarem de sistemas de representação, de instituições e processos, de corpos sociais, para elas mesmas se gerirem, em um movimento voluntário. Esta capacidade de consciência (o movimento voluntário), de organização (as instituições, os corpos sociais), de conceitualização (os sistemas de representação), de adaptação a novas situações é uma característica das sociedades humanas. É um dos traços que as distinguem das outras sociedades de seres vivos, animais e vegetais.

São as instituições de Bretton Woods – Banco Mundial, Fundo Monetário Internacional – que a puseram na moda. Ela engloba, com efeito, o conjunto dos poderes legislativo, executivo e judiciário, a administração, o governo, o parlamento, os tribunais, as coletividades locais, a administração do Estado, a Comissão Européia, o sistema das Nações Unidas...

A emergência progressiva dos Estados, dos princípios e das modalidades de governança pacífica, em sociedades sempre mais povoadas e sempre mais complexas, é o sinal e para alguns a própria definição da civilização[1].

Ora, o corporate governance consiste, precisamente, na criação de mecanismos tendentes à minimização da assimetria de informação existente entre a gestão e os detentores da propriedade ou de interesses relevantes (daí ter-se evoluído da consideração dos shareholders para outros stakeholders), de forma a permitir uma monitorização tão próxima quanto possível da associação dos objetivos da gestão àquela dos stakeholders: maximizar o valor da empresa. Dito de outra forma, "corporate governance é uma área […] que investiga a forma de garantir/motivar a gestão eficiente das empresas, utilizando mecanismos de incentivo como sejam os contratos, os padrões organizacionais e a legislação. O que frequentemente se limita à questão da melhoria do desempenho financeiro, como, por exemplo, a forma como os proprietários das empresas podem garantir/motivar os gestores das empresas a apresentarem uma taxa de retorno competitiva" - Cfr. definição defendida pelo Instituto Português do Corporate Governance, em http://www.cgov.pt/.

História

As crises da governança

Apesar dos avanços da governança em escala internacional e da recente reabilitação do Estado no próprio seio de instituições internacionais tradicionalmente pouco simpáticas ao setor público, existe uma profunda crise da ação pública desde o final dos anos 1970, mais ou menos em todo o mundo. Estão na moda a crise do Estado, a crítica do setor público, o fracasso da ONU, o euroceticismo. Observa-se em muitos países, o desmantelamento dos sistemas estatais pelo tríplice movimento da privatização dos serviços públicos, da mundialização dos mercados e da descentralização. A implosão dos regimes de economia planejada na Europa e a abertura ao mercado dos regimes comunistas da Ásia, a crise financeira e moral do Estado-providência na maioria das democracias ocidentais, a rápida mundialização das trocas comerciais e dos mercados financeiros puderam dar, nos anos que se seguiram à queda do muro de Berlim, o sentimento de uma vitória do neoliberalismo e da “revolução conservadora”[2].

A década de 1960 fora aquela do Estado triunfante. A URSS, com a conquista do espaço, parecia mostrar sua capacidade, ao menos técnica, de alcançar os EUA. No terceiro mundo, planejamento e capitalismo público pareciam, na ausência de tradições industriais ou empresariais locais, o caminho principal e programado do desenvolvimento. Nos países desenvolvidos, os Estados aperfeiçoavam seus instrumentos e suas políticas para enquadrar as economias nacionais, garantir o pleno emprego, organizar as transferências sociais necessárias, oferecer a cada um a proteção do Estado-providência.

Vinte anos depois, mudança completa de discurso e de cenário. O Estado-nação ficou na berlinda. Sua autonomia e seu poder foram erodidos. Erodidos por cima com a mundialização da economia e a globalização dos mercados financeiros; com, para os países europeus, o papel crescente da União Européia, das diretrizes de Bruxelas, dos critérios de convergência de Maastricht, com o desenvolvimento das convenções internacionais, como o GATT; com o aumento do poder das grandes firmas multinacionais, sempre menos ligadas aos países em que nasceram. Erodidos por baixo, com a descentralização, o aumento dos poderes locais e das reivindicações autonomistas, com o enfraquecimento dos grandes corpos intermediários políticos, sindicais, religiosos, sociais que garantiam em escala nacional o diálogo entre o Estado e a sociedade.

As oito principais características da "boa governança"

  1. Participação
  2. Estado de direito
  3. Transparência
  4. Responsabilidade
  5. Orientação por consenso
  6. Igualdade e inclusividade
  7. Efetividade e eficiência
  8. Prestação de contas (accountability)

Participação

Participação significa que homens e mulheres devem participar igualmente das atividades de governo.

A participação deve contemplar a possibilidade de participação direta ou participação indireta através de instituições ou representantes legítimos.

A participação implica a existência de liberdade de expressão e liberdade de associação de um lado, e uma sociedade civil organizada de outro lado.

O princípio, apesar de parecer utópico, é perfeitamente possível desde que existam leis claras e específicas que garantam os termos propostos; e existam iniciativas do Estado visando à sustentação dos termos.

Estado de Direito

A boa governança requer uma estrutura legal justa que se aplica a todos os cidadãos do Estado independentemente de sua riqueza financeira, de seu poder político, de sua classe social, de sua profissão, de sua raça e de seu sexo.

A boa governança deve garantir total proteção dos direitos humanos, pertençam as pessoas a maiorias ou a minorias sociais, sexuais, religiosas ou étnicas.

A boa governança deve garantir que o poder judiciário seja independente do poder executivo e do poder legislativo.

A boa governança deve garantir que as forças policiais sejam imparciais e incorruptíveis.

Transparência

Mais do que "a obrigação de informar", a administração deve cultivar o "desejo de informar", sabendo que da boa comunicação interna e externa, particularmente quando espontânea, franca e rápida, resulta um clima de confiança, tanto internamente, quanto nas relações da empresa com terceiros. A comunicação não deve restringir-se ao desempenho econômico-financeiro, mas deve contemplar também os demais fatores (inclusive intangíveis) que norteiam a ação empresarial e que conduzem à criação de valor. No Brasil existe a Lei de Responsabilidade Fiscal, que induz o gestor público à transparência de seus atos. Essa transparência pode ser melhorada, significativamente, com instrumentos como a Demonstração do Resultado Econômico, com o contracheque econômico e o balanço social.

Responsabilidade

As instituições governamentais e a forma com que elas procedem são desenhadas para servir os membros da sociedade como um todo e não apenas pessoas privilegiadas.

Os processos das instituições governamentais são desenhados para responder as demandas dos cidadãos dentro de um período de tempo razoável.

Decisões orientadas para um Consenso

As decisões são tomadas levando-se em conta que os diferentes grupos da sociedade necessitam mediar seus diferentes interesses. O objetivo da boa governança na busca de consenso nas relações sociais deve ser a obtenção de uma concordância sobre qual é o melhor caminho para a sociedade como um todo. Além disso, as decisões também devem ser tomadas levando em conta a forma como tal caminho pode ser trilhado.

Essa forma de obter decisões requer uma perspectiva de longo prazo para que ocorra um desenvolvimento humano sustentável. Essa perspectiva também é necessária para conseguir atingir os objetivos desse desenvolvimento.

Igualdade e inclusividade

A boa governança deve assegurar igualdade de todos os grupos perante os objetivos da sociedade. O caminho proposto pelo governante deve buscar promover o desenvolvimento econômico de todos os grupos sociais.

As decisões devem assegurar que todos os membros da sociedade sintam que façam parte dela e não se sintam excluídos em seu caminho para o futuro.

Esta abordagem requer que todos os grupos, especialmente os mais vulneráveis, tenham oportunidade de manter e melhorar seu bem –estar.

Efetividade e eficiência

A boa governança deve garantir que os processos e instituições governamentais devem produzir resultados que vão ao encontro das necessidades da sociedade ao mesmo tempo em que fazem o melhor uso possível dos recursos à sua disposição. Veja Lei do Ótimo de Pareto. Isso também implica que os recursos naturais sejam usados sustentavelmente e que o ambiente seja protegido.

Suporte à auditoria fiscalizadora

As instituições governamentais, as instituições do setor privado e as organizações da sociedade civil deveriam ser fiscalizáveis pelas pessoas da sociedade e por seus apoiadores institucionais. De forma geral, elas devem ser fiscalizáveis por todas aquelas pessoas que serão afetadas por suas decisões, atos e atividades.

fonte:wikipedia

Software

 

CobiT

| Imprimir | PDF 

Origem: Wikipédia, a enciclopédia livre.

COBIT®, do inglês, Control Objectives for Information and related Technology, é um guia de boas práticas apresentado como framework, dirigido para a gestão de tecnologia de informação (TI). Mantido pelo ISACA (Information Systems Audit and Control Association), possui uma série de recursos que podem servir como um modelo de referência para gestão da TI, incluindo um sumário executivo, um framework, objetivos de controle, mapas de auditoria, ferramentas para a sua implementação e principalmente, um guia com técnicas de gerenciamento. Especialistas em gestão e institutos independentes recomendam o uso do CobiT como meio para otimizar os investimentos de TI, melhorando o retorno sobre o investimento (ROI) percebido, fornecendo métricas para avaliação dos resultados (Key Performance Indicators KPI, Key Goal Indicators KGI e Critical Success Factors CSF).

O CobiT independe das plataformas de TI adotadas nas empresas, tal como independe do tipo de negócio e do valor e participação que a tecnologia da informação tem na cadeia produtiva da empresa.

Em 28 de janeiro de 2010, foi anunciada oficialmente a tradução do COBIT 4.1 para a Língua Portuguesa.[1]

Índice

  • 1 O cubo do Cobit
    • 1.1 Critérios de Informação ou Requisitos de Negócio
    • 1.2 Recursos de TI
  • 2 Estrutura do Cobit
    • 2.1 Planejar e Organizar
    • 2.2 Adquirir e Implementar
    • 2.3 Entregar e Suportar
    • 2.4 Monitorar e Avaliar
  • 3 Estrutura de cada processo
  • 4 Notas e referências
  • 5 Ver também
  • 6 Referências

O cubo do Cobit

É o modelo que representa como os componentes se inter-relacionam:

Critérios de Informação ou Requisitos de Negócio

  • Efetividade
  • Eficiência
  • Confidencialidade
  • Integridade
  • Disponibilidade
  • Conformidade
  • Confiabilidade

Recursos de TI

  • Aplicações
  • Informações
  • Infraestrutura
  • Pessoas
  • Processos
  • Informações de TI

Estrutura do Cobit

CobiT cobre quatro domínios, os quais possuem 34 processos, e estes processos possuem 318 objetivos de controle:

  • Planejar e Organizar
  • Adquirir e Implementar
  • Entregar e Dar Suporte
  • Monitorar e Avaliar

Planejar e Organizar

O domínio de Planejamento e Organização cobre o uso de informação e tecnologia e como isso pode ser usado para que a empresa atinja seus objetivos e metas. Ele também salienta que a forma organizacional e a infraestrutura da TI devem ser consideradas para que se atinjam resultados ótimos e para que se gerem benefícios do seu uso. A tabela seguinte lista os processos de TI para o domínio do Planejamento e Organização.

PROCESSOS DE TI Planejar e Organizar

PO1 Definir um Plano Estratégico de TI 6 OCs
PO2 Definir a Arquitetura de Informação 4 OCs
PO3 Determinar o Direcionamento Tecnológico 5 OCs
PO4 Definir os Processos, Organização e Relacionamentos de TI 15 OCs
PO5 Gerenciar o Investimento em TI 5 OCs
PO6 Comunicar as Diretrizes e Expectativas da Diretoria 5 OCs
PO7 Gerenciar os Recursos Humanos de TI 8 OCs
PO8 Gerenciar a Qualidade 6 OCs
PO9 Avaliar e Gerenciar os Riscos de TI 6 OCs
PO10 Gerenciar Projetos 14 OCs

Adquirir e Implementar

O domínio de Adquirir e Implementar cobre a identificação dos requisitos de TI, a aquisição de tecnologia e a implementação esta dentro dos processos de negócio da companhia. Esse domínio também lida com o desenvolvimento de um plano de manutenção que a companhia adota para prolongar a vida do sistema de TI e de seus componentes. A seguinte tabela lista os processos de TI de Aquisição e Implementação.

PROCESSOS DE TI Adquirir e Implementar

AI1 Identificar Soluções Automatizadas 4 OC
AI2 Adquirir e Manter Software Aplicativo 10 OC
AI3 Adquirir e Manter Infraestrutura de Tecnologia 4 OC
AI4 Habilitar Operação e Uso 4 OC
AI5 Adquirir Recursos de TI 4 OC
AI6 Gerenciar Mudanças 5 OC
AI7 Instalar e Homologar Soluções e Mudanças 9 OC

Entregar e Suportar

O domínio Entregar e Suportar foca aspectos de entrega de tecnologia da informação. Cobre a execução de aplicações dentro do sistema de TI e seus resultados, assim como os processos de suporte que permitem a execução de forma eficiente e efetiva. Esses processos de suporte também incluem questões de segurança e treinamento. A seguir, a tabela com os processos de TI desse domínio.

PROCESSOS DE TI Entregar e Suportar

DS1 Definir e Gerenciar Níveis de Serviço 6 OC
DS2 Gerenciar Serviços de Terceiros 4 OC
DS3 Gerenciar Capacidade e Desempenho 5 OC
DS4 Assegurar Continuidade de Serviços 10 OC
DS5 Assegurar a Segurança dos Serviços 11 OC
DS6 Identificar e Alocar Custos 4 OC
DS7 Educar e Treinar Usuários 3 OC
DS8 Gerenciar a Central de Serviço e os Incidentes 5 OC
DS9 Gerenciar a Configuração 3 OC
DS10 Gerenciar os Problemas 4 OC
DS11 Gerenciar os Dados 6 OC
DS12 Gerenciar o Ambiente Físico 5 OC
DS13 Gerenciar as Operações 5 OC

Monitorar e Avaliar

O domínio de Monitorar e Avaliar lida com a estimativa estratégica das necessidades da companhia e avalia se o atual sistema de TI atinge os objetivos para os quais ele foi especificado e controla os requisitos para atender objetivos regulatórios. Ele também cobre as questões de estimativa, independentemente da efetividade do sistema de TI e sua capacidade de atingir os objetivos de negócio, controlando os processos internos da companhia através de auditores internos e externos.

PROCESSOS DE TI Monitorar e Avaliar

ME1 Monitorar e Avaliar o Desempenho 6 OC
ME2 Monitorar e Avaliar os Controles Internos 7 OC
ME3 Assegurar a Conformidade com Requisitos Externos 5 OC
ME4 Prover a Governança de TI 7 OC

Estrutura de cada processo

Cada processo do CobIT deve descrever as seguintes características:

  • Nome do processo
  • Descrição do processo
    • Critérios de informação
    • Declaração genérica de ações
      • Indicadores de performace
    • Recursos de TI envolvidos
    • Objetivos de controle detalhados
    • Diretrizes de gerenciamento
      • Entradas
      • Saídas
      • Matrizes de responsabilidade
      • Objetivos e métricas
    • Modelo de maturidade

fonte.wikipedia

Software

 

ITILv3

| Imprimir | PDF 

A versão 3 da biblioteca ITIL foi lançada mundialmente em maio de 2007 como uma atualização completa da antiga versão 2, publicada na década de 90 do século passado.

Índice

  • 1 Visão sobre ITIL v3
    • 1.1 Estratégia do serviço (Service Strategy)
    • 1.2 Projeto de Serviço ou Desenho de serviço (Service Design)
    • 1.3 Transição do serviço (Service Transition)
    • 1.4 Operação do serviço (Service Operation)
    • 1.5 Melhoria contínua do serviço (Continual Service Improvement)
  • 2 Conjunto de livros
  • 3 Processos
  • 4 Ver também
  • 5 Ligações externas

Visão sobre ITIL v3

O ITIL v3, publicado em maio de 2007, é composto de cinco volumes:

  • Estratégia do serviço (Service Strategy)
  • Projeto de serviço ou Desenho de serviço(Service Design)
  • Transição do serviço (Service Transition)
  • Operação do serviço (Service Operation)
  • Melhoria contínua do serviço (Continual Service Improvement)

Estratégia do serviço (Service Strategy)

Como ponto de origem do ciclo de vida de serviço ITIL, o volume sobre estratégia do serviço é um guia sobre como tornar mais claro e priorizar investimentos sobre provimento de serviços.

Os pontos chaves sobre este volume são:

  • Definição do valor do serviço;
  • Desenvolvimento de um caso de negócio;
  • Ativos do serviço (service assets);
  • Análise de mercado;
  • Tipos de provimento de serviço.

Processos incluem geração de estratégia, gerenciamento da carteira de serviços(de portfólio de serviços), gerenciamento de demandas, e gerenciamento financeiro de TI.

Projeto de Serviço ou Desenho de serviço (Service Design)

O volume de desenho do serviço é um guia sobre boas práticas no projeto de serviços de IT, processos, e outros aspectos no esforço de gerenciamento de serviços.

Projeto com ITIL é entender para englobar todos os elementos relevantes à entrega de serviços de tecnologia, ao invés de focar somente no projeto da tecnologia propriamente dita. Assim, projeto de serviços aponta como uma solução planejada de serviço interage com o negócio e ambiente técnico.

Com ITIL, trabalho de projetar um serviço de TI é agregado em um simples pacote de projeto de serviços (Service Design Package - SDP). SDP, em conjunto com outros serviços de informação, são gerenciados com um catálogo de serviços.

Processos inclusos neste volume incluem:

  • Gerenciamento do nível de serviço (Service Level Management - SLM)
  • Gerenciamento de disponibilidade
  • Gerenciamento de capacidade
  • Gerenciamento de serviços de IT continuados
  • Gerenciamento de segurança da informação
  • Gerenciamento de fornecedores
  • Gerenciamento de catálogo de serviços..

Transição do serviço (Service Transition)

Este volume é direcionado à entrega dos serviços necessários ao negócio no uso operacional, e geralmente englobam o "projeto".

Os processos deste volume incluem:

  • Gerenciamento de configurações e ativos de serviço
  • Planejamento de transição e suporte
  • Gerenciamento de liberação e entrega (release and deployment)
  • Gerenciamento de mudança (Change Management)
  • Gerenciamento de conhecimento
  • Papéis da equipe engajada na transição do serviço.

Operação do serviço (Service Operation)

Parte do ciclo de vida onde serviços e valor são entregues diretamente. Assim, monitoramento de problema e balanceamento entre disponibilidade de serviço e custo, etc, são considerados.

Processos inclusos são:

  • Balanceamento do conflito das metas (disponibilidade vs custo, etc)
  • Gerenciamento de eventos
  • Gerenciamento de incidentes
  • Gerenciamento de problemas
  • Cumprimento dos pedidos
  • Gerenciamento de acesso, (service desk).

Melhoria contínua do serviço (Continual Service Improvement)

A meta do CSI (Continual Service Improvement) é ajustar e reajustar serviços de TI às mudanças contínuas do negócio através da identificação e implementação de melhorias aos serviços de TI que apoiam processos negociais.

Para gerenciar melhorias, o CSI deve definir claramente o que deve ser controlado e medido..

Conjunto de livros

Versões eletrônicas (eBook):

  • ISBN 9780113312424 Service Strategy (SS)
  • ISBN 9780113310548 Service Design (SD)
  • ISBN 9780113310555 Service Transition (ST)
  • ISBN 9780113310531 Service Operation (SO)
  • ISBN 9780113310562 Continual Service Improvement (CSI)
  • ISBN 9780113310517 ITIL Lifecycle Publication Suite (Conjunto completo da biblioteca ITIL V3)
  • ISBN 9780113310623 Official Introduction to the ITIL Service Lifecycle

Versões Impressas:

  • ISBN 9780113310456 Service Strategy (SS)
  • ISBN 9780113310470 Service Design (SD)
  • ISBN 9780113310487 Service Transition (ST)
  • ISBN 9780113310463 Service Operation (SO)
  • ISBN 9780113310494 Continual Service Improvement (CSI)
  • ISBN 9780113310500 ITIL Lifecycle Publication Suite (Conjunto completo da biblioteca ITIL V3)
  • ISBN 9780113310616 Official Introduction to the ITIL Service Lifecycle

Complementos

  • ISBN 0955124581 An Introductory Overview of ITIL® V3(Grátis)

Processos

O ITIL v3 possui exatos 26 processos, listados a seguir nominalmente e agrupados de acordo com o estágio do ciclo de vida de serviço a que pertencem.

Processo Publicação Extensão
Estágio do Ciclo de Vida de Serviço Processo
Avaliação ST
Estratégias de Serviço
(Service Strategies)		 Geração de Estratégia
Cumprimento de Requisição SO
Gerenciamento Financeiro
Geração de Estratégia SS
Gerenciamento de Portfólio de Serviço
Gerenciamento da Capacidade SD SO, CSI Gerenciamento da Demanda
Gerenciamento da Configuração e de Ativo de Serviço ST SO Desenho de Serviço
(Service Design)		 Gerenciamento da Capacidade
Gerenciamento da Continuidade do Serviço de TI SD CSI Gerenciamento da Continuidade do Serviço de TI
Gerenciamento da Demanda SS SD Gerenciamento da Disponibilidade
Gerenciamento da Disponibilidade SD CSI Gerenciamento de Fornecedor
Gerenciamento de Acesso SO
Gerenciamento de Segurança da Informação
Gerenciamento de Evento SO
Gerenciamento do Catálogo de Serviço
Gerenciamento de Fornecedor SD
Gerenciamento do Nível de Serviço
Gerenciamento de Incidente SO CSI Transição de Serviço
(Service Transition)		 Avaliação
Gerenciamento de liberação e Implantação ST SO Gerenciamento da Configuração e de Ativo de Serviço
Gerenciamento de Mudança ST
Gerenciamento de liberação e Implantação
Gerenciamento de Portfólio de Serviço SS SD Gerenciamento de Mudança
Gerenciamento de Problema SO CSI Gerenciamento do Conhecimento
Gerenciamento de Segurança da Informação SD SO Planejamento e Suporte da Transição
Gerenciamento do Catálogo de Serviço SD SS Validação e Teste de Serviço
Gerenciamento do Conhecimento ST CSI Operação de Serviço
(Service Operation)		 Cumprimento de Requisição
Gerenciamento do Nível de Serviço SD CSI Gerenciamento de Acesso
Gerenciamento Financeiro SS
Gerenciamento de Evento
Mensuração de Serviços CSI
Gerenciamento de Incidente
Planejamento e Suporte da Transição ST
Gerenciamento de Problema
Processo de Melhoria em 7 Etapas CSI
Melhoria Contínua de Serviço
(Continual Service Improvement)		 Mensuração de Serviços
Relatório de Serviço CSI
Processo de Melhoria em 7 Etapas
Validação e Teste de Serviço ST
Relatório de Serviço

fonte.wikipedia

Software

 

ITIL

| Imprimir | PDF 

Information Technology Infrastructure Library (ITIL) é 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). 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.

A ITIL busca promover a gestão com foco no cliente e na qualidade dos serviços de tecnologia da informação (TI). A ITIL lida com estruturas de processos para a gestão de uma organização de TI apresentando um conjunto abrangente de processos e procedimentos gerenciais, organizados em disciplinas, com os quais uma organização pode fazer sua gestão tática e operacional em vista de alcançar o alinhamento estratégico com os negócios.

ITIL dá uma descrição detalhada sobre importantes práticas de IT com checklists, tarefas e procedimentos que uma organização de IT pode customizar para suas necessidades.

Histórico

A versão inicial da ITIL consistia em uma biblioteca de 30 volumes, cobrindo todos os aspectos do Gerenciamento de Serviços de TI (GSTI). Em meados de 1990, a ITIL foi reconhecida como um "padrão de fato", no Gerenciamento de Serviços de TI (GSTI) ou IT Service Management (ITSM). Posteriormente a versão inicial foi revisada e substituída pela ITIL v2 (versão 2), que consistia em 7 volumes. A ITIL v2 se tornou a base padrão para a norma BS 15000, que se tornou um anexo da norma ISO 20000.

Em maio de 2007, foi lançada ITIL V3 (também conhecida como ITIL Refresh Project) consistindo de vinte e seis processos e funções, agora agrupadas sobre somente cinco volumes, arranjados sobre conceitos sobre uma estrutura de ciclo de vida de serviços.

Em 2009, o OGC anunciou oficialmente que ITIL v2 poderia ser descontinuado e lançou uma consulta de como poderia proceder.

Conceitos

Serviços

Serviço é uma forma de entregar valor ao cliente facilitando o resultado almejado por eles sem a necessidade de arcar com custos específicos e riscos. O valor do serviço é medido pela sua utilidade e garantia. Utilidade é servir um propósito, melhorando o desempenho médio. Garantia é servir para uso, reduzindo variações de desempenho. Exemplo de utilidade é SMS sem limite do tamanho de texto, e exemplo de garantia é menor número de quedas no serviço. Juntos, utilidade e garantia, representam o valor do serviço. O ITIL – Information Technology Infrastructure Library – é reconhecido mundialmente como um padrão para gerenciamento de serviço e tem como foco principal a operação e a gestão do conjunto de melhores práticas para gerenciamento de processos de TI. A utilização dos processos do ITIL para a implementação da Governança de TI é adotado após o estabelecimento de uma visão conjunta das áreas demandantes com a TI que descreva o objetivo de implementar um Programa de Melhoria Contínua de Serviços e que a organização possua uma resposta clara do que ocorrerá se nada mudar. Os processos do ITIL podem ser subdivididos em: Gerenciamento de Aplicações, Gerenciamento de Serviços e Gerenciamento de Infra-estrutura de TI. A biblioteca ITIL ocupa-se em sua maior parte do Gerenciamento de Serviço por ser o que contém a maior parte dos processos do ITIL. O principal objetivo do Gerenciamento de Serviços é certificar-se que os serviços de TI estão alinhados com as necessidades do negócio da empresa e seus processos estão subdivididos em dois grupos:

Entrega de Serviço (Gerenciamento de Níveis de Serviço, Gerenciamento de Capacidade, Gerenciamento de Finanças, Gerenciamento de Disponibilidade e Continuidade do Serviço);
Suporte de Serviços. (Service Desk, Gerenciamento de Incidentes, Gerenciamento de Problemas,

Gerenciamento de Configuração, Gerenciamento de Mudanças e Gerenciamento de Versões);

Em razão de sua flexibilidade, a adoção do ITIL traz grandes benefícios, uma vez que não define os processos a serem implementados, mas sim demonstra as melhores práticas que podem ser utilizadas. De forma objetiva, podemos apontar alguns resultados decorrentes de sua implementação,tais como: definição dos ciclos de vida dos processos,análise e classificação dos erros,aumenta o grau de segurança do usuário, organiza métodos de trabalho,gera melhorias contínuas e referências para novos usuários, contribui como facilitador e integrador entre as áreas de trabalho,disponibiliza recursos tecnológicos em tempo integral, restaura a operação normal do serviço (incidentes), avaliação de impactos de mudança, obtenção e uso de indicadores, entre outros.
Service Support (ITIL V2)

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

Incident Management (Gerenciamento de incidentes) – reduzir o tempo de indisponibilidade (downtime) dos serviços;
Problem Management (Gerenciamento de problemas) – minimizar o impacto no negócio dos incidentes e problemas causados pelos erros nas aplicações e infraestrutura de TI e prevenir incidentes recorrentes desses mesmos erros;
Configuration Management (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;
Change Management (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;
Release Management (Gerenciamento de versõ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:

Service Level Management/SLM (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;
Financial Management for IT Service (Gerenciamento Financeiro para TI) – demonstrar ao cliente o custo real dos serviços prestados e gerenciá-los de forma profissional;
Availability Management (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;
Capacity Management (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;
IT Service Continuity Management/ITSCM (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.

Conjunto de livros

Em Português:

"Introdução ao ITIL" - ISBN 011331034X
"Fundamentos do Gerenciamento de Serviços de TI" - ISBN 9788574524382

Em Inglês:

"Service Delivery" - ISBN 0113300174
"Service Support" - ISBN 0113300158
"Business Perspective Volume 1" - ISBN 0113308949
"Business Perspective Volume 2" - ISBN 0113309694
"Planning to Implement IT Service Management" - ISBN 0113308779
"Software Asset Management" - ISBN 0113309430
"Security Management" - ISBN 011330014X
"ITIL Small-Scale Implementation" - ISBN 0113309805
"Applications Management" - ISBN 0113308663
"ICT Infrastructure Management" - ISBN 0113308655
"Software Maintenance Management" - ISBN 0470147075

fonte:wikipedia

Software

 

SOA - Arquitetura orientada a Serviços

| Imprimir | PDF 

Service-Oriented Architecture (SOA), pode ser traduzido como arquitetura orientada a serviços, e é um estilo de arquitetura de software cujo princípio fundamental prega que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços.[1][2] Frequentemente estes serviços são conectados através de um "barramento de serviços" (enterprise service bus, em inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra forma de comunicação entre aplicações.[2][3][4] A arquitetura SOA é baseada nos princípios da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.[5]

Além da perspectiva estritamente técnica, a arquitetura orientada a serviços também se relaciona com determinadas políticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os serviços disponibilizados.[6][7]

A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos de tecnologia da informação das organizações, permitindo um melhor relacionamento entre as áreas que dão suporte tecnológico à empresa e as áreas responsáveis pelo negócio propriamente dito, graças a maior agilidade na implementação de novos serviços e reutilização dos ativos existentes.[8][9]

SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio
interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.
— Gartner Group

Introdução

As implementações SOA dependem de uma rede de serviços de software. Serviços incluem baixo acoplamento de unidades e de funcionalidade. Cada serviço implementa uma ação, como preencher um requerimento on-line para uma conta ou visualizar um banco on-line de instrução, ou colocar uma reserva on-line ou para bilhete de avião. Em vez de serviços de chamadas para encaixar uns aos outros em seu código fonte que eles usam protocolos definidos que descrevem como os serviços de análise e passar mensagens, utilizando metadados descrição.

Desenvolvedor SOA associa objetos individuais usando orquestração. No processo de orquestração que o desenvolvedor associa funcionalidade de software (serviços) em um arranjo não-hierárquica usando uma ferramenta de software que contém uma lista completa de todos os serviços disponíveis, suas características e os meios para criar uma aplicação utilizando essas fontes.

Subjacente e que permite tudo isso requer metadados em detalhes suficientes para descrever não só as características desses serviços, mas também os dados que os impulsiona. Programadores fizeram amplo uso de XML em SOA para estrutura de dados que envolvem quase que em uma exaustiva descrição de contêiner. Analogamente, os Web Services Description Language (WSDL) normalmente descreve os próprios serviços, enquanto o protocolo SOAP descreve os protocolos de comunicação. Se estas linguagens de descrição são as melhores possíveis para o trabalho, e se tornará / permanecem os favoritos no futuro, permanecem questões abertas. A partir de 2008 [update] SOA depende dos dados e serviços que são descritos por metadados que devem satisfazer os seguintes critérios:

1. Os metadados devem vir de uma forma que os sistemas de software pode usar para configurar dinamicamente a descoberta e a incorporação de serviços definidos, e também para manter a coerência e integridade. Por exemplo, os metadados podem ser utilizados por outros aplicativos, como um catálogo, para executar serviços de autodescoberta, sem modificar o contrato de um serviço funcional.

2. Os metadados devem vir de uma forma que os designers de sistema capaz de compreender e gerir com um gasto razoável de custo e esforço.

Para isto funcionar, não deve existir interações entre os pedaços dentro do especificado, ou pedaços de si. Em vez disso, os seres humanos especificar a interação dos serviços (todos eles pares não associados) em uma forma relativamente ad hoc com a intenção impulsionado por exigências de recém-emergente. Assim, a necessidade de serviços como unidades de maior funcionalidade do que as funções tradicionais ou classes, para que a enorme complexidade de milhares de tais objetos granulares sobrecarregar o designer de aplicativo. Os programadores desenvolvem os próprios serviços usando linguagens tradicionais como Java, C, C + +, C # ou COBOL.

A partir de 2008, um número crescente de empresas de software de terceiros oferecem serviços de software para uma taxa. No futuro, sistemas SOA pode consistir de tais serviços de terceiros combinado com outros criados em casa. Este tem o potencial de repartir os custos sobre os clientes e usa muitos dos clientes e promove a normalização, tanto dentro como através das indústrias. Em particular, a indústria do turismo tem agora um bem-definidas e documentadas conjunto de ambos os serviços e dados, suficiente para permitir que qualquer engenheiro de software razoavelmente competente para criar software de agência de viagens que utilizam os serviços totalmente off-the-shelf software.

Outras indústrias, como a indústria financeira, também começaram a fazer progressos significativos nesse sentido.

SOA como uma arquitetura depende de orientação a serviços como o seu princípio fundamental de design. Se um serviço apresenta uma interface simples que abstrai a complexidade subjacente, os usuários podem acessar os serviços independentes, sem conhecimento da execução do serviço de plataforma.

SOA se baseia em serviços expondo suas funcionalidades através de interfaces que outros aplicativos e serviços pode ler para entender como utilizar esses serviços.

Requisitos

A fim de utilizar eficientemente uma SOA, deve-se atender aos seguintes requisitos:

A interoperabilidade entre diferentes sistemas e linguagens de programação fornece a base para a integração entre aplicações em diferentes plataformas, através de um protocolo de comunicação. Um exemplo dessa comunicação depende do conceito de mensagens. Usando mensagens, através de canais de mensagens definidos, diminui a complexidade da aplicação final, permitindo que o desenvolvedor do aplicativo se concentre na funcionalidade do aplicativo de verdade, em vez das necessidades intrincadas de um protocolo de comunicação. O desejo é o de criar um conjunto de recursos a ser compartilhado, bem como estabelecer e manter o fluxo de dados para um sistema de banco de dados compartilhado. Isto permite que novas funcionalidades desenvolvidas para um formato de negócio de referência comum para cada elemento de dados.

Abordagem Serviços Web

Serviços Web podem implementar uma arquitetura orientada a serviços. Serviços Web fazem blocos funcionais de construção acessíveis através de protocolos de Internet padrão independente de plataformas e linguagens de programação. Estes serviços podem representar tanto novas aplicações quanto apenas invólucros em torno dos sistemas legados existentes para torná-los em rede ativada.

Cada bloco de construção SOA pode desempenhar um ou ambos os papéis:

Service Provider - O prestador de serviços cria um serviço Web e, eventualmente, publica sua interface e acesso a informação para o registro de serviços. Cada fornecedor deve decidir quais os serviços irá expor, como fazer trade-offs entre a segurança e a facilidade de acesso, como preço dos serviços, ou (se nenhuma taxa extra), como e se a explorá-los para outro valor. O provedor também tem que decidir em qual categoria os serviços devem ser listados em um dado serviço de broker e que tipo de acordos com parceiros comerciais são obrigados a usar o serviço. Ele registra que os serviços estão disponíveis dentro dele, e as listas de todos os beneficiários potenciais do serviço. O implementador do corretor, então, decide o âmbito do corretor. Corretores públicos estão disponíveis através da Internet, enquanto intermediários privados só são acessíveis a um público limitado, por exemplo, os usuários de uma intranet da empresa. Além disso, a quantidade de informações oferecidas tem de ser decidido. Alguns corretores especializados em muitas listas. Outros oferecem altos níveis de confiança nos serviços listados. Algumas cobrem um amplo panorama de serviços e outros, o foco dentro de uma indústria. Alguns corretores catálogam outros. Dependendo do modelo de negócio, os corretores podem tentar maximizar o look-up dos pedidos, o número de anúncios ou exatidão dos anúncios. O Universal Description Discovery and Integration (UDDI) define uma maneira de publicar e descobrir informações sobre os serviços da Web. Outros serviços incluem (por exemplo) ebXML (Electronic Business utilizando eXtensible Markup Language) e aqueles baseados na ISO / IEC 11179 Metadata Registry (MDR) padrão.

Atendimento ao consumidor - O consumidor de serviços ou cliente do serviço web localiza entradas no registro do corretor para encontrar as operações e, em seguida, liga-se ao prestador do serviço para invocar um de seus serviços de web. Seja qual for o serviço a serviço, os consumidores precisam, eles têm que levá-la para o corretor, em seguida, vinculá-lo com o respectivo serviço e usá-lo. Eles podem acessar vários serviços, se o serviço oferece vários serviços.
Acoplamento

É o nível de interdependência entre os módulos de um sistema. Por outro lado, um módulo é considerado coeso quando possui uma atividade bem definida. Diferentemente do que as pessoas pensam, SOA não se trata de uma simples invenção. A arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemas tradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas de mercado, que se faz cada vez mais exigente em qualidade e agilidade.

Serviço

Um serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é disponibilizado para outro sistema. Um serviço deve funcionar de forma independente do estado de outros serviços, exceto nos casos de serviços compostos (composite services), e deve possuir uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web services.

Processos

Mais do que uma tecnologia, SOA também influencia regras e processos de negócios,
além de muitas vezes implicar reengenharia de software simultaneamente.
— Gartner Group

A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal conceito é análogo a "Ciclo de Deming" aplicado aos serviços, que define o ciclo que envolve o planejamento, a execução, o monitoramento e a tomada de ação pró ativa para a melhoria da qualidade


A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal conceito é análogo a "Ciclo de Deming" aplicado aos serviços, que define o ciclo que envolve o planejamento, a execução, o monitoramento e a tomada de ação pró ativa para a melhoria da qualidade.
Esquema adaptado do paradigma "find-bind-execute"

Tecnicamente falando, o processo preconiza que os provedores de serviços registrem informações em um registro central, com suas características, indicadores, e aspectos relevantes às tomadas de decisões. O registro é utilizado pelo cliente para determinar as características dos serviços necessários, e se o mesmo estiver disponível no registro central, como por exemplo por um catálogo de serviços, o cliente poderá utilizá-lo, sendo este oficializado através de um contrato que enderece este serviço.

Tecnologia

O termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Serviços expressa um conceito no qual aplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões abertos. A maior parte das implementações de SOA se utilizam de Web services (SOAP , REST e WSDL). Entretanto, uma implementação de SOA pode se utilizar de qualquer tecnologia padronizada baseada em web.

Definições de SOA

O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão de serviços e ao cliente.

Termo Definição / Comentário
Serviço É uma função independente, sem estado (stateless) que aceita uma ou mais requisições e devolve uma ou mais respostas através de uma interface padronizada e bem definida. Serviços podem também realizar partes discretas de um processo tal como editar ou processar uma transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de programação, não pode fazer parte da definição do serviço.
Orquestração Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados.
Stateless Não depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebem todas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.
Provedor O recurso que executa o serviço em resposta a uma requisição de um consumidor.
Consumidor É quem consome ou pede o resultado de um serviço fornecido por um provedor.
Descoberta SOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio.
Binding A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; ela é estabelecida em tempo de execução através de um mecanismo de binding.

SOA Fundamental

Como serviços encapsulam a lógica

Pode ser em contextos distintos. Estes contextos podem ser específicos para uma tarefa de negócio, entidades de negócio e outros agrupamentos de negócio.
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Na figura, quando construímos uma solução consistente de serviço, cada serviço pode encapsular a tarefa realizada por um passo individual ou um sub-processo composto de um conjunto de passos. Um serviço pode encapsular toda a lógica do processo. O último caso representado pelo serviço pode englobar a lógica encapsulada de outros serviços.

Como serviços são relacionados
Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Dentro do SOA serviços podem ser usados por outros serviços ou por outros programas. Independentemente, o relacionamento por trás do serviço é baseado no entendimento que os serviços possam interagir. Eles devem estar atentos ao outro. Esta consciência é obtida através do uso da descrição do serviço.

Como serviços se comunicam

Quando as mensagens são enviadas eles perdem o controle do que acontece depois. Essas mensagens podem ser equipadas com inteligência suficiente para auto-governar as partes lógicas do processamento.

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Esta arquitetura é similar ao passado da arquitetura distribuída que suporta mensagens e separação de interface de processamento lógico. O que distingue é como esses três componentes fundamentais (serviço, descrição e mensagem) são projetados. Onde entra a orientação de serviços.


Como serviços são projetados

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Acoplamento: busca-se um fraco acoplamento. Contrato de serviço: meio de acesso a esse serviço. Autonomia: serviços têm controle sobre a lógica que a encapsulam. Abstração: além do que é descrito no contrato de serviço, serviços escondem a lógica do mundo exterior. Reusabilidade: a lógica é dividida no serviço com a intenção de reuso. Agregabilidade: coleções de serviços podem ser coordenados e montados em forma de serviços compostos. Statelessness: serviços minimizam a retenção da informação em determinada atividade. Descoberta: serviços são projetados para ser exteriormente descrito, para que possam ser encontrados e avaliados através de mecanismos de descobertas disponíveis.

Como serviços são construídos A obtenção do SOA não exige serviço web, mas SOA pode e deve ser realizada através do uso da plataforma de tecnologia de serviço web.

fonte:wikipedia

Software

 

Orientação a objetos

| Imprimir | PDF 

A orientação a objetos é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos.

Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de programação. De fato, o paradigma "orientação a objeto", tem bases conceituais e origem no campo de estudo da cognição, que influenciou a área de inteligência artificial e da linguística, no campo da abstração de conceitos do mundo real. Na qualidade de método de modelagem, é tida como a melhor estratégia para se eliminar o "gap semântico", dificuldade recorrente no processo de modelar o mundo real do domínio do problema em um conjunto de componentes de software que seja o mais fiel na sua representação deste domínio. Facilitaria a comunicação do profissional modelador e do usuário da área alvo, na medida em que a correlação da simbologia e conceitos abstratos do mundo real e da ferramenta de modelagem (conceitos, terminologia, símbolos, grafismo e estratégias) fosse a mais óbvia, natural e exata possível.

Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (definido nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. C++, C♯, VB.NET, Java, Object Pascal, Objective-C, Python, SuperCollider, Ruby e Smalltalk são exemplos de linguagens de programação orientadas a objetos. ActionScript, ColdFusion, Javascript, PHP (a partir da versão 4.0), Perl (a partir da versão 5) e Visual Basic (a partir da versão 4) são exemplos de linguagens de programação com suporte a orientação a objetos.

Conceitos essenciais

Classe representa um conjunto de objetos com características afins. Uma classe define o comportamento dos objetos através de seus métodos, e quais estados ele é capaz de manter através de seus atributos. Exemplo de classe: Os seres humanos
Subclasse é uma nova classe que herda características de sua(s) classe(s) ancestral(is)

Objeto / instância de uma classe. Um objeto é capaz de armazenar estados através de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Exemplo de objetos da classe Humanos: João, José, Maria

Atributo são características de um objeto. Basicamente a estrutura de dados que vai representar a classe. Exemplos: Funcionário: nome, endereço, telefone, CPF,...; Carro: nome, marca, ano, cor, …; Livro: autor, editora, ano. Por sua vez, os atributos possuem valores. Por exemplo, o atributo cor pode conter o valor azul. O conjunto de valores dos atributos de um determinado objeto é chamado de estado

Método definem as habilidades dos objetos. Bidu é uma instância da classe Cachorro, portanto tem habilidade para latir, implementada através do método deUmLatido. Um método em uma classe é apenas uma definição. A ação só ocorre quando o método é invocado através do objeto, no caso Bidu. Dentro do programa, a utilização de um método deve afetar apenas um objeto em particular; Todos os cachorros podem latir, mas você quer que apenas Bidu dê o latido. Normalmente, uma classe possui diversos métodos, que no caso da classe Cachorro poderiam ser sente, coma e morda

Mensagem é uma chamada a um objeto para invocar um de seus métodos, ativando um comportamento descrito por sua classe. Também pode ser direcionada diretamente a uma classe (através de uma invocação a um método estático)

Herança (ou generalização) é o mecanismo pelo qual uma classe (sub-classe) pode estender outra classe (super-classe), aproveitando seus comportamentos (métodos) e variáveis possíveis (atributos). Um exemplo de herança: Mamífero é super-classe de Humano. Ou seja, um Humano é um mamífero. Há herança múltipla quando uma sub-classe possui mais de uma super-classe. Essa relação é normalmente chamada de relação "é um"

Associação é o mecanismo pelo qual um objeto utiliza os recursos de outro. Pode tratar-se de uma associação simples "usa um" ou de um acoplamento "parte de". Por exemplo: Um humano usa um telefone. A tecla "1" é parte de um telefone

Encapsulamento consiste na separação de aspectos internos e externos de um objeto. Este mecanismo é utilizado amplamente para impedir o acesso direto ao estado de um objeto (seus atributos), disponibilizando externamente apenas os métodos que alteram estes estados. Exemplo: você não precisa conhecer os detalhes dos circuitos de um telefone para utilizá-lo. A carcaça do telefone encapsula esses detalhes, provendo a você uma interface mais amigável (os botões, o monofone e os sinais de tom)

Abstração é a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades existentes no domínio do sistema de software

Polimorfismo consiste em quatro propriedades que a linguagem pode ter (atente para o fato de que nem toda linguagem orientada a objeto tem implementado todos os tipos de polimorfismo):
Universal:
Inclusão: um ponteiro para classe mãe pode apontar para uma instância de uma classe filha (exemplo em Java: "List lista = new LinkedList();" (tipo de polimorfismo mais básico que existe)
Paramétrico: se restringe ao uso de templates (C++, por exemplo) e generics (Java/C♯)
Ad-Hoc:
Sobrecarga: duas funções/métodos com o mesmo nome mas assinaturas diferentes
Coerção: a linguagem que faz as conversões implicitamente (como por exemplo atribuir um int a um float em C++, isto é aceito mesmo sendo tipos diferentes pois a conversão é feita implicitamente)

Interface é um contrato entre a classe e o mundo externo. Quando uma classe implementa uma interface, ela está comprometida a fornecer o comportamento publicado pela interface[1]

Pacotes (ou Namespaces) são referências para organização lógica de classes e interfaces
fonte:wikipedia

Software

 

Ambiente de desenvolvimento integrado

| Imprimir | PDF 

IDE, do inglês Integrated Development Environment ou Ambiente Integrado de Desenvolvimento, é um programa de computador que reúne características e ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar este processo.

Geralmente os IDEs facilitam a técnica de RAD (de Rapid Application Development, ou "Desenvolvimento Rápido de Aplicativos"), que visa a maior produtividade dos desenvolvedores.

As características e ferramentas mais comuns encontradas nos IDEs são:

Editor - edita o código-fonte do programa escrito na(s) linguagem(ns) suportada(s) pela IDE;
Compilador (compiler) - compila o código-fonte do programa, editado em uma linguagem específica e a transforma em linguagem de máquina;
Linker - liga (linka) os vários "pedaços" de código-fonte, compilados em linguagem de máquina, em um programa executável que pode ser executado em um computador ou outro dispositivo computacional.
Depurador (debugger) - auxilia no processo de encontrar e corrigir defeitos no código-fonte do programa, na tentativa de aprimorar a qualidade de software;
Modelagem (modeling) - criação do modelo de classes, objetos, interfaces, associações e interações dos artefatos envolvidos no software com o objetivo de solucionar as necessidades-alvo do software final.

Geração de código - característica mais explorada em Ferramentas CASE, a geração de código também é encontrada em IDEs, contudo com um escopo mais direcionado a templates de código comumente utilizados para solucionar problemas rotineiros. Todavia, em conjunto com ferramentas de modelagem, a geração pode gerar todo ou praticamente todo o código-fonte do programa com base no modelo proposto, tornando muito mais rápido o processo de desenvolvimento e distribuição do software;

Distribuição (deploy) - auxilia no processo de criação do instalador do software, ou outra forma de distribuição, seja discos ou via internet.
Testes Automatizados (automated tests) - realiza testes no software de forma automatizada, com base em scripts ou programas de testes previamente especificados, gerando um relatório, assim auxiliando na análise do impacto das alterações no código-fonte. Ferramentas deste tipo mais comuns no mercado são chamadas robôs de testes.
Refatoração (refactoring) - consiste na melhoria constante do código-fonte do software, seja na construção de código mais otimizado, mais limpo e/ou com melhor entendimento pelos envolvidos no desenvolvimento do software. A refatoração, em conjunto com os testes automatizados, é uma poderosa ferramenta no processo de erradicação de "bugs", tendo em vista que os testes "garantem" o mesmo comportamento externo do software ou da característica sendo reconstruída.

Exemplos

Maker - Multi-linguagem e multi-banco, gerando aplicativos, documentação e funciona integrando BPM;
HB++ (Handheld-Basic) - Desenvolve projetos PalmOS Palm OS;
Boa Constructor - Gera código Python;
Delphi - Trabalha originalmente com a linguagem Object Pascal/Pascal, agregando na suite Delphi Studio 2005, a linguagem C# e a extensão da Object Pascal para .NET;
Lazarus - Uma alternativa gratuita e de código livre (open source) para o Delphi, que também trabalha originalmente com Pascal e Object Pascal, é baseado no compilador Free Pascal, sua interface é semelhante a do Delphi até sua versão 7 (antes do Delphi mudar para o estilo visual das ferramentas da Microsoft).
Eclipse - Gera código Java (através de plugins, o Eclipse suporta muitas outras linguagens como Python e C/C++);
Netbeans - Gera código Java e suporta muitas outras linguagens como Python e C/C++);.
Sun Studio - Linguagens C, C++ e Fortran
BlueJ - Gera código Java.
Genexus - Ferramenta baseada em conhecimento, gera em diversas linguagens de programação e bancos de dados.
Visual Basic - Gera código Basic;
Visual Studio .NET - Gera código para Framework .NET, suportando linguagens como Visual Basic .NET, C#, C++, J# e outras compatíveis com .NET.
SharpDevelop - Gera código C#.
MonoDevelop - Baseado no SharpDevelop, para ambiente Unix
DEV-C++, Code::Blocks, Turbo C - Geram código para C e C++
Anjuta - Gera código para C e C++
Anubis - Gera código PHP-GTK;
Zend Studio - Gera código PHP;
WOL - Gera código pascal (também é biblioteca)
Xcode - Gera código Objective-C
IAR Embedded Workbench - Gera códigos em C e Assembly para programação de microcontroladores.
Source Insight - Suporta: C,C++, VHDL, para Ambiente Windows - Source Dynamics;
Force(IDE) - Gera código Fortran, para Ambiente Windows - Lepsch;
OutSystems - Agile Platform.

fonte:wikipedia

Software

 

IBM Rational Unified Process

| Imprimir | PDF 

O RUP, abreviação de Rational Unified Process (ou Processo Unificado Racional), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".

Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como a Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.

Linhas mestras

O RUP define as seguintes linhas-mestras e esqueletos (templates) para os membros da equipe de um ciclo de produção: parte do cliente, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda os programadores a manterem-se concentrados no projeto.

Gestão de requisitos

Uma documentação apropriada é essencial para qualquer grande projeto; note que o RUP descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio.

Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais.

Uso de arquitetura baseada em componentes

A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo. Um componente normalmente se relaciona com um objeto na programação orientada a objetos.

O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala.

Estes componentes são normalmente incluidos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objectos).

Uso de software de modelos visuais

Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução.

O uso de modelos visuais também pode permitir que indivíduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.

A linguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP!

Verificação da qualidade do software

Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento.

O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.

Gestão e Controle de Mudanças do Software

Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto.

O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.
Fases

Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um projeto. As fases[1] indicam a ênfase que é dada no projeto em um dado instante. Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em quatro fases diferentes:

Concepção: ênfase no escopo do sistema;
Elaboração: ênfase na arquitetura;
Construção: ênfase no desenvolvimento;
Transição: ênfase na implantação.

O RUP também se baseia nos 4 Ps:

Pessoas
Projeto
Produto
Processo

As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definido enquanto as fases são objetivas.

Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e documentam o projeto, além de permitir melhor acompanhamento.
Fase de Concepção

A fase de concepção contém os workflows necessários para que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura e o planejamento do projeto. Se as partes interessadas tiverem bons conhecimentos, então, pouca análise será requerida. Caso contrário, uma análise maior será requerida. Nesta fase os requisitos essenciais do sistema são transformados em casos de uso. O objetivo não é fechar todos os requisitos, mas apenas aqueles necessários para se formar uma opinião. Esta fase é geralmente curta e serve para se definir se vale a pena continuar com o projeto e definir os riscos e o custo deste. Um protótipo pode ser feito para que o cliente possa aprovar.

Como cita o RUP, o ideal é que sejam feitas iterações, mas estas devem ser bem definidas quanto a sua quantidade e objetivos.

Fase de Elaboração

A fase de elaboração será apenas para o projeto do sistema, buscando complementar o levantamento / documentação dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os projetos e inicia a versão do manual do usuário. Deve-se aceitar: Visão geral do produto (incremento + integração) está estável?; O plano do projeto é confiável?; Custos são admissíveis?

Fase de Construção

Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa e beta.

Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem "baseline".
Fase de Transição

Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de implantação e entrega, acompanhamento e qualidade do software. Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação do cliente. Nesta fase também é realizada a capacitação dos usuários.
Disciplinas
Seis Disciplinas de Engenharia

Disciplina de Modelagem de Negócios

As organizações estão cada vez mais dependentes de sistemas de TI, tornando-se imperativo que os engenheiros de sistemas de informação saibam como as aplicações em desenvolvimento se inserem na organização. As empresas investem em TI, quando entendem a vantagem competitiva do valor acrescentado pela tecnologia. O objetivo de modelagem de negócios é, primeiramente, estabelecer uma melhor compreensão e canal de comunicação entre engenharia de negócios e engenharia de software. Compreender o negócio significa que os engenheiros de software devem compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais problemas na organização e possíveis melhorias. Eles também devem garantir um entendimento comum da organização-alvo entre os clientes, usuários finais e desenvolvedores.

Modelagem de negócios, explica como descrever uma visão da organização na qual o sistema será implantado e como usar esta visão como uma base para descrever o processo, papéis e responsabilidades.
Disciplina de Requisitos

Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-los em um conjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído e fornecem requisitos detalhados para o que deve fazer o sistema.

Disciplina de Análise e Projeto("Design")

O objetivo da análise e projeto é mostrar como o sistema vai ser realizado. O objetivo é construir um sistema que:

Execute, em um ambiente de execução específica, as tarefas e funções especificadas nas descrições de casos de uso
Cumpra todas as suas necessidades
Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais

Resultados de projeto em um modelo de análise e projeto tem, opcionalmente, um modelo de análise. O modelo de design serve como uma abstração do código-fonte, isto é, o projeto atua como um modelo de "gabarito" de como o código-fonte é estruturado e escrito. O modelo de projeto consiste em classes de design estruturado em pacotes e subsistemas com interfaces bem definidas, representando o que irá se tornar componentes da aplicação. Ele também contém descrições de como os objetos dessas classes colaboram para desempenhar casos de uso do projeto.

Disciplina de Implementação

Os efeitos da implementação são:

Para definir a organização do código, em termos de subsistemas de implementação organizadas em camadas
Para implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros)
Para testar os componentes desenvolvidos como unidades
Integrar os resultados produzidos por implementadores individuais (ou equipes), em um sistema executável

Sistemas são realizados através da aplicação de componentes. O processo descreve como a reutilização de componentes existentes ou implementar novos componentes com responsabilidades bem definidas, tornando o sistema mais fácil de manter e aumentar as possibilidades de reutilização.
Disciplina de Teste

As finalidades da disciplina de teste são:

Para verificar a interação entre objetos
Para verificar a integração adequada de todos os componentes do software
Para verificar se todos os requisitos foram corretamente implementados
Identificar e garantir que os defeitos são abordados antes da implantação do software
Garantir que todos os defeitos são corrigidos, reanalisados e fechados

O Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo de reparar o defeito. Os testes são realizados ao longo de quatro dimensões da qualidade:confiabilidade, funcionalidade, desempenho da aplicação, e o desempenho do sistema. Para cada uma destas dimensões da qualidade, o processo descreve como você passar pelo teste do ciclo de planejamento, projeto, implementação, execução e avaliação.

Disciplina de Implantação

O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o software para seus usuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, a embalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação de ajuda e assistência aos usuários. Embora as atividades de implantação estejam principalmente centradas em torno da fase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação, no final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm menos detalhes do que outros workflows.
Três Disciplinas de Apoio/Suporte

Disciplina de Ambiente

O ambiente enfoca as atividades necessárias para configurar o processo para um projeto. Ele descreve as atividades necessárias para desenvolver as diretrizes de apoio a um projeto. A proposta das atividades de ambiente é prover à organização de desenvolvimento de software os processos e as ferramentas que darão suporte à equipe de desenvolvimento. Se os usuários do RUP não entendem que o RUP é um framework de processo, eles podem percebê-lo como um processo pesado e caro. No entanto, um conceito-chave dentro do RUP foi que o processo RUP pode e, muitas vezes, deve ser refinado. Este foi inicialmente feito manualmente, ou seja, por escrito, um documento de "caso de desenvolvimento" que especificou o processo refinado para ser utilizado. Posteriormente, o produto IBM Rational Method Composer foi criado para ajudar a tornar esta etapa mais simples, engenheiros de processos e gerentes de projeto poderiam mais facilmente personalizar o RUP para suas necessidades de projeto. Muitas das variações posteriores do RUP, incluindo OpenUP/Basic, a versão open-source e leve do RUP, são agora apresentados como processos distintos, por direito próprio, e atendem a diferentes tipos e tamanhos de projetos, tendências e tecnologias de desenvolvimento de software. Historicamente, como o RUP, muitas vezes é personalizado para cada projeto por um perito do processo RUP, o sucesso total do projeto pode ser um pouco dependente da capacidade desta pessoa.

Disciplina de Configuração e Gerência de Mudança

A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos específicos: de configuração, de solicitações de mudança, e de status e medição.

Gerenciamento de configuração: A gestão de configuração é responsável pela estruturação sistemática dos produtos. Artefatos, como documentos e modelos, precisam estar sob controle de versão e essas alterações devem ser visíveis. Ele também mantém o controle de dependências entre artefatos para que todos os artigos relacionados sejam atualizados quando são feitas alterações
Gerenciamento de solicitações de mudança: Durante o processo de desenvolvimento de sistemas com muitos artefatos existem diversas versões. O CRM mantém o controle das propostas de mudança
Gerenciamento de status e medição: Os pedidos de mudança têm os estados: novo, conectado, aprovado, cedido e completo. A solicitação de mudança também tem atributos como a causa raiz, ou a natureza (como o defeito e valorização), prioridade, etc. Esses estados e atributos são armazenados no banco de dados para produzir relatórios úteis sobre o andamento do projeto. A Rational também tem um produto para manter a solicitações de mudança chamado ClearQuest. Esta atividade têm procedimentos a serem seguidos

Disciplina de Gerência de Projeto

O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa granularidade ou planos de Fase que descreve todo o projeto, e uma série de alta granularidade ou planos de Iteração que descrevem os passos iterativos. Esta disciplina concentra-se principalmente sobre os aspectos importantes de um processo de desenvolvimento iterativo: Gestão de riscos; Planejamento um projeto iterativo através do ciclo de vida e para uma iteração particular; E o processo de acompanhamento de um projeto iterativo, métricas. No entanto, esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de projetos.

Por exemplo, não abrange questões como:

Gestão de Pessoas: contratação, treinamento, etc
Orçamento Geral: definição, alocação, etc
Gestão de Contratos: com fornecedores, clientes, etc

Princípios e melhores práticas

RUP é baseado em um conjunto de princípios de desenvolvimento de software e melhores práticas, por exemplo:

Desenvolvimento de software iterativo
Gerenciamento de requisitos
Uso de arquitetura baseada em componente
Modelagem visual de software
Verificação da qualidade do software
Controle de alteração no software

Desenvolvimento iterativo

Dado o tempo gasto para desenvolver um software grande e sofisticado, não é possível definir o problema e construir o software em um único passo. Os requerimentos irão freqüentemente mudar no decorrer do desenvolvimento do projeto, devido a restrições de arquitetura, necessidades do usuário ou a uma maior compreensão do problema original. Alterações permitem ao projeto ser constantemente refinado, além de assinalarem itens de alto risco do projeto como as tarefas de maior prioridade. De forma ideal, ao término de cada iteração haverá uma versão executável, o que ajuda a reduzir o risco de configuração do projeto, permitindo maior retorno do usuário e ajudando ao desenvolvedor manter-se focado.

O RUP usa desenvolvimento iterativo e incremental pelas seguintes razões:

A integração é feita passo a passo durante o processo de desenvolvimento, limitando-se cada passo a poucos elementos
A integração é menos complexa, reduzindo seu custo e aumentado sua eficiência
Partes separadas de projeto e/ou implementação podem ser facilmente identificadas para posterior reuso
Mudanças de requisitos são registradas e podem ser acomodadas
Os riscos são abordados no inicio do desenvolvimento e cada iteração permite a verificação de riscos já percebidos bem como a identificação de novos

Arquitetura de software é melhorada através de um escrutino repetitivo

Usando iterações, um projeto terá um plano geral, como também múltiplos planos de iteração. O envolvimento dos stakeholders é freqüentemente encorajado a cada entrega. Desta maneira, as entregas servem como uma forma de se obter o comprometimento dos envolvidos, promovendo também uma constante comparação entre os requisitos e o desenvolvimento da organização para as pendências que surgem.

Gerenciamento de requisitos

O Gerenciamento de requisitos no RUP está concentrado em encontrar as necessidades do usuário final pela identificação e especificação do que ele necessita e identificando aquilo que deve ser mudado. Isto traz como benefícios:

A correção dos requisitos gera a correção do produto, desta forma as necessidadades dos usuários são encontradas.
As características necessárias serão incluídas, reduzindo o custo de desenvolvimentos posteriores.

RUP sugere que o gerenciamento de requisitos tem que seguir as atividades:

Análise do problema é concordar com o problema e criar medições que irão provar seu valor para a organização
Entender as necessidades de seus stakeholders é compartilhar o problema e valores com os stakeholders-chave e levantar quais as necessidades que estão envolvidas na elaboração da ideia
Definir o problema é a definição das características das necessidades e esquematização dos casos de uso, atividades que irão facilmente mostrar os requerimentos de alto-nível e esboçar o modelo de uso do sistema
Gerenciar o escopo do sistema trata das modificações de escopo que serão comunicadas baseadas nos resultados do andamento e selecionadas na ordem na qual os fluxogramas de casos de uso são atacados
Refinar as definições do sistema trata do detalhamento dos fluxogramas de caso de uso com os stakeholders de forma a criar uma especificação de requerimentos de software que pode servir como um contrato entre o seu grupo e o do cliente e poderá guiar as atividades de teste e projeto
Gerenciamento das mudanças de requisitos trata de como identificar as chegadas das mudanças de requerimento num projeto que já começou

Uso de arquitetura baseada em componentes

Arquitetura baseada em componentes cria um sistema que é facilmente extensível, intuitivo e de fácil compreensão e promove a reusabilidade de software. Um componente freqüentemente se relaciona com um conjunto de objetos na programação orientada ao objeto.

Arquitetura de software aumenta de importância quando um sistema se torna maior e mais complexo. RUP foca na produção da arquitetura básica nas primeiras iterações. Esta arquitetura então se torna um protótipo nos ciclos iniciais de desenvolvimento. A arquitetura desenvolve-se em cada iteração para se tornar a arquitetura final do sistema. RUP também propõe regras de projeto e restrições para capturar regras de arquitetura. Pelo desenvolvimento iterativo é possível identificar gradualmente componentes os quais podem então ser desenvolvidos, comprados ou reusados. Estes componentes são freqüentemente construídos em infra-estruturas existentes tais como CORBA e COM, ou JavaEE, ou PHP

Modelagem visual de software

Abstraindo sua programação do seu código e representando-a usando blocos de construção gráfica constitui-se de uma forma efetiva de obter uma visão geral de uma solução. Usando esta representação, recursos técnicos podem determinar a melhor forma para implementar a dado conjunto de interdependências lógicas. Isto também constrói uma camada intermediária entre o processo de negócio e o código necessário através da tecnologia da informação. Um modelo neste contexto é uma visualização e ao mesmo tempo uma simplificação de um projeto complexo. RUP especifica quais modelos são necessários e porque.

A Linguagem modelagem unificada (UML) pode ser usada para modelagem de Casos de Uso, diagrama de classes e outros objetos. RUP também discute outras formas para construir estes modelos.
Verificar qualidade de software

Garantia da qualidade de software é o ponto mais comum de falha nos projetos de software, desde que isto é freqüentemente algo que não se pensa previamente e é algumas vezes tratado por equipes diferentes. O RUP ajuda no planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos os membros da equipe. Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP assume que cada membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de qualidade esperado e provê testes nos processos para medir este nível.

Controle de alterações no software

Em todos os projetos de software, mudanças são inevitáveis. RUP define métodos para controlar, rastrear e monitorar estas mudanças. RUP também define espaços de trabalho seguros (do inglês secure workspaces), garantindo que um sistema de engenharia de software não será afetado por mudanças em outros sistemas. Este conceito é bem aderente com arquiteturas de software baseados em componentização.
fonte:wikipedia

Software

 

UML

| Imprimir | PDF 

A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML.

É importante distinguir entre um modelo UML e um diagrama[1] (ou conjunto de diagramas) de UML. O último é uma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. O XMI (XML Metadata Interchange) na sua versão corrente disponibiliza troca de modelos mas não de diagramas.

Objetivos da UML

Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem.

O futuro da UML

Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir a sua estrutura interna.

A UML será a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual, simulações e ambientes de desenvolvimento. Em breve, ferramentas de integração e padrões de implementação baseados em UML estarão disponíveis para qualquer um.

A UML integrou muitas ideias adversas, e esta integração acelera o uso do desenvolvimento de softwares orientados a objetos.

História

A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.

A UML ainda não é um padrão da indústria, mas esse objetivo está a tomar forma sob os auspícios do Object Management Group (OMG). O OMG pediu informação acerca de metodologias orientadas a objetos que pudessem criar uma linguagem rigorosa de modelagem de software. Muitos líderes da indústria responderam na esperança de ajudar a criar o padrão.

Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process - Processo Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.

Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio internacional de empresas que define e ratifica padrões na área de Orientação a Objetos.
Visão geral da UML



Diagramas da UML 2.0

Diagramas estruturais

Diagrama de classes
Diagrama de objectos
Diagrama de componentes
Diagrama de implementação
Diagrama de pacotes
Diagrama de estrutura

Diagramas comportamentais

Diagrama de caso de uso
Diagrama de transição de estados
Diagrama de atividade

Diagramas de interação (todos também são diagramas comportamentais)

Diagrama de sequência
Diagrama de interatividade
Diagrama de colaboração ou comunicação
Diagrama de tempo

Elementos

De estrutura:
Classe
Objetos
Interface
Componente
Colaboração
Nó

De comportamento:
Casos de uso
Iteração
Máquina de estados

De agrupamento:
Pacote
Modelo
Subsistema
Framework

De anotação:
Notas

Relacionamentos

Agregação
Associação (bidirecional ou unidirecional)
Composição
Generalização
origem:wikipedia

Software

 

Modelagem de dados

| Imprimir | PDF 

Modelagem de Dados Representa um conjunto de requerimentos de informações de negócio. É uma parte importante do desenho de um sistema de informação.

A abordagem que se dispensa ao assunto normalmente atende a três perspectivas: Modelagem Conceitual, Modelagem Lógica e Modelagem Física. A primeira é usada como representação de alto nível e considera exclusivamente o ponto de vista do usuário criador do dado, a segunda já agrega alguns detalhes de implementação e a terceira demonstra como os dados são fisicamente armazenados.

Quanto ao objetivo, podemos identificar as seguintes variações: modelagem de dados entidade-relacionamento (leitura, construção e validação dos modelos); modelagem de relacionamentos complexos, grupos de dados lógicos e ciclo de vida das entidades; modelagem de dados corporativa; modelagem de dados distribuídos (cliente/servidor); modelagem e re-engenharia de dados legados e modelagem de dados para Data Warehouse.

Modelos

De acordo com a abordagem que utilizam, os modelos de dados normalmente são classificados da seguinte forma:

Modelo Conceitual:
Representação dos conceitos e características observados no ambiente;
Ignorar particularidades de implementação.

Modelo Lógico:
Regras de Derivação:
Normalização das estruturas de dados
Derivação de estruturas de agregação e generalização-especialização
Derivação de relacionamentos
Regras de Restrição:
Restrição de domínio
Restrição de Integridade
Restrição de Implementação

Modelo Físico:
Inclui a análise das características e recursos necessários para armazenamento e manipulação das estruturas de dados (estrutura de armazenamento, endereçamento, acesso e alocação física).

Identificação de Objetos

Os objetos podem ser identificados como:

Coisas Tangíveis: elementos que têm existência concreta, que ocupam lugar no espaço.

Ex: Meio de Transporte (avião, carro, etc);

Funções: percepção dos objetos através da função por eles exercida (papel, atribuição, classificação, capacitação, etc).

Ex: Organização (órgãos funcionais - venda, suporte, despacho de mercadorias, etc), especialistas (médicos, engenheiros, etc), cliente (pessoa atendida), atendente (pessoa que atende), etc;

Eventos ou Ocorrências: alguns objetos só conseguem ser individualizados ou percebidos enquanto uma certa ação se desenrola (identifica-se características que tornam determinado fato materializável).

Ex: vôo comercial, acidente de trânsito, jogo de futebol, etc.

Interações: resultantes das associações entre objetos em função de um processo executado - cada objeto participante da interação preserva suas características não sendo impactados pela materialização da interação.

Ex: compra de um imóvel, adoção de uma criança, venda de um produto;

Especificações: são elementos que definem características de outros objetos.

Ex: modelos de carro (cor, dimensões, etc), espécies animais (mamíferos, carnívoros, etc.)

Definição

Uma definição deve:

ser única (dentro de qualquer dicionário no qual ela aparece);
ser estabelecida no singular;
estabelecer o que o conceito é (não o que ele não é), o que faz, quando algum elemento passa a ser, ou deixa de ser, pertencente a esse grupo;
ser estabelecida como uma frase ou sentença descritiva;
ser expressa sem definições embutidas de outros termos;
estabelecer o significado essencial do conceito;
ser precisa e não-ambígua;
ser concisa;
ser significativa por si só;
evitar raciocínio circular.
Atributos

Quanto ao tipo, podem ser classificados como:

Descritivos: representam as características intrínsecas dos objetos;
Nominativos: além de cumprirem a função de descritivos servem como definidores de nomes ou rótulos de identificação dos objetos (nome, código, número, sigla, etc);
Referenciais: representam uma citação ou ligação do objeto em questão com outro objeto, não propriamente definindo uma característica do objeto mas explicitando um relacionamento existente[1].

Ex: Cidade de nascimento, Nome do fabricante do carro, Local de trabalho, etc.

Relacionamentos

Na descrição de um relacionamento devem aparecer:

Sua função;
O que ele representa;
Quais as regras de seu estabelecimento;
Quais as exceções a seu estabelecimento;
Quando ocorre;
Quando pode deixar de existir.

Modelo Lógico de Dados

Um modelo lógico de dados para uso meramente operacional/transacional deve:

Ser completamente normalizado;
Representar fielmente o NEGÓCIO, e NÃO necessariamente a base de dados desejada, a qual será construída posteriormente por ocasião do Projeto Físico;
Conter descrição sucinta das entidades, atributos e relacionamentos;
Conter os nomes de entidades e atributos, extensos e abreviados, atribuídos de acordo com algum padrão adotado na organização e formados por termos previamente convencionados em um glossário;
Contemplar, para cada um dos atributos, o tipo de dado, tamanho e opcionalidade.

Recomendações

Um Modelo Lógico de Dados para uso meramente operacional/transacional não deve conter:

Replicações de atributos: fisicamente pode ser interessante alguma redundância com o objetivo de melhorar a performance de determinado(s) processo(s). No modelo lógico isso não pode ser feito; um atributo só é representado na Entidade que o pertence.
Atributos derivados: pelos mesmos motivos apontados anteriormente, a implementação das tabelas pode requerer o armazenamento de uma informação derivada de outra(s) (valor do saldo por exemplo). Tal tipo de informação não se constitui um atributo do modelo lógico.
Atributos repetitivos: o uso de atributos repetidos, como Telefone-1 e Telefone-2, não é admitido. Se existe a possibilidade de uma pessoa possuir mais de um telefone, então Telefone deve ser representado como uma entidade, mantendo relacionamento Nx1 com a entidade Pessoa.
origem:wikipedia

Software

 

Arquitetura de dados

| Imprimir | PDF 

Arquitetura de dados é a estrutura dos componentes de dados de uma organização - considerados sob diferentes níveis de abstração, suas inter-relações, bem como os princípios, diretrizes, normas e padrões que regem seu projeto e evolução ao longo do tempo.

Envolve, portanto, o processo de gerenciamento dos ativos informacionais e o projeto de dados usado para definir uma determinada situação futura, incluindo o subsequente planejamento necessário para alcançar tal estado. É considerada um dos domínios que constituem os pilares da Arquitetura Empresarial. Em um sentido restrito, pode significar também o conjunto das definições de estruturas de dados, relacionamentos e regras comportamentais aplicadas a uma particular solução de TI.

Resumo

A arquitetura de dados descreve a estrutura de dados utilizada por uma organização e/ou seus aplicativos e contempla descrições de dados - tanto armazenados quanto em movimento, descrições de meios de armazenamento, grupos de dados, itens de dados e modelos de dados de soluções de TI.

Essencial à concepção da situação futura, a Arquitetura de Dados descreve como os dados são processados, armazenados e utilizados em um determinado sistema (sentido amplo). Ela fornece os critérios para as operações de processamento de dados, possibilitando que sejam projetados e também controlados os fluxos de dados no sistema.[1]

O Arquiteto de Dados é responsável por definir a situação futura, pelo alinhamento durante o desenvolvimento e pelo acompanhamento para garantir que melhorias sejam feitas sempre de acordo com as especificações arquitetônicas originais. Ele se ocupa de trabalhar os dados como um recurso estratégico da organização, representando-os independentemente dos processos das diferentes unidades que os utilizam, respeitando as múltiplas visões derivadas do mesmo dado, permitindo seu compartilhamento, considerando as características dos níveis de informação necessários: operacional – tático – estratégico e disponibilizando estruturas de dados de forma organizada; propiciando com isso a construção da base para sistemas de informação flexíveis e integrados.[2]

Durante a definição do estado de destino, a Arquitetura de Dados decompõe um assunto de informação até o seu nível atômico para, em seguida, trilhar o caminho inverso e compor o contexto desejado. Os Arquitetos de Dados executam essa tarefa, utilizando três processos tradicionais de Arquitetura: Conceitual, Lógico e Físico.


Abordagem do Framework Zachman para a Arquitetura de Dados:

Camada Visão Dados (o quê) Interessado
1 Escopo/Contexto Lista de coisas importantes para o negócio (áreas temáticas) Planejador
2 Modelo de Negócios / Conceitual Modelo semântico ou Conceitual / Enterprise Data Model Proprietário
3 Modelo de Sistema / Lógico Modelo de dados lógico Projetista
4 Modelo Tecnológico / Físico Modelo de dados físico Construtor
5 Configuração de Componentes Definições de dados Implementador
6 Corporação Funcional Dados Trabalhador

Neste segundo - e mais amplo - sentido, a Arquitetura de Dados inclui uma análise completa dos relacionamentos entre as funções de uma organização, tecnologias disponíveis e tipos de dados.

A Arquitetura de Dados deve ser definida na fase de planejamento do projeto de uma nova solução de TI que envolva persistência. Os principais tipos e fontes de dados necessários para apoiar uma organização devem ser identificados de modo completo, consistente e compreensível. O requisito principal nesta fase é a definição de todas as entidades de dados relevantes e não a especificação de itens tecnológicos ou de hardware. Uma entidade de dados é qualquer coisa real ou abstrata sobre a qual uma organização ou indivíduo deseja armazenar dados.

Arquitetura Conceitual de Dados

Visão de alto nível que dá suporte ao atendimento das necessidades do negócio de uma organização, direcionando as decisões sobre as soluções de tecnologia. Essa perspectiva destaca os elementos envolvidos nas relações negociais e não negociais da organização (entidades corporativas), contemplando-os em modelos independentes de qualquer limitação tecnológica e que buscam alinhar o suporte de TI à missão empresarial estabelecida.

Arquitetura Lógica de Dados

Uma arquitetura lógica de dados descreve com precisão as propriedades e os relacionamentos de cada uma das entidades de dados envolvidas em um domínio organizacional ou problema de negócio a ser resolvido com apoio de TI, compondo um desenho detalhado a partir do qual líderes de projeto e desenvolvedores possam trabalhar com relativa independência.

Normalização das estruturas de dados e derivação de relacionamentos de cardinalidade múltipla em entidades associativas são práticas inerentes a essa abordagem, além do estreito alinhamento a um modelo corporativo previamente concebido e de alguma preocupação com padrões de implementação da arquitetura de banco de dados.

Arquitetura Física de Dados

Arquitetura física de dados de um sistema de informação é parte de um Plano de Tecnologia. Como o próprio nome indica, o plano tecnológico está focado em elementos reais e tangíveis a serem utilizados na implementação da arquitetura de dados do projeto. Arquitetura Física de Dados engloba "arquitetura de banco de dados", que vem a ser um esquema da tecnologia de banco de dados utilizado para viabilizar a realização de um projeto de arquitetura de dados.

Portanto, a sua concepção está ligada à necessidade de suportar a implementação de um modelo que visa ao atendimento das necessidades de um negócio e que direciona as decisões sobre as soluções de tecnologia a serem adotadas.

Elementos da Arquitetura de Dados

Há certos elementos que devem ser definidos como partes do esquema de arquitetura de dados desenhado em uma organização. Por exemplo, a estrutura administrativa que será criada para gerir os recursos de dados deve ser descrita. Além disso, as metodologias que serão empregadas para armazenar os dados precisam ser definidas. Há ainda a necessidade de se gerar uma descrição da tecnologia de banco de dados a ser utilizada, assim como uma descrição dos processos que irão manipular os dados.

Também é importante definir um projeto de governança de dados, que servirá para garantir o alinhamento de todos os projetos de dados às diretrizes e padrões eleitos na organização. Caso contrário, as operações comuns de dados correm o risco de serem implementadas de diversas formas, tornando-se difíceis de compreender e de controlar o fluxo de dados dentro de tais sistemas. Este tipo de fragmentação é altamente indesejável devido ao seu potencial maior custo e por gerar dados discrepantes. Tais dificuldades podem surgir em empresas que experimentam um crescimento muito rápido, assim como em organizações que apresentam grande diversidade de negócios (produtos e serviços).[4]

Faz-se necessário o estabelecimento de padrões capazes de homogeneizar o significado de palavras, expressões e símbolos utilizados em todo o ciclo de produção das soluções de TI. A introdução de um vocabulário controlado (ou glossário) pode contribuir decisivamente para minimizar as barreiras de entendimento, proporcionando um meio eficiente e confiável para o compartilhamento dos dados.

Quando executada apropriadamente, a fase arquitetura de dados do planejamento de sistema de informação induz a organização a especificar e delinear tanto fluxos de informação internos quanto externos. Estes são padrões para cuja conceituação a organização pode não ter investido tempo previamente. É portanto possível, nesta fase, identificar importantes lacunas de informação, divergências entre departamentos e entre os sistemas organizacionais que podem não ter ficado evidentes antes da análise da arquitetura de dados.

Restrições e influências

Várias restrições e influências podem ter efeito sobre um projeto de arquitetura de dados: requisitos organizacionais, direcionadores tecnológicos, fatores econômicos, políticas de negócios e necessidades de processamento de dados.

Requisitos organizacionais
Geralmente incluem elementos tais como a expansão do sistema, níveis de desempenho aceitáveis - especialmente quanto à velocidade de acesso, confiança das transações e transparência na gestão de dados. Além disso, a conversão de dados brutos, tais como registros de operações e arquivos de imagens, em informações úteis, por meio de recursos tais como data warehouses, é também um requisito organizacional comum, já que viabiliza decisões gerenciais e outros processos organizacionais. Uma das técnicas usadas na gestão de uma arquitetura é a separação entre "Dados Transacionais" e "Dados de Referência". Outra estratégia consiste em separar "Sistemas de Captura de Dados" de "Sistemas de Recuperação de Dados".

Direcionadores tecnológicos
Normalmente determinados pela arquitetura de dados vigente e por projetos de arquitetura de banco de dados. Além disso, alguns direcionadores de tecnologia derivam de frameworks e padrões de integração organizacional existentes, assim como de sistemas legados, resultantes de desenvolvimento interno ou adquiridos de terceiros.

Fatores econômicos
Tratam-se de aspectos importantes que devem ser levados em conta durante a fase de arquitetura de dados. É possivel que algumas soluções, consideradas ideais em princípio, não possam ser potenciais candidatas devido ao seu custo. Fatores externos, tais como o ciclo de negócios, taxas de juros, condições de mercado e questões legais, podem exercer influência sobre as decisões relevantes sobre uma Arquitetura de Dados.

Políticas de negócios
Políticas negociais que também direcionam o projeto de arquitetura de dados. Incluem políticas internas da organização, normas de órgãos reguladores, padrões profissionais e leis originadas em diferentes instâncias governamentais. Tais políticas e regras ajudam a descrever a maneira pela qual a organização deseja processar os seus dados.

Necessidades de processamento de dados
Incluem transações precisas e reprodutíveis, realizadas em grandes volumes, data warehousing para suporte a sistemas de informações gerenciais (potencial data mining), relatórios periódicos repetitivos, relatórios ad hoc e apoio a várias iniciativas organizacionais conforme requeridas (por exemplo: orçamento anual e desenvolvimento de novo produto).


fonte:wikipedia


Software

 

ISO/IEC 9126

| Imprimir | PDF 

ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, que se enquadra no modelo de qualidade das normas da família 9000. A norma brasileira correspondente é a NBR ISO/IEC 9126.

Modelo de Qualidade de Software

A qualidade de um sistema de software pode ser entendida de diversas formas e utilizando diferentes abordagens.

A norma ISO/IEC 9126, ou conjunto de normas que tratam deste assunto no âmbito da ISO, estabelece um modelo de qualidade com os seguintes componentes:

Processo de desenvolvimento, cuja qualidade afeta a qualidade do produto de software gerado e é influenciado pela natureza do produto desenvolvido;
Produto, compreendendo os atributos de qualidade do produto (sistema) de software. Estes atributos de qualidade podem ser divididos entre atributos internos e externos. Estes se diferenciam pela forma como são aferidos (interna ou externamente ao produto de software) e em conjunto compõem a qualidade do produto de software em si;
Qualidade em uso que consiste na aferição da qualidade do software em cada contexto específico de usuário. Esta é, também, a qualidade percebida pelo usuário.

Modelo de Qualidade da Norma ISO 9126

A norma 9126 se foca na qualidade do produto de software, propondo Atributos de Qualidade, distribuídos em seis características principais, com cada uma delas divididas em sub-características, conforme podemos ver na figura abaixo:

No nível mais alto temos as características de qualidade e nos quadros abaixo as suas sub-características. Cada característica/sub-característica compõe um Atributo de Qualidade do software.

Note que em todas as características temos uma sub-categoria com o nome de Conformidade. A conformidade é utilizada para avaliar o quanto o software obedece aos requisitos de legislação e todo o tipo de padronização ou normalização aplicável ao contexto.

Funcionalidade

A capacidade de um software prover funcionalidades que satisfaçam o usuário em suas necessidades declaradas e implícitas, dentro de um determinado contexto de uso.

Suas sub-características são:

Adequação, que mede o quanto o conjunto de funcionalidades é adequado às necessidades do usuário;
Acurácia (ou precisão) representa a capacidade do software de fornecer resultados precisos ou com a precisão dentro do que foi acordado/solicitado;
Interoperabilidade que trata da maneira como o software interage com outro(s) sistema(s) especificados;
Segurança mede a capacidade do sistema de proteger as informações do usuário e fornecê-las apenas (e sempre) às pessoas autorizadas;

Confiabilidade

O produto se mantém no nível de desempenho nas condições estabelecidas.

Suas sub-características são:

Maturidade, entendida como sendo a capacidade do software em evitar falhas decorrentes de defeitos no software;
Tolerância a Falhas representando a capacidade do software em manter o funcionamento adequado mesmo quando ocorrem defeitos nele ou nas suas interfaces externas;
Recuperabilidade que foca na capacidade de um software se recuperar após uma falha, restabelecendo seus níveis de desempenho e recuperando os seus dados;

Usabilidade

A capacidade do produto de software ser compreendido, seu funcionamento aprendido, ser operado e ser atraente ao usuário.

Note que este conceito é bastante abrangente e se aplica mesmo a programas que não possuem uma interface para o usuário final. Por exemplo, um programa batch executado por uma ferramenta de programação de processos também pode ser avaliado quanto a sua usabilidade, no que diz respeito a ser facilmente compreendido, aprendido, etc. Além disto, a operação de um sistema é uma interface Humano-Computador (ver IHC) sujeita às avaliações de usabilidade.

Suas sub-características são:

Inteligibilidade que representa a facilidade com que o usuário pode compreender as suas funcionalidades e avaliar se o mesmo pode ser usado para satisfazer as suas necessidades específicas;
Apreensibilidade identifica a facilidade de aprendizado do sistema para os seus potenciais usuários;
Operacionalidade é como o produto facilita a sua operação por parte do usuário, incluindo a maneira como ele tolera erros de operação;
Atratividade envolve características que possam atrair um potencial usuário para o sistema, o que pode incluir desde a adequação das informações prestadas para o usuário até os requintes visuais utilizados na sua interface gráfica;

Eficiência

O tempo de execução e os recursos envolvidos são compatíveis com o nível de desempenho do software.

Suas sub-características são:

Comportamento em Relação ao Tempo que avalia se os tempos de resposta (ou de processamento) estão dentro das especificações;
Utilização de Recursos que mede tanto os recursos consumidos quanto a capacidade do sistema em utilizar os recursos disponíveis;

Manutenibilidade

A capacidade (ou facilidade) do produto de software ser modificado, incluindo tanto as melhorias ou extensões de funcionalidade quanto as correções de defeitos, falhas ou erros.

Suas sub-características são:

Analisabilidade identifica a facilidade em se diagnosticar eventuais problemas e identificar as causas das deficiências ou falhas;
Modificabilidade caracteriza a facilidade com que o comportamento do software pode ser modificado;
Estabilidade avalia a capacidade do software de evitar efeitos colaterais decorrentes de modificações introduzidas;
Testabilidade representa a capacidade de se testar o sistema modificado, tanto quanto as novas funcionalidades quanto as não afetadas diretamente pela modificação;

Portabilidade

A capacidade do sistema ser transferido de um ambiente para outro.

Como "ambiente", devemos considerar todo os fatores de adaptação, tais como diferentes condições de infra-estrutura (sistemas operacionais, versões de bancos de dados, etc.), diferentes tipos e recursos de hardware (tal como aproveitar um número maior de processadores ou memória). Além destes, fatores como idioma ou a facilidade para se criar ambientes de testes devem ser considerados como características de portabilidade.

Suas sub-características são:

Adaptabilidade, representando a capacidade do software se a adaptar a diferentes ambientes sem a necessidade de ações adicionais (configurações);
Capacidade para ser Instalado identifica a facilidade com que pode se instalar o sistema em um novo ambiente;
Coexistência mede o quão facilmente um software convive com outros instalados no mesmo ambiente;
Capacidade para Substituir representa a capacidade que o sistema tem de substituir outro sistema especificado, em um contexto de uso e ambiente específicos. Este atributo interage tanto com adaptabilidade quanto com a capacidade para ser instalado;

fonte:wikipedia

Software

 

Melhoria de Processos do Software Brasileiro

| Imprimir | PDF 

O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.

Ele é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro, bem como é compatível com o CMMI.

No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação as normas estrangeiras, sendo ideal para micro, pequenas e médias empresas.

Um dos objetivos do projeto é replicar o modelo na América Latina, incluindo o Chile, Argentina, Costa Rica, Peru e Uruguai.

O projeto tem apoio do Ministério da Ciência e Tecnologia, da FINEP e do Banco Interamericano de Desenvolvimento. No Brasil o projeto é desenvolvido pela Softex, interagindo com as universidades e com o Governo Federal.

Motivação

O Brasil é um país cujo desenvolvimento de produtos de software está entre os maiores do mundo, e a cada dia, aumenta o nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos. A partir deste ponto, podemos observar que as empresas estão buscando cada vez mais a maturidade nos seus processos de software para atingir padronizações de qualidade e produtividade internacionais, que são essenciais para a sobrevivência no mercado de TI.

Porém, o custo de uma certificação para uma empresa pode ser de até US$ 400 mil, o que se torna inviável para empresas de micro, pequeno e médio porte. Então, em uma parceria entre a Softex, Governo e Universidades, surgiu o projeto MPS.Br (melhoria de processo de software brasileiro), que é a solução brasileira compatível com o modelo CMMI, está em conformidade com as normas ISO/IEC 12207 e 15504, além de ser adequado à realidade brasileira.

O modelo

O MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS

MR-MPS (Modelo de referência para melhoria do processo de software)

O MPS.BR apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que são:

A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.

Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento).

Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistos.

AP 1.1 - O processo é executado;
AP 2.1 - O processo é gerenciado;
AP 2.2 - Os produtos de trabalho do processo são gerenciados;
AP 3.1 - O processo é definido;
AP 3.2 - O processo está implementado;
AP 4.1 - O processo é medido;
AP 4.2 - O processo é controlado;
AP 5.1 - O processo é objeto de inovações;
AP 5.2 - O processo é otimizado continuamente.


MA-MPS (Método de avaliação para melhoria do processo de software)

Tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresa e organizações que implementaram o MR-MPS. Avaliação MA-MPS:

Equipe de avaliação: 3 a 8 pessoas, sendo:

1 avaliador líder
no mínimo 1 avaliador adjunto
no mínimo 1 técnico da empresa

Duração: 2 a 4 dias;
Validade: 3 anos;

Estruturação da Avaliação:

Planejar e preparar avaliação

Plano de Avaliação / Descrição dos indicadores de processo;

Conduzir Avaliação

Resultado da avaliação;

Relatar resultados

Relatório da avaliação;

Registrar e publicar resultados

Banco de dados Softex (Ver portal MPS.BR nas 'Ligações Externas')

MPS.BR

MN-MPS (Modelo de negócio para melhoria do processo de software)

Instituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciar através de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase na experiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamento de consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista de consultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinados no modelo e aprovados em prova específica.

Cursos e certificação

A Softex realiza cursos para formação de consultores, compradores e avaliadores MPS.BR. São ao todo 4 cursos:

Curso de Introdução - C1
Curso de Implementação - C2
Curso de Avaliaçao - C3
Curso de Aquisição - C4

Periodicamente, são realizadas provas em nível nacional para certificar profissionais em cada um dos cursos descritos acima. Tanto os cursos e as provas são realizadas nos Agentes SOFTEX em cada estado, por exemplo:

SOFTEX Campinas (SP)
ITS (São Paulo - SP)
FUMSOFT (Belo Horizonte - MG)
RIOSOFT (Rio de Janeiro - RJ)
SOFTSUL (Porto Alegre - RS)
Entre outras


Próximos passos

O modelo MPS.Br tem como objetivo implementar o Modelo de Referência para melhoria de processo de software em 120 empresas. E como objetivos secundários, a disseminação em diversos locais do país, capacitação no uso do modelo e o credenciamento de instituições implementadoras e avaliadoras do modelo, especialmente instituições de ensino e centros tecnológicos e também a implementação e avaliação do modelo com foco em grupos de empresas. A avaliação conjunta de grupos empresariais, objetiva a redução dos custos, porém há uma perda de foco, pois não há uma especificidade para cada empresa e sim um mesmo modelo de referência para todas elas. O MPS.Br já é uma realidade, e dentro de alguns anos, existe um projeto de implantação em seis países da América Latina, são eles: Chile, Argentina, Costa Rica, Peru, Uruguai e Cuba.

fonte:wikipedia

Software

 

CMMI

| Imprimir | PDF 

O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.

O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção.

A versão atual do CMMI (versão 1.3) foi publicada em 27 de outubro de 2010 e apresenta três modelos:

CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e serviços.
CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e terceirização de bens e serviços.
CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de serviços.

Uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de uma empresa".

Histórico

Os processos de melhoria nasceram de estudos realizados por Deming (Out of the Crisis), Crosby (Quality is Free: The Art of Making Quality Certain) e Juran, cujo objetivo principal era a melhoria da capacidade dos processos. Entende-se por capacidade de um processo a habilidade com que este alcança o resultado desejado.

Um modelo tem como objetivo estabelecer - com base em estudos, históricos e conhecimento operacional - um conjunto de "melhores práticas" que devem ser utilizadas para um fim específico.

O CMMI tem como origens em três outros modelos de maturidade - SW-CMM (SEI Software CMM), EIA SECM (Electronic Industries Alliances's Systems Engineer Capability Model) e IPD-CMM (Integrated Product Development CMM).

Dimensões

O CMMI foi construído considerando três dimensões principais: pessoas, ferramentas e procedimentos. O processo serve para unir essas dimensões.

Disciplinas

O processo inclui quatro disciplinas ou corpos de conhecimento (body of knowledges), sendo eles:

Engenharia de sistemas
Engenharia de software
Desenvolvimento integrado de produtos e processos (IPPD - Integrated Product and Process Development)
Fontes de abastecimento (Supplier sourcing)

A engenharia de software é similar à engenharia de sistemas em relação às áreas de processo, apenas com enfoque diferente nos processos. As áreas de processo requeridas para engenharia de sistemas são as mesmas para engenharia de software, mas o nível de maturidade que é diferente.

Representações

O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem à organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representação Continua

Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels):

Nível 0: Incompleto (Ad-hoc)
Nível 1: Executado
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Gerenciado Quantitativamente (Quantitatively managed)
Nível 5: Otimizado (Optimizing)


Nesta representação a capacidade é medida por processos separadamente, onde é possível ter um processo com nível um e outro processo com nível cinco, variando de acordo com os interesses da empresa.

No nível 1(um) o processo é executado de modo a completar o trabalho necessário para produzir o trabalho necessário. No nível 2(dois) é sobre planejar a execução e confrontar o executado contra o que foi planejado. No nível 3(três) o processo é construído sobre as diretrizes do processo existente, e é mantido uma descrição do processo. No nível 4(quatro) é quando o processo é gerenciado quantitativamente através de estatísticas e outras técnicas. No nível 5(cinco) o processo gerido quantitativamente é alterado e adaptado para atender às necessidades negociais/estratégicas da empresa.

A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando já utiliza algum modelo de maturidade contínua ou quando não pretende usar a maturidade alcançada como modelo de comparação com outras empresas.

Representação Por Estágios

Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):

Nível 1: Inicial (Ad-hoc)
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
Nível 5: Em otimização

Nesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos os processos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase todos os processos forem nível três, mas apenas um deles estiver no nível dois a empresa não irá conseguir obter o nível de maturidade três.

Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios, quando deseja utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando pretende usar o nível de conhecimento obtido por outros para sua área de atuação.

Áreas de Processo

O modelo CMMI v1.2 (CMMI-DEV) contém 22 áreas de processo. Em sua representação por estágios, as áreas são divididas da seguinte forma:

Nível 1: Inicial (Ad-hoc)

Não possui áreas de processo.

Nível 2: Gerenciado / Gerido

Gerenciamento de Requisitos - REQM (Requirements Management)
Planejamento de Projeto - PP (Project Planning)
Acompanhamento e Controle de Projeto - PMC (Project Monitoring and Control)
Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement Management)
Medição e Análise - MA (Measurement and Analysis)
Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance)
Gerência de Configuração - CM (Configuration Management)

Nível 3: Definido

Desenvolvimento de Requisitos - RD (Requirements Development)
Solução Técnica - TS (Technical Solution)
Integração de Produto - PI (Product Integration)
Verificação - VER (Verification)
Validação - VAL (Validation)
Foco de Processo Organizacional - OPF (Organizational Process Focus)
Definição de Processo Organizacional - OPD (Organizational Process Definition)
Treinamento Organizacional - OT (Organizational Training)
Gerenciamento Integrado de Projeto - IPM (Integrated Project Management)
Gerenciamento de Riscos - RSKM (Risk Management)
Análise de Decisão e Resolução - DAR (Decision Analysis and Resolution)

Nível 4: Quantitativamente gerenciado / Gerido quantitativamente

Desempenho de Processo Organizacional - OPP (Organizational Process Performance)
Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)

Nível 5: Em otimização

Gestão de Processo Organizacional - OPM (Organizational Process Management)
Análise Causal e Resolução - CAR (Causal Analysis and Resolution)

ISO/IEC 15504

A ISO/IEC_15504, também conhecida como SPICE, define um "processo para relatórios técnicos no assessoramento em desenvolvimento de software", e similarmente ao CMMI possui níveis de maturidade para cada processo. O CMMI não é baseado nesta norma, mas sim compatível.

Histórico de Avaliações

Até o ano de 2002, os EUA tinham realizado 1,5 mil avaliações de CMMI, a Índia feito 153, o Reino Unido 103 e o Brasil apenas 15. Em 2004 a TATA Consultancy Services (empresa indiana) alcançou o nível 5 em todas as unidades da empresa, tendo sido avaliada inclusive a unidade brasileira (a primeira empresa presente no Brasil a receber o nível máximo na avaliação).

Entre abril de 2002 e junho de 2006 foram conduzidas 1581 avaliações em 1377 organizações. Segue abaixo o resultado obtido pelas empresas na avaliação (resultados encaminhados para o SEI até 30 de junho de 2006):

18,2%: nível 5 (Optimizing);
4,4%: nível 4 (Quantitatively Managed);
33,8%: nível 3 (Defined);
33,3%: nível 2 (Managed);
1,9%: nível 1 (Initial);
8,4%: sem qualificação (Not Given).


No Brasil, as empresas listadas a seguir conseguiram a certificação no nível 3:

1997

Xerox do Brasil

2001

DBA Engenharia de Sistemas
EDS S
Ericsson
Motorola

2003

IBM Fábrica de Software
Stefanini

2004

Accenture Delivery Center
CI&T

2005

Accenture
Instituto de Pesquisas Eldorado
Politec

2006

Instituto Atlantico
Qualitas

2007

Atos Origin
C.E.S.A.R – Recife Center
Itaú
TIVIT
Spress Informática S/A
Vetta Technologies

2008

7COMm
B2Br – Business to Business Informática
Kaizen Consultoria e Serviços
Senior Sistemas
Serasa

2009

Accenture Brazil
CINQ Technologies
e-Core
CWI Software Ltda
CPqD
DATUM
CITS – Centro Internacional de Tecnologia de Software
Hold
NTConsult
Synapsis Brasil Ltda
T-Systems do Brasil
Tlantic SI
Triad System
Unisys Corporation
Sofhar Gestão e Tecnologia

2010

BSI Tecnologia
Inovare
Itatec
Resource IT Solutions (Fábrica de Projetos)
Resource IT Solutions (Fábrica de Código)

2011

Chemtech


O nível 4 foi alcançado pelas empresas:

2003

EDS

2006

Ci&T


Já as empresas abaixo conseguiram realizar a certificação até o final, ou seja, alcançaram o nível 5 do CMMI (por ano da certificação):

2004

TCS (TATA Consultancy Services) Brazil

2005

Accenture SP
IBM Brazil
EDS - Electronic Data Systems
Stefanini IT Solutions

2007

Ci&T[1]
CPM Braxis[2]

2009

Instituto Atlântico[3]
BRQ IT Services

2011

Spread Systems [4]

fonte:wikipedia

Software

 

Qualidade de software

| Imprimir | PDF 

A qualidade de software é uma área de conhecimento da engenharia de software que objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente.

Segundo a norma ISO 9000 (versão 2000), a qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para estes.

No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento[1], desta forma, é comum que a busca por um software de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento.

Rodney Brooks, diretor do Laboratório de Inteligência Artificial e Ciência da Computação do MIT, define qualidade como a conformidade aos requisitos. Essa definição exige determinar dois pontos: I) o que se entende por conformidade; e II) como são especificados - e por quem - os requisitos.

Principais tópicos

Para um melhor entendimento e estudo, o SWEBOK divide a qualidade de software em três tópicos, e cada tópico é subdividido em atividades, da seguinte forma:

Fundamentos de qualidade de software
Cultura e ética de engenharia de software
Valores e custos de qualidade
Modelos e características de qualidade
Melhoria da qualidade
Gerência do processo de qualidade de software
Garantia de qualidade de software
Verificação e validação
Revisões e auditorias
Considerações práticas
Requisitos de qualidade para aplicações
Caracterização de defeitos
Técnicas de gerência de qualidade de software
Medidas de qualidade de software

Ainda segundo o SWEBOK, a qualidade de software é um tema tão importante que é encontrado, de forma ubíqua, em todas as outras áreas de conhecimento envolvidas em um projeto. Além disso, ele deixa claro que essa área, como nele definida, trata do aspectos estáticos, ou seja, daqueles que não exigem a execução do software para avaliá-lo, em contraposição á área de conhecimento teste de software.

Porém, é normal que se encontrem autores e empresas que afirmam serem os testes de software uma etapa da qualidade de software.

Muita coisa pode ser encontrada no site http://www.ibqts.com.br O IBQTS, Instituto Brasileiro de Qualidade em Testes de Software

Requisitos de qualidade

Requisitos de qualidade é um tópico por si dentro do assunto qualidade. Dentro da ótica desta última, espera-se que os requisitos sejam definidos de maneira a caracterizar completamente o produto a ser construído. Nesse aspecto - e em relação à definição de Brooks - é evidente que as zonas de sombra dentro de uma especificação abrem margem a todo tipo de problemas de avaliação de produtos.

Sommerville[2] distingue requisitos funcionais e não funcionais. O modelo internacional mais recente Square, estabelecido pela norma ISO 25000, adota uma classificação um pouco diferente e utiliza uma descrição hierárquica. Dentro dessa descrição, "funcionalidade" é uma das seis divisões iniciais em que se classificam os requisitos de um produto de software.

Idealmente, a especificação de requisitos deve permitir que o processo de fabricação do software seja controlado. Isso significa que idealmente a qualidade de produtos intermediários deve poder ser mensurada e que os dados obtidos devem trazer informação que possa levar ao controle de desvios, localização de defeitos e outras ocorrências negativas.

O processo de software

Nas últimas décadas foram propostas dezenas de metodologias e processos adaptados a diferentes cenários e produtos. Embora se possa justificar essa multiplicidade por outra lei de Brooks - a ausência de "balas de prata", é um fato que a situação se mostra confusa.

Há dezenas de trabalhos propostos para casos particulares. Exemplos das diversas iniciativas para tratar o assunto são metodologias como XP e Scrum; o modelo CMM, seguido de toda uma série de adaptações (como SW-CMM, people-CMM, etc.), mais tarde substituído pelo modelo CMMI; e dezenas de artigos e teses de mestrado e doutorado, abordando tópicos particulares em um ou mais de tais métodos, ou propondo ainda novas adaptações a casos particulares.

A situação deixa evidente que há um vácuo a ser preenchido - atacar a raiz do problema e identificar uma estrutura suficientemente geral, capaz de explicar o problema de qualidade e ser adaptada a todos os cenários diferentes. Se tal objetivo é possível resta a ser provado - assunto para novos artigos e teses.

Garantia de qualidade de software

A Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é fornecer aos vários níveis de gerência a adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. A GQS atua como "guardiã", fornecendo um retrato do uso do Processo e não é responsável por executar testes de software ou inspeção em artefatos.

Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro grandes objetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de alta qualidade, ter alta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido junto ao cliente e não necessitar de recursos adicionais não previstos.

Para conseguir esses objetivos a área-chave de processo GQS estimula a atuação das equipes responsáveis pelo desenvolvimento de software em diversas frentes objetivando internalizar comportamentos e ações, podendo-se destacar:

o planejamento do projeto e o acompanhamento de resultados;
o uso dos métodos e ferramentas padronizadas na organização;
a adoção de Revisões Técnicas Formais;
o estabelecimento e a monitoração de estratégias de testes;
a revisão dos artefatos produzidos pelo processo de desenvolvimento;
a busca de conformidade com os padrões de desenvolvimento de software;
a implantação de medições associadas a projeto, processo e produto;
a utilização de mecanismos adequados de armazenamento e recuperação de dados relativos a projetos, processos e produtos; e
a busca de uma melhoria contínua no processo de desenvolvimento de software.

Para facilitar o trabalho dos desenvolvedores e evitar geração de metodologias diversas, o Serpro desenvolveu o Processo Serpro de Desenvolvimento de Soluções (PSDS).

O PSDS foi construído por pessoas das unidades da empresa que procuraram aproveitar as melhores práticas existentes e consagradas.

O "CMM - Capability Maturity Model for Software /SEI" é uma estrutura-"framework", que descreve os principais elementos de um processo de desenvolvimento de software efetivo. O CMM descreve os estágios de maturidade através dos quais Organizações de software evoluem o seu ciclo de desenvolvimento de software através de sua avaliação contínua, identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade: inicial, repetitivo, definido, gerenciado e otimizado.

O Modelo CMM (CMM- Capability Maturity Model) fornece às organizações uma direção sobre como ganhar controle de seu processo de desenvolvimento de software e como evoluir para uma cultura de excelência na gestão de software. O objetivo principal nas transações destes níveis de maturidade é a realização de um processo controlado e mensurado como a fundação para melhoria contínua. Cada nível de maturidade possui um conjunto de práticas de software e gestão específicas, denominado áreas-chave do processo. Estas devem ser implantadas para a organização atingir o nível de maturidade em qualidade de software.

fonte:wikipedia

Software

 

Engenharia de software

| Imprimir | PDF 

Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade.[1]

Atualmente, essas tecnologias e práticas englobam linguagens de programação, banco de dados, ferramentas, plataformas, bibliotecas, padrões, processos e a questão da Qualidade de Software.

Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema de informação Sistema computacional, pois ambos se confundem!

Definição

Friedrich Ludwig Bauer foi o primeiro a defini-la como sendo: "Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais". O próprio significado de engenharia já traz os conceitos de criação, construção, análise, desenvolvimento e manutenção.

A Engenharia de Software se concentra nos aspectos práticos da produção de um sistema de software, enquanto a ciência da computação estuda os fundamentos teóricos dos aspectos computacionais.

O termo foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO Conference on Software Engineering (Conferência sobre Engenharia de Software da OTAN). Sua criação surgiu numa tentativa de contornar a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software complexos. Um sistema de software complexo se caracteriza por um conjunto de componentes abstratos de software (estruturas de dados e algoritmos) encapsulados na forma de procedimentos, funções, módulos, objetos ou agentes e interconectados entre si, compondo a arquitetura do software, que deverão ser executados em sistemas computacionais.

Os fundamentos científicos envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disto, deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento. Empresas desenvolvedoras de software passaram a empregar esses conceitos sobretudo para orientar suas áreas de desenvolvimento, muitas delas organizadas sob a forma de Fábrica de Software.

A Engenharia de Sistemas é uma área mais ampla por tratar de todos os aspectos de sistemas baseados em computadores, incluindo hardware e engenharia de processos além do software.

Áreas de Conhecimento

Segundo o SWEBOK (Corpo de Conhecimento da Engenharia de Software), versão 2004, as áreas de conhecimento da Engenharia de Software são:

Requisitos (Requirements) de Software
Projeto (Design) de Software
Construção (Construction) de Software
Teste (Testing) de Software
Manutenção (Maintenance) de software
Gerência de Configuração de Software
Gerência de Engenharia de Software
Processos de Engenharia de Software
Ferramentas e Métodos de Engenharia de Software
Qualidade (Quality) de Software

Conforme Pressman, a Engenharia de Software (ES) é uma tecnologia em camadas. E a base de todas essas camadas é o foco na qualidade do software desenvolvido. Portanto, inclusive do ponto de vista didático, é interessante estudarmos a ES em suas camadas de Processo, Métodos e Ferramentas.

Processo de Software



Processo de software, ou processo de engenharia de software, é uma seqüência coerente de práticas que objetiva o desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos.

SEE e PSEE são os ambientes voltados ao desenvolvimento e manutenção de processos. O projeto ExPSEE é uma continuação dos estudos de processos, principalmente do ambiente PSEE.

Devido ao uso da palavra projeto em muitos contextos, por questões de clareza, há vezes em que se prefira usar o original em inglês design.

Modelos de Processo de Software

Um modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo, pode ser visto como uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente o progresso do projeto.

Exemplos de alguns modelos de processo de software;

Modelos ciclo de vida
Sequencial ou Cascata (do inglês waterfall) - com fases distintas de especificação, projeto e desenvolvimento.
Desenvolvimento iterativo e incremental - desenvolvimento é iniciado com um subconjunto simples de Requisitos de Software e interativamente alcança evoluções subseqüentes das versões até o sistema todo estar implementado
Evolucional ou Prototipação - especificação, projeto e desenvolvimento de protótipos.
V-Model - Parecido com o modelo cascata, mas com uma organização melhor, que permite que se compare com outros modelos mais modernos.
Espiral - evolução através de vários ciclos completos de especificação, projeto e desenvolvimento.
Componentizado - reuso através de montagem de componentes já existentes.
Formal - implementação a partir de modelo matemático formal.
Ágil
RAD
Quarta geração

É muito importante o desenvolvimento do software.

Modelos de Maturidade

Os modelos de maturidade são um metamodelo de processo. Eles surgiram para avaliar a qualidade dos processos de software aplicados em uma organização (empresa ou instituição). O mais conhecido é o Capability Maturity Model Integration (CMMi), do Software Engineering Institute - SEI.

O CMMi pode ser organizado através de duas formas: Contínua e estagiada. Pelo modelo estagiado, mais tradicional e mantendo compatibilidade com o CMM, uma organização pode ter sua maturidade medida em 5 níveis:

Nível 1 - Caótico;
Nível 2 - Capacidade de repetir sucessos anteriores pelo acompanhamento de custos, cronogramas e funcionalidades;
Nível 3 - O processo de software é bem definido, documentado e padronizado;
Nível 4 - Realiza uma gerência quantitativa do processo de software e do produto;
Nível 5 - Usa a informação quantitativa para melhorar continuamente e gerenciar o processo de software.

O CMMi é um modelo de maturidade recentemente criado com o fim de agrupar as diferentes formas de utilização que foram dadas ao seu predecessor, o CMM.

O (MPS.BR), ou Melhoria de Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.

Metodologias e Métodos

O termo metodologia é bastante controverso nas ciências em geral e na Engenharia de Software em particular. Muitos autores parecem tratar metodologia e método como sinônimos, porém seria mais adequado dizer que uma metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas diferenciadas para realizar algo.[2]

Assim teríamos, por exemplo, a Metodologia Estruturada, na qual existem vários métodos, como Análise Estruturada e Projeto Estruturado (muitas vezes denominados SA/SD, e Análise Essencial). Tanto a Análise Estruturada quanto a Análise Essencial utilizam a ferramenta Diagrama de Fluxos de Dados para modelar o funcionamento do sistema.

Metodologia Estruturada
Análise Estruturada
Projeto Estruturado
Programação Estruturada
Análise Essencial
SADT
DFD - Diagrama de Fluxo de Dados
MER - Modelo de Entidades e Relacionamentos
Metodologia Orientada a Objetos
Orientação a Objetos
Rational Unified Process ( RUP )
Desenvolvimento ágil de software
Feature Driven Development ( FDD )
Enterprise Unified Process (EUP)
Scrum (Scrum)
Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web)
Programação extrema ( XP )
Outras Metodologias
Microsoft Solution Framework ( MSF )
Modelagem

A abstração do sistema de software através de modelos que o descrevem é um poderoso instrumento para o entendimento e comunicação do produto final que será desenvolvido.

A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre simplicidade (favorecendo a comunicação) e a complexidade (favorecendo a precisão) do modelo.

Para a modelagem podemos citar 3 métodos:

Análise estruturada, criada por Gane & Searson;
Análise Essencial, criada por Palmer & McMenamin e Ed. Yourdon;
UML criada por Grady Booch, Ivar Jacobson & Jaimes Rumbaugh (veja exemplos).

Atualmente a modelagem mais recomendada, e sendo a mais comum, é a utilização da linguagem UML.

Ferramentas, Tecnologias e Práticas

A engenharia de software aborda uma série de práticas e tecnologias, principalmente estudadas pela ciência da computação, enfocando seu impacto na produtividade e qualidade de software.

Destacam-se o estudo de linguagem de programação, banco de dados e paradigmas de programação, como:

Programação estruturada
Programação funcional
Programação orientada a objetos
Componentes de Software
Programação orientada a aspecto
Ferramentas

Outro ponto importante é o uso de ferramentas CASE (do inglês Computer-Aided Software Engineering). Essa classificação abrange toda ferramenta baseada em computadores que auxiliam atividades de engenharia de software, desde a análise de requisitos e modelagem até programação e testes.

Os ambientes de desenvolvimento integrado (IDEs) têm maior destaque e suportam, entre outras coisas:

Editor
Compilador
Debug
Geração de código
Modelagem
Deploy
Testes não automatizados
Testes automatizados
Refatoração (Refatoring)
Gestão de Riscos nos projectos de Software
Uso da Prototipagem na Eng. de Requisitos
Gerência de Projetos

A gerência de projetos se preocupa em entregar o sistema de software no prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitações de orçamento e tempo.

A gerência de projetos de software se caracteriza por tratar sobre um produto intangível, muito flexível e com processo de desenvolvimento com baixa padronização.

Planejamento

O planejamento de um projeto de desenvolvimento de software inclui:

Análise Econômica de Sistemas de Informações
organização do projeto (incluindo equipes e responsabilidades)
estruturação das tarefas (do inglês WBS - work breakdown structure)
cronograma do projeto (do inglês project schedule)
análise e gestão de risco
estimativa de custos

Essas atividades sofrem com dificuldades típicas de desenvolvimento de software. A produtividade não é linear em relação ao tamanho da equipe e o aumento de produtividade não é imediato devido aos custos de aprendizado de novos membros. A diminuição de qualidade para acelerar o desenvolvimento constantemente prejudica futuramente a produtividade.

A estimativa de dificuldades e custos de desenvolvimentos são muito difíceis, além do surgimento de problemas técnicos. Esses fatores requerem uma análise de riscos cuidadosa.

Além da própria identificação dos riscos, há que ter em conta a sua gestão. Seja evitando, seja resolvendo, os riscos necessitam ser identificados (estimando o seu impacto) e devem ser criados planos para resolução de problemas.

Análise de Requisitos

As atividades de análise concentram-se na identificação, especificação e descrição dos requisitos do sistema de software. Em resumo, requisito é uma necessidade que o software deve cumprir.

Há várias interpretações e classificações sobre requisitos, entre elas:

funcional
não funcional
de usuário
de sistema

É comum que o cliente não saiba o que ele realmente deseja, que haja problemas na comunicação e ainda que haja mudança constante de requisitos. Todos esses fatores são recrudescidos pela intangibilidade sobre características de sistemas de software, principalmente sobre o custo de cada requisito.

Estudo de Viabilidade (Levantamento de Requisitos)

A Engenharia de requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos de sistema (SOMMERVILLE). Segundo RUMBAUGH, alguns analistas consideram a engenharia de Requisitos como um processo de aplicação de um método estrutura como a analise orientada a objetos. No entanto, a Engenharia de requisitos possui muito mais aspectos do que os que estão abordados por esses métodos.

Abaixo um pequeno Processo de Engenharia de Requisitos (SOMMERVILLE).

Estudo da viabilidade → "Relatório de Viabilidade" Obtenção e Analise de Requisitos → "Modelos de Sistema" Especificação de Requisitos → "Requisitos de Usuário e de Sistema" Validação de Requisitos → "Documento de Requisitos"

O primeiro processo a ser realizado num Sistema novo é o Estudo de Viabilidade. Os resultados deste processo devem ser um relatório com as recomendações da viabilidade técnica ou não da continuidade no desenvolvimento do Sistema proposto. Basicamente um estudo de viabilidade, embora seja normalmente rápido, deverá abordar fundamentalmente as seguintes questões:

O Sistema proposto contribui para os objetivos gerais da organização? O Sistema poderá ser implementado com as tecnologias dominadas pela equipe dentro das restrições de custo e de prazo? Ou precisa de treinamentos adicionais? O Sistema pode ser integrado, e é compatível com os outros sistemas já em operação?

Gestão

Pessoal
Produto
Processo
Projeto
Material
Histórico

A Engenharia de Software (ES) surgiu em meados dos anos 1970 numa tentativa de contornar a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software complexos. Um sistema de software complexo se caracteriza por um conjunto de componentes abstratos de software (estruturas de dados e algoritmos) encapsulados na forma de procedimentos, funções, módulos, objetos ou agentes interconectados entre si, compondo a arquitetura do software, que deverão ser executados em sistemas computacionais.

ES no Presente e Tendências

Atualmente existe um destaque todo especial para a Engenharia de Software na Web. Também utilizado por Presmann a sigla WebE, é o processo usado para criar WebApps (aplicações baseadas na Web) de alta qualidade. Embora os princípios básicos da WebE sejam muito próximos da Engenharia de Software clássica, existem peculiaridades específicas e próprias.

Com o advento do B2B (e-business) e do B2C (e-commerce), e ainda mais com aplicações para a Web 2.0, maior importância ficou sendo esse tipo de engenharia. Normalmente adotam no desenvolvimento a arquitetura MVC (Model-View-Controller).

Outra área de tendência em Engenharia de Software trata da aplicação de técnicas otimização matemática para a resolução de diversos problemas da área. A área, denominada Search-based software engineering, ou Otimização em engenharia de software em Português, apresenta vários resultados interessantes.[3] Para mais detalhes em Português, ver texto com aplicações da otimização em engenharia de software.[4]


Origem:Wikipédia

Software

 

Desenvolvimento de software

| Imprimir | PDF 

Na computação, o desenvolvimento de software é o ato de elaborar e implementar um sistema computacional, isto é, transformar a necessidade de um utilizador ou de um mercado em um produto de software[1]. Também é entendido como a aplicação dos processos da engenharia de software combinados com a pesquisa das necessidades do produto para desenvolver software.

É difícil avaliar se a engenharia (de software) ou o Marketing é o maior responsável pelo sucesso ou falha de um produto de software para satisfazer as expectativas do consumidor. Por isso é importante entender tanto os processos quanto as facilidades de colaboração entre a engenharia e o marketing em todo o processo de desenvolvimento.

Software development (also known as application development, software design, designing software, software application development, enterprise application development, or platform development[1]) is the development of a software product. The term "software development" may be used to refer to the activity of computer programming, which is the process of writing and maintaining the source code, but in a broader sense of the term it includes all that is involved between the conception of the desired software through to the final manifestation of the software, ideally in a planned and structured process.[2] Therefore, software development may include research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.[3]

Software can be developed for a variety of purposes, the three most common being to meet specific needs of a specific client/business (the case with custom software), to meet a perceived need of some set of potential users (the case with commercial and open source software), or for personal use (e.g. a scientist may write software to automate a mundane task). Embedded software development, that is, the development of embedded software such as used for controlling consumer products, requires the development process to be integrated with the development of the controlled physical product.

The need for better quality control of the software development process has given rise to the discipline of software engineering, which aims to apply the systematic approach exemplified in the engineering paradigm to the process of software development.

There are several different approaches to software development, much like the various views of political parties toward governing a country. Some take a more structured, engineering-based approach to developing business solutions, whereas others may take a more incremental approach, where software evolves as it is developed piece-by-piece. Most methodologies share some combination of the following stages of software development:

Market research
Gathering requirements for the proposed business solution
Analyzing the problem
Devising a plan or design for the software-based solution
Implementation (coding) of the software
Testing the software
Deployment
Maintenance and bug fixing

These stages are often referred to collectively as the software development lifecycle, or SDLC. Different approaches to software development may carry out these stages in different orders, or devote more or less time to different stages. The level of detail of the documentation produced at each stage of software development may also vary. These stages may also be carried out in turn (a “waterfall” based approach), or they may be repeated over various cycles or iterations (a more "extreme" approach). The more extreme approach usually involves less time spent on planning and documentation, and more time spent on coding and development of automated tests. More “extreme” approaches also promote continuous testing throughout the development lifecycle, as well as having a working (or bug-free) product at all times. More structured or “waterfall” based approaches attempt to assess the majority of risks and develop a detailed plan for the software before implementation (coding) begins, and avoid significant design changes and re-coding in later stages of the software development lifecycle.

There are significant advantages and disadvantages to the various methodologies, and the best approach to solving a problem using software will often depend on the type of problem. If the problem is well understood and a solution can be effectively planned out ahead of time, the more "waterfall" based approach may work the best. If, on the other hand, the problem is unique (at least to the development team) and the structure of the software solution cannot be easily envisioned, then a more "extreme" incremental approach may work best. A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

Consistency in Software

In order to ensure that software can evolve in a way that maintains its inherent multidimensionality, one must ensure that the different dimensions evolve together in a consistent manner. Software has too many dimensions to combine within a single framework. A good mechanism should not be geared to a specific problem such as ensuring the consistency of a UML class diagram with the source code. Instead it should be flexible enough to handle the broad range of dimensioins that are actually involved in software development

Software development topic

Marketing
The sources of ideas for software products are legion.[5] These ideas can come from market research including the demographics of potential new customers, existing customers, sales prospects who rejected the product, other internal software development staff, or a creative third party. Ideas for software products are usually first evaluated by marketing personnel for economic feasibility, for fit with existing channels distribution, for possible effects on existing product lines, required features, and for fit with the company's marketing objectives. In a marketing evaluation phase, the cost and time assumptions become evaluated. A decision is reached early in the first phase as to whether, based on the more detailed information generated by the marketing and development staff, the project should be pursued further. Pranay.[5]

In the book "Great Software Debates", Alan M. Davis states in the chapter "Requirements", subchapter "The Missing Piece of Software Development"

Students of engineering learn engineering and are rarely exposed to finance or marketing. Students of marketing learn marketing and are rarely exposed to finance or engineering. Most of us become specialists in just one area. To complicate matters, few of us meet interdisciplinary people in the workforce, so there are few roles to mimic. Yet, software product planning is critical to the development success and absolutely requires knowledge of multiple disciplines.

Because software development may involve compromising or going beyond what is required by the client, a software development project may stray into less technical concerns such as human resources, risk management, intellectual property, budgeting, crisis management, etc. These processes may also cause the role of business development to overlap with software development.

Software development methodology

A software development methodology is a framework that is used to structure, plan, and control the process of developing information systems. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

wikipedia

Software

 

MAIS INFORMAÇÕES DO SETOR DE SOFTWARE

Rede de computadores

article thumbnail

A Wikipédia possui o portal:
Portal das tecnologias de informação Uma rede de comp [ ... ]


Leia mais
Symfony

article thumbnail

Symfony

Projeto padrão do Symfony Desenvolvedor Sensio Labs Versão está [ ... ]


Leia mais
Steve Jobs

article thumbnail

Steve Jobs Steve Jobs apresentando um iPhone 4 durante a Apple Worldwide Develo [ ... ]


Leia mais
Orientação a objetos

A orientação a objetos é um paradigma de análise, projeto e programação de sistemas de softwar [ ... ]


Leia mais
dotProject

Software Livre - dotProject
dotProject Desenvolvedor Adam Donnison, Karen Chisholm, Gregor Er [ ... ]


Leia mais
Larry Page

article thumbnail

Lawrence Edward Page Larry Page Nascimento 26 de Março de 1973 (38 anos) [ ... ]


Leia mais
Segurança da informação

article thumbnail

A Wikipédia possui o portal:
Portal das tecnologias de informação A segurança da  [ ... ]


Leia mais
Modelagem de dados

Modelagem de Dados Representa um conjunto de requerimentos de informações de negócio. É uma part [ ... ]


Leia mais
Sistemas de CRM

Os sistemas de CRM.. são aplicativos de informação desenvolvidos com o objetivo de auxiliar na ge [ ... ]


Leia mais
Framework

Um framework, ou arcabouço, em desenvolvimento de software, é uma abstração que une códigos c [ ... ]


Leia mais
Struts framework

Struts é um framework de desenvolvimento da camada controladora, numa estrutura seguindo o padrã [ ... ]


Leia mais
Gestão do conhecimento

article thumbnail

A definição clássica de conhecimento. A Gestão do Conhecimento, do inglês KM - Knowled [ ... ]


Leia mais
Desktop

Desktop, expressão inglesa oriunda de desktop publisher (editor de textos de mesa). São os computa [ ... ]


Leia mais
Modelo em espiral

O Modelo em espiral é um processo de desenvolvimento de software que combina elementos de projeto [ ... ]


Leia mais
Computação em nuvem

article thumbnail

A nuvem (cloud) é o símbolo da Internet. O conceito de computação em nuvem (em inglê [ ... ]


Leia mais
Rede complexa

Rede Complexa é uma forma de modelar a natureza onde as propriedades de um elemento são resumidas [ ... ]


Leia mais
JBuilder

JBuilder, é uma IDE para desenvolvimento de aplicações na tecnologia Java criada pela Borland e [ ... ]


Leia mais
Software livre nos governos

Nos últimos anos a questão do software livre nos governos está na ordem do dia. Alguns governos c [ ... ]


Leia mais
Eclipse

article thumbnail


Eclipse é um IDE desenvolvido em Java, seguindo o modelo open source de desenvolvimento de softw [ ... ]


Leia mais
Algoritmos

article thumbnail

Um algoritmo é uma sequência finita de instruções bem definidas e não ambíguas, cada uma das q [ ... ]


Leia mais
UML

article thumbnail

A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira gera [ ... ]


Leia mais
Microsoft SharePoint Workspace

article thumbnail

Título a ser usado para criar uma ligação interna é Microsoft SharePoint Workspace. Micr [ ... ]


Leia mais
E-learning


O e-learning, ou ensino eletrónico, corresponde a um modelo de ensino não presencial suportado  [ ... ]


Leia mais
NetBeans

NetBeans Desenvolvedor Oracle Corporation Plataforma x86 e x64 Lançado em  [ ... ]


Leia mais
Antivírus

article thumbnail

Os antivírus são programas de computador concebidos para prevenir, detectar e eliminar vírus de [ ... ]


Leia mais
Gerenciamento de nível de serviços

Gerenciamento de nível de serviços é uma disciplina de gestão responsável pelo processo gerenci [ ... ]


Leia mais
Ferramenta CASE

Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abran [ ... ]


Leia mais
ISO/IEC 9126

article thumbnail

ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, que se enquadra no modelo de qu [ ... ]


Leia mais
CobiT

Origem: Wikipédia, a enciclopédia livre. COBIT®, do inglês, Control Objectives for Information  [ ... ]


Leia mais
Firewall

article thumbnail

Firewall separando redes LAN e WAN A Wikipédia possui o portal:
Portal das tecno [ ... ]


Leia mais
APPS

article thumbnail

Apps (do inglês application) é uma forma abreviada para software aplicativo. A extensão .app si [ ... ]


Leia mais
Business Intelligence - Inteligência empresarial

Inteligência empresarial (em inglês Business Intelligence), refere-se ao processo de coleta, orga [ ... ]


Leia mais
CMMI

O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Ge [ ... ]


Leia mais
BackTrack

article thumbnail

Backtrack

Backtrack 5 Desenvolvedor Max Moser, Mati Aharoni, Martin J. Muench  [ ... ]


Leia mais
Hacker

article thumbnail


Originalmente, e para certos programadores, hackers (singular: hacker) são indivíduos que elabo [ ... ]


Leia mais
Seis Sigma

article thumbnail

Símbolo comumente usado do Seis Sigma
Seis Sigma ou Six Sigma (em inglês) é um conjunto [ ... ]


Leia mais
Outsourcing

 Outsourcing (em inglês, "Out" significa "fora" e "source" ou "sourcing" significa fonte)  [ ... ]


Leia mais
Miniaturização

Miniaturização é o processo de produção de objetos de consumo cada vez menores (miniaturas), in [ ... ]


Leia mais
Software

article thumbnail


OpenOffice.org Writer. Software, logiciário ou suporte lógico é uma sequência de in [ ... ]


Leia mais
Web 2.0

article thumbnail

Web 2.0 é um termo criado em 2004 pela empresa americana O'Reilly Media[1] para designar uma segu [ ... ]


Leia mais
Parque Tecnologico Capital Digital (Cidade Digital)

Toda a informação será disponibilizada através do site da secretaria de Ciência e Tecnologia do [ ... ]


Leia mais
Gestão de riscos em TI

A Gestão de riscos (termo também conhecido como Risk Management) é um processo/disciplina util [ ... ]


Leia mais
Banco de dados

article thumbnail

Bancos de dados, ou bases de dados (em Portugal), são coleções de informações que se relacion [ ... ]


Leia mais
Trac

Trac é uma simples ferramenta, open source e de interface web para controle de mudanças em pro [ ... ]


Leia mais
Sharepoint

Plataforma de colaboraçãoO Windows Sharepoint Services (WSS) é uma plataforma de colaboração vo [ ... ]


Leia mais
Smartphone

article thumbnail

Galaxy Nexus, exemplo de Smartphone. Nokia Communicator 9000, 9110, 9210, 9500  [ ... ]


Leia mais
Paradigmas de programação

Um paradigma de programação fornece e determina a visão que o programador possui sobre a estrut [ ... ]


Leia mais
Inteligência organizacional

Inteligência Organizacional é a capacidade coletiva disponível em uma organização para identifi [ ... ]


Leia mais
Qualidade de software

A qualidade de software é uma área de conhecimento da engenharia de software que objetiva garant [ ... ]


Leia mais
Zend Framework

article thumbnail

Zend Framework Logotipo do Zend Framework Desenvolvedor Zend Tech [ ... ]


Leia mais
Artigos Relacionados

Pluriverso - Inteligência em Tecnologia

Pluriverso - Inteligência em Tecnologia


Ed.Centro Sul, 2°Andar, SCIA, Qd. 14, Conj. 07, Lt 1, S. Ind.
CEP: 71.250-135, Brasília-DF.  
Como Chegar | Atendimento  


+55 (61) 4141.5555

Serviços

Desenvolvimento de Software
Oursourcing de T.I
Consultoria em Tecnologia
Licitação com o Governo

Produtos

ERP, CRM, Colaboração
Cloud Computing

Soluções
Soluções em Outsourcing de Tecnologia
Integração de Software
Avaliação de nível tecnológico
Cálculo de custos de T.I
Softwares customizados


Porque escolher a Pluriverso

Blog Corporativo
Blog do Software

Conheça a Pluriverso
quem somos
verticais de atuação
portifólio
casos de sucesso

Atendimento
contatos
sala de imprensa
como chegar
Trabalhe conosco

desenvolvimento de software