domingo, 31 de agosto de 2014

Engenharia de Requisitos

1.       Introdução

Os sistemas de informação estão presentes em diversas, senão todas, áreas de aplicação e são reconhecidamente importantes ativos estratégicos para diversas organizações, pois, apresentam um papel vital de apoio nos processos organizacionais e nas tomadas de decisões. Entretanto, é de fundamental importância que estes sistemas de informação apoiem adequadamente e corretamente todos os requisitos estabelecidos no domínio da aplicação, respeitando sempre, o escopo pré-determinado. Neste contexto, a identificação e o entendimento dos requisitos se tornam as principais tarefas do desenvolvimento de software. 

A Engenharia de Requisitos é descrita por SOMMERVILLE (2011) como o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema, tendo como objetivo criar e manter um documento de requisitos de sistema.

Este texto apresenta os conceitos relacionados a Engenharia de Software, relatando, inicialmente, o que são requisitos de um sistema e alguns tipos de requisitos, seguido por uma maior explanação sobre a Engenharia de Requisitos e seus subprocessos, que são a elicitação e análise de requisistos, a especificação e a validação dos requisitos.


É importante ressaltar que este texto considera o público discente dos cursos técnicos e tecnológicos do eixo de informação e comunicação do IFPR câmpus Paranavaí. 

2. Requisitos

 Os requisitos de software tem um papel fundamental no processo de desenvolvimento de software, e eles são considerados fatores determinantes para o sucesso ou fracasso de um projeto de software.

SOMMERVILLE (2011) conceitua requisito de um sistema como sendo descrições dos serviços que devem ser fornecidos por este sistema e suas restrições operacionais. E a IEEE conceitua requisito como uma condição ou uma funcionalidade necessária ao usuário para resolver um problema (PRESSMAN, 2011).

A partir destas definições, podemos dizer que os requisitos de um sistema incluem as especificações dos serviços que os sistemas devem prover as restrições sobre as quais ele deve operar, as propriedades gerais que o software deve atender e as necessidades e limitações que devem ser satisfeitas ao longo do processo de desenvolvimento.

As definições de requisitos apontam para diferentes tipos de requisitos, de forma genérica, podemos classificar os requisitos como requisitos funcionais, requisitos não funcionais e requisitos de domínio. Entretanto, há na literatura os requisitos de sistema e requisitos de interface. 

2.1. Requisitos Funcionais

Os requisitos funcionais estão diretamente relacionados às funcionalidades dos sistemas. São declarações de serviços que o sistema deve fornecer; como o sistema deve reagir a entradas específicas; e como o sistema deve se comportar em determinadas situações. Podendo, em algumas situações, determinar explicitamente o que o sistema não deve fazer (SOMMERVILLE, 2011).

Também é de responsabilidade dos requisitos funcionais descrever as interações entre o sistema e seu ambiente, por exemplo: “O software deve permitir que o atendente realize o cadastro do paciente” (SOMMERVILLE, 2011). 

2.2. Requisitos Não Funcionais

Os requisitos não funcionais descrevem as restrições sobre os serviços ou funções que o sistema deve prover, expressando condições que o software deve atender ou qualidades específicas que o software deva ter (PRESSMAN, 2011; SOMMERVILLE, 2011). Estes requisitos são muito importantes para a fase de projeto, servindo como base para tomada de decisão nesta fase.

A origem dos requisitos não funcionais está em fatores como: nas necessidades dos usuários; em restrições de orçamentos; em políticas organizacionais; necessidades de interoperabilidade com outros sistemas ou hardware; e, até mesmo, fatores externos como regulamentos e legislações. Estes requisitos podem ser mais críticos do que os requisitos funcionais, pois, caso o software não venha a atender algum requisito não funcional pode se tornar inútil (SOMMERVILLER, 2011). Logo, os requisitos não funcionais podem ser classificados quanto à sua origem. SOMMERVILLE (2011) classifica-os em:

  •  Requisitos de produto: especificam o comportamento do software. Referem-se a atributos de qualidade que o sistema deve apresentar, tais como confiabilidade, usabilidade, eficiência, portabilidade, manutenibilidade e segurança;
  •  Requisitos organizacionais: são derivados de metas, políticas e procedimentos das organizações do cliente e do desenvolvedor. Incluem requisitos de processo (padrões de processo e modelos de documentos que devem ser usados), requisitos de implementação (tal como a linguagem de programação a ser adotada), restrições de entrega (tempo para chegar ao mercado, restrições de cronograma etc.), restrições orçamentárias (custo, custo-benefício) etc
  • Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos de interoperabilidade com sistemas de outras organizações, requisitos legais (tais como requisitos de segurança e privacidade) e requisitos éticos.

É importante ressaltar que a identificação de um requisito não funcional deve ser realizada de forma que o mesmo possa ser validado. Logo, um requisito não funcional deve ser mensurável. Portanto, os requisitos não funcionais devem ser elaborados até que os mesmos se tornem verificáveis. 

