O ciclo de vida dos sistemas ERP pode ser dividido em 3 etapas: seleção, implementação e utilização.

A Seleção:

A seleção de um sistema ERP analisa a decisão de escolha do sistema sob a compatibilidade entre as necessidades da organização e as características do sistema (ressaltando a necessidade de avaliar a adequação entre a estratégia empresarial e a maneira de fazer negócios que estes sistemas impõem). Se a empresa apressar-se em instalar um ERP sem ter total entendimento de suas implicações no negócio, o resultado da integração pode ser um grande problema.

Alguns fatores que influenciam na seleção de um ERP: suporte aos processos de negócio da empresa, adequação às exigências legais e condições do país onde será implantado (como moeda, idioma, etc.), facilidades para integração, flexibilidade, tecnologia necessária, maturidade (estabilidade do sistema), suporte local, entre outros.

A Implementação:

A implementação de um sistema ERP pode ser definida como o processo pelo qual os módulos do sistema são colocados em funcionamento em uma empresa.

A implementação de sistemas ERP tem sido tratada como um projeto na maioria das empresas, isto é, tem início, meio e fim. Para obter os benefícios desejados dos sistemas ERP é preciso encará-los dessa maneira, e tomar as medidas gerenciais necessárias, tais como alocação de recursos para um centro permanente de adaptação do sistema ERP às novas necessidades.

A Utilização:

Após o processo de implementação, a utilização do sistema passa a fazer parte das operações da empresa. É durante a utilização do sistema que todas as possibilidades são realmente conhecidas. Normalmente descobrimos novas alternativas, que possivelmente serão atendidas por outros módulos ou com “condições de contorno”, isto é, parâmetros já estabelecidos e em uso que somente poderão ser alterados mediante mudança nos procedimentos operacionais da empresa.

Fontes utilizadas neste post:

– SOUZA, C. A,  ZWICKER. Ciclo de Vida de Sistemas ERP. Caderno de Pesquisas em administração ;
- DAVENPORT, T.H. Putting into the enterprise system. Harvard Business Review;
- TONINI, Carlos A. Sistemas ERP no Brasil: teoria e casos.

Há alguns dias, recebi um comentário de Sinara Duarte do blog “Software Livre na Educação” no post “A História das coisas“. Ela colocou um ping back do post em seu blog e renomeou para “Software Livre é Software Verde!”. Fiquei bastante feliz com a replicação e resolvi fazer uma continuação do assunto.

Comecei a procurar correlações sobre o problema do lixo tecnológico e a utilização de software proprietário. Nessa empreitada encontrei as seguintes matérias:

• Spams contribuem para o aquecimento global, diz estudo da McAfee – Por IDG News Service/Cingapura – Publicada em 15 de abril de 2009 às 08h33 e atualizada em 16 de abril de 2009 às 13h11.
  Cingapura – Além de serem um incômodo, os 62 trilhões de spams enviados anualmente consomem 33 bilhões de kilowatts/hora de eletricidade.

  Considerando que as redes mundiais de spam não são operadas de computadores específicos, mas de computadores pessoais infectados com vírus, podemos chegar à conclusão de que o sistema operacional mais popular do mundo é responsável indireto por esse problema.

• Cebit 2009: Greenpeace pressiona empresas de tecnologia – Por IDG News Service/Alemanha – Publicada em 03 de março de 2009 às 16h35 e atualizada em 04 de março de 2009 às 15h07.
  Hannover – ONG quer que companhias do setor cumpram promessas e tomem medidas concretas que ajudem na preservação do meio ambiente.

  Por que o discurso fica tão distante da prática? Por que essas empresas, entre elas Microsoft, Nokia, Fujitsu, Sharp, Sony, Samsung, Apple, Intel, AMD, entre outras, gastam enormes quantias em marketing vendendo a imagem de empresas preocupadas com o meio ambiente mas, na prática, adotam apenas medidas cosméticas e enganam seus “consumidores”?

• Greenpeace: eletrônicos ainda não são ecologicamente corretos – Por IDG News Service/França – Publicada em 08 de janeiro de 2009 às 15h56 e atualizada em 09 de janeiro de 2009 às 09h42.
  Paris – De acordo com estudo conduzido por ONG, produtos tecnológicos são mais agressivos ao ambiente do que afirmam seus fabricantes.

  Se já existe tecnologia para fazer equipamentos ecologicamente corretos, por quê não se faz? A resposta é simples: redução de custos. A questão toda não é oferecer às pessoas produtos bons, ecologicamente corretos, eficientes energeticamente, duráveis. A questão se resume em oferecer aos “consumidores” produtos com ciclo de vida curto, com materiais baratos (e por isso não há preocupação com a qualidade), sem compromisso com o meio ambiente (afinal, isso aumenta os custos e diminui o lucro dos acionistas). Se não for assim, por quê ainda não encontramos produto que sejam duráveis, ecologicamente corretos e baratos?

• Crackers falsificam registros para transportar madeira ilegalmente – Por Redação do IDG Now! – Publicada em 12 de dezembro de 2008 às 19h24 e atualizada em 12 de dezembro de 2008 às 19h25.
  São Paulo – Segundo o Greenpeace, invasão de controle do permitido para comercialização desviou 1,7 milhão de metros cúbicos de madeira.

  Não é exclusividade do software proprietário a invasão por crackers. Entretanto, em redes onde existem sistemas livres e proprietários operando em conjunto, ou onde existe apenas sistemas proprietários, a possibilidade de invasão é bem maior, devido à falta de segurança do segundo. Inúmeros são os casos de invasão que tiveram como origem a vulnerabilidade de sistemas proprietários. Alguns exemplos:

  • Estações Linux salvam empresa de energia de ataque de vírus na Austrália;
  • Bolsa de valores de Londres adota Linux em suas operações;
  • Onda de ciberataques atinge EUA e Coréia do Sul;
  • Trojan rouba clientes de internet banking;
  • Cracker invadem página do Ministério da Defesa;
  • Ataques em massa assustam o ecossistema da Internet;
  • Criminosos na Web criam seis mil ameaças virtuais/dia;
  • Spams que tiraram Twitter e Facebook do ar partiram de máquinas no Brasil, Turquia e Índia;

• Crackers invadem Kaspersky e enviam vírus – Plantão Info/Tecnologia pessoal – Segunda-feira, 11 de novembro de 2002 – 15h37.
  SÃO PAULO – Um grupo de crackers invadiu o site do fabricante de antivírus Kaspersky Labs e enviou a assinantes de uma newsletter da empresa mensagens contaminadas com o vírus Bridex. A informação foi publicada pela própria Kaspersky.

  Se os próprios desenvolvedores de anti-vírus para os sistemas proprietários estão vulneráveis assim, eles que são os “consultores de segurança” não conseguem proteger a si mesmos, que dirá aos seus “consumidores”.

• Fabricantes de eletrônicos lutam contra leis de reciclagem nos EUA – Por Redaçãodo IDG Now! – Publicada em 02 de julho de 2009 às 11h40.
  São Paulo – Associação dos Eletrônicos de Consumo diz que indústria gastaria US$ 200 milhões anuais com reciclagem – só em Nova York.

  O custo para manter nosso planeta limpo é alto demais para essas empresas.

Agora, essa é a pior:

• Greenpeace traça caminho do lixo eletrônico para África e Ásia – Por Guilherme Felitti, editor assistente do IDG Now! – Publicada em 05 de junho de 2009 às 07h00 e atualizada em 05 de junho de 2009 às 09h27.
  São Paulo – Líder para lixo eletrônico do Greenpeace, Zeina Al Hajj detalha o descarte internacional e dá dicas para compras mais verdes.

  Esse lixo eletrônico já foi discutido neste post.

