Concluindo projetos
Não há nada mais gratificante do que vivenciar a conclusão de um projeto. Esse momento nos remete às sensações similares ao nascimento de um filho. É uma sensação satisfatória de dever cumprido, de metas alcançadas. Porém, não é fácil alcançar esse momento de satisfação, sem contar que existem projetos que jamais poderão ser finalizados.
Um projeto é construído a partir de sua base e sua estrutura fundamental estará assentada sobre esses fundamentos que permitirão a sustentação das demais estruturas que serão construídas ao longo do ciclo de vida do projeto. Caso essa fundação não seja bem alicerçada o projeto poderá ser lançado ao fracasso.
Pois bem, a primeira etapa na construção de um projeto que seja passível de conclusão é, que este, tenha seus marcos bem delimitados; suas metas devem ser claras e objetivas. A premissa principal para se alcançar um objetivo é saber qual é, exatamente, esse objetivo.
A elicitação de requisitos dentro da engenharia de software deve ser tratada como um fundamento básico para constituição de base sólida sobre a qual serão erigidos os pilares de sustentação de um projeto.
Os pilares de um projeto são os sub-projetos e processos que o complementam. A maioria desses sub-projetos e processos são intercalados e dependentes e a execução plena de cada um deles influenciará radicalmente na qualidade final do produto que está sendo desenvolvido. Por isso, devemos encarar esses elementos com todo cuidado e acompanhar a sua construção com a seriedade com que é executado o projeto em seu todo. Cada um desses elementos serão fundamentos básicos para que o todo esteja harmonizado, volto a lembrar! Dito isso, é bom ressaltar que em cada um desses elementos devemos atentar para a elicitação de requisitos e determinação das responsabilidades associadas a cada um desses elementos. Esse procedimento é fundamental para a determinação das fronteiras de cada um dos elementos que compõem um projeto.
A determinação de responsabilidades concernentes aos elementos do projeto é uma tarefa árdua, algumas vezes, fica difícil definir com precisão as fronteiras de ação de cada um desses elementos e tendemos a repetir responsabilidades ao logo de um processo de definição de fronteiras para a construção de um elemento.
Quando delimitamos mal essas fronteiras, caímos na armadilha da repetição desnecessária, da indefinição de responsabilidades e da imprecisão de conceitos.
Devemos ter o cuidado de fazer o usuário enxergar também essas responsabilidades e perceber que cada coisa nesse cenário deve ter o seu lugar. Na maioria das vezes, o usuário só consegue perceber o todo e, confusamente, tenta resolver todo o seu problema num processo só e no mesmo momento.
Com habilidade o analista de requisito deve fazê-lo entender que cada processo é um processo ‘limpo’ e objetivo. Sendo que seus objetivos e responsabilidades devem estar claramente definidos. Se essa premissa for negligenciada esse projeto estará fadado ao fracasso.


0 Comments:
Postar um comentário
<< Home