2.3 Requisitos de Domínio

Além da classificação de requisitos funcionais e não funcionais, SOMMERVILLE (2011) considera também os requisitos de domínio e o define como requisitos provenientes do domínio de aplicação do sistema e refletem características e restrições desse domínio. Estes requisitos são derivados do domínio da aplicação e podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas, refletindo fundamentos do domínio da aplicação. Para exemplificar, um requisito de domínio pode ser um cálculo que deve ser realizado para uma determinada funcionalidade.

Na literatura, encontramos autores que compreendem requisitos de domínio como sendo regras de negócio e essas regras de negócio, assim como os requisitos de domínio, incluem terminologias específicas do domínio da aplicação e são mais facilmente capturadas em uma fase de modelagem conceitual. 

2.4 Requisitos de Usuários e Requisitos de Sistema

Considerando que os requisitos devem ser passíveis de entendimento a todos os envolvidos com o seu processo, como os stakeholders[1] (cliente, usuários, desenvolvedores) e que, cada envolvido possui expectativas diferentes, SOMMERVILLE (2011) sugere mais dois níveis de classificação para requisitos, sendo os requisitos de sistema e requisitos de usuários.

Os requisitos de usuários são declarações em linguagem natural acompanhadas de diagramas intuitivos de quais serviços são esperados do sistema e das restrições sob as quais ele deve operar. Devem estar em um nível de abstração mais alto, de modo que sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico.

Os requisitos de sistema definem detalhadamente as funções, serviços e restrições do sistema. São versões expandidas dos requisitos de usuário usados pelos desenvolvedores para projetar, implementar e testar o sistema. Como requisitos de sistema são mais detalhados, as especificações em linguagem natural são insuficientes e para especificá-los, portanto,  notações mais especializadas, como o exemplo diagramas da UML (Linguagem de Modelagem Unificada) devem ser utilizadas.

Vale destacar que esses níveis de descrição de requisitos são aplicados em momentos diferentes e com propósitos distintos. Requisitos de usuário são elaborados nos estágios iniciais do desenvolvimento (levantamento preliminar de requisitos) e servem de base para um entendimento entre clientes e desenvolvedores acerca do que o sistema deve contemplar. Esses requisitos são, normalmente, usados como base para a contratação e o planejamento do projeto. Requisitos de sistema, por sua vez, são elaborados como parte dos esforços diretos para o desenvolvimento do sistema, capturando detalhes importantes para as fases técnicas posteriores do processo de desenvolvimento, a saber: projeto, implementação e testes.

3. Engenharia de Requisitos

A engenharia de requisitos pode ser descrita como um processo que compreende das atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência dos requisitos (controle de mudanças, gerencia de configuração, rastreabilidade e gerencia de qualidade dos requisitos). Este processo pode variar de organização para organização ou, até mesmo, de projeto para projeto dentro de uma organização. A Figura 1 exibe estas atividades. 

Figura 1: Atividades da Engenharia de Requisitos (Fonte: DevMidia)

Ao analisar a Figura 1 identificamos dois conceitos base para a realização do processo da Engenharia de requisitos, que é a produção de requisitos e a gerencia de requisitos. A produção de requisitos fornece o conjunto de requisitos que será gerenciado na gerencia de requisitos que, por sua vez, assegura que as mudanças que ocorram nos requisitos sejam tratadas de forma adequada durante o processo de desenvolvimento. Logo, podemos concluir que ter um processo de gerencia de requisitos estabelecido representa ter capacidade de lidar com mudanças que possam ocorrer ao longo do ciclo de vida de desenvolvimento de software, além também, de poder melhor garantir a qualidade dos requisitos elicitados. Desta forma, é importante ressaltar que as atividades de gerencia de requisitos devem ocorrer paralelamente as atividades de elicitação, análise e modelagem dos requisitos, como pode ser visto na Figura 2.

Figura 2: Produção e Gerencia de Requisitos

Dentre os objetivos da engenharia de requisitos, vamos destacar alguns neste texto:

  •  Estabelecer uma visão comum entre o cliente e a equipe do projeto em relação aos requisitos que serão atendidos pelo projeto de software;
  • Registrar e acompanhar os requisitos ao longo de todo o processo de desenvolvimento de software;
  • Documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da engenharia de software;
  • Manter planos, artefatos e atividades de software consistentes com os requisitos alocados.
  • Para alcançar a todos estes objetivos citados, é importante que se tenha um processo de engenharia bem definido e seguido corretamente.

 SOMMERVILLE (2011) considera que um processo de engenharia de requisitos deve contemplar, tipicamente, as atividades mostradas na Figura 3

Figura 3: Processo da Engenharia de Requisitos

