Olá leitores
Hoje em dia, existem muitas pequenas empresas de tecnologia ( entenda como software, hardware, mídia digital etc. ) e departamentos de TI, onde princípios de um bom gerenciamento técnico de suas “atividades” são completamente deixados de lado.
O fluxo de trabalho de empresas pequenas ou departamentos de T.I. geralmente não estão relacionadas à projetos ( temporais - inicio - meio - fim ), e sim manutenções constantes em projetos que surgiram apenas de uma idéia e em seguida ja sua implementação, tornando-se Franksteins . Existem exceções sem dúvida, e essas conseguem destaque diante das outras que possuem processos mal definidos em relação ao desenvolvimento de seus produtos ou serviços.
Uma empresa de tecnologia de pequeno porte ou um departamento de TI, não precisa necessariamente seguir todas as etapas do PMBOK para realizar seus projetos, mas podem extrair algumas para melhorar muito esse cenário.
Já cansei de ouvir colegas de profissão dizer que a empresa em que trabalha não possui sequer uma documentação decente em relação aos sistemas existentes, muitos deles na verdade afirmam que não existem nenhuma documentação, controle, processo de qualidade,etc. Resumindo, esses departamentos ou empresas são fabricas de Xarxixo, que criam “profissionais” que acham que para desenvolver um software ou sistema , basta sentar o rabo na cadeira e começar a programar. Para isso que existe metodologias de desenvolvimento.
Papeis são completamente ignorados nessas entidades. O analista de sistemas é obrigado muitas vezes a trocar bolinha de mouse. Isso não existe quando metodologias são incorporadas à empresa. No RUP, o analista de sistemas não desenvolve, o analista de negócios não faz analise do sistema, o desenvolvedor não faz análise do sistema nem de negócio.
O conhecimento do negócio nessa visão, fica na mão do analista/programador/servecafézinho, que é aquele sujeito que desenvolveu tudo sozinho, sem nenhuma documentação e que quando resolver sair da empresa, da uma bela preocupação para o empregador, pois esta na cabeça desse sujeito todas as regras do sistema e POG�s ( programação orientada a gambiarra ).
Quem se da mal nisso tudo é o seu sucessor, que é obrigado a desvendar os misteriosos algoritmos para fazer algo funcionar corretamente, e que muitas vezes, chega à conclusão de que é mais fácil apagar tudo e refazer do que “dar manutenção”. Mas existem soluções para se evitar isso, como o RUP.
O RUP é apoiado e utilizado por empresas reconhecidas e embora a sua aplicação seja trabalhosa, vale a pena pela organização, maior facilidade de manutenção/integração de novos módulos e rastreabilidade.
O workflow no cenário RUP inicia-se no analista de negócios. É ele é quem realiza o levantamento das necessidades do cliente e transforma essas necessidades em casos de uso de negocio.
Define também uma lista de requisitos e as classifica. A partir deste ponto esses requisitos passam para o analista de sistemas para a definição de escopo do sistema e etc.
Vamos focar no papel “analista de negócios”, mas especificamente no levantamento de requisitos do sistema, pois caso essa etapa seja feita de forma errada, é possível que o restante também seja (se o analista de sistemas e gerente do projeto forem umas topeiras e não enxergarem o erro).
Existem diversas formas de classificar os requisitos. O RUP define-as como Funcional e Não Funcional.
Um requisito funcional descreve as funcionalidades de um sistema não levando em consideração restrições físicas, e um requisito não funcional o contrário.
Exemplo:
Um cliente X precisa de um software que cadastre os seus empregados.
No caso de uso - cadastrar cliente.
Tipo de requisito - Funcional
Para este software que cadastra o cliente funcionar, será necessário um 486 com 32mb de RAM
No caso de uso - Não é possível a descrição
Tipo de requisito - Não Funcional
Os requisitos não funcionais não podem ser descritos com casos de uso. Em alguns casos isso é possível, mas especificamente para isso, o RUP dispõe da “especificação suplementar”, que é aonde requisitos não funcionais podem ser detalhados utilizando as classificações abaixo descritas, também conhecidas como FURPS (acrônimo):
- Funcionalidade
- Usabilidade
- Confiabilidade
- Desempenho
- Suportabilidade
Abaixo segue o link onde cada tópico desse pode ser descrito com maiores detalhes.
http://www.wthreex.com/rup/process/workflow/requirem/co_req.htm
Um simples levantamento de requisitos já pode ajudar em muito na documentação e na garantia de que o sistema não perderá o seu foco. Ajuda a evitar o que aconteceu na ilustração abaixo
[ ] ‘ sss
Adicione ->
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