Estou incerto se seria necessário comentar algo mais mas, acho estamos todos tampando o sol com uma peneira. Quase todos, senão todos, os problemas descritos acima poderiam ser solucionados com a adoção do software livre. Cada vez mais, o software livre, o código aberto, o conhecimento compartilhado, a difusão das idéias indicam que podemos resolver os problemas que nos atingem, bastando termos um pouco mais de coerência entre o que pensamos falamos e fazemos. Se queremos, realmente, um mundo melhor, a paz, a não violência, a preservação do nosso planeta, o respeito aos nossos direitos, o fim da miséira, entre outras coisas, comecemos a agir para que isso aconteça.

Comece a considerar a possibilidade de utilizar o software livre e a contribuir para que ele se multiplique.

Este é o meu primeiro post, de muitos! Então vamos lá.

Quando me formei em 2004 e iniciei a minha vida profissional, achava legal chegar em casa e não ter que me preocupar em ficar estudando para provas, fazer trabalhos, preparar slides para apresentações em equipe. Até que um dia parei para pensar: “aonde vou chegar se não fizer uma busca contínua pelo conhecimento e crescimento profissional?” E a resposta não parece ser surpresa para ninguém: “a lugar nenhum, é claro”.

Resolvi escrever sobre esse assunto, não porque já possua muita experiência, mas porque tenho ouvido: “a empresa não reconhece meu trabalho”, ou “com esse salário, como posso investir no meu crescimento?”. Porém o que tenho visto são muitos profissionais no mercado, da área de T.I., que ainda não entenderam que estamos em um mundo globalizado, onde o profissional que não buscar o crescimento, em pouco tempo está fora do mercado e poderá simplesmente está realizando tarefas operacionais. Não desmerecendo as tarefas operacionais, mas acredito que devemos almejar, constantemente, proposta de novos desafios.

A matriz SWOT, onde cada letra significa Strengths (Força), Weaknesses (Fraquezas), Opportunities (Oportunidades) e Threats (Ameaças), é muito utilizada no planejamento estratégico de uma empresa, porém nada impede que possamos utilizá-la para analisarmos a nossa carreira profissional. Comece se perguntando pelos seus pontos fortes e fracos. Se você não se conhece, como poderá transmitir confiança às pessoas que te cercam? Outra pergunta seria: quais são as oportunidades e ameaças do mercado?

Com base nessa análise trace metas e busque não só o crescimento profissional, mas também, o intelectual e o emocional, para que assim possa atingir uma maturidade. Todavia, lembre-se sempre, não é porque você atingiu uma maturidade que deve parar de buscar o crescimento, pois dentro de um ciclo de vida, após a maturidade os dois próximos ciclos são: declínio e desaparecimento.

Esta foi uma tática de guerra de sucesso empregada na expansão do domínio Império Romano. Grupos ou facções com interesses diferentes eram ‘corrompidos’ fragilizando a estrutura do país e facilitando a dominação Romana.

No Gerenciamento de Comunicações, temos stakeholders com interesses diferentes, que precisam ter suas expectativas gerenciadas e atendidas. Estes interessados podem, em maior ou menor grau, influenciar, e até mesmo prejudicar, o andamento do projeto. Negligenciar a existência de algum desses stakeholders ou não entender o seu grau de influência no projeto é fator crítico uma vez que falhar nessa análise pode causar impactos ao seu projeto. Neste momento, o gerente (e seu grupo de trabalho, se for o caso) deve analisar as demandas e necessidades desses stakeholders de modo a minimizar riscos para o projeto.

No Gerenciamento do escopo, os requisitos do projeto são transformados (divididos) em diferentes entregáveis (deliverables) da Estrutura Analítica do Projeto (EAP). Já no Gerenciamento de Tempo, todas essas atividades que compõem o conjunto de entregáveis devem ser estimadas, sequenciadas e seu andamento (cronograma) monitorado.

Neste contexto, quando trata-se de ciência da computação, dividir para conquistar refere-se a uma técnica de recursão utilizada onde o problema a ser resolvido é dividido em instâncias menores, que são executadas recursivamente e o resultado final é obtido combinando-se as soluções intermediárias. Esta dinâmica, influenciada pela grande competição do mercado, traz a necessidade de agilidade e da escolha correta do Ciclo de Vida do Projeto e suas respectivas fases.

E é no Gerenciamento de Integração que o plano de dominação – ou melhor, o plano de gerenciamento – desse Império, o projeto, ganha forma. E agora, cabe ao General, o Gerente de Projeto, liderá-lo e conduzi-lo ao sucesso.

Seu projeto não é o Império Romano, mas ainda assim, precisa ser conquistado.

Abraço, Giovani Faria.

ciclo de vida

Estive um pouco distante, pois além de um projeto pessoal no qual estou trabalhando, estou também iniciando um novo projeto profissional. Estou começando a me envolver com projetos da área naval!

Durante toda minha vida profissional, estive envolvido em projetos na área industrial, seja na execução ou no gerenciamento, mas sempre industrial. Portanto, posso dizer que conheço muito bem o ciclo de vida desse tipo de projeto.

Embora muita gente “padronize” o ciclo de vida como suas fases são descritas na literatura, a mais famosa delas o “PMBoK”, não é correto resumir-se apenas à isso, o ciclo de vida não se inicia no processo de iniciação. Muita coisa já aconteceu antes disso, até chegarmos ao “project charter”, o documento mais “famoso” da fase de iniciação. Houve a fase da idéia, da concepção (que nasceu de uma necessidade, uma oportunidade ou alguma outra razão), passou por um processo de viabilidade, de escolha e etc, para aí sim chegarmos à iniciação.

Cada tipo de projeto tem seu ciclo de vida próprio, não posso dizer que um projeto de “TI” seja igual à um projeto industrial, ou a um projeto social, naval e assim por diante.  Por isso, o desafio é conhecer o ciclo de vida para aquele tipo de projeto! E este é meu desafio hoje.

Já comentei anteriormente, e ratifico minha opinião. Gerentes de projeto, devem ser mais generalistas do que especialistas.  Tenho certeza que muitos engenheiros podem gerenciar um projeto de TI, assim como um engenheiro eletricista, como eu, pode se envolver em um projeto naval. A chave disso é: Conhecer o ciclo de vida do projeto! Identificar as fases, as transições, os requisitos e entregas para cada fase, as dependências “arbitrárias”  e obrigatórias. A partir disso, podemos fazer as coisas como sempre fizemos.

É como planejar uma viagem, podemos ir para onde quisermos, vamos ter fases onde vamos escolher o local, o meio de transporte, a hospedagem e etc. Se formos para a praia, precisaremos de trajes adequados, programaremos passeios de acordo com o local e etc, se formos para o campo, teremos requisitos diferentes, mas continua sendo uma viagem! Preciso saber o local, o meio de transporte, hospedagem e etc.  Ou seja, mudamos todos os requisitos, mas o ciclo de vida é o mesmo! É o ciclo de vida de uma viagem!

Assim, fica claro que projetos industriais possuem ciclos de projetos industriais, projetos de “TI” possuem ciclos de vida de projetos de “TI” e assim sucessivamente. Portanto, quando aceitamos um novo desafio, rumo ao desconhecido, nós (gerentes, coordenadores, lideres de projeto) já sabemos por onde começar. Identificando o ciclo de vida.

Afinal, aceitar desafios também faz parte de um ciclo de vida. O nosso!

crédito da imagem: http://conteudo.imasters.com.br

Para una arquitectura sostenible, es muy importante hablar del ciclo de vida de un edificio. Se trata de un análisis de los materiales que construyen el edificio y los métodos empleados para ellos, desde la extracción de las materias primas hasta la gestión de sus residuos una vez derribada la obra.

A continuación veremos un video para tener claro en qué consiste.
Análisis del ciclo de vida de un edifio y el impacto ambiental que genera.

Para pensar un edificio de caracter sostenible tenemos que tener muy encuenta su ciclo de vida y desde el primer momento de su concepción el pensar:

• cómo se diseña
• cómo se construye
• cómo se mantiene
• cómo se derriba

A continuación veremos una relación fotográfica de ejemplos de proyectos sotenibles, además de la B&W House, prototipo de vivienda sostenible presentado por la UPM para el concurso Solar Decathlon 2009.

Referencia: http://es.wikipedia.org/wiki/Ciclo_del_proyecto

Un proyecto tiene 6 fases, según wikipedia

1. Programación

• Comienzo del ciclo
• Definición de objetivos
• Se establecen tiempos
• Actores del proceso

2. Identificación

• Prefactibilidad técnica, económica, legal y ambiental
• Estudios suplementarios antes de la fase “Factibilidad”
• Soluciones para la problemática planteada
• Determinación de costos
• Se analiza si seguir o no con el detallamiento del proyecto

3. Instrucción (Diseño, preparación, formulación)

• Se examinan los aspectos importantes del proyecto
• Más detalle y precisión en la solución
• Se ajusta marco lógico con los beneficiarios

4. Financiación

• Se presenta el proyecto a patrocinadores
• Se firma un convenio de acuerdo

5. Ejecución

• Utilización de recursos para implementar
• Se monitorea para que pueda adaptarse a cambios contextuales

6. Evaluación

• Análisis de resultados
• Las evaluaciones pueden ser:
  • De medio término, durante la ejecución del proyecto
  • Al final de la implementación del proyecto
  • Un tiempo después de que esté operando

Existe no mundo de desenvolvimento web a figura do sobrinho. Este personagem se caracteriza por ter conseguido modificar uns scripts daqui, entender alguns códigos e conseguir montar um “site”. Chamam de sobrinho porque na estória ele desenvolve o site para a empresa do tio e o tio fica orgulhoso de saber que o sobrinho dele, sem curso nenhum, conseguiu fazer aquele site. Então o tio pensa “para que pagar um programador de verdade sendo que o meu sobrinho consegue fazer um site.” O pior, o sobrinho se acha programador e começa a fazer as famosas POG’s nos diversos sistemas web que existem por ai. Cobra uma miséria e quem não conhecem a figura paga o valor solicitado achando que está fazendo um tremendo negócio. O sobrinho cobra barato porque ele pensa que está aprendendo quando está fazendo esses sites.

A estória acima é encontrada, conforme já citado, em diversos segmentos do desenvolvimento web, principalmente em linguagens onde fazer um Hello World é uma tarefa bem simples (ex: PHP). A questão está quando o sistema ou site que foi desenvolvido pelo sobrinho passa por pelo menos duas situações. A primeira é quando o site necessita crescer. Adicionar um novo módulo, fazer uma modificação na base de dados, ou simplesmente trocar o layout do site. Como ele não sabe programar escreve os famosos códigos macarrônicos. Códigos macarrônicos são aqueles que unem diversas partes que deveriam ser separadas em uma única parte. Extração de dados do banco, html, javascript, css, tudo no mesmo arquivo. Qualquer modificação levará pelo menos 5 vezes mais tempo do que uma modificação atual. Se houver um aumento da demanda de modificações no site, em pouquíssimo tempo o preço pago ao sobrinho vai ficar muito mais caro que se um programador tivesse desenvolvido. E se necessitar de uma modificação maior, o sistema terá que ser reescrito. A segunda questão acontece quando o site está no ar e esse site é invadido . Existem milhares de falhas que se podem ser cometidas pelo pouco conhecimento de desenvolvimento. Essa característica é peculiar ao desenvolvimento web. Mas ai alguém pode falar: “Mas é só um site, se invadirem e só substituir os arquivos e acabou”. Talvez, mas usando uma vulnerabilidade no site, todas as aplicações que rodam naquele servidor ficarão expostas. Serviços de e-mail, sistemas de controle de arquivos, banco de dados, e sabe-se lá o que mais podem ser destruídos ou utilizados para fins malignos. Uma boa parte dos spams que recebemos são formulários mal feitos que pessoas mal intencionadas utilizem para disseminar mensagens.

Portanto, caso você esteja pensado em ter um site ou um sistema. Procure alguém que saiba fazer. Busque referência profissional, procure saber os trabalhos realizados pelo profissional. Conforme o texto acima mostrou, em quase todas as vezes o barato sai caro.

Para os sobrinhos….

Este texto não tem a intenção de desencorajar quem está aprendendo. Todos nós, programadores, estamos sempre aprendendo. Eu grifei a palavra curso no texto porque muitas pessoas pensam que fazer um curso de programação e já sabe tudo. Sinceramente, para ser um bom programador necessita de dedicação em estudar e estudar e estudar. Leia sobre diversos assuntos. Aprenda as tecnologias recentes do mercado. Não pense que um Hello World é tudo. Existem muitas coisas além dele que são fundamentais para fazer um sistema com um ciclo de vida alto e com um bom grau de segurança….

O RUP (Rational Unified Process), desenvolvido pela Rational Software Corporation,  foi criado utilizando alguns conceitos de modelos mais antigos como o modelo espiral e o waterfall, porém agregando os conceitos da UML e da Orientação a objetos.

É baseado em um conjunto de boas práticas, as principais são:

• Desenvolver iterativamente;
• Gerenciar requisitos;
• Usar arquiteturas baseadas em componentes;
• Modelar visualmente;
• Verificar continuamente a qualidade;
• Gerenciar a mudança.

Por ser um modelo evolutivo, cada ciclo de um projeto é dividido em quatro fases:

1 – Início;

2 -  Elaboração;

3 -  Construção;

4 – Transição;

Durante a sua execução, primeiramente é gerado um ciclo de desenvolvimento inicial, que foca em definir uma visão e um plano de alto nível, para o desenvolvimento do produto por inteiro. Após este primeiro ciclo, os demais ciclos evolutivos focam em adicionar novas funcionalidades, melhorias e correções. Ao final de cada um dos ciclos é entregue uma nova “versão” do produto.

Ciclo de vida do RUP

A recente notificação sobre uma suposta reativação da atividade qualificada por parte do império à Porto Claro mostra exatamente como é o micronacionalismo que praticamos, que nada mais é do que o nivelamento pelo nível mais baixo das intelectualidades nas quais são compostas nesta micronação.

A teoria micropatriológica clássica nos ensina que é necessário haver um ciclo de vida em todo projeto micronacional, uma vez que é por meio deste, supor os pontos fortes e fracos, bem como aqueles que causam o enfraquecimento do grupo, de forma a serem compreendidos em sua totalidade e descartados nos estudos micronacionais futuros.

Desta maneira, é correto afirmar que Porto Claro precisa acabar, pois como uma árvore madura se podada, dará chance de adquirir mais oxigênio e com isso poder ressurgir com mais vida.

Ao reconhecer e oferecer subsídios para o não-falecimento do projeto portoclarense, tão somente transformamos o mesmo naquilo que entendemos como zumbi, pois ao nos ‘preocuparmos’ com nossos irmãos, e por isso o dever de ’sustentá-los’, também colocaremos lá um pouco de nós mesmos, nas só nas práticas diárias, mas também na cultura fundante.

Esta miscigenação faz com que no final das contas exista apenas mais do mesmo. Passaríamos a ser micronacionalistas mestiços.

Mas o que o tema da miscigenação evoca? Muita coisa. E não se trata de enfatizar ou negar misturas. Sociais, políticas e culturais. E também étnicas (que em termos micronacionais representa o projeto como um todo). A questão é indagar o quanto essa temática — como fator estrutural — tem validade (num pressuposto de exclusividade) para se pensar sociedades do passado e aquelas do presente. Mais do que evidências, dados e mesmo argumentação histórica e sociológica, já no mito fundante do micronacionalismo fomos bombardeados por uma imensa propaganda ideológica, que sempre funcionou como fios condutores de ideias no final imperialistas e expansionistas, justapondo não apenas argumentos e interesses em diferentes contextos, escolhas e personagens, mas capaz de transformar a miscigenação ideológica em algo naturalizado, real e ideal. Por que não? Normal.