O processo inicia-se pelo levantamento de requisitos, no qual são identificados os requisitos que irá compor o software, levando em conta as necessidades do cliente e usuários, informações disponíveis, legislações, regulamentos, sistemas existentes, etc. Após a identificação dos requisitos então inicia-se a etapa de análise, nesta etapa, os requisitos levantados são utilizados como base para a modelagem dos requisitos. Nestas etapas é importante documentar os requisitos, conforme já discutido anteriormente. Após a produção dos documentos de definição e de especificação dos requisitos, então estes são verificados e validados. Adicionalmente, um esforço de garantia da qualidade deve ser realizado, visando garantir conformidade em relação a padrões e ao processo estabelecidos pela organização. Caso os cliente, usuários e desenvolvedores estejam de acordo com os requisitos levantados, as próximas etapas do ciclo de vida de desenvolvimento de software pode avançar, caso contrário deve-se retornar as atividades anteriores para a eliminação dos problemas identificados.

Não há limites entre as atividades destacadas na Figura 3, na prática elas são intercaladas e existem um alto grau de interação e feedback entre elas. O processo é executado até que todas as partes envolvidas estejam satisfeitos e concordem com os requisitos identificados (SOMMERVILLE, 2011).

A seguir as atividades do processo de engenharia de requisitos são discutidas com mais detalhe. 

3.1 Elicitação e Análise de Requisitos

A elicitação ou levantamento de requisitos corresponde a fase inicial do processo de desenvolvimento de software. É uma fase extremamente complexa e não se resume em apenas questionar os usuários do sistema, mas sim, analisar cuidadosamente a organização, o domínio da aplicação e todos os processos de negócio que irão compor o sistema. Nesta etapa ocorre um trabalho conjunto entre analistas de sistemas, usuários, cliente e especialistas do domínio da aplicação (PRESSMAN, 2011; SOMMERVILLE, 2011).

A tarefa de levantamento compreende da realização de atividades que permitem obter informações sobre o domínio da aplicação, estas atividades podem ser dinâmicas como: entrevistas, observações, aplicações de questionários, realização de seminários envolvendo sempre os stakeholders, além de consultas a documentos como legislações, tutoriais, manuais e/ou normas internas e prototipação . Neste contexto, devemos considerar quatro dimensões distintas, sendo: 

  • Entendimento do Domínio da Aplicação: compreende do entendimento geral da área que o software será aplicado.
  • Entendimento do Problema: compreende do entendimento do problema específico, ou seja, compreender detalhadamente o problema específico que será implementado.
  • Entendimento do negócio: compreende em entender como o sistema irá afetar a organização e como contribuirá para o desenvolvimento da organização. Para isso, deve-se conhecer, intimamente, as regras que compõem o negócio;
  •  Entendimento das necessidades e das restrições dos interessados: compreende em entender as demandas de apoio de trabalho de cada um dos interessados, ou seja, compreender com clareza o que cada interessado necessita que o sistema o apoie para a realização de suas atividades. 


PRESSMAN (2011) comenta que a tarefa de levantamento de requisitos é complexa pelo fato de ser dominada por fatores humanos, sociais e organizacionais. Envolvendo pessoas diferentes com culturas e objetivos diferentes, o que pode resultar em alguns problemas como a má definição do escopo do projeto, no qual, leva os stakeholders a relatar detalhes técnicos desnecessários ou omitir outros importantes; problemas de entendimento, no qual os stakholders podem não estar totalmente certos de suas necessidades, ou ainda, ter pouco conhecimento ou limitação sobre o domínio da aplicação, ter dificuldades de comunicação, omitir informações que para eles podem ser óbvias, especificar requisitos conflitantes com as necessidades de outros usuários ou ainda, especificar requisitos ambíguos ou impossível de ser testado; e por fim, problemas de volatilidade, no qual, os requisitos mudam ao longo do tempo. 

3.2 Análise de Requisitos

Após a etapa de levantamento de requisitos, inicia-se a etapa de análise. Nesta etapa, os requisitos são analisados e utilizados como base para os modelos que são desenvolvidos.

De maneira bem simples, a fase de análise de requisitos se resume em atividades de modelagem destes requisitos, no qual, é realizado a modelagem conceitual preocupando-se apenas com o domínio do problema e não com soluções técnicas para este problema. Os modelos construídos nesta fase são elaborados para obter uma maior e melhor compreensão acerca do sistema que será desenvolvido e podem ser construídos para representar diferentes perspectivas, como: 

  • Perspectiva estrutural: busca modelar os conceitos, propriedades e relações do domínio que são relevantes para o sistema em desenvolvimento. Provê uma visão estática das informações que o sistema necessita tratar e, portanto, refere-se às representações que o sistema terá de prover para abstrair entidades do mundo real. Diagramas de classes são usados para modelar esta perspectiva.
  • Perspectiva comportamental: visa modelar o comportamento geral do sistema, de uma de suas funcionalidades ou de uma entidade específica ao longo do tempo. Provê uma visão do comportamento do sistema ou de uma parcela do sistema. Diagramas de casos de uso, diagramas de atividades, diagramas de estados e diagramas de interação podem ser utilizados para modelar essa visão.


 PRESSMAN (2011) cita que os objetivos destes modelos estão em ajudar os analistas a entender a informação, a função e o comportamento do sistema, tornando a tarefa de análise de requisitos mais fácil e sistemática. Além do entendimento, os modelos são também, um ponto focal para a revisão e, portanto, chave para a determinação da consistência da especificação. Desta forma, os modelos são capazes de prover uma base para o entendimento e concordância entre clientes e desenvolvedores acerca do que o sistema fará e, também, prove uma especificação que serve como guia para os desenvolvedores nas demais etapas de desenvolvimento do sistema.

