Espacios. Vol. 34 (10) 2013. Pág. 13


Conceitos de análise de requisitos de software à luz da aprendizagem significativa

Concepts of software requirements analysis in the light of significant learning

Sheila Cristiana de FREITAS 1 y Antonio Carlos de FRANCISCO 2

Recibido: 25-07-2013 - Aprobado: 20-08-2013


Contenido

Gracias a sus donaciones esta página seguirá siendo gratis para nuestros lectores.
Graças a suas doações neste site permanecerá gratuito para os nossos leitores.
Thanks to your donations this site will remain free to our readers.

RESUMO:
Neste artigo será apresentada uma estratégia de ensino utilizada na elaboração de uma aula para ensino dos conceitos de análise de requisitos de software, utilizando como ferramenta a aprendizagem significativa, segundo Ausubel. A referida teoria se apóia na construção de novos conceitos a partir de ancoragem de conceitos pré-existentes na estrutura cognitiva do aprendiz. Os conceitos pré-existentes são chamados de subsunçores, porém quando o conteúdo a ser ensinado é totalmente novo, eles podem ainda não existir. Neste caso Ausubel sugere em sua teoria o uso de organizadores prévios. A pesquisa realizada em uma turma do curso técnico em informática na modalidade subseqüente apresenta uma estratégia utilizada na preparação da aula onde foca a seleção do material, a preparação dos organizadores prévios e a busca por subsunçores.
Palavras-chave: Aprendizagem significativa, Organizadores prévios, Análise de requisitos, Ensino.

ABSTRACT:
In this article we will present a teaching strategy used for preparation of a lesson teaching the concepts of software requirements analysis, using as a meaningful learning tool second Ausubel. That theory is based on the construction of new concepts from anchoring pre-existing concepts in the cognitive structure of the learner. The pre-existing concepts are called subsumers, but when the content to be taught is totally new, they may not yet exist. In this case Ausubel suggests in his theory using previous organizers. The research carried out in a class of computer technician course in subsequent modality presents a strategy used in the preparation of lesson where seal material selection, preparation of previous organizers and the search for subsumers.
Keywords: Meaningful learning, Advance organizers, Requirements analysis, Teaching.


1. Introdução

Cada vez que um professor prepara uma aula, mesmo de conteúdos que já tenha ministrado em outro momento, surgem questões que colocam em dúvida se os alunos irão construir seus conceitos, e se o professor selecionou seu conteúdo de forma coerente. Neste sentido, pode-se observar que os professores buscam por estratégias que contribuam para que cada aula tenha sua real importância, identificando mecanismos que possam auxiliar a preparação de aula é que este artigo traz uma estratégia utilizando a teoria da aprendizagem significativa de Ausubel para os conceitos sejam trabalhados de forma individual e significativa no ensino dos conceitos de análise de requisitos de software.

De acordo com com (SWEBOK, 2004) a análise de requisitos relaciona os processos:

•Detectar e resolver os conflitos entre os requisitos.

•Descobrir os limites do software e como ele deve interagir com seu meio ambiente.
•Requisitos de sistema elaborado para derivar requisitos de software.

Porém para que o aluno compreenda os processos que envolvem a análise de requisitos primeiramente deverá ser apresentado aos conceitos técnicos que são utilizados para o desenvolvimento desta atividade. Para alguns alunos, talvez a maioria, os conceitos são totalmente novos e os mesmos terão que empenhar esforços para “aprender”.

Neste artigo esta sendo proposta uma estratégia de ensino utilizada na elaboração de uma aula para ensino dos conceitos de análise de requisitos de software, utilizando como ferramenta a aprendizagem significativa, segundo Ausubel. Para Moreira e Masini (2011, p. 14), a “aprendizagem significativa processa-se quando o material novo, idéias e informações que apresentam uma estrutura lógica, interagem com conceitos relevantes e inclusivos, claros e disponíveis na estrutura cognitiva”.

Ausubel em sua teoria sugere o uso de organizadores prévios quando o material é totalmente novo, e levando em consideração que o trabalho foi desenvolvido em uma sala de aula onde se encontram diversidade de conhecimentos, optou-se em propor o uso de material desenvolvido como organizadores prévios.

2. Aprendizagem significativa