Do que falamos e por que falamos? Ou de quem e com quem dialogamos, afinal? Do passado fictício dos paples? Da nação romantizada no alvorecer do império? Das narrativas que criaram a “nossa” identidade e cultura? Das políticas públicas do ontem e do hoje? Debates se colocam.

Portanto, é nosso dever rogar aos nossos governantes a serenidade ao tomarem suas decisões, não apenas as de âmbito internacional, mas com mais ímpeto as domésticas, que acabam nos afetando em nossos cotidianos.

DALTONISMO SOCIAL

Sem ironias desnecessárias que muitas vezes rondam o debate acadêmico e intelectual — sempre necessário e cada vez mais ausente —, louvamos a idéia de Rafael Marquese, ao propor o debate (um quase-convite), testando hipóteses e ensaiando argumentos. Dentro do mesmo espírito, desejamos neste ensaio nada diferente disso. Perspectivas historiográficas, misturadas com pressupostos teóricos, têm a sua validade, assim com expectativas ideológicas e narrativas envolventes. Em termos historiográficos, as possibilidades de análises comparativas — abordagens de projetos menos reuniãos — sugerem caminhos interpretativos novos.

Corremos o risco talvez de perder essas “explicações nacionais” ao unirmo-nos e tornarmo-nos mais do mesmo. Há muito de cotidiano, micropolíticas, eventos e não-eventos necessitando de abordagens e interpretações. E os horizontes interpretativos dos impérios podem (en)cobrir em demasia as paisagens analíticas dos outros sujeitos micronacionais. Estreitar estas margens, isolar — realinhando — tempos e espaços históricos, assim como refletir sobre projetos, processos, estruturas e agências — também como propôs Marquese — pode aumentar focos, interesses e mobilizar investigações em torno do conhecimento histórico de nós mesmos.

Bibliografia:

Carvalho, José Murilo de. Teatro de sombras. A política imperial. Rio de Janeiro: Iuperj, 1988;

Marquese, R. B. “A dinâmica da escravidão no Brasil. Resistência, tráfico negreiro e alforrias, séculos XVII a XIX”. Novos Estudos, São Paulo, nº 74, 2006, pp. 107-123.

O modelo espiral procura através do desenvolvimento de protótipos em ciclos, nos permite entregar um produto mais próximo à necessidade/realidade do cliente. Para isto utiliza os seguintes passos:

1 – Definição dos objetivos;

2 -  Análise de riscos;

3 – Desenvolvimento e testes;

4 – Panejamento do próximo ciclo;

Estes passos se assemelham ao ciclo PDCA (Plan, Do, Check, Act), ferramenta gerencial que auxilia na tomada de decisão e  na garantia de alcance de metas/objetivos.

Modelo Espiral

Por se tratar de um modelo evolutivo, uma das suas vantagens é ter um maior controle sobre os riscos do projeto, tornando o processo de construção de um produto complexo de uma maneira mais segura.

Posteriormente Barry Boehm criou o modelo Win-Win Spiral, que unia os seus trabalhos sobre o modelo espiral e a Teoria-W, propondo que toda a gestão do projteto deve considerar a relação ganha-ganha.

Para a sua execução são executados os seguintes passsos:

1 – Identificar os stakeholders;

2 – Identificar os requisitos que satisfaçam os stakeholders;

3 – Planejar/Estabelecer objetivos, restrições e alternativas;

4 – Avaliar os riscos, restrições e alternativas;

5 – Definir o produto e o processo;

6 – Validar o produto e o processo;

7 – Revisar;

Modelo Espiral win-win

O modelo waterfall, ou modelo cascata, foi descrito nos anos 70 pelo Dr. Winston W. Royce em um artigo chamado “Managing the development of large software systems” que apresentava as suas experiências no desenvolvimento de softwares para o planejamento de missões espaciais.

As etapas necessárias para a execução de um projeto seguindo este modelo são as seguintes:

1 Requisitos de Sistema;

2 Requisitos de Software;

3 Análise;

4Arquitetura;

5 Codificação;

6 Testes;

7 Operações;

É importante destacar que etapa só será iniciada após a conclusão da etapa anterior. Entre os produtos gerados estão a documentação de todas as etapas, incluindo a sua revisão nas fases seguintes, o código, o software, o plano de testes e as instruções para a sua operação.

O autor enfatiza que é de extrema importância o envolvimento do cliente/consumidor para o sucesso do projeto, para isto os pontos de aprovação do modelo encontram-se na fase de revisão preliminar do sistema (PSR),  na revisão crítica do sistema (CSR) e na revisão final de aceitação (FSAR).

Modelo Waterfall - Resumo

A figura apresenta um resumo do modelo waterfall. Nesta, podemos identificar todas as etapas para o desenvolvimento de um software complexo, porém este modelo acaba sendo muito oneroso, já que consome recursos em demasia, tanto em tempo quanto em dinheiro, exigindo um alto grau de formalidade e chegando ao ponto de sugerir que o software seja feito duas vezes para que seja obtido o resultado desejado.

Críticas à parte, o modelo serviu como base (ou no mínimo como ponto de partida) para o surgimento das diversas metodologias para o desenvolvimento de software criadas até hoje.

    Uma página passa por várias etapas de processamento a partir do momento que é executada. Conheça agora essas etapas:

    Page request –> Quando o usuário solicita uma página, o ASP.Net vai determinar se ela será será compilada e executada ou se o cache da memória que será mandado para o usuário. Esta fase ocorre antes do ciclo começar, pois ele só começará se a página for compilada e executada.

    Start –> As propriedades iniciais da página são definidas. Request, response e UICulture são algumas dessas propriedades.

    Page initialization –> Os controles e os temas ficam disponíveis na página.

    Load –> Se a solicitação for um postback durante o carregamento, as propriedades são carregadas com informações recuperadas.

    Validation –> Os métodos de validação são chamados nesta etapa.

    PostBack event handling –> Manipuladores de evento são chamados se for um postback.

    Rendering –> O método Render é chamado fornecendo um text writer para o response.

    Unload –> As propriedades da página são descarregadas. Ocorre quando a página já foi enviada para o cliente e já foi processada.

Fonte:
 http://msdn.microsoft.com/en-us/default.aspx                                                          

                                                           Escrito por Luísa Pèret Moraes e Paula Pèret Moraes

Este tema surgió durante la conversación del almuerzo, y que también vengo teniendo en la cabeza en los últimos días a partir de tanto darle vueltas a los diferentes proyectos en los que estoy metido. Una idea no es sólo una idea, creo, o en todo caso, encierra el potencial para ser también varias otras cosas.

Así que he venido jugando con la idea de que hay un ciclo de vida para las ideas: nacen como ideas, y en su crecimiento se vuelven proyectos cuando las ideas empiezan a encontrar algún tipo de aplicación tentativa, aunque sea para agrupar más personas en torno a suyo que comparten el mismo interés. Los proyectos se desarrollan, y en el camino, con un poco de suerte también, resultan en un piloto, algún tipo de experiencia de prueba que se puede llevar al mundo real para probar y refinar el concepto y su aplicación. Los pilotos exitosos, refinados y mejorados, encuentran quizás el camino para convertirse en productos – una suerte de versión final, lanzada al mercado, lista para su consumo.

Sé que esto parece muy parcializado al comercialismo, pero no quiero llevarlo por ese camino. Es, más bien, una radiografía de cómo se implementan las ideas, que finalmente se realizan en el mundo de alguna manera: sea a través de prácticas, conductas, artefactos, objetos, o lo que fuera, alguna forma de producto. Me molesta un poco la linealidad del proceso, pero fácil no es realmente un proceso lineal: la existencia del producto, aunque profundamente vinculada a la idea, no es lo mismo, ni es su reemplazo ni desplazamiento. Quizás las etapas coexistan pacíficamente en simultáneo. Al mismo tiempo que un mismo proyecto puede llevar a muchos pilotos, y así sucesivamente.

