Modelagem de Negócio é uma das 9 disciplinas do RUP e a primeira das 6 consideradas “core disciplines”. Dentro do ciclo de desenvolvimento de software podemos dizer que essa é sem dúvida a disciplina menos praticada.
Como o próprio nome diz a Modelagem de Negócio tem um foco na organização e em seu funcionamento, o que antecede a criação de qualquer sistema. Para quem conhece ou trabalha em empresas certificadas pela ISO 9001, segue processos do ITIL ou mesmo do CMMI fica fácil entender o papel da modelagem de negócio. Todas essas certificações exigem processos e métodos de trabalho claros, institucionalizados e publicados,
suportados ou não por sistemas de TI.
O RUP não define a modelagem de negócio como uma disciplina obrigatória, mas recomenda fortemente que ela seja executada especialmente para empresas que estão iniciando um novo negócio e não possuam uma clara modelagem do negócio. Esse conselho é extremamente valioso e posso dizer por experiência própria que é fundamental para o sucesso de um projeto de desenvolvimento de software. Há alguns anos atrás participei de um projeto cujo objetivo era suportar o processo de vendas de uma nova rede de lojas. Por ser um negócio novo nem mesmo o proprietário da empresa sabia como o negócio iria funcionar e a tentativa de levantar requisitos sob algo totalmente volátil foi catastrófico na fase de requisitos e conseqüentemente de desenvolvimento aonde mudanças chegavam a toda hora.
Diante desse cenário o objetivo da modelagem de negócio fica claro: não tente desenvolver um sistema para um negócio que não é claramente definido, pois seu sistema sem dúvida não poderá informatizar um processo que não existe ou não é consistente.
Para quem está estudando para a certificação 839 ai vai a dica: entenda(para não dizer decore) claramente os propósitos de todas as disciplinas. As finalidades da modelagem de negócio são:
- Entender os problemas da organização identificando as possíveis melhorias;
- Avaliar o impacto de mudanças na organização;
- Assegurar que os clientes, usuários, desenvolvedores e outros parceiros tenham uma compreensão comum da organização;
- Gerar conteúdo para a fase de requisitos do sistema que suportará a organização e seus processos;
- Entender como o software se ajustará à organização.
Veja a WBS da disciplina e consulte o RUP para aprofundar em cada uma das atividades do fluxo:
Work ProductsVeja também
alguns dos Work Products gerados nessa disciplina:
- Business Vision;
- Business Architecture Document;
- Supplementary Business Specification;
- Business Rules;
- Business Glossary.
RolesAbaixo as Roles envolvidas na disciplina:
- Business Process Analyst;
- Business Architect;
- Business Designer;
- Technical Reviewer.
Imagine iniciar a fase de levantamento de requisitos com toda a modelagem de negócio definida! Sem dúvida a estabilidade dos requisitos seria muito maior além de facilitada pelo comum entendimento de negócio. Uma boa dica é solicitar ao cliente que entregue esse tipo de definição, especialmente para empresas certificadas ISO 9001 que já possuem todo o processo escrito e definido. Também não tente desenvolver um sistema caso perceba que o negócio não está claramente definido ou em mudança. Um erro comum é tentar aproveitar o desenvolvimento de um sistema para modelar ou mudar o negócio(RISCO!).
Não deixe de explorar a disciplina através do RUP entendendo o fluxo da WBS, os principais Work Products e as Roles envolvidas.
Para quem ainda não tem o RUP instalado na máquina faça o
download do RMC Trial que possui o RUP 7.2
SimuladosAbaixo algumas questões de simulados para a prova 839 relacionadas a essa disciplina:
1. Which of the following statements is true about Business Modeling? (Select all that apply.)
a. Supports the derivation of software requirements
b. Is not always mandatory
c. Aligns the corporate business strategy with software development
d. Replaces the requirements discipline for business-driven software projects
RESP: ABC
2. Which of the following roles is part of Business Modeling? (Select all that apply.)
a. System Analyst
b. Business Process Analyst
c. Business Architect
d. Test Architect
RESP: BCD
Qualquer dúvida ou sugestão post um comentário ou entre em contato fernando.dantas@gmail.com).
Postagens