Para Ausubel (1976) a aprendizagem significativa ocorre quando um novo conceito é relacionado de maneira não arbitrária e não literal a conceito já existe na estrutura cognitiva do aprendiz. Na abertura do livro “Psicología Educativa – Um punto de vista cognoscitivo” é preciso em suas palavras:

Se eu tivesse que reduzir toda a psicologia educacional, em um princípio único, enunciaria este: de todos os fatores que influenciam a aprendizagem, o mais importante consite no que o aprendiz já sabe. Verificar isso, é consequentemente ensinar. (AUSUBEL, 1976, p.6)

De uma forma geral a situação de aprendizagem destina-se a dar um novo tratamento ao conteúdo que será objeto de estudo. O professor trará para o aluno algo que deverá se relacionar com o mundo particular de conhecimentos deste. Para Martins (2009, p.23) “terá sempre como objetivo central estabelecer relação entre os conhecimentos prévios dos alunos e as informações novas que irão descobrindo no estudo do objeto ou do fato”.

Para que a aprendizagem seja significativa cabe ao professor refletir sobre a maneira com que está conduzindo seus alunos para estes possam construir seus conceitos.

Segundo Moreira e Masini (2011, p. 12): “é significativa uma situação do ponto de vista fenomenológico, quando o indivíduo decide de forma ativa, por meio de uma ampliação e aprofundamento da consciência, por sua própria elaboração e compreensão”.

Cada aluno possui suas limitações e particularidades na forma de adquirir conhecimentos. Conscientes das diversidades existentes em sala de aula o professor deve buscar mecanismo que possam auxiliar seus alunos a tornar a sua aprendizagem significativa, de modo que, ao final de uma aula ou de um módulo de conteúdo, este seja capaz de expressar e representar o conhecimento adquirido.

Ausubel coloca como ideia central da sua teoria, a importância sobre o que o aluno já sabe, pois a aprendizagem significativa nasce a partir de conceitos que são formados e elencados a outros que já existem na estrutura cognitiva do indivíduo. O aluno irá associar os novos conceitos a conceitos antigos, ou seja, conceitos que já fazem parte da sua estrutura cognitiva, e estes conhecimentos são chamados por Ausubel de subsunçores ou conceito subsunçor. De acordo com Moreira (1999, p. 11) “O subsunçor é, portanto, um conceito, uma idéia, uma proposição, já existente na estrutura cognitiva, capaz de servir de ancoradouro a uma nova informação de modo que esta adquira, assim, significado para o sujeito”.

Porém existem situações em que o conteúdo seja totalmente novo, e neste caso o aluno não teria subsunçores que possam ser ancorados. Neste caso, segundo Moreira e Masini (2011, p. 21) “recomenda-se o uso de organizadores prévios que sirvam de âncora para a nova aprendizagem e levem ao desenvolvimento de conceitos subsunçores que facilitem a aprendizagem subseqüente”.

Com a aprendizagem significativa, os alunos são capazes de relacionar conceitos e, assim, criar mecanismos de auto-aprendizagem em qualquer área de conhecimento sobre qualquer conteúdo.

No momento em que o aluno começa a buscar os conceitos existentes, para que possa, a partir destes, criar novos e até mesmo modificá-los e armazená-los, o mesmo aprenderá por descoberta. Entretanto, após a descoberta em si, a aprendizagem só é significativa se o conteúdo descoberto relacionar-se a conceitos subsunçores relevantes e já existentes na estrutura cognitiva (MOREIRA E MASINI, 2011, p. 19). Assim, o papel do professor, nesta situação, é fundamental, pois é ele que irá conduzir a aprendizagem dos seus alunos. “Tal aprendizagem, entretanto, somente ocorre se duas condições forem simultaneamente atendidas: o material de ensino deve ser potencialmente significativo e o aprendiz deve apresentar disposição para aprender de forma significativa” (BELMONT, R. S.; LEMOS, E., 2012. p. 3).

3. Subsunçores

A base da aprendizagem significativa são os subsunçores, pressupõe-se que os mesmos devam existir para que sejam ancorados aos novos conceitos. Partindo da idéia central da teoria, onde se entende que “a aprendizagem significativa ocorre quando a nova informação se relaciona com um aspecto relevante na estrutura do conhecimento do indivíduo” (MOREIRA E MASINI, 2011, p.17), vale esclarecer que na formação de conceitos existem diferenças de acordo com a idade do aluno, e este trabalho irá se referir à formação de conceitos na idade adulta. Crianças não serão levadas em consideração, pois no caso de uma criança na idade pré-escolar existe aquisição espontânea de ideias genéricas por meio de experiência empírico-concreta (MOREIRA E MASINI, 2011, p. 20).

