Eric Evans, compilou uma série de técnicas e conceitos de desenvolvimento de software, está nova abordagem visa um maior entendimento do negócio.
Um software está sempre relacionado com a necessidade, negócio ou atividade diária de seus usuários. Essa área de interesse onde o usuário aplica o programa é denominada domínio. Se o software é utilizado para em um sistema de controle aéreo seu domínio é o controle de aviões, se é utilizado para fazer matrículas de alunos de uma escola, seu domínio é o cadastro de alunos, o domino é a área na qual o software é aplicado.
É fundamental entender que o software está intimamente relacionado com o seu domínio, ou seja, o sistema deve se comportar de modo que reflita o problema que se propõem a resolver, está é, a principal razão pela qual é projeto e desenvolvido.
Para que um software possa trazer benefícios aos patrocinadores e usuários que o utilizarão, a equipe de desenvolvimento deve ter um bom conhecimento do domínio em que o sistema está inserido.
Como o desenvolvimento de software está ligado com o mundo real, seu desenvolvimento se assemelha a construção de um objeto real. A exemplo de uma montadora de veículos, é feita uma analise sobre o carro, sua aerodinâmica, projeto interno, designer externo, centro de gravidade, tipo de uso do veículo. Após a análise uma equipe trabalha na construção do carro, essa equipe tem uma visão limitada do que é na verdade construir um automóvel. Esta equipe sabe apenas que tem algumas peças e que deve juntá-las para que no final tenha um produto funcional. Mas um carro é mais do que isso, é construído através de um projeto que foi reformulado centena de vezes durante anos ate atingir a perfeição, somente após vários testes em situações críticas suas peças foram construídas e o projeto formulado.
Existem algumas semelhanças no desenvolvimento de um software e no exemplo acima. O desenvolvedor não pode simplesmente, sentar e desenvolver o sistema sem antes conhecer o seu domínio. É mais difícil criar um sistema com qualidade, sem saber como o sistema deve se comportar dentro do negócio que está sendo aplicado. Para entender o domínio de um software contamos com a ajuda dos especialistas de negócio que pode ser um analista de negocio, um steakholder que tenha um grande conhecimento do negócio ou usuários do sistema que trabalham no dia a dia com o negócio e tenha vivência de diversas situações que o domínio oferece, estas são as melhores pessoas para nos dizer o que deve ser feito e como o sistema deve se comportar em cada situação.
A quantidade e a complexidade de informações passada por um analista de negócio pode ser imensa, e para entendemos melhor essas informações e o domínio do problema podemos contar com a ajuda de um modelo.
Segundo Evans (Evans, 2004) um modelo é:
“Um sistema de abstrações que descreve determinados aspectos de um domínio e que pode ser usado para resolver problemas relacionados aquele domínio.”
Um modelo não é simplesmente um diagrama da UML embora sua representação possa ser expressa por um. Modelo é um conjunto de conceitos formado pelas pessoas que estão envolvidas no projeto com termos que refletem o domínio.
O software precisar ser a representação do domínio e se não for plenamente baseado no domínio, não será capaz de se adaptar as mudanças do negócio ao qual está relacionado.
Para temos uma boa comunicação com os especialistas utilizaremos a linguagem onipresente.
Um software está sempre relacionado com a necessidade, negócio ou atividade diária de seus usuários. Essa área de interesse onde o usuário aplica o programa é denominada domínio. Se o software é utilizado para em um sistema de controle aéreo seu domínio é o controle de aviões, se é utilizado para fazer matrículas de alunos de uma escola, seu domínio é o cadastro de alunos, o domino é a área na qual o software é aplicado.
É fundamental entender que o software está intimamente relacionado com o seu domínio, ou seja, o sistema deve se comportar de modo que reflita o problema que se propõem a resolver, está é, a principal razão pela qual é projeto e desenvolvido.
Para que um software possa trazer benefícios aos patrocinadores e usuários que o utilizarão, a equipe de desenvolvimento deve ter um bom conhecimento do domínio em que o sistema está inserido.
Como o desenvolvimento de software está ligado com o mundo real, seu desenvolvimento se assemelha a construção de um objeto real. A exemplo de uma montadora de veículos, é feita uma analise sobre o carro, sua aerodinâmica, projeto interno, designer externo, centro de gravidade, tipo de uso do veículo. Após a análise uma equipe trabalha na construção do carro, essa equipe tem uma visão limitada do que é na verdade construir um automóvel. Esta equipe sabe apenas que tem algumas peças e que deve juntá-las para que no final tenha um produto funcional. Mas um carro é mais do que isso, é construído através de um projeto que foi reformulado centena de vezes durante anos ate atingir a perfeição, somente após vários testes em situações críticas suas peças foram construídas e o projeto formulado.
Existem algumas semelhanças no desenvolvimento de um software e no exemplo acima. O desenvolvedor não pode simplesmente, sentar e desenvolver o sistema sem antes conhecer o seu domínio. É mais difícil criar um sistema com qualidade, sem saber como o sistema deve se comportar dentro do negócio que está sendo aplicado. Para entender o domínio de um software contamos com a ajuda dos especialistas de negócio que pode ser um analista de negocio, um steakholder que tenha um grande conhecimento do negócio ou usuários do sistema que trabalham no dia a dia com o negócio e tenha vivência de diversas situações que o domínio oferece, estas são as melhores pessoas para nos dizer o que deve ser feito e como o sistema deve se comportar em cada situação.
A quantidade e a complexidade de informações passada por um analista de negócio pode ser imensa, e para entendemos melhor essas informações e o domínio do problema podemos contar com a ajuda de um modelo.
Segundo Evans (Evans, 2004) um modelo é:
“Um sistema de abstrações que descreve determinados aspectos de um domínio e que pode ser usado para resolver problemas relacionados aquele domínio.”
Um modelo não é simplesmente um diagrama da UML embora sua representação possa ser expressa por um. Modelo é um conjunto de conceitos formado pelas pessoas que estão envolvidas no projeto com termos que refletem o domínio.
O software precisar ser a representação do domínio e se não for plenamente baseado no domínio, não será capaz de se adaptar as mudanças do negócio ao qual está relacionado.
Para temos uma boa comunicação com os especialistas utilizaremos a linguagem onipresente.
Nenhum comentário:
Postar um comentário