Aproveitei e fiz uma traduçãozinha de cada quadro. Espero que gostem.

Segue a url para o documento na íntegra de David Seaver sobre FAST Function Points.
http://sunset.usc.edu/Activities/oct24-27-00/Presentations/Seaver_FAST Function Points.pdf

A meu ver, o principal papel do CIO é conseguir colocar a máquina corporativa funcionando, ou seja, melhorar a comunicação entre equipes e alinhar o pensamento de todos rumo a objetivos comuns.

Seguem os links para os textos de Miriam Vasco.

• Parte 1 – O Perfil do CIO: uma equação!

• Parte 2 – O Perfil do CIO: uma equação!

• Parte 3 – O Perfil do CIO: uma equação!

O amadurecimento na avaliação dos processos de negócio, e a forma com que as melhorias e evoluções dos mesmos podem ser realizadas, são objetos de estudo de pesquisadores desde o início da década de 50. As adequações e mudanças nos processos devem poder refletir as decisões gerenciais em tempo hábil de forma que a empresa não perca espaço em seu mercado atuante. É nesse contexto que a tecnologia da informação vem sendo aplicada: no sentido de aperfeiçor, agilizar e facilitar a BPM.

A problemática do Gerenciamento de Processos de Negócio foi bem ilustrada por Howard Smith e Peter Fingar em seu livro Business Process Management: The third Wave, onde não somente ilustram a evolução do pensamento acerca da BPM como também propõem uma nova abordagem sobre o assunto, integrando os conceitos da melhoria contínua e da reengenharia e transformando os trabalhos de processos em programas contínuos de gestão. A chamada Terceira Onda (Third Wave), também foca na importância da aplicação da tecnologia como ferramenta auxiliar tanto no mapeamento como também na execução e no monitoramento do desempenho dos processos.

O ideal de um Sistema de Informação voltado para BPM é que fosse criado de acordo com a concepção de BPMS. Porém, soluções completas de BPMS (Business Process Management Software) aplicando definições como as encontradas nas publicações do Gartner Group, ainda não são facilmente encontradas em implantação. Segundo Vinícius Amaral, atualmente espera-se de uma verdadeira solução de BPMS que:

1. Seja aderente aos padrões da área (BPMN, BPEL e/ou BPML);

2. Permita modelar processos de negócio, podendo também simulá-los e documentá-los extensivamente;

3. Tenha componentes prontos para integração com sistemas heterogêneos. Integrações via Web Services, JMS e JCA são básicas, sendo esperados mecanismos prontos para conectar com ERPs (SAP, Peoplesoft, Oracle E-Business Suite etc.);

4. Possua componente de BAM (Business Activity Monitoring) ou integre-se nativamente a um produto deste tipo. Uma solução de BAM monitora em tempo real os indicadores dos processos, e permite que os gestores tomem ações corretivas imediatamente;

5. Possua componente de BRM (Business Rules Management) ou integre-se nativamente a um produto deste tipo. Um BRM permite separar as regras dos processos do código de aplicação, permitindo que usuários de negócios configurem estas regras de forma ágil e transparente;.

Hoje, podemos contar no mercado com soluções que atendam isoladamente os pontos acima e agregá-las de forma que tenhamos sistemas que venham a contribuir agregando valor às etapas da BPM.

Sendo assim, vemos os Sistemas de Informação como peças chaves junto a BPM à medida que fornecem meios para a análise, medição, tomadas de decisões, e rápida modificações nos processos mapeados.

Referências

AMARAL, V. Bpm – afinal, o que é (e o que não é) isso? iProcess. Disponível em: <http://www.iprocess.com.br/artigos/1.htm>. Acesso em: 28 jun. 2009.

SMITH, P. F. H. Business Process Management: The third Wave. São Paulo: Meghan Kiffer Pr, 2003.

Na minha opinião, a metodologia a ser adotada deve ser analisada de acordo com o retorno a ser obtido com a adoção da mesma e das características intrínsicas do projeto a ser desenvolvido.

Leia por meio do link abaixo o artigo de Luiz Claudio Parzianello na íntegra.

Reflexões de um agilista …: Compreender a natureza dos requisitos pode estimular a adoção de metodologias ágeis.

Lendo hoje sobre testes e o retorno sobre investimento nos mesmos, me deparei com duas publicações nos blogs abaixo que achei interessante postar aqui. O autor do post original, Clavius Tales, propõe uma curva para análise do quanto se deve testar em um sistema de software de forma que o custo benefício seja maior em função da natureza do software produzido. Apesar da abordagem não científica, a discussão levantada pelo autor atinge o propósito de causar a reflexão no leitor sobre o assunto.

quanto testar « Clavius Tales.

Quanto testar? – CMilfont Tech.

Abraços

Bruno Guimarães

Novos tempos. Novas tecnologias. Novas idéias. Novas formas de pensar.

Com o advento das novas filosofias de desenvolvimento, a mensagem proveniente da indústria de Tecnologia da Informação não poderia ser mais clara: aprenda, aplique, critique, evolua. Nossa sopa de letrinhas só aumenta (PMI, CMMI, COBIT, ITIL, BPM, RUP, SCRUM, XP, etc) e a melhor forma de utilizar todo esse conhecimento de forma a realmente agregar valor em investimentos de TI acaba ficando um pouco nebulosa.

Comecei esse blog na intenção de ter um espaço em que pudesse compartilhar a minha experiência em desenvolvimento de software utilizando várias dessas tecnologias citadas, apresentar casos de estudo, e expor algumas idéias a fim de que estas possam ser criticadas e analisadas por colegas da área. Tudo isso tendo sempre em mente a busca da melhor forma de agregar valor à investimentos em TI.

Todo comentário é bem-vindo. Minha intenção é que esse possa ser um espaço de aprendizado mútuo.

Abraços,

Bruno Guimarães