Na infância aprende-se por descoberta, porém nas crianças mais velhas bem como nos adultos existe a assimilação de conceitos, ou seja, fazendo a relação dos novos conceitos com os já existentes na estrutura cognitiva. O processo da assimilação de conceitos envolve de acordo com Moreira e Masini (2011, p. 20), “ideias relevantes estabelecidas na estrutura cognitiva do aprendiz com o conteúdo potencialmente significativo, implícito na definição dos termos ou das pistas contextuais”.

Muitas vezes o aluno não possui o subsunçor mais adequado ou nem tanto rebuscado, porém se consegue reconhecer em sua estrutura cognitiva um significado, este poderá ser transformado e melhorado até que haja aprendizagem significativa.

Para que os subsunçores possam ser ancorados da melhor maneira possível, cabe ao professor preparar as suas aulas de maneira que esteja consciente de que “é importante não sobrecarregar o aluno de informações desnecessárias, dificultando a organização cognitiva. É preciso buscar a melhor maneira de relacionar, explicitamente, os aspectos mais importantes do conteúdo da matéria de ensino” (MOREIRA, 1999, p. 113).

4. Organizadores prévios

Existem situações totalmente novas para os alunos e que não é possível encontrar nenhum conceito prévio para possa servir de subsunçor. Neste caso se faz necessário o uso de organizadores prévios.

Segundo Moreira e Masini (2011, p. 21) “o uso de organizadores prévios é uma estratégia proposta por Ausubel para, deliberadamente manipular a estrutura cognitiva a fim de facilitar a aprendizagem significativa”.

Os organizadores prévios terão um papel de iniciar, conduzir o aluno a criar subsunçores, através de “materiais introdutórios apresentados antes do material de aprendizagem em si em um nível mais alto de abstração, generalidade e inclusividade” (MOREIRA, 1999, p.114).

Partindo do princípio que o professor estará trabalhando em uma turma de alunos e que a diversidade trará vários subsunçores para aquele ambiente e não haverá como afirmar que todos os alunos terão subsunçores para ancorar aos novos conceitos, pode-se afirmar que os organizadores prévios terão grande importância no momento da preparação do material de aula.

Os organizadores construídos de cada unidade podem ser simples comparações introdutórias entre material novo e o material conhecido, permitindo que o aprendiz perceba as características e crie o seu subsunçor, capaz de:

a) identificar o conteúdo relevante na estrutura cognitiva e explicar a relevância desse conteúdo para a aprendizagem do novo material.

b) dar uma visão geral do material em um nível mais alto de abstração, salientando as relações importantes.

c) prover elementos organizacionais inclusivos, que levem em consideração mais eficientemente e, ponham em melhor destaque, o conteúdo específico do novo material. (MOREIRA E MASINI; 2011, p. 22)

Para que os organizadores sejam úteis devem ser formulados com termos familiares, de simples interpretação permitindo que todos os alunos estejam em condições de compreender, e a partir destes organizadores criar seus subsunçores e a assim iniciar a aprendizagem significativa.

5. Ensino de análise de requisitos

Nos cursos técnicos de informática, específicos para análise e desenvolvimento de software, uma das disciplinas é a Análise de Sistemas onde o nome da disciplina pode variar, porém irá trabalhar para os alunos compreendam as fases de um projeto de software. A disciplina de Análise de Sistemas permite que o aluno entenda o caminho percorrido para a construção de um projeto de software.

Todo o software inicia a partir de uma necessidade ou desejo para o mesmo seja projetado e partir disto é que as demais fases serão trabalhadas.

Engholm (2010) sugere um exemplo resumido das fases de um projeto de software. A opção do autor é devido à facilidade de utilização e clareza na divisão das fases do projeto. O autor divide as fases em:

1ª Fase - Elicitação e Análise de Requisitos: Pode-se afirmar que esta é a principal fase no desenvolvimento de um projeto de software, pois é ela que irá definir os objetivos do software e suas funcionalidades. As demais fases do projeto são dependentes da primeira.

