Hoje ao ler um livro sobre modelação utilizando o paradigma object oriented, deparei-me
com algo que me fez pensar uns minutos, não pude deixar de me rir, pois o que o autor
diz já o presenciei por diversar vezes em projecto.
Passo a citar:
" "The more complex the system, the more open it is to total breakdown".
Rarely would a builder think about addin a new sub-basement to an existing
100 - story building. Doing that would be very costly and would undoubedly invite
failure. Amazingly, users of sotware systems rarely think twice about asking for
equivalent changes. Besides they argue it it only a simple matter of programming. "
Depois continua a discução sobre a problemática da complexidade do software e
o seu impacto no software, custos prazos de entrega manutenção.
E agora a questão, como medimos a complexidade de um dado programa ?
O que isso nos permite inferir ?
Cumps
Luís
p.s. O livro: "Object Oriented Analysis and Design with Applications, Third Edition"
Subscrever:
Enviar feedback (Atom)
2 comentários:
"como medimos a complexidade de um dado programa ?"
Luís, essa deixou-me a pensar... então nada como visitar o meu amigo google!
software complexity metrics
revelaram-se palavras-chave interessantes para encontrar propostas de soluções para essa questão... :)
Viva Flávio :)
Já trocamos umas ideias sobre o assunto.
A questão, não está no quanto é dificl de obter o conhecimento.
Eu quando fiz a pergunta, já tinha uma ideia da resposta e já anda a avaliar algumas métricas e algumas ferramentas.
A questão, é mais, esta diárimanete somos confrontados com pedidos de estimativas, pedidos de alterações disto e daquilo.
Há que ter no nosso reportório de técnias um conjunto que nos permitam perante a gestão quantificar que o método X é mais complexo que o método Y. Deste modo Y levará muito mais tempo a modificar e o risco será muito maior.
Esta complexidade, entenda-se é unica e exclusivamente centrada no código, não contempla o negócio! Para a ferramenta é completamente transparente se é banca, se é seguro... Isto é puramente irrelevante, o que interessa, é saber quantos caminhos distintos de execução tem um dado método.
Que percentagem desses caminhos está coberta por testes "unitários".
E em função de pelo menos estas duas preocupações, conseguir perante a gestão apresentar argumentos que mostrem o risco que corremos, ou não.
No fundo trata-se de forma objectiva de ter uma maneira de medir. Há muitas como refereiste e bem, nem todas se aplicam a todas as situações, é algo que tem de ser estudado, que é critico para os projectos e que se formos a ver é descurado por completo.
O alerto e o repto vem neste sentido de nos consciencilizarmos do que há, do que já é feito e de como podemos melhorar o que nós fazemos todos os dias.
Enviar um comentário