[Metodologias Ágeis] Padrões de Qualidade de Software – MPS Br x CMMI e a realidade Brasileira
Padrões de Qualidade de Software – MPS Br x CMMI e a realidade Brasileira: "
Falar sobre um processo de desenvolvimento de software nem sempre é uma coisa fácil, porque esse é um assunto considerado muito teórico por uns e de difícil compreensão por outros. No entanto sabe-se da experiência diária que estabelecer um processo adequado, minimamente gerenciado para o desenvolvimento de software hoje não é mais simplesmente um diferencial e sim uma exigência.
Nesse contexto, a Associação para Promoção da Excelência do Software Brasileiro – Softex - em parceria com orgãos das iniciativas privada e pública, além de universidades por todo o país mantém um modelo de melhoria do processo de software brasileiro, o MPS-Br. Um dos objetivos desse modelo de processo é capacitar empresas desenvolvedoras de software para que adotem um processo que lhes permita a construção de sistemas de qualidade.
Esse modelo surgiu a partir de uma análise realizada, onde constatou-se que as empresas brasileiras tinham uma baixa participação no mercado mundial de desenvolvimento de software. Observou-se que esse baixo índice era devido a falta de capacitação dos processos de desenvolvimento adotados pelas empresas brasileiras, que por sua vez não se capacitavam em função do alto custo para se obter certificação CMMI (Capability Maturity Model Integration), considerado o modelo de maturidade de processo de software referência no mundo. O MPS-Br com custos bem mais baixos permitiu então que, a partir de 2003, as empresas brasileiras pudessem se capacitar e comprovar a maturidade dos processos de desenvolviomento adotados.
O MPS-Br é composto por diversos subprocessos que compõem o processo de desenvolvimento de sistemas. Dentre eles está o subprocesso de Gestão de Requisitos – GRE. Em nossa apresentação, optamos por comentar brevemente sobre duas atividades entre as cinco definidas no Guia Geral do MPS-Br para o subprocesso de Gerência de Requisitos:
Levantamos a importância de se manter a rastreabilidade entre requisitos, definindo-a como sendo a capacidade de manter links entre um requisito definido e todos os produtos de trabalho que são gerados ao longo da execução do projeto, como por exemplo, modelos de sistemas, classes em códigos fonte, casos de teste, etc. Além disso, também falamos sobre a importância da execução de uma atividade de gestão dos requisitos ao longo do projeto, considerando que o conjunto de requisitos inicialmente levantados sofre diversas alterações ao longo do processo. Logo, é necessário que controlemos essas alterações definindo prioridades, alocando recursos necessários para sua execução e delegando responsabilidades de realização de cada uma.
Finalmente, comentamos sobre o processo de levantamento de requisitos dentro de do modelo ágil Scrum usando a analogia do acrônimo INVEST, que define que um requisito seja:
I – Independente
N – Negociável
V – Valorável (valor que o requisito agrega ao sistema)
E - Estimável
S – Small
T – Testável
Falamos que, para levantar requisitos no momento da construção do sprint backlog, é fortemente recomendado que se analise o requisito definido de acordo com esses itens. Se qualquer um deles não puder ser satisfeito temos um forte indício de que a especificação não está bem definida e que uma nova análise deve ser feita.
Concluindo, um modelo pioneiro de qualidade de software como o MPS-Br é muito interessante para que consigamos uma melhora na qualidade de nossos processos de desenvolvimento, desencadeando uma melhora nos produtos de nosso processos: produtos mais estáveis, e uma melhor satisfação do cliente.
Escrito por: Marcelo Matos da equipe da 2XT
"
Falar sobre um processo de desenvolvimento de software nem sempre é uma coisa fácil, porque esse é um assunto considerado muito teórico por uns e de difícil compreensão por outros. No entanto sabe-se da experiência diária que estabelecer um processo adequado, minimamente gerenciado para o desenvolvimento de software hoje não é mais simplesmente um diferencial e sim uma exigência.
Nesse contexto, a Associação para Promoção da Excelência do Software Brasileiro – Softex - em parceria com orgãos das iniciativas privada e pública, além de universidades por todo o país mantém um modelo de melhoria do processo de software brasileiro, o MPS-Br. Um dos objetivos desse modelo de processo é capacitar empresas desenvolvedoras de software para que adotem um processo que lhes permita a construção de sistemas de qualidade.
Esse modelo surgiu a partir de uma análise realizada, onde constatou-se que as empresas brasileiras tinham uma baixa participação no mercado mundial de desenvolvimento de software. Observou-se que esse baixo índice era devido a falta de capacitação dos processos de desenvolvimento adotados pelas empresas brasileiras, que por sua vez não se capacitavam em função do alto custo para se obter certificação CMMI (Capability Maturity Model Integration), considerado o modelo de maturidade de processo de software referência no mundo. O MPS-Br com custos bem mais baixos permitiu então que, a partir de 2003, as empresas brasileiras pudessem se capacitar e comprovar a maturidade dos processos de desenvolviomento adotados.
O MPS-Br é composto por diversos subprocessos que compõem o processo de desenvolvimento de sistemas. Dentre eles está o subprocesso de Gestão de Requisitos – GRE. Em nossa apresentação, optamos por comentar brevemente sobre duas atividades entre as cinco definidas no Guia Geral do MPS-Br para o subprocesso de Gerência de Requisitos:
- GRE 3: A rastrebailidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;
- GRE 5: Mudanças de requisitos são gerenciadas ao longo do projeto.
Levantamos a importância de se manter a rastreabilidade entre requisitos, definindo-a como sendo a capacidade de manter links entre um requisito definido e todos os produtos de trabalho que são gerados ao longo da execução do projeto, como por exemplo, modelos de sistemas, classes em códigos fonte, casos de teste, etc. Além disso, também falamos sobre a importância da execução de uma atividade de gestão dos requisitos ao longo do projeto, considerando que o conjunto de requisitos inicialmente levantados sofre diversas alterações ao longo do processo. Logo, é necessário que controlemos essas alterações definindo prioridades, alocando recursos necessários para sua execução e delegando responsabilidades de realização de cada uma.
Levantamento de Requisitos em Metodologias Ágeis
Finalmente, comentamos sobre o processo de levantamento de requisitos dentro de do modelo ágil Scrum usando a analogia do acrônimo INVEST, que define que um requisito seja:
I – Independente
N – Negociável
V – Valorável (valor que o requisito agrega ao sistema)
E - Estimável
S – Small
T – Testável
Falamos que, para levantar requisitos no momento da construção do sprint backlog, é fortemente recomendado que se analise o requisito definido de acordo com esses itens. Se qualquer um deles não puder ser satisfeito temos um forte indício de que a especificação não está bem definida e que uma nova análise deve ser feita.
Concluindo, um modelo pioneiro de qualidade de software como o MPS-Br é muito interessante para que consigamos uma melhora na qualidade de nossos processos de desenvolvimento, desencadeando uma melhora nos produtos de nosso processos: produtos mais estáveis, e uma melhor satisfação do cliente.
Escrito por: Marcelo Matos da equipe da 2XT
"
Comentários
Postar um comentário