2ª Fase - Arquitetura: Neste momento haverá a preocupação com os requisitos não funcionais do sistema, que são itens e observações que não irão fazer parte do sistema, porém são relevantes para o funcionamento do mesmo.

3ª Fase - Design: Para atender os objetivos os mesmo serão modelados com o auxilio de ferramentas específicas. Segundo Pressman (2010, p. 144), “a modelagem de análise usa uma combinação de formas textuais e diagramáticas para mostrar os requisitos de dados, função e comportamento, de modo que seja relativamente fácil de entender”.

4ª Fase - Desenvolvimento: Os profissionais que irão transpor tudo que foi idealizado na fase anterior para as linguagens de programação.

5ª Fase - Teste: Para Sommerville (2011, p. 145) “o processo de verificação e validação (V&V) objetivam verificar se o software em desenvolvimento satisfaz suas especificações e oferece a funcionalidade esperada pelas pessoas que estão pagando o software”.

6ª Fase - Implantação: Chega o momento de sair do ambiente de projeto e desenvolvimento com o produto software dito pronto para que este seja colocado no ambiente do cliente e possa ver avaliado.

Este trabalho se propõe a trabalhar apenas com a primeira fase, mais especificamente com os conceitos de análise de requisitos. Esta fase descreve como e onde acontecem os fatos, de acordo com Machado (2011, p. 20), “formas de obter o conhecimento de um negócio, técnicas para levantamento dos requisitos, técnica de abstração e análise de negócio, conhecimentos de processos de negócios são muito mais difíceis de ensinar à imensa quantidade de mão de obra”. É neste momento que o professor coloca seus esforços para auxiliar o aluno a abstrair e ser capaz de entender um problema e identificar os requisitos de software.

Foram vistos os principais conceitos de análise de requisitos de software, com a finalidade de preparar um material objetivo.

6. Metodologia e desenvolvimento da pesquisa

Participantes

Participaram deste trabalho os alunos do terceiro período de uma turma de um curso técnico em informática na modalidade subseqüente com duração de dois anos num total de quatro períodos.

Este artigo trata de uma estratégia de ensino dos conceitos de análise de requisitos de software que contempla aprendizagem significativa em duas etapas: a primeira utilizando organizadores prévios e a segunda a busca por subsunçores.

a) Selecionando assunto e os conceitos trabalhados

Para selecionar o assunto o professor elaborou um texto simples com o resumo do conteúdo da aula e em seguida destacou os principais conceitos a serem trabalhados:

Resumo:

A Análise de Requisitos é a primeira etapa da criação de um software. É necessário traçar e analisar o cenárioe descobrir quais as necessidades e desejos dos clientes. A partir das necessidades e desejos é que extraímos os requisitos de software. “Requisitos são objetivos ou restrições estabelecidas por clientes e usuários que definem as diversas propriedades de um sistema”. Os requisitos são divididos em dois tipos: Requisitos Funcionais e Requisitos Não Funcionais. Nos primeiros contatos existe a preocupação em esclarecer as funcionalidades do sistema, os Stakeholders (todos os interessados e envolvidos no projeto) se preocupam em definir o que o sistema irá fazer para atender seus objetivos. Os requisitos funcionais determinam o que o sistema deve fazer ainda sem se preocupar como irá fazer.

Os requisitos não funcionais não dizem respeito às funcionalidades do sistema, porém são relevantes para o projeto e descrevem atributos do sistema ou do ambiente. Referem-se à usabilidade, confiabilidade, desempenho, suportabilidade, restrições do projeto, requisitos de implementação, requisitos de interface e requisitos físicos.

As técnicas mais utilizadas para extrair os requisitos são Questionários e entrevistas. A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados (Machado, 2011, p. 142). Para fazer uma entrevista é necessário que a mesma seja planejada, ou seja, com questões e roteiros previamente elaborados.

A entrevista deve ser registrada, com todas as questões e considerações dos entrevistados. O uso de questionários é indicado, por exemplo, quando há diversos grupos de usuários que podem estar em diversos locais geograficamente diferentes (Machado, 2011, p. 148). O questionário pode ser elaborado de várias formas: múltipla escolha, lista de verificações e questões com espaços em branco. Independente do tipo elaborado deve ter por objetivo minimizar o tempo gasto nas suas respostas.

Após a elicitação de requisitos os desenvolvedores irão analisar o problema, e gerar o Documento de Requisitos, que será um registro dos requisitos e que será assinado pelas partes envolvidas com o objetivo de acordo para início do Projeto de software.