Por fim, é nesta etapa que são identificados problemas e conflitos nos requisitos elicitados, e estes, devem 
ser eliminados totalmente antes de ir para a próxima etapa de engenharia de requisitos. 

3.3 Documentação de Requisitos

Os documentos de requisitos, também chamado de documento de especificação de requisitos de software é a declaração oficial do que os desenvolvedores de sistema devem implementar (SOMMERVILLE, 2011; PRESSMAN, 2011). 

Considerando que os requisitos de usuários e os requisitos de sistemas possuem propósitos e públicos diferentes, é útil descrever o documento de requisitos de maneira diferente, podendo ser: 

  •  Documento de definição de requisitos: deve ser escrito de forma que o cliente[2] possa entender, deixando claro o que o cliente espera que o software faça. Este documento representa um consenso entre o cliente e o desenvolvedor na definição do escopo do software.
  •  Documento de especificação de requisitos: redefini os requisitos de usuários em termos técnicos, apropriados para o desenvolvimento do software, sendo produzido por analistas de requisitos.

Ambos os documentos podem ter uma correspondência direta, podendo, o documento de definição de requisitos complementar e ser complementado pelo documento de especificação de requisitos.

A composição dos itens do documento de especificação de requisitos pode variar de acordo com o padrão e modelo de desenvolvimento que está sendo seguido pela equipe de desenvolvimento.

A IEEE cita que uma boa documentação fornece muitos benefícios, como: (i) facilita a comunicação dos requisitos; (ii) reduz o esforço de desenvolvimento, pois sua preparação força usuários e clientes a considerar os requisitos atentamente, evitando retrabalho nas fases posteriores; (iii) fornece uma base realística para estimativas; (iv) fornece uma base para verificação e validação; (v) facilita a transferência do software para novos usuários e/ou máquinas e (vi) serve como base para futuras manutenções ou incremento de novas funcionalidades.

3.4 Verificação & Validação de Requisitos

As atividades de Verificação & Validação (V&V) devem ser iniciadas o quanto antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos são encontrados, maiores os custos associados à sua correção. Uma vez que os requisitos são a base para o desenvolvimento, é fundamental que eles sejam cuidadosamente avaliados. Assim, os documentos produzidos durante a atividade de documentação de requisitos devem ser submetidos à verificação e à validação.

A verificação consiste em assegurar que o software esteja sendo construído de forma correta e a validação, por sua vez, assegura que o software desenvolvido é o correto, ou seja, irá atender as necessidades identificadas no levantamento de requisitos (PRESSMAN, 2011; SOMMERVILLE, 2011).

No caso de requisitos, a verificação é feita, sobretudo, em relação à consistência entre requisitos e modelos e à conformidade com padrões organizacionais de documentação de requisitos. Já a validação tem de envolver a participação de usuários e clientes, pois somente eles são capazes de dizer se os requisitos atendem aos propósitos do sistema.

As atividades de V&V consistem em examinar os documentos de requisitos gerados para assegurar que: (i) todos os requisitos do sistema tenham sidos declarados de modo não ambíguo. (ii) as inconsistências, conflitos, omissões e erros tenham sido identificados e corrigidos. (iii) os documentos estão em conformidade         com os padrões estabelecidos. (iv) os requisitos realmente satisfazem as necessidades dos usuários (PRESSMAN, 2011; SOMMERVILLE, 2011). Em outras palavras, idealmente um requisito, seja ele uma regra de negócio, um requisito funcional ou um requisito não funcional deve estar completo, correto, consistente, realista com as necessidades dos usuários, realmente necessários, passíveis de ser priorizado, verificável e passível de confirmação e rastreável. 

SOMMERVILLE (2011) comenta que das atividades de V&V, a atividade de teste é o elemento mais crítico para garantir a qualidade do artefato do produto e, por consequente, do produto final, porém, exceto por meio de protótipos não é possível testar requisitos, entretanto, uma das características de um requisito bem elaborado é que ele seja testável, portanto, uma boa maneira de identificar problemas nos requisitos é definir casos de testes para eles. Outra etapa imprescindível das atividades de V&V é realizar revisões dos documentos de requisitos.