Lo que más me gusta: a partir de esta radiografía, me parece más fácil preguntar cómo podríamos típicamente describir los rasgos de cada etapa. Y si podemos hacer eso, también podemos, quizás, describir los rasgos típicos de los movimientos entre cada etapa. En otras palabras: identificar qué es lo necesario, lo que hace falta, para llevar una idea de una etapa a la siguiente. Y esto es lo que más me interesa porque, como también salió el tema durante el almuerzo, quizás en la implementación de varias ideas, los proyectos que vengo trabajando se encuentran en el limbo entre la etapa de proyecto y la de piloto.

Enlace a la parte 1 y a la parte 2

Continuemos con algunos conceptos básicos de DataBase Marketing que nos ayuden a estructurar mejor las buenas prácticas en este tema.  En esta entrada la parte final de un concepto fundamental para el DBM: el Ciclo de Vida del Cliente. Recuerde la importancia de su participación

Ciclo de vida del Cliente (CVC) (también conocido como Customer Life Cycle (CLC)):

Como se comentó en la entrada anterior, el concepto de Ciclo de Vida del cliente ha sido examinado desde múltiples ópticas (en este link una artículo muy interesante), y, no obstante, es un concepto poco conocido en las organizaciones colombianas que, de ser bien implementado, marcaría notablemente la diferencia en el enfoque estratégico del marketing directo. Aunque algunos autores lo resumen en cinco factores claves, aquí lo mostramos en siete pasos que se pueden trabajar desde diversas ópticas, mostradas a continuación:

Hasta aquí (junto con la entrada anterior) se han tratado las tres primeras etapas del ciclo de vida del cliente, Adquisición, Desarrollo y Mantenimiento. Examinemos los últimos cuatro pasos que nos ayuden a contemplar el esquema de la imagen anterior.Fidelización: En el mantenimiento se ha expuesto que se buscan detalles e incentivos que estén dirigidos a generar una relación más profunda (con un mayor involucramiento) de los clientes de nuestras organizaciones. La fidelización, sobre la cual se puede discutir extensamente pues existe mucho material relacionado (donde se destaca este link), es la fase en la cual se busca brindar al cliente un plus o un factor de beneficio adicional que conlleve a que su relación con la organización sea de largo plazo y en los mejores términos.

4. Fidelización: En el mantenimiento se ha expuesto que se buscan detalles e incentivos que estén dirigidos a generar una relación más profunda (con un mayor involucramiento) de los clientes de nuestras organizaciones. La fidelización, sobre la cual se puede discutir extensamente pues existe mucho material relacionado, es la fase en la cual se busca brindar al cliente un plus o un factor de beneficio adicional que conlleve a que su relación con la organización sea de largo plazo y en los mejores términos.

En la fidelización existen muchos puntos de controversia que aun no se encuentran resueltos como tal (y que obviamente están sujetos a discusión): uno de estos se centra en la efectividad real de los programas de fidelización, para la cual interactúan muchas componentes de mercadeo como son la comunicación, la inversión que se hace sobre los programas, y la expectativa de que estos programas sean auto sostenibles en el mediano y largo plazo. Los más famosos programas de fidelización, como es conocido, son aquellos correspondientes a las aerolíneas, almacenes de cadena, tarjetas de crédito, entre otros. En Colombia en particular son programas que aun están en evolución y que se encuentran en las principales empresas del país

Otro factor de discusión comúnmente hablado aquí es la importancia relativa de la fidelización dentro del ciclo de vida del cliente con respecto a otras funciones del ciclo, como adquirir, retener o recuperar clientes. Algunos teóricos, un tanto estrictos para el gusto del autor, afirman que un programa de fidelización exitoso es todo aquel que no permite la existencia de programas de retención y de recuperación. Esto es un tanto discutible si se examina desde la perspectiva de que todo esfuerzo de mercadeo bien dirigido genera, en cualquier plazo, un mínimo retorno.

La interacción de la fidelización con el DBM no es directa, como si ocurre en otros aspectos como la adquisición, el desarrollo o la retención, pues es una herramienta de apoyo que emplea técnicas estadísticas y de segmentación en minería de datos para identificar a los mejores clientes de un producto o servicio, con el fin de orientar las estrategias de fidelización a los mismos.

5. Servicio: El servicio se define como la existencia de canales adecuados para la interacción con el cliente en el momento que el lo requiera, ya sea para despejar dudas o inquietudes, presentar quejas o reclamos, hacer sugerencias o reclamos y afianzar la relación con el cliente no solo en aspectos post-venta, sino incluso antes y durante la misma.
La creación de modelos de servicio adecuados, que incorporen el personal pertinente y los canales efectivos (Web, telefónicos, personales, en punto de venta, etc.) complementa de manera eficiente el relacionamiento con el cliente. Desde la  perspectiva del cliente se evidencia que la disponibilidad de estos canales llega en ciertos casos a ser un factor decisivo en el momento de compra, así como un complemento a las estrategias de mantenimiento y fidelización.

La pertinencia de este paso del ciclo de vida del cliente en  el DBM se centra en la contabilización adecuada de eventualidades de servicio y su respectiva clasificación. Cuando se construyen modelos de valoración del cliente, se suele emplear la información de servicio con el fin de clasificar a los clientes como tal, dependiendo los costos de mercadeo que pueden generar. En otros casos, como los modelos de retención, se suele observar para algunos sectores que aquellos clientes que presentan una mayor interacción con los canales de servicio, en especial para quejas y reclamos, suelen ser clientes afines a la deserción.

6. Retención: La retención recibe muchos nombres dependiendo el enfoque con que se quiera trabajar. Recibe el nombre de retención si la organización lo ve desde un enfoque más positivista, o deserción (el popular termino churn), si lo quieren ver como un problema identificado de urgente resolución. En si, el problema es el mismo, pero si existe una diferencia en el sentido de comunicación: si un cliente valioso decide desertar o si por lo menos a través de modelos predictivos se puede anticipar este hecho, la comunicación y los ofrecimientos que se hagan al cliente deben ser pertinentes para evitar esta situación. Pero si el cliente no es valioso, o por lo menos representa un alto costo de mercado mantenerlo, algunas organizaciones optan por dejarlos ir pues saben de antemano que la perdida no va a ser tan significativa como la salida de un cliente valioso (a veces llamado Top o VIP).

Es importante distinguir primero que el término deserción o churn hace referencia a la deserción voluntaria de un cliente en la relación con la organización. Es decir, que la motivación de salida obedece a factores de decisión autónoma del cliente, relacionados con producto, precio, promoción o servicio. Cuando al deserción se comete de forma involuntaria, la cual puede ser causada por factores de incumplimiento de pago, desacuerdo contractual, sanción o suspensión, se conoce normalmente como attrition y es atacada con modelos tipo recuperación de cartera, entre otros, que normalmente no son relacionados directamente con el marketing.

Desde el DBM el problema de deserción (o la estrategia de retención) es prioritario para muchas organizaciones, sobre todo aquellas que se caracterizan por estar en sectores de la economía muy competidos como las telecomunicaciones, los medios y todos aquellos relacionados con suscripciones o afiliaciones. Las empresas buscan retener a sus clientes valiosos para evitar que los mismos sean “adquiridos” (captados) por la competencia. La solución más importante que se debe implementar en modelos de retención es realizar estrategias proactivas que involucren modelos predictivos de minería de datos que utilicen toda la información de negocio posible y que generen reglas que permitan detectar cuando un cliente va a tomar la decisión de salida.