No Documento de requisitos é que se define o escopo do projeto, ou seja, é descrita afinalidade daquilo que se pretende atingir. No escopo do projeto não pode haver ambiguidades (significados diversos para uma mesma mensagem).

Todo projeto deve ter um administrador, ou seja, uma pessoa que irá controlar e gerenciar as atividades.

A partir da seleção do conteúdo é que o professor irá apresentar aos alunos utilizando figuras ilustrativas que servirão de organizadores prévios para auxiliar a aprendizagem significativa. Este trabalho utilizou figuras que dão ideia de que o conceito central é formado ou está relacionado por várias definições e exemplos. Para Moreira (1999, p. 115),

Provavelmente, o maior potencial didático dos organizadores está na sua função de estabelecer, em um nível mais alto de generalidade, inclusividade e abstração, relações explícitas entre o novo conhecimento e conhecimento prévio já adequado do aluno para dar significado aos novos materiais de aprendizagem.

Assim, a partir do resumo do conteúdo apresentado em sala de aula, foram selecionados os principais conceitos que serão trabalhados:

Neste caso foram selecionados:

  • 01 – Requisitos
  • 02 – Requisito Funcional
  • 03 – Requisito não funcional
  • 04 – Cenário
  • 05 – Stakeholders
  • 06 – Cliente
  • 07 – Escopo
  • 08 – Ambiguidade
  • 09 – Questionário
  • 10 – Entrevista
  • 11 – Documentos de Requisitos
  • 12 – Administrador
  • 13 – Problema
  • 14 – Análise
  • 15 – Projeto

Em seguida cada conceito foi trabalhado de forma individual:

- A metodologia preconiza que seja colocado o conceito selecionado no centro do quadro e em seguida o professor traz sugestões simples sendo possíveis exemplos e definições, como pode ser observado nas figuras.

Figura 1 - Requisitos Funcionais
Fonte: O autor

As sugestões são formadas por frases ou ideias simples e familiar aos alunos, a definição de Requisitos Funcionais, segundo Sommerville (2011, p. 59), “são declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações”.

A figura 2 diz respeito aos requisito não funcionais:

Descripción: requisitos Não Funcionais.png

Figura 2 - Requisitos Não Funcionais
Fonte: O autor

Os Requisitos não funcionais, segundo Sommerville (2011, p. 59), “são restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições no processo de desenvolvimento e restrições impostas pelas normas”.

A figura 3 tem como objetivo dar mostrar que os requisitos do software são formados pelos requisitos funcionais e não funcionais.

Figura 3 - Requisitos
Fonte: O autor

Para Machado (2011, p. 24), “os requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema”, ou seja envolve todos os requisitos funcionais e os não funcionais.

Após os requisitos (funcionais e não funcionais) terem sido esclarecidos, foi apresentado o que seria uma cenário do ambiente para onde o software se destina. Este cenário está descrito na figura 4.

Figura 4 - Cenário
Fonte: O autor

A figura 4 representa um cenário de onde serão extraídos dos requisitos.

Descripción: Stakholder.png

Figura 5 - Stakeholders
Fonte: O autor

De acordo com Machado (2011, p. 30), “é qualquer pessoa materialmente afetada pelo resultado do projeto: clientes, usuários diretos e indiretos, investidores, acionistas, fornecedores, supervisores, gerentes, compradores” são chamados de stakeholders.

A figura 6 mostra que os interessados pelo software podem ser chamados de clientes.

Descripción: cliente.png

Figura 6 - Cliente
Fonte: O autor

-----

Descripción: escopo.png

Figura 7 - Escopo
Fonte: O autor

-----

Figura 8 - Ambiguidade
Fonte: O autor

O Significado da palavra ambiguidade é a possibilidade de uma mensagem ter dois sentidos. De acordo com Sommerville (2011, p. 471), “quando você coleta dados quantitativos sobre o software e processos de software, precisa analisar este dados para entender seu significado. É fácil interpretar dados erroneamente e fazer inferências incorretas.”

Descripción: questionario.png

Figura 9 - Questionário
Fonte: O autor

Questionário segundo Machado (2011, p. 148), devem ser desenvolvidos de forma a minimizar o tempo gasto de sua resposta”.

Descripción: Entrevista.png