De forma geral, em uma revisão os processos, documentos e outros artefatos são revisados por um grupo de pessoas com o objetivo de avaliar se os mesmos estão em conformidade com os padrões do projeto e com os objetivos do produto de software, logo, em uma revisão o objetivo principal é encontrar erros e inconsistência nos artefatos e nos processos. A revisão de requisitos pode ocorrer por meio de diversas técnicas, como leitura ad-hoc, leitura baseada em checklist, leitura de modelos orientados a objetos e outras dispostas na literatura. 

3.5 Gerencia de Requisitos

Gerenciar requisitos consiste de atividades que auxiliam as equipes de desenvolvimento a identificar, controlar e rastrear requisitos, permitindo assim gerenciar as mudanças que ocorra ao longo do ciclo de vida de desenvolvimento de software (PRESSMAN, 2011; SOMMERVILLE, 2011).

As mudanças em requisitos podem ocorrer em qualquer fase do ciclo de vida de desenvolvimento de software e são decorrentes de fatores externos ou internos, tais como descobertas de erros, omissões ou conflitos, inconsistência nos requisitos, problemas técnicos, problemas de cronograma ou custo, mudança de prioridades, mudança de negócio, mudanças econômicas, mudanças na equipe ou mesmo no ambiente onde o software será implantado, ou ainda mudanças organizacionais ou legais.

Os objetivos da gerencia de requisitos são: 

  • Gerenciar alterações nos requisitos acordados;
  • Gerenciar relacionamentos entre os requisitos;
  • Gerenciar dependência entre os requisitos e outros documentos produzidos durante o processo de desenvolvimento de software. 

As atividades que compõem o gerenciamento de requisitos são:

  •  Controle de mudança: defini os procedimentos, processos e padrões que devem ser utilizados para gerenciar alterações de requisitos. Deve assegurar que qualquer proposta de mudança seja analisada conforme os critérios estabelecidos pela organização.
  • Controle de versão: Defini o esquema de identificação da versão, identificando versões de documentos de requisitos e versões de cada requisito.
  •  Acompanhar o estado do requisito: nesta atividade deve-se ser capaz de identificar e definir os possíveis estados para um requisito, armazenando e documento todos os estados de cada requisito.
  • Rastrear os requisitos: Deve-se definir ligações com outros requisitos e com outros documentos. 

Os requisitos guiam diversas atividades do processo de software, como o planejamento, projeto, codificação e testes e, portanto, estes requisitos devem ser rastreáveis para e a partir dos requisitos.

Logo, para manter a consistência entre as várias alterações pedidas (e para estas serem feitas de um modo controlado), é importante que o processo de gestão de mudanças esteja definido de um modo formal, sendo que deverá incluir as seguintes três fases:

  •  Análise do problema e especificação da alteração a fazer: identificação do problema existente nos requisitos originais e proposta de alteração a fazer aos requisitos do sistema.
  • Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas previamente, avaliação do impacto da alteração no sistema.
  • Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário, no design e implementação.

É importante seguir este processo conforme foi enunciado já que cair na tentação de implementar a alteração diretamente e só depois, retrospectivamente, atualizar os requisitos pode levar a "dessincronização" entre requisitos e implementação.

4. Conclusão

A engenharia de requisitos representa uma das principais atividades da engenharia de software. Definir um processo de engenharia de requisitos capacita os desenvolvedores a lidar com mudanças durante o processo de desenvolvimento de software e a sua importância é destacada na literatura por diversos autores como SOMMERVILLE (2007), PRESSMAN (2006).

Neste texto foi apresentado uma visão geral de requisitos, conceituando-os e classificando-os, a fim, de que se proporcione uma melhor compreensão sobre o processo de gerenciamento de requisitos. Além da abordagem sobre requisitos, também foi tratado neste texto, de forma geral, uma contextualização sobre documentos de requisitos apresentando os tipos de documentos que são gerados relacionados a requisitos.

Por fim, foi abordado também o conceito, objetivo e as atividades que compõem a engenharia de requisitos. Desde as atividades de levantamento, analise, documentação, verificação e validação de requisitos até as atividades de gerenciamento de requisitos.

Referências

PRESSMAN, R. Engenharia de Software. São Paulo. Ed. Makron Books, 2011.

SOMMERVILLE, I. Engenharia de Software. São Paulo. Ed. Addison-Wesley, 2011. 





[1] Stakeholders partes interessadas 
[2] Entendemos cliente como sendo aqueles que contratam o serviço de desenvolvimento de software

quinta-feira, 28 de agosto de 2014

IFPR Câmpus Paranavaí participa do Mutirão de Lixo Eletrônico

