Gestão de demandas

2011-01-13T02:05:00.000-03:00

O Governo Federal pode ser considerado como uma grande empresa. Assim como uma empresa privada necessita de controles, gestão, gerência e diretorias, o Governo não é diferente. Dessa forma, quando estamos trabalhando com processos, o Governo pode ser uma boa fonte de consulta. Devido ao seu tamanho e sua complexidade, o Governo pode já ter implementado e estudado um processo que você pode estar procurando conhecer melhor.

Pesquisando o site o do Ministério do Planejamento (www.planejamento.gov.br) você pode encontrar não somente informações sobre o Ministério e suas ações, mas como também, se beneficiar das informações relacionadas a planejamento, gestão estratégica e até softwares gratuitos desenvolvidos para atender as necessidades do mais variadas setores do Governo (www.softwarepublico.gov.br).

Pesquisando a parte de softwares, dois projetos me chamaram a atenção. O primeiro é o SGD – Sistema de Gestão de Demandas (http://www.softwarepublico.gov.br/ver-comunidade?community_id=51261), e o segundo é o OASIS – Sistema de Gestão de Projetos, Demandas, e Serviços de Tecnologia da Informação (http://www.softwarepublico.gov.br/ver-comunidade?community_id=8566986).

O SGD foi desenvolvido especialmente para atender as necessidades da TI, onde segundo o site do projeto explica que a função principal do sistema é transformar as demandas internas em projetos que são controlados pelo escritório de projetos, melhorando consequentemente a qualidade do atendimento do serviço publico.

O software é destinado não somente para os órgãos públicos, mas inclusive para empresas que desejam controlar suas demandas. Não vou explicar aqui o funcionamento do software, mas sim, o seu embasamento ideológico.

O sistema é baseado em dois conceitos muito atuais: Processos internos transformados pela tecnologia e o Processo de Gestão do Conhecimento. É notório que em vários setores, tanto privados quanto públicos, os processos foram transformados ou remodelados pela tecnologia. O que era manual, lento e sujeito a falhas humanas, foi adaptado para um processo, eletrônico, ágil e com menor incidência de falhas. É evidente também que o conhecimento passou a ser peça fundamental em qualquer trabalho ou ação a ser realizada. Gerenciar esse conhecimento, de modo que ele possa ser propagado, compartilhado, distribuído e aprimorado é essencial para a continuidade de qualquer negócio, trabalho ou projeto.

A gestão de demanda tem a função de coordenar, controlar todos os fatores de demanda, de forma que o sistema produtivo possa ser eficientemente utilizado e as datas de entregas dos produtos possam ser pontualmente atendidas.

Conforme a figura acima as demandas podem variar de tipo através de 4 fatores:

Tamanho (pequena, média ou grande)
Complexidade (baixa, média ou alta)
Classificação (corretiva, melhoria ou novidade)
Prioridade (baixa, média ou alta)

A combinação desses valores resulta em 81 possibilidades de combinações.

A análise de demandas oferece vários benefícios.

Curto prazo

Auxilia no dimensionamento de recursos necessários a produção: equipamentos, mão de obra e matéria prima.

Longo Prazo

Serve de base para decisões estratégicas, tais como: criação de novos produtos, ampliação da instalação.

A análise de demandas são divididas em 9 macro processos:

Prever a demanda
Comunicar com o mercado
Influenciar a demanda
Prometer prazo de entrega
Priorizar e alocar as demandas
Registrar os pedidos de clientes
Planejar nível de serviços de clientes
Planejar entregas
Controlar os indicadores de desempenho do processo

Assim podemos concluir que um sistema de gestão de demandas busca basicamente otimizar o atendimentos das solicitações de forma eficiente e transparente e controlar o fluxo das atividades desenvolvidas pelo executor.

No próximo post irei discutir mais sobre a gestão de demandas. Até mais!

Versionamento de Software

2009-09-10T16:49:00.000-04:00

Versionamento de software é o processo onde atribui nomes de versão ou números de versão, sendo estes únicos, para estados de um software.

Existe uma determinada categoria de números de versão (maior, menor), esses números são definidos em ordem crescente e correspondem a uma nova alteração no desenvolvimento do software. Em um nível mais detalhado, o controle de revisão é usado para rastrear o progresso das versões de uma informação eletrônica, sendo ela um software ou não.

Esquemas de versionamento de softwares

Vários esquemas de numeração de versão têm sido criados para rastrear as diferentes versões de uma parte do software. Esses esquemas são usados não somente para softwares, mas também em outros contextos fora da computação.

Identificador baseado em sequência

No esquema de versionamento de software baseado em sequência, a cada release do software é atribuído um identificador único que consiste em uma ou mais sequências de números e letras. Essa é o padrão, entretanto, os esquemas podem variar em várias formas tais como: na quantidade de sequências, na definição da importância com relação às diferentes sequências e na forma de incrementar as sequências.

Variação de importância

Em alguns sistemas, os identificadores baseados em sequência são utilizados para repassar a importância das alterações entre os releases: As alterações são classificadas por nível de importância do release, dessa forma a decisão de qual sequência utilizar entre as liberações é baseada na importância das alterações com relação à importância da liberação anterior, onde a primeira sequência será modificada para as mudanças mais importantes, e as mudanças após a primeira sequência representam mudanças com importância menor.

Por exemplo, em um esquema que se utiliza uma sequência com 4 identificadores, a primeira sequência só pode ser incrementada quando o código é totalmente reescrito, enquanto uma mudança de interface do usuário ou da documentação justifica a alteração apenas da quarta sequência.

Essa prática permite aos usuários (ou usuários em potencial) avaliar em um teste real o nível da alteração que um software sofreu. Se as alterações são feitas entre, digamos 1.3rc4 e o release de produção 1.3, então com relação aquele release, podemos afirmar que teve uma produção específica para testes reais de nível qualidade e que essas alterações, de fato, não têm necessidade de serem testadas por todos os integrantes do mundo real.

Esse tipo de alteração abrange normalmente o terceiro nível de numeração (“mudanças”), mas não se aplica esse nível de rigor para que as alterações recebam o número: 1.3.1, 1.3.2, 1.3.3, 1.3.4 ... 1.4b1, etc. 1.4b1, etc.

Em princípio o maior número é aumentado quando há saltos significativos de funcionalidade, o menor número é incrementado apenas quando pequenas funcionalidades ou correções significativas são adicionadas e o número da revisão é incrementado quando pequenos bugs são corrigidos.

Um produto típico poderia utilizar os números 0.9 (para a versão beta do software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0. 2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Desenvolvedores têm por vezes que saltar da versão 5.0 para a versão 5.5 para indicar que foram adicionadas funcionalidades importantes que não justificam o incremento da versão principal, que seria abusiva.

Uma abordagem diferente é utilizar os maiores e menores números juntamente com uma sequência alfanumérica denotando o tipo da liberação, tais como: alfa, beta ou candidata a liberação oficial (release candidate, rc). As sucessões de liberações poderiam ser semelhantes a: 0.5, 0.6, 0.7, 0.8, 0.9, == 1.0b1, 1.0b2 (com algumas correções), 1.0b3 (com mais correções) == 1.0rc1 (caso for considerada estável) == 1.0. Se encontrar erros em 1.0rc1 que precisam ser corrigidos ele se transformará em 1.0rc2, e assim por diante. A característica importante dessa abordagem é que a primeira versão de um determinado nível (beta, rc ou release) deve ser idêntica a da última versão do release abaixo dela: você não pode realizar qualquer alteração a partir da última versão beta para primeiro RC ou a partir do último RC para a produção. Se fizer isso, deverá passar outro release para um nível inferior.

No entanto, desde que as versões sejam geradas por humanos, e não por computador, não há nada que impeça alterações arbitrárias que impeçam essas regras: por exemplo, a primeira sequência poderia ser incrementada entre as versões de se diferem nem se quer por uma única linha de código, para dar uma (falsa) impressão que alterações muito significativas foram realizadas.

Outros esquemas repassam importância em sequências individuais:

maior.menor [. Build [. revision]] ou major.minor[.maintenance[.build]].

Mais uma vez, neste exemplo, o que constitui uma alteração importante de uma alteração menos importante é totalmente arbitrária e é o autor que define o que é uma build, ou como uma revisão (revision) se difere de uma pequena alteração.
Na maioria dos softwares proprietários, a primeira versão liberada de um produto é a versão 1.

Definindo estágio de desenvolvimento

Alguns esquemas utilizam fazem uso de um zero na primeira sequência para designar os status de liberação alfa ou beta, onde não são totalmente estáveis para uso geral, práticas de implantação, e são destinados para testes ou uso interno.

Pode ser usado na terceira posição:

•    0 para o estado alfa
•    1 para o estado beta
•    2 para candidato a liberação (release candidate)
•    3 para a liberação pública (public release).

Por exemplo:

•    1.2.0.1 ao invés de 1.2-a
•    1.2.1.2 ao invés de 1.2-b2 (beta com alguns bugs corrigidos)
•    1.2.2.3 ao invés de 1.2-rc
•    1.2.3.0 ao invés de 1.2-r (distribuição comercial)
•    1.2.3.5 ao invés de 1.2-r5 (distribuição comercial com correção de vários bugs)

Separando sequências

Quando impressas, as sequências podem ser separadas com caracteres. A escolha dos caracteres e sua utilização variam de acordo com o esquema. A lista seguinte exibe exemplos hipotéticos que esquemas de separação para a mesma liberação (release) (O 13º do terceiro nível da revisão para o 4º do segundo nível da revisão para o 2º do primeiro nível da revisão):

•    Um esquema pode usar o mesmo caractere para todas as sequências: 2.4.13, 2/4/13, 2-4-13
•    A escolha do esquema de sequência de separações pode ser inconsistente, separando algumas sequências e outras não: 2.413
•    A escolha do esquema de caracteres pode ser inconsistente dentro de um mesmo identificador 2.4_13

Quando um ponto é usado para separar as sequências, ele não pode ser representado como um ponto decimal, e as sequências não têm posição significativa. Um identificador 2.5, por exemplo, não é “2 e meio” ou “metade da versão 3”, é o 5º do segundo nível da revisão do 2º do primeiro nível da revisão e não seria adequando ao menos que existisse um 2.1, 2.2, 2.3 e 2.4.

Número de sequências

Existem às vezes 4 números não publicados que indicam a build do software (utilizado pela Microsoft). Algumas empresas incluem ainda a data de realização da build. Versões numeradas podem conter letras e outros caracteres, por exemplo, Lotus 1-2-3 Release 1a.

Incrementando sequências

Existem duas escolas de pensamento de como os números da versão são incrementados: Muitos pacotes de software livre tratam os números da versão como um fluxo contínuo, pois um software livre pode ter números de versão 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, etc. Um exemplo é o pacote de software do MediaWiki. No entanto, muitos programas tratam o número de versão de outro modo, eles podem ter números de versão como: 1.8, 1.9, 1.9.1, 1.9.2, etc. Nos pacotes de software que utilizam essa forma de numeração 1.91 é a próxima menor versão depois de 1.9. Releases de manutenção, isto é, correções de bugs, geralmente seriam denominadas como: 1.91a, 1.91b, etc.

Utilizando números negativos

Existem alguns projetos que usam números negativos na versão. Um exemplo é o compilador Smalleiffel que começou a partir de -1.0 e contadas de 0.0 em diante.

Grau de compatibilidade

Alguns projetos utilizam o número maior da versão para indicar releases incompatíveis. Dois exemplos são: Apache TAEG e do FarCry CMS.

Data

O projeto Wine utilizou um esquema de versionamento baseado em datas, nos utiliza o ano, seguido do mês, seguido do dia do lançamento, por exemplo, “Wine 20040505”. O Wine segue atualmente um padrão de liberação por faixa, a versão mais atual a partir de 6 de Junho de 2008 é 1.0-rc4. O Linux Unbutu utiliza um esquema semelhante, Unbutu 8.10, por exemplo, foi liberado em Outubro de 2008.

Ao utilizar datas em versões, por exemplo, nome de arquivo, é comum utilizar o esquema ISO YYYY-MM-DD, pois essa string é facilmente ordenada em ordem crescente e decrescente. Os hífens são geralmente omitidos.

Ano de lançamento

Outros exemplos, identificando versões por ano (Adobe Illusrator 88, Word Perfect Office 2003). Embora quando a data é utilizada para identificar a versão é geralmente para fins de marketing e existe um numero de versão real. Por exemplo, o Microsoft Windows 2000 Server é versionado internamente como NT 5.0. (“NT” é uma referência para o nome original do produto).

Códigos Alfanuméricos

Exemplos:

• Macromedia Flash MX
• Adobe Photoshop CS2

Info Praeiro

Gestão de demandas

Versionamento de Software