Figura 10 - Entrevista
Fonte: O autor

Para Machado (2011, p. 142), é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção dos dados. Convém que o administrador dê margem ao entrevistado para expor suas idéias”.

Descripción: Documento de Requisitos.png

Figura 11 - Documento de requisitos
Fonte: O autor

Segundo Machado (2011, p.104), “os requisitos aprovados devem ser documentados em um nível apropriado de detalhamento. O documento de requisitos é formal e obrigatório, utilizado para comunicar os requisitos aos clientes, engenheiros e gerentes”.

Descripción: Administrador.png

Figura 12 - Administrador
Fonte: O autor

Todo projeto deve ter um administrador, ou seja, uma pessoa que irá controlar e gerenciar as atividades.

Figura 13 - Problema
Fonte: O autor

Após a elicitação de requisitos os desenvolvedores irão analisar o problema, e gerar o Documento de Requisitos, que será um registro dos requisitos e que será assinado pelas partes envolvidas com o objetivo de acordo para início do Projeto de software.

Descripción: Análise.png

Figura 14 - Análise

Na fase de Análise de requisitos “ocorre à negociação e análise de viabilidade de execução do que fora solicitado.” (MACHADO, 2011, p. 104).

Figura 15 - Projeto
Fonte: O autor

Segundo Sommerville (2011, p. 25), “um projeto de software é uma descrição da estrutura do software a ser implementado, dos modelos e estruturas de dados usados pelo sistema, das interfaces entre os componentes do sistema e às vezes, dos algoritmos usados”.

As figuras fazem a interação entre os conceitos técnicos e as explanações do professor resgatando ideias servindo de organizadores prévios.

b) Trabalhando com a busca por subsunçores

Depois de trabalhar com organizadores prévios, o próximo passo foi trazer uma atividade para que os alunos possam construir seus conceitos prévios e tragam seu subsunçores de forma simples.

O professor solicita aos alunos que relacionem as palavras trabalhadas com algum conceito que consigam buscar em sua estrutura cognitiva, sendo através de exemplos, descrições, associações, comparações ou alguma outra forma que o aluno encontrasse para criar o seu próprio conceito a respeito da palavra, pois “à medida que a aprendizagem começa a ser significativa, esses subsunçores vão ficando cada vez mais elaborados e mais capazes de ancorar novas informações” (MOREIRA E MASINI, 2011, p. 19).

Será apresentado apenas algumas respostas dos alunos:

01– Requisitos: Para Machado (2011, p. 24), “os requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema”.

Respostas:

  1. Para o computador ligar é necessário que tenha energia elétrica.
  2. Para jogar truco é necessário conhecer as regras.
  3. Um sistema para playground precisa cadastrar crianças, cadastrar responsáveis e emitir pulseiras.
  4. Em uma nota fiscal para preencher o destinatário é preciso ter CPF ou CNPJ.
  5. É necessário possuir um cadastro de clientes.

02 – Requisito Funcional: Segundo Sommerville (2011, p. 59), “são declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações”.

Respostas:

  1. Para o carro funcionar é necessário ter combustível.
  2. Possuir um baralho com quatro cartas sendo quatro cartas de As ao sete e quatro de cada uma.
  3. O cadastro de cliente (criança) será vinculado com o cadastro do responsável.
  4. O sistema deve permitir a inclusão, exclusão e alteração dos clientes.
  5. Precisa inserir RG e CPF.

03 – Requisito não funcional: Segundo Sommerville (2011, p. 59), “são restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições no processo de desenvolvimento e restrições impostas pelas normas”.

Respostas:

  1. Tipo de monitor
  2. Possuir um marcador caracterizado.
  3. O sistema do playground não terá interação com o sistema da loja.
  4. O sistema não fará a baixa automática dos cheques pendentes.
  5. Declarar renda.

04 – Stakeholder: De acordo com Machado (2011, p. 30), “é qualquer pessoa materialmente afetada pelo resultado do projeto: clientes, usuários diretos e indiretos, investidores, acionistas, fornecedores, supervisores, gerentes, compradores”.

Respostas:

  1. Gerente.
  2. São as pessoas envolvidas direta e indiretamente ao sistema. Ex: administrador, colaboradores e clientes.
  3. Analista, programador, cliente e funcionários.
  4. Quem usa o sistema, funcionário ou gerente.
  5. Proprietário e funcionários que utilizam o sistema.