Nos dias 22 e 23 de agosto aconteceu o Mutirão do Lixo Eletrônico, desenvolvido por meio da parceria entre o IFPR – Campus Paranavaí, a Secretaria do Meio Ambiente e a COOPERVAÍ – Cooperativa de Seleção de Materiais Recicláveis e Prestação de Serviços.
Este evento objetivou recolher equipamentos eletroeletrônicos, eletrodomésticos, cabos de energia e metais. Em dois dias de arrecadações e orientações acerca da necessidade de realizar o descarte correto, foi recolhido o total de 6.342,70 Kg de lixo eletrônico e contou com a participação de 129 doadores.
Todo o material recolhido foi repassado para a COOPERVAÍ que providenciou o destino correto deste lixo.

     
 



segunda-feira, 26 de maio de 2014

CEDI Promove Palestra sobre SCRUM: Gerenciamento de Projetos Ágeis

Com a participação maciça dos alunos dos cursos Técnico em Informática Integrado ao Ensino Médio, Técnico em Informática Subsequente e Superior de Tecnologia em Análise e Desenvolvimento de Sistemas do IFPR Câmpus de Paranavaí, a palestra SCRUM: Gerenciamento de Projetos Ágeis, realizada nos dias 15 e 16 de maio, foi um sucesso.
Em sua palestra o SCRUM Master e Gerente de Projetos, Marco Aurélio Rossi, apresentou o framework SCRUM, com riquezas de detalhes, possibilitando aos alunos obterem uma visão real de como o SCRUM é aplicado em inúmeras empresas de desenvolvimento de software.
A palestra foi promovida pelo CEDI – Centro de Desenvolvimento em Informática – IFPR Câmpus de Paranavaí e contou com o apoio da Empresa Unimake Softwares que disponibilizou o palestrante.
O objetivo do evento foi proporcionar aos estudantes de informática um ambiente para troca de informações e experiências sobre SCRUM aplicado no gerenciamento e desenvolvimento de produtos computacionais.
“Atualmente as empresas necessitam agilizar e melhorar seus processos de produção de software, afim de se manterem competitivas no mercado, então, temos observado que empresas de desenvolvimento tem discutido e aderido ao SCRUM, logo, proporcionar esta palestra para os nossos alunos, foi inspirador, pois oportunizamos a eles a capacitação inicial e conseguimos mostrar que a essência de projetos ágeis está na mudança de atitude das pessoas, no qual,  o comprometimento e a organização são fundamentais” ressalva a Prof. Késsia Rita da Costa Marchi.


quarta-feira, 19 de março de 2014

segunda-feira, 17 de março de 2014

1ª Mosta de Painéis – Técnico em Informática – Turma 2014

O 1º Ano do curso Técnico em Informática – Integrado ao Ensino Médio surpreendeu pela sua capacidade técnica e sua criatividade na 1ª Mostra de Painéis realizada.

Nesta mostra as equipes compostas por até 3 alunos, criaram painéis abordando os mais diferentes tipos de softwares e apresentaram estes painéis a todos os demais alunos do IFPR.


Parabéns a todos que participaram desta atividade! 






quinta-feira, 3 de outubro de 2013

Normalização


Ao modelar um banco de dados no modelo conceitual, podem ser identificadas inúmeras entidades com inúmeros atributos, que compõem o domínio da aplicação. Diante deste cenário, é inevitável o surgimento de diversas dúvidas, como, quantas entidades, de fato, irão compor o meu modelo? Quais são os atributos que devem ser considerados? Quais relacionamentos realmente existem? Com qual cardinalidade? Para responder a estas e outras dúvidas que podem surgir, garantindo que não haverá duplicidade de informações e não terá entidades, atributos e relacionamentos perdidos, é aplicado um processo bem definido, denominado Normalização.
A normalização nos ajuda tanto no refinamento de novos projetos, como também, no refinamento de entidades, atributos, relacionamento e cardinalidade de sistemas legados, permitindo ser aplicado em processos de engenharia reversa (HEUSER, 2009).
O processo de normalização consiste em uma técnica geralmente utilizada como guia no projeto de dados relacionais. Proposto por Codd, por volta de 1970, inicialmente com apenas 3 formas normais, que posteriormente, foi estendida por outras formas normais (SILBERCHATZ, 2012).
Como definição de normalização, podemos dizer que é o processo que permite a simplificação da estrutura de um banco de dados de modo que esta se apresente em um estado ótimo, sem duplicações de informações (DAMAS, 2007).
A teoria da normalização é baseada no conceito de Formas Normais. Uma forma normal é uma regra que deve ser obedecida por uma tabela para que seja considerada bem projetada(HEUSER, 2009). As formas normais são denominadas primeira, segunda, terceira e quarta forma normal, tendo como abreviações 1FN, 2FN, 3FN, Forma normal de Boyce/Cood, 4FN e 5 FN.
Neste texto apresentarei as Formas Normais, porém, vale a pena ressaltar que para a maioria dos casos basta normalizar até a 3 FN para obter um esquema considerado como normalizado.

Passagem à Primeira Forma Normal

 

