Provas Subjetivas: CESPE 2009 ANTAQ Analista de Informática
Fala, pessoal!
Há muito tempo não tinha feito uma prova tão bem feita como foi a prova da ANTAQ. Foi bem elaborada. Que pena que as questões de Direito me tiraram do páreo, entretanto é isso mesmo. É estudar o que erramos e melhorar!
Bom, o motivo do post é mostrar um possível texto para a redação exigida para o cargo 9 (Analista de Informática).
Antes de mostrar o texto, acredito que é interessante revisar os itens exigidos no comando da redação que está assim definido:
O MPS.BR, programa para melhoria de processo do software brasileiro, desenvolvido desde dezembro de 2003, é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX) e conta com o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).
Considerando a caracterização do MPS.BR apresentada acima, redija um texto dissertativo acerca da importância de requisitos no MPS.BR. Ao elaborar seu texto, aborde, necessariamente, a gerência de requisitos (GRE) e o desenvolvimento de requisitos (DRE), apresentando exemplos de requisitos funcionais e não funcionais.
Com isso, podemos revisar os seguintes itens:
- Gerência de Requisitos (GRE) do MPS.BR [1];
- Desenvolvimento de Requisitos (DRE) do MPS.BR; e
- Requisitos funcionais e não funcionais.
Gerência de Requisitos (GRE)
- Nível MR-MPS:
- G – Parcialmente Gerenciado
- Propósito:
- Gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
- Resultados esperados:
- GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;
- GRE 2. Os requisitos de software são aprovados utilizando critérios objetivos;
- GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;
- GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos;
- GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
- Equivalência CMMI:
- Gerência de Requisitos
Encontrei um resumo que resume bem a GRE [2]:
O principal objetivo da Gerência de Requisitos é controlar a evolução dos requisitos. O processo Gerência de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais e não-funcionais, bem como os requisitos impostos ao projeto pela organização. Para assegurar que o conjunto de requisitos acordados é gerenciado e fornece suporte às necessidades de planejamento e execução do projeto, a organização deve executar um conjunto de passos definidos e apropriados. Quando um projeto recebe requisitos de um fornecedor de requisitos – pessoa autorizada a participar de sua definição e a solicitar modificação –, estes devem ser revisados para resolver questões e prevenir o mau entendimento, antes que os requisitos sejam incorporados ao escopo do projeto. Quando o fornecedor de requisitos e a organização chegam a um acordo, é obtido um compromisso das demais partes interessadas sobre os requisitos. Outras atribuições do processo Gerência de Requisitos são documentar as mudanças nos requisitos e suas justificativas, bem como manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho em geral e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
Outra fonte interessante sobre esse processo é o artigo Desmistificando o MPS.BR – Gerência de Requisitos (GRE) [3] do blog do Samuel Luiz [4].
Desenvolvimento de Requisitos (DRE)
- Nível MR-MPS:
- D – Largamente Definido
- Propósito:
- Estabelecer os requisitos dos componentes do produto, do produto e do cliente.
- Resultados esperados:
- DRE 1. As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas;
- DRE 2. Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas;
- DRE 3. Um conjunto de requisitos funcionais e não-funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido, é definido e mantido a partir dos requisitos do cliente;
- DRE 4. Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, elaborados e alocados;
- DRE 5. Interfaces internas e externas do produto e de cada componente do produto são definidas;
- DRE 6. Conceitos operacionais e cenários são desenvolvidos;
- DRE 7. Os requisitos são analisados para assegurar que sejam necessários, corretos, testáveis e suficientes e para balancear as necessidades dos interessados com as restrições existentes;
- DRE 8. Os requisitos são validados.
- Equivalência CMMI:
- Desenvolvimento de Requisitos
Diferença entre os processos
A principal diferença dos processos é que o primeiro, Gerência de Requisitos (GRE), trata somente do gerenciamento e evolução dos requisitos dos produtos e componentes do produto do projeto e identifica inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Não foca o levantamento e especificação dos requisitos ou como eles serão validados. São essas lacunas que o processo Desenvolvimento de Requisitos (DRE) vem para fechar.
Síntese dos dois processos
Requisitos funcionais e não funcionais
Usando as definições do Sommerville [5], temos
- Requisitos funcionais: descrevem o que o sistema deve fazer. Eles dependem do tipo de software que está sendo desenvolvido, dos usuários a que o software se destina e da abordagem geral considerada pela organização ao redigir os requisitos. São declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas e como o sistema deve se comportar em determinadas situações. Em alguns casos, esses requisitos podem também estabelecer explicitamente o que o sistema não deve fazer.
- Requisitos não funcionais: são restrições sobre os serviços ou as funções oferecidos pelo sistema. Eles não estão diretamente relacionados às funções específicas fornecidas pelo sistema. Podem estar relacionados a propriedades como confiabilidade, tempo de resposta e espaço de armazenamento.
A Redação
Vamos agora como seria um exemplo de redação que pudesse responder ao comando da prova:
Os requisitos de software são muitos importantes, pois eles irão oferecer ao software o porquê de sua existência. Um requisito mal identificado, validado ou gerenciado pode afetar significadamente o tempo e o custo do desenvolvimento de uma aplicação. Sendo assim, o programa MPS.BR (Melhoria de Processos do Software Brasileiro) reservou dois processos para tratar dos requisitos de software, sendo eles funcionais ou não funcionais: Gerência de Requisitos (GRE) no nível G (Parcialmente Gerenciado) e Desenvolvimento de Requisitos (DRE) no nível D (Largamente Definido).
Logo no primeiro em seu primeiro nível de maturidade, nível G, o MPS.BR define a GRE, pois a empresa que decidir seguir o MPS.BR precisa saber de imediato gerenciar os requisitos dos seus projetos de software. A GRE foca o gerenciamento e a evolução dos requisitos dos produtos e componentes do produto do projeto e identifica inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Não define o levantamento e especificação dos requisitos ou como eles serão validados, que é justamente os resultados esperados pelo processo DRE que possui o objetivo de estabelecer os requisitos dos componentes do produto, do produto e do cliente.
Tanto a GRE quanto o DRE tratam de requisitos funcionais ou não funcionais. Os primeiros são requisitos que descrevem o que sistema deve fazer e, em alguns casos, o que não deve fazer. São exemplos desse tipo de requisitos são: o sistema a ser desenvolvido deve possibilitar o cadastramento dos dados pessoais dos clientes; emitir relatórios gerenciais; e deve permitir a baixa automática do estoque quando da venda de um produto.
Já os requisitos não funcionais são restrições sobre os serviços ou as funções oferecidos pelo sistema e ão estão diretamente relacionados às funções específicas fornecidas pelo sistema. Como exemplos para esses requisitos temos: o software deve permitir um sistema de autenticação e permissão; o tempo de resposta não deve ultrapassar 15 segundos; o aplicativo será construído utilizando a linguagem de programação Java; e o banco de dados será Oracle.
[]s e até a próxima!
Rogério Araújo
Blog: https://rogerioaraujo.wordpress.com/
Gmail: rgildoaraujo@gmail.com
O trabalho árduo e a disciplina são os meios mais rápidos de alcançar meus objetivos!!!
Eu posso, eu consigo! Eu acredito em mim!
Referências
[1] MPS.BR: http://www.softex.br/mpsbr/
[2] mpsbr-gre Gerência de Requisitos do MPS.BR: http://code.google.com/p/mpsbr-gre/
[3] Desmistificando o MPS.BR – Gerência de Requisitos (GRE): http://blogdosamueldiniz.blogspot.com/2009/03/desmistificando-o-mpsbr-gerencia-de.html
[4] Blog do Samuel Diniz: http://blogdosamueldiniz.blogspot.com/
[5] SOMMERVILLE, Ian. Software Engineering, 8ª Edição, Addison-Wesley, 2007
Show!
Num deixa de postar não, mestre =D
Abraço!
Bom texto Rogério.
É bom lembrar da dica do curso lá do tal de Moraes. Antes de fazer a redação fazer um mapa mental utilizando brainstorm.