05 – Ambiguidade: O Significado da palavra é a possibilidade de uma mensagem ter dois sentidos. De acordo com Sommerville (2011, p. 471), “quando você coleta dados quantitativos sobre o software e processos de software, precisa analisar este dados para entender seu significado. É fácil interpretar dados erroneamente e fazer inferências incorretas.”

Respostas:

  1. Garantia do carro são dois ou três anos.
  2. O projeto ficará pronto em dois ou três meses.
  3. A gata da minha irmã dormiu na minha cama.
  4. Proibida a entrada com carros, sem camisa, menores de 18 anos.
  5. Proibida a entrada com bebidas e animais. Se eu tiver com bebida e sem animal, posso entrar?

06 – Questionário: Segundo Machado (2011, p. 148), devem ser desenvolvidos de forma a minimizar o tempo gasto de sua resposta”.

Respostas:

  1. Respostas do trabalho para a professora.
  2. Ficha de Inscrição.
  3. Como é o laboratório do IFPR? ( ) Bom ( ) Ruim ( ) Não utilizo.
  4. Prova ou as questões que envolvem o sistema: Quais as dificuldades na clinica? Quantos PCs pretende ter na loja?
  5. Quantas pessoas usam simultaneamente o sistema? Qual valor que deseja gastar na implementação.

07 – Entrevista: Para Machado (2011, p. 142), é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção dos dados. Convém que o administrador dê margem ao entrevistado para expor suas idéias”.

Respostas:

  1. Jô Soares.
  2. O delegado interrogando o réu.
  3. Como é o laboratório do IPFR? Descreva a resposta.
  4. Dia e hora para contato.
  5. Marcar data e hora com o cliente para tirar dúvidas.

08 – Documento de Requisitos: Segundo Machado (2011, p.104), “os requisitos aprovados devem ser documentados em um nível apropriado de detalhamento. O documento de requisitos é formal e obrigatório, utilizado para comunicar os requisitos aos clientes, engenheiros e gerentes”.

Respostas:

  1. IBGE – Pesquisa demográfica.
  2. ABNT
  3. O sistema para playground conterá requisitos funcionais e não funcionais.
  4. Diagrama de caso de uso, lista de tabelas.
  5. Diagrama de classe, diagrama de objetos e dicionário de dados

09 – Análise: Na fase de Análise de requisitos “ocorre à negociação e análise de viabilidade de execução do que fora solicitado.” (MACHADO, 2011, p. 104).

Respostas:

  1. Exame de sangue.
  2. Exame de sangue.
  3. Estou em dúvida em comprar um sapato ou uma bolsa. Estou analisando qual será mais útil.
  4. Análise de ambiguidade de erros.
  5. Requisitos funcionais e não funcionais.

10 – Projeto: Segundo Sommerville (2011, p. 25), “um projeto de software é uma descrição da estrutura do software a ser implementado, dos modelos e estruturas de dados usados pelo sistema, das interfaces entre os componentes do sistema e às vezes, dos algoritmos usados”.

Respostas:

  1. Construção de uma casa.
  2. Roteiro de férias.
  3. Quando terminar o curso, tenho projeto de sair da cidade.
  4. Projeto de conclusão de curso.
  5. Plano para melhorar ao atendimento ao cliente através de um cadastro.

Observou-se que os alunos são capazes trazer de sua estrutura cognitiva subsunçores que poderão ser ancorados aos novos conhecimentos, mesmo não sendo bem elaborados, porém poderão ser alterados e armazenados.

O processo resume-se em buscar um subsunçor mesmo que ainda não seja uma informação lapidada e ancorar com o novo conhecimento e a partir daí armazenar um novo conceito que servirá de um novo subsunçor e melhorar o antigo.

Os resultados da aprendizagem significativa é percebida segundo Laburú, Barros e Silva (2011, p. 12) “por meio da observação do que faz o aluno, ao ser confrontado com as representações de diferentes situações, que é possível descobrir o grau de conexões conquistadas durante a aprendizagem” (LABURÚ; BARROS; SILVA, 2011, p. 12).