Diz-se que uma tabela está na primeira forma normal, quando ela não contém tabelas aninhadas. Portanto, a passagem à 1FN consta na eliminação das tabelas aninhadas, eventualmente existentes.
Para transformar um esquema de tabelas não normalizadas para a 1FN há duas alternativas:
·         Construir uma única tabela com redundância de dados;
·         Construir uma tabela para cada tabela aninhada.
Considere o esquema conceitual apresentado a seguir:
PROJ(codProj, Tipo, Descr, (codEmp, nome, categoria, salario, datainicial, tempoal))
No esquema apresentado, é possível notar que há duas tabelas aninhadas, a primeira que consta os dados do projeto e a segunda que consta os dados do empregado. Para passarmos este esquema para a 1FN, vamos separar em duas tabelas, ficando na tabela PROJ apenas os dados do projeto, e levando para a tabela PROJEMP os dados do empregado no projeto, conforme o esquema conceitual a seguir:
PROJ(codProj, Tipo, Descr)
PROJEMP(codProj, codEmp, nome, categoria, salario, datainicial, tempoal)

Nesta passagem, podem ser perdidas relações entre informações, entretanto, para fins práticos, vamos considerar a decomposição de tabelas.

Passagem à Segunda Forma Normal

 

Para compreendermos a passagem a segundo forma normal, vamos entender primeiro o conceito de dependência funcional.
Em uma tabela relacional, diz-se que uma coluna C2 depende funcionalmente de uma coluna C1 (ou que a coluna C1 determina a coluna C2) quando, em todas linhas da tabela, para cada valor de C1 que aparece na tabela, aparece o mesmo valor de C2. Para exemplificar, temos a Tabela 1, que no qual, exibe o mesmo salário para cada código, ou seja, o Código E1 sempre exibe o salário 10. A notação de dependência funcional é representa por C1à C2, no exemplo, Código à Salário, que podemos dizer que o atributo Código determina o atributo salário ou que o atributo salário depende funcionalmente do atributo Código.
Tabela 1 - Exemplo de Dependência Funcional

Uma tabela encontra-se na 2FN quando, além de estar na 1FN, não contém dependências (funcionais) parciais.
Um dependência (funcional) parcial ocorre quando uma coluna depende apenas de uma parte de uma chave primária composta. Entendemos como chave primária compostas, as chaves primárias que são formadas por mais um atributo.
As tabelas que já estão na 1FN e possuem apenas uma coluna como chave primária, não contém dependências parciais, o que resulta na afirmação de que ela já está na 2FN. No exemplo apresentado abaixo, a tabela PROJ já está na 2FN por não contém chave primária composta, mas a tabela PROJEMP está apenas na 1FN, pois possui dependência parcial. Identificamos as dependências parciais nos atributos nome, categoria e salário, que são determinados apenas pela chave primária codEmp, o que estabelece uma dependência parcial. Os atributos datainicial e tempoal são determinados pelo chave primária composta por codProj e codEmp.
1FN
PROJ(codProj, Tipo, Descr)
PROJEMP(codProj, codEmp, nome, categoria, salario, datainicial, tempoal)
Para a passagem para a 2FN, copiamos a tabela PROJ, pois ela já está na 2FN e na tabela PROJEMP devemos eliminar as dependências parciais, fazemos isso dividindo a tabela PROJEMP em duas tabelas, como:
2FN
 PROJ(codProj, Tipo, Descr)
EMP (codEmp, nome, categoria, salario)
PROJEMP(codProj, codEmp, datainicial, tempoal)
O exemplo citado é possível observar que a tabela PROJEMP mantém sua chave primária composta.


Passagem a 3 Forma Normal

 

Uma tabela está na 3FN quando, além de estar na 2FN, não contém dependências transitivas. Uma dependência (funcional) transitiva ocorre quando uma coluna, além de depender da chave primária, depende de outra coluna ou conjunto de colunas da tabela.
Para exemplificar, vamos considerar a tabela EMP, exposta no exemplo acima. Neste exemplo, vamos supor que o salário (coluna salário) do funcionário seja determinado pela categoria funcional (coluna categoria). Neste caso, a representação de salário, que é determinada pela categoria, está representado redundantemente na tabela, pois para todos os funcionários pertencentes a mesma categoria será repetido o valor do salário. Então, podemos identificar neste exemplo uma dependência transitiva, no qual, o atributo salario é determinado pelo atributo chave primária codEmp e pelo atributo não chave categoria.
Para eliminar essa dependência transitiva realizamos a passagem a 3FN que consiste na divisão da tabela EMP de forma a eliminar a dependência transitiva.
3FN
PROJ(codProj, Tipo, Descr)
CAT (categoria, salario)
EMP (codEmp, nome, categoria)
PROJEMP(codProj, codEmp, datainicial, tempoal)

Forma Normal de Boyce/Codd

 