Una apreciación personal en forma de pregunta: Ustedes que acción tomarían si tuvieran un balde con agua pura y limpia al cual se le ha abierto una fisura: ¿seguirían llenando el balde con cualquier tipo de agua (no necesariamente pura y limpia) o tapar la fisura de alguna forma para evitar que el agua pura y limpia se siga fugando? Algo similar es (o debería ser) el razonamiento que los gerentes de mercadeo de las organizaciones deberían hacer a la hora de dirigir los recursos de mercadeo a actividades específicas dentro del ciclo de vida.

7. Recuperación: La recuperación consiste en, como su nombre lo indica, traer de vuelta aquellos clientes que, por uno u otro motivo, desertaron voluntariamente en el pasado de corto plazo. Dividamos el concepto: traer de vuelta a los clientes no implica tener que ingresar al ciclo de vida nuevamente a todos aquellos que se han ido, sino solamente a aquellos que por su pasado positivo en el relacionamiento con la organización son considerados valiosos y, por ende, muy importantes para cualquier empresa. Además, esta recuperación basada en estrategias debe realizarse preferiblemente en el corto plazo, pues el cliente tiene aun “fresco” el reracionamiento que en el pasado tuvo en la firma. Esto, siempre y cuando, se le puedan ofrecer garantías que permitan su retorno como cliente de la organización que suavicen las causas de su deserción previa (servicio, maltrato al usuario, inconformidad general, entre otras posibles).

Existen algunos enfoques particulares respecto al tema de la recuperación de clientes: quienes son defensores de la fidelización, generalmente señalan que el cliente que deserta no tenía un alto compromiso con la organización, o su involucramiento como cliente no llego a ser lo suficientemente profundo como para ser valorado como un cliente excepcional. Este tipo de clientes generalmente son descritos como los “cazarecompensas” o “cazaofertas”(es decir, aquellos que se mueven por factores promocionales) y también son descritos como tomadores de precio como el principal motivador de compra.

Otra visual que tiene el tema de recuperación es aquella que valora a sus clientes con patrones un poco menos intangibles o afectivos hacia el producto (sin que esto sea malo, claro esta). Esta corriente es aquella que generalmente valora a su cliente en factores monetarios, usando modelos de valoración como el Lifetime Value o valor en ciclo de vida del mismo (que veremos, con seguridad, más adelante). Es decir, aquellos que ponderan que todo cliente que sea rentable y que represente para la firma niveles de facturación significativamente mayores al promedio son candidatos a ser recuperados mediante atractivas ofertas de recuperación que no escatimen en costos sobre la misma. El tema de comunicación con estos clientes es un poco más complejo de trabajar, pero muchas veces se usan estrategias de negocio que garanticen  que aquel cliente valioso que ha sido recuperado no se marche nuevamente en el corto plazo y que permita encaminar la relación cliente-empresa de la mejor forma posible. Un ejemplo de esto son las famosas claúsulas de permanencia mínima, muy comunes en sectores como el de las telecomunicaciones.

La implementación del DBM es activa en cuanto a la recuperación de clientes, pues su rol en este caso es el de disponer de la mejor información histórica posible que permita convencer al cliente, por medio de su pasado, de lo beneficiosa que ha sido esa relación para él. Esto, complementado con una adecuada valoración de los clientes (donde también profundizaremos en posteriores entradas) y estrategias de comunicación efectivas, garantizan el emprendimiento de estas estrategias.

Participe. Dudas, comentarios, aclaraciones?…pregunte en los comentarios de este Blog o si lo prefiere al correo julian.ramirez@wunderman.com

UN saludo!

Fiel a la  - convertida en habitual en los últimos tiempos -  cita mensual con sus lectores, las rotativas electrónicas de ISACA producían el pasado viernes, 15 de mayo de 2009, una nueva publicación de la familia CobiT.

El documento, que lleva por título “Cobit and Application Controls: A Management Guide“, disponible, actualmente, sólo en formato electrónico (descargable gratuitamente para miembros), podrá ser adquirido en formato papel, a través de la librería de la Asociación, a partir del próximo día 25.

Puede sorprender, nada más abrirlo, ver el logotipo de ISACA en lugar del del IT Governance Institute, como cabría esperar de una publicación sobre el modelo CobiT. Sin embargo, esta “novedad” no es sino la puesta en escena de la evolución de la dirección estratégica de la Asociación, anunciada recientemente. Como parte de dicha evolución se identificaban cinco “temas estratégicos”, entre los que se encontraban “desarrollar el potencial completo de CobiT” y “reforzar el compromiso con los miembros de base de la Asociación: profesionales del control interno de TI y auditores de sistemas de información“. Ambos “temas” parecen materializarse con la publicación de “CobiT and Application Controls: A Management Guide“:

• por un lado, se desarrollan las fronteras del modelo CobiT cubriendo, en esta ocasión, los aspectos relativos al ciclo de vida de las soluciones software de aplicación al negocio; o, más concretamente, los aspectos relativos al control interno que ha de transcurrir paralelo a las distintas etapas de dicho ciclo de vida. (Hace tan sólo unas semanas se presentaba la publicación “CobiT User Guide for Service Managers“, con la que se trataba de “aterrizar” la filosofía CobiT sobre el área de la Gestión de los Servicios de TI); y,
• por otro, se trata, a pesar de su título, de un documento dirigido, principalmente, a los profesionales del control interno que han de desarrollar su labor en el ámbito de la construcción de aplicaciones y a los auditores encargados de evaluar dichos marcos de control.

Mediante este anglicismo, GREEN IT pretende definir al estudio del uso eficiente de los recursos informaticos en terminos de energia y protección ambiental. Sus principios son:

1. Reduccion del uso de materiales peligrosos, como el plomo, en su proceso productivo,
2. Maximizacion de la eficinecia energetica a lo largo del ciclo de vida de un producto,
3. Maximizacion del grado de reciclado o biodegradacion de los productos desechados tanto por usuarios como por fabricantes.

Adoptar GREEN IT no puede hacerse de una manera aislada sino que debe ser parte de la estrategia de la empresa. No deja de ser un conjunto de medidas que forma parte de la gestión ambiental de las empresas, tanto fabricantes como usuarias. Precisamente, el aumento de una conciencia ambiental, lleva a organizaciones tanto publicas como provadas a hacerse un planteamiento acerca de los metodos de direcion y gestion de las TIC. La mayor parte de las iniciativas para reducir las emisiones de dioxido de carbono, se han llevado a cabo a nivel operacional, es lo que se ha llamado “ciclo de vida del equipo”, lo que abarca la adquisicion, uso y disposicion del equipamiento informatico. Pero dentro de este nivel operacional, lo que se asume comunmente por las organizaciones es el reciclaje tanto de papel, PC y otros dispositivos como los cartucho de tóner. Con el incremento de los costes de energia y con los problemas crecientes de suministro y capacidad, la electricidad necesita de una estrategia especifica propia. Los proyectos de optimizacion y reducción de costes aplicados a cualquiera de las áreas de negocios de las empresas, se han extendido a los costes de energia: eficiencia energética. Indudablemnte la primera parte es conocer la utilizacion de dicha energia, poseer un mapa de consumos, donde se usa y en que equipos especificos. Precisamente eso es lo complejo ya que es muy dificil encontrar un medidor de consumo de energia que nos permita desglosar el uso a un nivel en que se puedan ver los resultados sus acciones. Lo que ocurre, por tanto, es que la mayoria de las organizaciones solo ven una factura de energia mensual que acumula el total consumido, lo que supone un escaso estimulo para el ahorro de la misma, ya que hace dificil apreciar la repercusion de las decisiones que se toman. Es complejo así demostrar que los pequeños cambios introducidos, suponen ahorro de energia.

El cambio climático amenaza con interrumpir el ciclo de vida de los crustáceos, cualquier daño a las reservas de camarones del norte podría repercutir en la cadena alimenticia oceánica que va desde las algas hasta el bacalao.

