Tenho meu lado acadêmico, mas infelizmente, as inúmeras viagens e compromissos pessoais me impedem de voltar a dar aulas, como o fiz na FGV-RJ e no MBI do NCE/UFRJ há vários anos. Mas sempre que posso estou palestrando em universidades.
Segundo SOMMERVILLE (2011), requisitos de um sistema são as descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais.
Dentre todas as engenharias, a engenharia de sistemas de software complexos ainda é a mais distante em termos de práticas, previsibilidade e eficiência, principalmente pelo aspecto ainda artesanal em que sistemas são construídos e as dificuldades em alavancar um processo fabril.
Claro que o correto é “Papéis e Responsabilidades” mas nesse caso fiz questão de escrever Irresponsabilidades porque é um erro muito comum nos desenvolvimentos de projetos.
E olha que não estamos falando de erros gramaticais!
As necessidades de negócio da empresa e consequentemente as demandas de projetos para a TI, na grande maioria dos casos, impacta um grande número de áreas e não só a área do demandante.
Algumas áreas de Tecnologia da Informação pecam, por mais irônico que possa parecer, achando que quem deve definir papeis e responsabilidades para a nova realidade demandada é o próprio demandante e isso acarreta em diversos problemas não só para a TI mas também para todas as áreas envolvidas e impactadas.
Mas quase sempre a TI é responsabilizada simplesmente porque é ela que implementa as mudanças.
A falta da definição clara de papéis e responsabilidades cria um problema para a própria TI e esse é um dos grandes desafios denominados “culturais” quando se implementa alguma modificação tecnológica ou sistêmica numa empresa.
Inicio este artigo falando sobre o ciclo de vida das ferramentas de desenvolvimento Oracle. Ciclo de vida, compreende um produto desde sua fase de lançamento, aquisição de maturidade através de inúmeras correções, patchsets e minipatches, até a sua completa substituição por uma nova versão/release, mudança de arquitetura ou o lançamento de um novo produto.
Outro dia recebi um e-mail muito interessante de um desenvolvedor, que recém-formado, se questionava sobre que tecnologias deveria se dedicar nos próximos anos. Debatemos o assunto pelo Skype e creio que um pequeno resumo do debate pode ser de interesse para outros desenvolvedores que estejam diante da mesma dúvida: como será o futuro do desenvolvedor?
Neste segundo artigo da série “Green Hat: conhecendo esta aquisição da IBM que revolucionará o mercado de testes” começamos com um questionamento que nos incomoda diariamente: a necessidade de aumentar a qualidade do software sem aumentar o tempo e o custo de desenvolvimento.
Este artigo é o primeiro de uma série chamada “Green Hat: conhecendo esta aquisição da IBM que revolucionará o mercado de testes” e visa mostrar, em poucas linhas, os benefícios das poderosas soluções oferecidas.
Você já deve ter tentando identificar, justificar e implantar alguma coisa por justamente não ter os “FATOS E DADOS” nas mãos.
Cá estou eu escrevendo sobre segurança da informação e sobre a importância emergencial de se modificar muito como se “escreve” códigos seguros.