Para a maioria dos esquemas, a decomposição até a 3FN é suficiente para obter o esquema de banco de dados normalizado ou, no caso da engenharia reversa, correspondente ao documento. Entretanto, na literatura são citados ainda a Forma Normal de Coyce/Codd, a 4FN e a 5FN.
A forma normal de Boyce/Codd (FNBC) refere-se a um refinamento da 3 FN, este nome foi proposto pelo fato de que já haviam a 1FN, 2FN, 3FN, 4FN E 5FN, logo, fazer a 6FN como algo parecido com a 3FN não fazia sentido (DAMAS, 2007).
Enquanto a 3FN lida com dependências entre atributos chaves e não chave, a FNBC lida com dependências entre chaves.
As situações específicas que a FNBC lida são:
·         Existem múltiplas chaves candidatas;
·         As chaves candidatas são compostas;
·         As chaves candidatas se sobrepõem.
Caso algumas das situações acima não se verificar, então a FNBC se reduz à 3FN.
Como exemplo, podemos citar as seguintes dependências funcionais:
Encarregadoà Cidade, Departamento.
                Cada empregado trabalha em uma única cidade e gerencia um único departamento.
Cidade, Departamento à Encarregado.
                Só existe um encarregado para cada Cidade e Departamento.
Encarregado, Projeto, Cidade à Departamento.
                Podem existir vários encarregados para um mesmo projeto, mas tem de existir em cidades distintas;
                Cada encarregado pode ser responsável por mais de um projeto.
                Em cada cidade um projeto está associado a um único departamento e só tem um encarregado responsável por ele.
Para resolver esta situação pode-se separar  em duas tabelas, contendo:
Encarregado à cidade, projeto
Projeto à cidade, departamento.
Para que a FNBC seja aplicável é necessário que existam pelo menos duas chaves candidatas com atributos comuns que se sobrepõem.

Passagem a 4 Forma Normal

 

Até a FNBC são tratadas no processo de normalização as dependências funcionais. Entretanto, para a verificação de consistência, é necessário basear-se também em uma variação da dependência funcional, denominada dependência multivalorada.
Uma dependência multivalorada, embora um conjunto de atributos não possa determinar outro conjunto de atributos, ainda assim consegue restringir os valores possíveis para o respectivo conjunto.
Como definição temos: Dada uma relação R, se um conjunto de atributos A pertencentes a R, restringe os valores possíveis para os atributos de outro conjunto B também pertencentes a R, diz-se então que A Multidetermina B ou que B é Multidependente de A, e é representando pela notação A àà B.
Como exemplo, podemos ver na Figura 1, o CodProj determina o conjunto de dados de CodEmpr. 


Figura 1- Exemplo de Dependência Multivalorada

Dizemos que uma tabela está na 4FN quando, além de estar na 3FN e/ou FNBC, não contém mais de uma dependência multivalorada.
A passagem para a 4 FN, assim como as anteriores, também consiste na decomposição da tabela em tabelas menores. Para exemplificar, vamos considerar a seguinte tabela:
MATRICULA(codProj, Aluno, Sala)
Neste exemplo, podem ocorrer redundâncias se, um grupo de alunos alocados a um projeto poder ocupar duas ou mais salas, como pode ser visto na Tabela 2.


Tabela 2- Exemplo - Tabela Matrícula
Projeto
Aluno
Sala
1
A
S1
P1
B
S1
P1
C
S1
1
A
S2
P1
B
S2
P1
C
S2

É notório, neste exemplo, as redundâncias ocorridas, pois os alunos aparecem tantas vezes quanto as salas alocadas, e o mesmo ocorre com salas, que aparecem tantas vezes quanto a alunos alocados. Sendo assim, para passar esta tabela para a 4FN, decompomos a tabela em duas tabelas menores, ficando:
4FN
MATRICULAPROJALU(codProj, Aluno)
MATRICULAPROJSALA(codProj, Sala

Passagem a 5 Forma Normal

 

Uma tabela está na 5FN quando, além de estar na 4FN, o seu conteúdo puder ser reconstruído a partir de entidades menores.
A 5FN ou Forma normal de Projeção-Junção baseia-se no conceito de dependência de junção.
Dependência de junção expressa a capacidade de um tabela, que tenha sido decomposta em duas ou mais tabelas menores, de se reconstruir novamente a partir das novas tabelas, obtendo-se a tabela original. Logo, uma tabela está na 5FN quando não é mais possível decompô-la.
Há um consenso que são raras as exceções que necessitam da passagem para a 5FN, na maioria dos casos, quando uma tabela está na 4FN também estará na 5FN.

Referências
DAMAS, L. SQL, Strutucture Query Language. Rio de Janeiro. LTC, 2007.
HEUSER, C. Projeto de Banco de Dados. São Paulo. Bookman, 2009.
SILBERCHATZ, A. Sistemas de Banco de Dados. Rio de Janeiro. Elsevier, 2012.