Processo de desenvolvimento de software

Os modelos de processos de software não podem ser considerados como metodologias específicas para o desenvolvimento de Objetos de Aprendizagem (OA), porém, esses modelos têm sido utilizados para esse fim (BRAGA et al.,2015).

Um modelo de processo de software é uma representação abstrata do mundo real e cada modelo representa um processo sob determinada perspectiva e, assim, fornece somente informações parciais sobre esse processo. Esses modelos incluem atividades que fazem parte do processo de software, os produtos de software e os papéis das pessoas envolvidas, trata-se de um conjunto de atividades

que podem envolver o desenvolvimento do software propriamente dito, usando uma linguagem de programação (SOMMERVILLE, 2011).

Existem diversos modelos de processo de desenvolvimento de software, e cada modelo pode ter mais do que uma metodologia que o operacionaliza.

Para Pressman (2011, p.40)

[...] uma metodologia (framework) de processo estabelece o alicerce para um processo de engenharia de software completo, por meio da identificação de um pequeno número de atividades estruturais aplicáveis a todos os projetos de software, independente de tamanho ou complexidade.

Embora existam muitos processos de softwares, algumas atividades fundamentais são aplicáveis em todo e qualquer processo, sendo elas: especificação de software, projeto e implementação de software, validação de software e evolução de software (SOMMERVILLE, 2011).

 Especificação de software

A funcionalidade do software e as restrições do seu funcionamento devem ser definidas. É um processo para compreender e definir quais serviços são necessários e identificar as restrições de operações e desenvolvimento do produto de software. Esse processo está dividido em quatro fases principais que leva à produção de um documento de requisitos, que é a especificação do sistema.

A figura 2mostra as fases do processo.

Figura 2 - Processo de especificação de software

Estudo de

viabilidade Elicitação e análise de requisitos

Especificação de requisitos Validação de requisitos Documento de requisitos

Fonte: Adaptado de Sommerville (2011, p.50)

No estudo da viabilidade é realizada uma avaliação para verificar se as necessidades dos usuários poderão ser satisfeitas por meio das tecnologias atuais. O estudo leva em consideração, a viabilidade financeira do produto a ser

desenvolvido. O resultado desta fase fornece informações, tanto para a tomada de decisão quanto para uma análise mais detalhada.

A elicitação e análise dos requisitos têm como objetivo obter o máximo de informações para o conhecimento do objeto em questão. Cabe à elicitação, a tarefa de identificar os fatos que compõem os requisitos do sistema, de forma a prover o mais correto e completo entendimento do que é demandado daquele software, tendo como objetivo, ultrapassar barreiras de comunicação entre os clientes e usuários e os desenvolvedores para que os requisitos possam ser capturados e modelados corretamente. O uso de protótipos e outras técnicas de comunicação, como: entrevistas, observação in-loco, questionários, ou técnicas específicas de comunicação, entre outros, são utilizados como ferramentas auxiliares para o levantamento de requisitos.

O objetivo da análise de requisitos é descobrir inconsistências e omissões nos requisitos elicitados, assim, a análise é intercalada com elicitação, pois problemas são descobertos quando os requisitos são identificados. Essa fase pode envolver o desenvolvimento de um ou mais modelos de sistemas e protótipos, uma vez que eles ajudam os envolvidos a compreender o sistema especificado.

A especificação dos requisitos traduz as informações coletadas durante a atividade de análise em um documento que define um conjunto de requisitos: do usuário e do sistema. Já na validação de requisitos é realizada a verificação dos requisitos em relação ao realismo, consistência e abrangência. Nesta fase, os modelos são criados para melhorar a compreensão do domínio da aplicação, eles são representações simplificadas, pois consideram apenas as características mais importantes e descartam as irrelevantes. Para o desenvolvimento desses modelos, são utilizadas linguagens de modelagens, como a Unified Language Modeling (UML) (OMG, 2016).

A UML, além de flexível, é extensível e independente de processos ou linguagens de programação, o que garante a liberdade para o desenvolvedor adotar qualquer processo (LIMA, 2007; IBM, 2016).

A UML permite representar o sistema na Visão de Caso de Uso, o qual descreve o comportamento do sistema do ponto de vista do usuário e permite mostrar, conceitualmente, o conjunto de funcionalidades que deverão ser executadas para atender aos requisitos dos usuários (LIMA, 2007).

Essa visão é representada pelo diagrama de caso de uso, escrito na forma de texto simples, compreensível, e serve como meio de comunicação entre as pessoas, muitas vezes sem treinamento especial.

A figura 3 ilustra um exemplo de diagrama de caso de uso.

Figura 3 - Exemplo de diagrama de caso de uso para resolução de uma atividade

Fonte: Autoria própria

A figura 3 representa um diagrama de caso de uso para resolução de uma atividade. O caso de uso é representado por uma elipse conectada a símbolos de atores. Um caso de uso representa uma funcionalidade do sistema (Realizar Login,

Resolver atividade, Realizar votação) e um ator (Aluno) é uma entidade externa (fora

do sistema) que, frequentemente, inicia o caso de uso e interage com o sistema.  Projeto e implementação de software

Um projeto é a descrição da estrutura de software a ser implementada, dos dados que irão compor o sistema, das interfaces, dos componentes e, às vezes, dos algoritmos que serão usados. O projeto é desenvolvido de forma iterativa, por meio de várias versões e revisões e pode envolver o desenvolvimento de vários modelos do sistema em diferentes níveis de abstração.