Según un estudio publicado en la revista Science, el camarón tiene un apareamiento sincronizado para que sus huevos se incuben, cuando las algas, que sirven de alimento para las larvas son más abundantes.

Los huevos que llevan las hembras tardan entre 6 a 10 meses en incubarse.

Los científicos descubrieron que los crustáceos, que viven desde en el Golfo de Maine hasta en las aguas árticas del norte de Noruega, sincronizan su apareamiento de acuerdo a las temperaturas de las aguas en el lecho marino donde viven los adultos.

Las aguas más cálidas podrían interrumpir esa sincronización.

Se define como Proceso al conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto, en este caso particular, para lograr la obtención de un producto software que resuelva un problema.

Ese proceso de creación de software puede llegar a ser muy complejo, dependiendo de su porte, características y criticidad del mismo. Por ejemplo la creación de un sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo programa (ejemplo: resolución de una ecuación de segundo orden), éste puede ser realizado por un solo programador (incluso aficionado) fácilmente. Es así que normalmente se dividen en tres categorías según su tamaño (líneas de código) y/o costo: de Pequeño, Mediano y Gran porte. Existen varias metodologías para estimarlo, una de las más populares es el sistema COCOMO que provee métodos y un software (programa) que calcula y provee una estimación de todos los costos de producción en un “proyecto software” (relación horas/hombre, costo monetario, cantidad de líneas fuente de acuerdo a lenguaje usado, etc.).

Considerando los de gran porte, es necesario realizar tantas y tan complejas tareas, tanto técnicas, de gerenciamiento, fuerte gestión y análisis diversos (entre otras) que toda una ingeniería hace falta para su estudio y realización: es la Ingeniería de Software.

En tanto que en los de mediano porte, pequeños equipos de trabajo (incluso un avezado analista-programador solitario) puede realizar la tarea. Aunque, siempre en casos de mediano y gran porte (y a veces también en algunos de pequeño porte, según su complejidad), se deben seguir ciertas etapas que son necesarias para la construcción del software. Tales etapas, si bien deben existir, son flexibles en su forma de aplicación, de acuerdo a la metodología o Proceso de Desarrollo escogido y utilizado por el equipo de desarrollo o analista-programador solitario (si fuere el caso).

Los “procesos de desarrollo de software” poseen reglas preestablecidas, y deben ser aplicados en la creación del software de mediano y gran porte, ya que en caso contrario lo más seguro es que el proyecto o no logre concluir o termine sin cumplir los objetivos previstos y con variedad de fallos inaceptables (fracasan, en pocas palabras). Entre tales “procesos” los hay ágiles o livianos (ejemplo XP), pesados y lentos (ejemplo RUP) y variantes intermedias; y normalmente se aplican de acuerdo al tipo y porte y tipología del software a desarrollar, a criterio del líder (si lo hay) del equipo de desarrollo. Algunos de esos procesos son Extreme Programming (XP), Rational Unified Process (RUP), Feature Driven Development (FDD), etc.

Cualquiera sea el “proceso” utilizado y aplicado en un desarrollo de software (RUP, FDD, etc), y casi independientemente de él, siempre se debe aplicar un “Modelo de Ciclo de Vida”.

Se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrasan y un 26% son totalmente exitosos. Cuando un proyecto fracasa, rara vez es debido a fallas técnicas, la principal causa de fallos y fracasos es la falta de aplicación de una buena metodología o proceso de desarrollo. Entre otras, una fuerte tendencia, desde hace pocas décadas, es mejorar las metodologías o procesos de desarrollo, o crear nuevas y concientizar a los profesionales en su utilización adecuada. Normalmente los especialistas en el estudio y desarrollo de estas áreas (metodologías) y afines (tales como modelos y hasta la gestión misma de los proyectos) son los Ingenieros en Software, es su orientación. Los especialistas en cualquier otra área de desarrollo informático (analista, programador, Lic. en Informática, Ingeniero en Informática, Ingeniero de Sistemas, etc.) normalmente aplican sus conocimientos especializados pero utilizando modelos, paradigmas y procesos ya elaborados.

Es común para el desarrollo de software de mediano porte que los equipos humanos involucrados apliquen sus propias metodologías, normalmente un híbrido de los procesos anteriores y a veces con criterios propios.

El proceso de desarrollo puede involucrar numerosas y variadas tareas, desde lo administrativo, pasando por lo técnico y hasta la gestión y el gerenciamiento. Pero casi rigurosamente siempre se cumplen ciertas etapas mínimas; las que se pueden resumir como sigue:

• Captura, Elicitación^[4] , Especificación y Análisis de requisitos (ERS)
• Diseño
• Codificación
• Pruebas (unitarias y de integración)
• Instalación y paso a Producción
• Mantenimiento

En las anteriores etapas pueden variar ligeramente sus nombres, o ser más globales, o contrariamente más refinadas; por ejemplo indicar como una única fase (a los fines documentales e interpretativos) de “Análisis y Diseño”; o indicar como “Implementación” lo que está dicho como “Codificación”; pero en rigor, todas existen e incluyen, básicamente,las mismas tareas específicas.

En el apartado 4 del presente artículo se brindan mayores detalles de cada una de las listadas etapas.

Hace poco, esperando el lanzamiento de la nueva versión de Ubuntu, me llamó la atención el modelo del ciclo de vida utilizado por los desarrolladores de esta distribución de GNU/Linux.

A mi ver, el modelo de desarrollo que más se ajusta es el modelo de entrega por etapas.

La entrega por etapas es un modelo basado en el modelo en cascada, aunque una de las diferencias es que el software puede ser puesto a la disposición de los clientes o usuarios en cada una de sus fases. Esto permite que se pueda probar el software sin que la aplicación este completamente terminada, lo que genera una alta visibilidad sobre el proceso de desarrollo.

Es lógico preguntarse cuales son estas fases de desarrollo, aunque muchas empresas utilizan nombres clave para las versiones antes del lanzamiento de un producto, otras utilizan nombres basados en el alfabeto griego. De esta forma:

Etapa Pre-alfa

En esta fase generalmente el producto no tiene características completas. Mas bien los diseñadores están determinando qué funcionalidades debe tener el producto, algunos nombres que se le dan al lanzamiento en esta etapa son development releases o nightly builds.

Etapa Alfa

La versión alfa de un producto es una etapa en la cual el equipo de desarrollo decide que implementará todas las funcionalidades específicas en los requisitos, esta versión es enviada a los verificadores para probarla, algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde el producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.

Etapa Beta

Esta etapa esta un un paso intermedio en el ciclo de desarrollo completo, un lanzamiento beta representa generalmente la primera versión completa del producto, que es probable que sea inestable, pero útil para demostraciones, vistas previas o pruebas generales. Algunos desarrolladores le llaman a esta etapa como inspección previa técnica (Technical preview [TP]). a menudo los desarrolladores anuncian en esta etapa que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores.

Versión Candidata para lanzamiento (release candidate)

El lanzamiento en esta etapa se refiere a un producto final, preparado para lanzarse como versión definitiva a menos que aparezcan errores que lo impidan. En esta fase el producto implementa todas las funciones del diseño y se encuentra libre de cualquier error que suponga un punto muerto en el desarrollo. Algunas empresas utilizan el termino gamma o delta para versiones que están prácticamente completas pero que todavía están en pruebas y omega para versiones que se creen libres de errores.

Versión Dorada

Esta es una versión de disponibilidad general y se refiere al lanzamiento definitivo de un producto software, normalmente es casi idéntica a la versión candidata, con solo correcciones de último momento.

Fuentes:

Desarrollo y gestión de proyectos informáticos (Steve McConnell).

Wikipedia, La enciclopedia líbre.

Planificación del Ciclo de Vida

El modelo del ciclo de vida escogido es un factor principal para conseguir los objetivos buscados, una mala elección del modelo de ciclo de vida puede hacer que se nos retrase el trabajo enormemente o que tengamos una planificación perfecta del trabajo.