As estratégias de ensino utilizadas nesta pesquisa para o uso de aprendizagem significativa, diz respeito à utilização de organizadores prévios e criação de subsunçores e analisando as respostas verificou-se que: quando se trata de sala de aula com vários alunos a utilização de organizadores prévios é importante, pois é difícil ou até mesmo impossível avaliar o nível de conhecimento prévio de todos os alunos. Com a utilização da estratégia sugerida neste artigo foi possível observar que todos os alunos na sequência foram capazes de expressar seus subsunçores. O professor avaliou que houve uma preparação para receber o conteúdo novo, mesmo de forma primitiva existem subsunçores e que os alunos são capazes de buscar quando são instigados. Chegam próximos dos conceitos necessários e para ocorrer aprendizagem significativa.

Lembrando que a próxima etapa seria a apresentação do novo conteúdo, porém este trabalho irá se limitar apenas em apresentar esta fase de preparação para que o alunos possa receber o novo conteúdo com aprendizagem significativa.

7. Considerações Finais

Pode-se observar que durante o desenvolvimento destas etapas os alunos envolvidos foram preparados para a aprendizagem significativa do assunto em questão.

Para que o aluno aprenda de forma significativa, cabe ao professor buscar mecanismos para preparar sua aula proporcionando sugestões de construção do conhecimento tornando a aprendizagem algo simples e mostrando ao aluno que ele é capaz de buscar seus conceitos.

Acredita-se que outros conteúdos da área de engenharia de software como conceitos de algoritmos, conceitos de modelagem, conceitos de testes, dentre outros podem ser trabalhados utilizando a estratégia proposta. Além das áreas de informática também pode sugerir trabalhar com como administração, saúde e outras. Desde que estabeleçam os requisitos propostos: selecionar o assunto a ser trabalhado, estabelecer os organizadores prévios e busca de subsunçores.

8. Referências

AUSUBEL, D. A.(1976), Psicología educativa – Um punio de vista cognoscitivo. Tradução para espanhol de Roberto Helier Domínguez, da primeira edição de Education psycholoy: a cognitive view. México: Editora Trillas.

AUSUBEL, D.; NOVAK, J.; HANESIAN, H.(1980),Psicologia educacional. 2ª edição, Editora Interamericana, Rio de Janeiro.

BELMONT, R. S.; LEMOS, E. (2012), “Intencionalidade para a aprendizagem significativa da biomecânica: reflexões sobre possíveis evidências em um contexto de formação inicial de professores de educação física”.Ciência & Educação, Bauru, vol.18, n.1, pp. 123-141. [Acessado em: 18 de fev de 2013]. Disponível em: http://www.scielo.br/pdf/ciedu/v18n1/08.pdf.

ENGHOLM, H. JR.(2010), Engenharia de Software na Prática, 1ª Edição, Editora Novatec, São Paulo.

IEEE, Computer Society (2004), “SWEBOK - Guide to the Software Engineering Body of Knowledge”. IEEE Computer Society.

LABURÚ, C. E.; BARROS, M. A.; SILVA O. H. M. (2011),” Multimodos e múltiplas Representações, aprendizagem significativa e subjetividade: três referenciais conciliáveis da educação científica”. Ciência & Educação, Bauru, vol.17no.2. [Acessado em: 18 de fev de 2013]. Disponível em: http://www.scielo.br/pdf/ciedu/v17n2/a14v17n2.pdf.

MACHADO, F.N. (2011), Análise e Gestão de Requisitos de Software, onde nascem os sistemas. 1ª Edição, Editora Érica, São Paulo.

MARTINS, J. S.(2009), Situações Práticas de Ensino e Aprendizagem Significativa. São Paulo, Editora Autores Associados Ltda.

MOREIRA, M. A., MASINI E.F.S.(2011), Aprendizagem Significativa – A Teoria de David Ausubel. 4ª edição. Editora Centauro, São Paulo.

MOREIRA, M. A.(1999), Aprendizagem Significativa. Coleção: Publicações Acadêmicas do CESPE/UNnB, Série: Fórum Permantente de Professores, Brasília, Editora UnB.

SOMMERVILLE, I. (2011), Engenharia de Software. 9ª edição, Editora Pearson Education, São Paulo.


1 IFPR, Curitiba-PR – Brasil, Email: sheila.freitas@ifpr.edu.br
2 UTFPR Ponta Grossa-PR – Brasil, Email: acfrancisco@utfpr.edu.br


Vol. 34 (10) 2013
[Índice]

[En caso de encontrar algún error en este website favor enviar email a webmaster]