Na UML, os sistemas são constituídos por modelos que representam diferentes pontos de vista, cada um descrevendo um aspecto particular da mesma solução. Assim, na Visão Lógica, ou estática, trata de uma visão arquitetônica que permite estruturar o sistema e organizar o desenho do sistema de forma lógica por meio do diagrama de classe que “mostra a estrutura estática do modelo, em que os elementos são representados por classes, com sua estrutura interna e seus relacionamentos” (LIMA, 2007, p.174).

Uma classe refere-se a um grupo de objetos que possui as mesmas propriedades, os mesmos comportamentos, os mesmos relacionamentos e as mesmas semânticas.

Um exemplo de diagrama de classe para resolver o diagrama de caso de uso, mostrado na figura 3, pode ser ilustrado na figura 4.

Figura 4 - Exemplo de diagrama de classe para “resolução de uma atividade”

Fonte: Autoria própria

A leitura do diagrama de classe ilustrado na figura 4 pode ser feita da seguinte maneira: uma atividade contém um conjunto de exercícios, ela está relacionada com a classe Exercício, por isso representado por um losango preenchido (denominado de composição). Um voto (classe Votação) pertence a uma atividade e uma atividade poderá ter muitos votos ou nenhum. Um login (classe

Login) pertence a um aluno (classe Aluno) e este aluno poderá realizar muitas

atividades ou nenhuma (classe Atividade) e uma atividade pode ser realizada por muitos alunos ou nenhum.

 Validação de software

O software deve ser validado para garantir que atenda às demandas do cliente. Mais genericamente, a verificação e a validação destinam-se a mostrar que um sistema está de acordo com sua especificação e que atende às expectativas do usuário. Isso envolve processos de verificação a cada estágio do processo de software, desde a definição de requisitos de usuário, porém, a maior parte dos custos ocorre após a implementação. Com exceção de programas pequenos, os sistemas não devem ser testados como uma unidade simples e monolítica.

O produto de software deve evoluir para atender às necessidades de mudanças dos clientes. A distinção entre o desenvolvimento e a manutenção tem se tornado cada vez mais irrelevante. Poucos sistemas são completamente novos, fazendo com que seja mais viável considerar o desenvolvimento e a manutenção como práticas contínuas. É mais fácil pensar no desenvolvimento de software como um processo evolutivo (figura 5).

Figura 5 - Evolução de sistema

Definir Requisitos

do sistema Avaliar sistemas existentes

Propor mudanças

de sistema Modificar sistemas

Sistemas novos Sistemas

existentes

Fonte: Sommerville (2011, p.54)

A figura 5 representa um processo evolutivo no qual o software é continuamente alterado ao longo de sua vida, em resposta às mudanças de requisitos e às necessidades do cliente.

Cabe ressaltar que, as atividades descritas são organizadas de maneira diferente nos diversos processos de desenvolvimento de software encontrados na literatura, pois não existe uma forma certa ou errada de organizar essas atividades, uma vez que a escolha da forma de distribuição dependerá do tipo de software, pessoas e estruturas organizacionais envolvidas.

Além disso, a aplicação dessas atividades independe do tamanho e da complexidade do sistema que será desenvolvido, ou seja, pode ser usada no desenvolvimento de programas pequenos e simples, para a criação de aplicações para a internet e até para a engenharia de complexos sistemas baseados em computador (PRESSMAN, 2011).

Pressman (2011) afirma, ainda, que para muitos projetos de software, as atividades metodológicas são aplicadas iterativamente, conforme o projeto se desenvolve. Ou seja, as atividades de especificação, projeto e implementação e a validação de software são aplicadas repetidamente quantas forem as iterações do

projeto, sendo que cada iteração produzirá um incremento do software. A cada incremento o software torna-se mais e mais completo.

Percebe-se que, tanto a metodologia ADDIE quanto o processo de desenvolvimento de software, possuem semelhanças na composição de etapas ou fases de desenvolvimento, com algumas semelhanças no que diz respeito às atividades recomendadas em cada uma das etapas.

Sendo assim, esse trabalho irá integrar as fases e características de ambos, uma vez que a proposta de desenvolvimento de um objeto virtual de aprendizagem (OVA) pode ser construída por meio da metodologia ADDIE que integra um modelo de design instrucional (ou pedagógico). No caso deste trabalho, o domínio da disciplina de Probabilidade e Estatística de nível superior. Em contrapartida, as atividades genéricas contidas em um processo de desenvolvimento de software, aplicadas de forma iterativa, irão contemplar as necessidades técnicas computacionais para a produção do objeto virtual de aprendizagem proposto. O processo de desenvolvimento de objetos virtuais de aprendizagem colaborativa proposto, será detalhado no Capítulo 6.

A aplicação de processos de desenvolvimento de software cria tecnologias que melhoram as práticas pedagógicas e permitem tornar o processo de aprendizagem mais colaborativo.

4 APRENDIZAGEM COLABORATIVA

Este capítulo traz um relato sobre a aprendizagem colaborativa como teoria que parte da ideia de que o conhecimento é resultante de um consenso entre membros de uma comunidade de conhecimento (TORRES, 2007). Na seção 4.1, são apresentados os pressupostos da aprendizagem colaborativa. A seção 4.2 trata da Aprendizagem Colaborativa Apoiada por Computador (CSCL - Computer

Supported Collaborative Learning), das suas áreas-chave e das principais

ferramentas que dão apoio aos processos colaborativos. A seção 4.3 e 4.4 tratam, respectivamente, das formas de medir e avaliar a colaboração e dos trabalhos relacionados aos assuntos-chave da pesquisa.