Tipos de modelos :

• Cascada pura
• Codificar y corregir
• Espiral
• Cascadas modificadas
• Prototipo evolutivo
• Entrega por etapas
• Diseño por planificación
• Entrega evolutiva
• Diseño por herramientas

Cascada Pura

Es el más antiguo de todos los modelos de ciclo de vida y sirve de modelo para otros modelos de ciclos de vida.

En un modelo en cascada un proyecto progresa a través de un secuencia ordenada de pasos que son :

Concepto del software.

• Análisis de requerimientos.
• Diseño global.
• Diseño detallado.
• Codificación y depuración.
• Prueba del sistema.

El modelo contiene una serie de etapas que no se solapan, y el proyecto se va revisando tras cada una de las etapas. Para poder pasar a la siguiente etapa se tiene que haber conseguido todos los objetivos de la etapa anterior, es un proceso secuencial.

Tiene una buena aplicación cuando el problema es estable y cuando se trabaja con metodologías técnicas conocidas. Este modelo será apropiado para la migración de una aplicación o a una versión de mantenimiento bien definida.

Con este modelo se tiene un seguimiento de todas las fases del proyecto y del cumplimiento de todos los objetivos marcados en cada etapa tanto de costes, fechas de entrega y lo más importante que pueden comprobar al final de cada etapa si el proyecto cumple todas las necesidades del usuario.

A su vez esto es un problema ya que si el usuario se da cuenta de que falta una tarea de la empresa en el proyecto una vez pasada esta etapa, el trabajo que hay que realizar se retrasa en fechas de entrega y el coste es mayor. Por lo tanto esto produce un fracaso en la industria ya que es reacio a las modificaciones de ultima hora.

Por este motivo se puede modificar el modelo en cascada pudiendo pasar de una etapa a la anterior, pero suele ser difícil ya que hay que rehacer la etapa anterior, este modelo es el ciclo de vida del salmón. Por lo tanto este es un modelo poco apropiado para proyectos con fecha de entrega corta, pero su rendimiento puede mejorar notablemente variando el modelo de la cascada pura.

Variaciones sobre el Ciclo de Vida en Cascada

El Ciclo de Vida en Cascada puede sufrir una serie de modificaciones para aumentar su eficiencia.

Una de estas variaciones puede ser El Sashimi o Cascada con fases solapadas, en el que para evitar algunos inconvenientes del modelo en cascada solapando sus etapas, pero este enfoque genera nuevos problemas ya que debido al solapamiento los hitos resultan más ambiguos y esto hace más difícil trazar el proceso correctamente.

Otra variación sobre el Ciclo de Vida en Cascada sería el Ciclo de vida en cascada con Subproyectos, en el que se permite la ejecución de algunas de las tareas de la cascada en paralelo, pero esta modificación tiene el problema que la planificación tiene que ser mucho más cuidadosa, aunque se gana velocidad.

Codificar y Corregir

El modelo codificar y corregir es el modelo utilizado cuando no nos paramos en buscar el modelo más idóneo para nuestro proyecto. Es decir en este modelo no se pierde el tiempo en la planificación, en la calidad, en los documentos que hay que realizar cuando se terminan etapas o en cualquier otra actividad que no sea la codificación. Por lo tanto este modelo no se necesita tener experiencia y una gran cantidad de conocimientos.

Al no seguir un modelo no tenemos ningún medio de ver si se cumplen las expectativas creadas, lo cual es un problema si encontramos un error casi al finalizar el proyecto ya que hay que empezar de nuevo. Por consiguiente tardamos más en ver los errores que en otro modelo que sigue un mínimo de planificación.

Espiral

El modelo de la espiral es un modelo orientado a riesgo que divide el proyecto software en miniproyectos. Cada proyecto se encargará de resolver uno o varios riesgos hasta que estén todos controlados. Una vez que estén los riesgos más importantes controlados se finaliza igual que el ciclo de vida en cascada.

En el ciclo de vida en espiral localizan los riesgos, genera un plan para manejarlos y se establece una aproximación a la siguiente iteración. Con cada iteración se produce una aproximación al producto final.

En el modelo en espiral se comienza con una parte pequeña del proyecto y se expande tras reducir los riesgos para la siguiente iteración.

En cada iteración seguimos los siguientes pasos :

• Determinar objetivos, alternativas y límites.
• Identificar y resolver riesgos.
• Evaluar las alternativas.
• Generar entregas de esta iteración, y comprobar que son correctas.
• Planificar la siguiente iteración.
• Si se decide ejecutar la siguiente iteración, hay que establecer un enfoque para ella.

En este modelo las primeras iteraciones son menos costosas y a medida que se avanza aumenta el coste.

Las ventajas de este modelo son :

• Se disminuyen los riesgos.
• Al final de cada iteración se obtienen los puntos de verificación.
• Se obtienen con anterioridad indicaciones de cualquier riesgo insuperable.

Las desventajas de este modelo son :

• Un aumento de costes.
• Es un modelo complicado de llevar a cabo porque exige una gestión concienzuda, atenta y unos conocimientos profundos.

Prototipo Evolutivo

Con el prototipo evolutivo se comienza diseñando y construyendo las partes más importantes de la aplicación en un prototipo que posteriormente se refinará y ampliará hasta que el prototipo se termine. Este prototipo será el software que se entregará al final.

Se utiliza cuando los requerimientos cambian con celeridad, cuando el cliente es contrario a facilitar los requerimientos y especificaciones o cuando no está clara la forma del área de aplicación.

Las ventajas de este prototipo son :

• Se generan signos visibles de progreso.
• Permite la modificación sobre la marcha.
• El cliente se va familiarizando con el nuevo entorno.

Y las desventajas de este prototipo son :

• Imposibilidad de conocer a priori el tiempo de desarrollo.
• La aproximación puede convertirse en excusa para realizar el desarrollo con el modelo de codificar y corregir.

Entrega por etapas

En este modelo se evita el problema del modelo en cascada de no terminar ninguna etapa del modelo hasta que este completamente finalizado. Tras el diseño global se puede implementar y entregar la aplicación en etapas.

La diferencia de este modelo con el prototipo evolutivo es que en este modelo conocemos exactamente que es lo que se va a construir.

Este modelo funciona exactamente igual que el de cascada en los tres primeras fases y en el diseño detallado se divide por etapas.

Sus principales ventajas son :

• Permite proporcionar una funcionalidad útil en manos del cliente sin tener la aplicación finalizada.
• Proporciona signos tangibles de progreso.

Su principal inconveniente es que este modelo no es viable sin una planificación adecuada.

Diseño por planificación

Es similar al modelo de entrega por etapas y es útil cuando el proyecto tiene un plazo concreto. Este modelo se utiliza cuando no se conoce si el producto se tendrá para la ultima entrega.

A diferencia del modelo de entrega por etapas, estas están ordenadas por orden de prioridad, así que la fecha tope aunque no hayamos terminado el proyecto estaremos seguros de haber cubierto las funcionalidades más importantes.

Entrega evolutiva

El modelo de entrega evolutiva ofrece el control que se obtiene con la entrega por etapas y la flexibilidad que se obtiene con el prototipo evolutivo. Este modelo puede ajustarse para proporcionar el control y la flexibilidad que se necesita.

Este modelo realmente se encuentra entre el prototipo evolutivo y la entrega por etapas ya que se van desarrollando versiones añadiendo funcionalidad a las anteriores y se le van mostrando al cliente. Este proceso se repetirá hasta agotar el tiempo, el presupuesto o hasta que el cliente este satisfecho.

Para poder empezar a desarrollar versiones deberemos haber diseñado el núcleo del sistema y su globalidad.

Este modelo se diferencia del prototipo evolutivo en el énfasis, no en la aproximación fundamental. En la entrega evolutiva se enfatiza en el núcleo del sistema que probablemente no será modificado por la realimentación del cliente.