O documento discute técnicas e modelos para levantamento de requisitos e modelagem de dados para desenvolvimento de sistemas. Apresenta entrevistas, questionários e JAD como técnicas para captura de requisitos e discute modelos como cascata, prototipação e espiral. Também aborda normalização e relacionamentos na modelagem de dados.

1. TUDO SÃO DADOS! DIEGO THOMAZ FLÔRES www.ecrayon.com.br PHP Conference 2008

2. DIEGO THOMAZ FLÔRES Analista e programador PHP há 6 anos, já desenvolveu projetos de médio e grande porte para clientes como o Ministério do Turismo, EMBRATUR, Fundação Getúlio Vargas - RJ, GMagazine, Telefonica e Agência Click. Atua como Gerente de Projetos na Bolsoni Tecnologia & Turismo , desenvolvendo e coordenando os projetos Brasil.com.br e Boletim de Ocupação Hoteleira (EMBRATUR/FGV-RJ). É aluno do último ano do curso superior em Análise de Bancos de Dados no IBTA – São Paulo/SP. Além disso, é responsável pela ECRAYON Tecnologia Criativa , estúdio de desenvolvimento de sistemas web-based .

3. ALGUNS CASES

4. AGENDA Especificação de Requisitos Conceituação Técnicas para captura de requisitos Modelagem de Dados Conceituação Projetando o Banco de dados Normalização

5. “ O modo mais provável do mundo ser destruído, como concorda a maioria dos especialistas, é através de um acidente. É ai que nós entramos. Somos profissionais de computação. Nós causamos acidentes.” Nathaniel Borestein

6. Estudos mostram que 50% das falhas no setor industrial alemão são causadas por erros em software. 1977: Média de 7-20 defeitos por 1000 linhas de código 1994: Média de 0,2-0,05 defeitos por 1000 linhas de código A tolerância de um nível de defeito de 0,1% significa: por ano: 20.000 medicamentos defeituosos 300 falhas em marcapassos por semana: 500 erros em operações médicas por dia: 16.000 cartas perdidas nos correios 18 quedas de aviões por hora: 22.000 cheques descontados incorretamente

7. AS SETE QUESTÕES FUNDAMENTAIS PARA O PLANEJAMENTO DE SOFTWARE Por que o sistema vai ser construído? O que deve ser feito? Como vai ser feito? Quando vai ser feito? Quem vai fazer? E quem são os responsáveis? Onde se aplicam essas responsabilidades? Quanto vai custar?

8. FASES DO PLANEJAMENTO DE SOFTWARE Definição Desenvolvimento Manutenção Análise do Sistema Planejamento do projeto Análise de Requisitos Projeto de Software Codificação Realização de Testes Correção Adaptação Expansão

9. FASE 1: DEFINIÇÃO ou ESPECIFICAÇÃO Por quê? Identificação do problema Análise da situação atual O quê? Definição conceitual de soluções Como? Definição do escopo global Planejamento do projeto de software Análise de riscos Quando? Refinamento do escopo Cronograma geral Cronograma modular Quem? Alocação de recursos Onde? Definição de responsabilidades; Definição de ambientes de desenvolvimento, homologação e produção. Quanto? Estimativa de custos Cronograma específico

10. FASE 2: DESENVOLVIMENTO Projeto de Software Traduz os requisitos do software num conjunto de representações que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algorítmicos e as características de interface. Codificação As representações do projeto devem ser convertidas numa linguagem artificial que resulte em instruções que possam ser executadas pelo computador. Realização de Testes Logo que o software é implementado numa forma executável por máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação.

11. FASE 3: MANUTENÇÃO Correção Mesmo com as melhores atividades de garantia de qualidade de software, é provável que o cliente descubra defeitos no software Adaptação Com o passar do tempo, o ambiente original para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o software para acomodar mudanças em seu ambiente. Expansão À medida que o software é usado, o usuário reconhecerá funções adicionais que oferecerão benefícios.

12. MODELOS DE PROCESSO DE SOFTWARE Consiste em uma série de atividades que garantem, técnica e administrativamente que o software pode ser desenvolvido de maneira organizada, disciplinada e previsível. Um modelo de processo procura descrever formalmente e de maneira organizada todas as atividades que devem ser seguidas para a obtenção segura de um produto de software. É importante escolher um modelo apropriado às metas da organização e saber o grau em que esse modelo será implementado. BENEFÍCIOS Estabelece uma linguagem comum; Constrói um conjunto de processos e procedimentos desenvolvidos com sugestões de uma ampla participação da comunidade de software; Oferece uma estrutura para se priorizar as ações. RISCOS Não são suficientemente abrangentes; É necessário bom senso para se utilizar modelos corretamente e com visão.

13. MODELOS DE PROCESSOS DE SOFTWARE: LINEAR ou CASCATA Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

14. PROBLEMAS NA IMPLEMENTAÇÃO LINEAR ou CASCATA Dificuldade em prever todos os detalhes de funcionamento e comunicação dos módulos logo no início do projeto; O prazo de entrega do produto final é sempre maior, uma vez que a etapa seguinte só inicia quando a anterior estiver completamente finalizada; Os custos do projeto aumentam devido à alocação desnecessária e ociosa de recursos, que ficam à espera das fases anteriores serem finalizadas para iniciarem suas atividades.

15. MODELOS DE PROCESSOS DE SOFTWARE: PROTOTIPAÇÃO construa/revise o protótipo teste do protótipo pelo cliente ouça o cliente

16. PROBLEMAS NA IMPLEMENTAÇÃO POR PROTOTIPAÇÃO Cliente cria grande espectativa em cima do prótipo e na maioria das vezes não enxerga o mesmo como um modelo híbrido do produto final; Desenvolvedor freqüentemente faz uma adaptação do modelo híbrido para o modelo final do produto, comprometendo a qualidade do código.

17. MODELOS DE PROCESSOS DE SOFTWARE: ESPIRAL É um modelo iterativo, que integra as etapas características do desenvolvimento linear com a familiarização do cliente ao produto final, típicas da prototipação. Nas primeiras iterações a versão incremental pode ser um modelo em papel ou um protótipo; nas iterações mais adiantadas são produzidas versões incrementais mais completas e melhoradas. Dinamiza e facilita possíveis correções ou alterações de escopo a cada iteração, permitindo melhor execução e implementação do produto final sem comprometer o cronograma geral. Planejamento Análise de Risco Engenharia Construção e Release Avaliação do Cliente Adaptações

18. TÉCNICAS PARA LEVANTAMENTO DE REQUISITOS Entrevistas É a técnica mais utilizada para captura de requisitos. A característica básica da entrevista é o diálogo entre o entrevistador e um entrevistado. Questionários Série de perguntas escritas para obter informações de indivíduos, usados quando há um grande número de pessoas de quem as informações e opiniões são necessárias. Também é muito utilizado para sistemas a serem implantados fora do cliente ou para sistemas com usuários espalhados em diversos locais. JAD – Joint Application Design Workshops de imersão, realizado em três etapas, onde reunem-se ao mesmo tempo usuários gerais, especializados, desenvolvedores e representantes do cliente.

19. ENTREVISTAS: boas práticas! Apresente-se e deixe claro o seu objetivo; foco é essencial; Garanta a confidencialidade das informações e anonimato das respostas; Fique atento às emoções e expressões do entrevistado. Muitas informações são colhidas por meio de comunicação não-verbal; Deixe o entrevistado à vontade, lembrando que uma ação provoca uma reação: ao se mostrar indiferente ao entrevistado, ele possivelmente desenvolverá uma reação de defesa, deixando de informar o que interessa; Mantenha a imparcialidade durante as perguntas: é a opinião dele que interessa; Encadeie os assuntos de forma lógica, criando ganchos na conversa que possibilitem a mudança de assunto; Equilibre profundidade e superficialidade das perguntas.

20. QUESTIONÁRIOS: boas práticas! Peça somente a informação que realmente pode ser fornecida; Disponha as perguntas em uma seqüência lógica e defina suas prioridades; Formule perguntas claras, evitando dupla interpretação; Seja o mais breve possível: ninguém gosta de responder um questionário sem fim; Informar na carta que acompanha o questionário o tempo estimado para o preenchimento; Caso exista algum padrão com que se possa comparar as repostas obtidas, dê preferência a perguntas fechadas, oferecendo apenas as alternativas esperadas; Evite abreviações, termos tendenciosos ou sugestivos; Numere as perguntas para evitar confusão; Ofereça anonimato aos entrevistados.

21. JAD: IMERSÃO E TRABALHO EM EQUIPE! Existem três tipos básicos de reuniões de projeto: sessões estratégicas , onde são discutidos o âmbito, objetivos, recursos, políticas e mudança organizacional; sessões de dados e processos , onde se constrói ou aperfeiçoa os diagramas de fluxo de dados e modelos de dados; sessões de telas e relatórios , onde se definem as entradas e saídas dos sistemas.

22. JAD – IMERSÃO E TRABALHO EM EQUIPE! A metodologia está dividida basicamente em três partes: Reunião inicial São estabelecidos os principais objetivos do projeto e planejado o trabalho. Reunião de revisão É feita uma revisão relativa à reunião inicial, avaliada a situação das tarefas previstas e identificados os problemas e suas possíveis correções, buscando atingir a terceira etapa dentro dos prazos estabelecidos. Sessão de design São desenvolvidos os projetos de interface da aplicação enfocada. A sessão de design é a reunião mais importante do processo . Dela devem participar todas as pessoas escolhidas na reunião inicial e confirmadas na reunião de revisão. Normalmente, a cada atividade da sessão, são atribuídos tempos previstos, procurando determinar a quantidade necessária de reuniões.

23. E o que a MODELAGEM DE DADOS tem a ver com tudo isso? TUDO! Assim como para o desenvolvimento de sistemas de software, também para a modelagem de dados o fator mais importante é a interação entre a equipe técnica e o cliente. Sem a compreensão do problema e do contexto onde ele está inserido e sem a compreensão das soluções propostas durante a especificação do sistema, todo o esforço até aqui pode ser desperdiçado por um modelo de dados ruim.

24. TUDO SÃO DADOS! DADOS São valores brutos, registros que são armazenados. Dados são estáticos, ou seja: eles permanecem da mesma forma do início ao fim de qualquer processo, a menos que sejam modificados por algum usuário ou funcionalidade da aplicação. INFORMAÇÃO É o dado dentro de um contexto onde ele faça sentido e ganhe significado. Um único dado pode representar inúmeras informações diferentes - tudo depende do contexto onde ele é apresentado e do público a quem ele será exibido. AQUILO QUE PARA O SEU CLIENTE É INFORMAÇÃO , PARA VOCÊ SEMPRE SERÁ D ADO !

25. ANÁLISE E MODELAGEM DE DADOS O processo de análise e modelagem de dados tem por objetivo principal definir um modelo claro, conciso e equilibrado da realidade, sem qualquer influência dos meios computacionais que utilizaremos para resolver o problema. Os dados gerados para ou pelo produto em desenvolvimento a fim de resolver determinado problema devem ser absolutamente independentes da tecnologia que será utilizada para interpretá-lo, fornecê-lo ou consumí-lo. Construir o modelo de dados é um processo evolutivo e se modifica à medida que a realidade é conhecida. Uma modelo de dados representa uma visão parcial da realidade do cliente ou produto. Cada visão da realidade tem vocabulário e regras definidas, que representam as próprias regras do negócio.

26. BENEFÍCIOS DA MODELAGEM DE DADOS O Modelo nasce no mundo do Usuário e do Negócio e, portanto, fornece um ponto focal para discussões sobre o que é importante para o desenvolvimento do produto em questão. As fases iniciais do processo são oportunidade real para os profissionais de Negócios se depararem com discussões sobre seus assuntos com profissionais de outras áreas, numa situação nova de compartilhamento de interesses e solução de conflitos; As reuniões de planejamento levam a uma linguagem comum para o assunto tratado e normalmente a fluidez de comunicação entre os participantes melhora; As fases iniciais estruturam meios de troca de uma grande quantidade de informação entre as áreas envolvidas, além de uma enorme transferência de conhecimento de Negócios para os profissionais de TI. As fases finais levam resíduos dessa transferência aos profissionais que irão implementar a solução; Os participantes acabam percebendo melhor como suas atividades se acomodam em um contexto mais amplo. Com o passar do tempo, há ganho em valores e reforço no senso de cooperação.

27. BENEFÍCIOS DA MODELAGEM DE DADOS Discussões sobre as funções que serão executadas pelo sistema sempre mostram novos requerimentos de dados; discussões sobre os dados e sua estrutura sempre mostram novos requerimentos funcionais. Dessa forma, é importante desenvolver simultaneamente o Modelo de Dados e o Modelo Funcional. Enquanto os Modelos Funcionais descrevem "como" os requisitos serão atendidos pelo sistema, os Modelos de Dados descrevem "o quê" será atendido e "por quem".

28. MODELO DE PROCESSOS DE MODELAGEM DE DADOS ENTIDADES TABLES CHAVES PRIMARY KEY, FOREIGN KEYS, INDEXES ATRIBUTOS COLUMN TRANSFORMAÇÃO SQL DUMP ESCOPO MODELO LÓGICO FÍSICO

29. MODELO DE PROCESSOS DE MODELAGEM DE DADOS NÍVEL 1: ENTIDADES Identificam-se os principais atores do Modelo de Dados. NÍVEL 2: CHAVES Para cada entidade identificada, definem-se seus chaves de identificação e os relacionamentos entre elas. A partir desses relacionamentos, e com a especificação correta das cardinalidades entre eles, é que as regras de negócio são implementadas no Modelo de Dados. NÍVEL 3: ATRIBUTOS Pode ser dividido em dois sub-níveis: detalhamento e normalização. No primeiro, todas as estidades são qualificadas e descritas em detalhes; no segundo, os atributos são levados da 1ª à 3ª Forma Normal, garantindo a consistência do Modelo em questão.

30. CARDINALIDADE É a regra do Modelo de Dados que estabelece quantas vezes um registro da entidade-pai poderá se relacionar com um único registro da entidade-filha . Esses relacionamento são chamados FOREIGN KEYS . As cardinalidades possíveis de implementação são: UM para ZERO, UM ou mais; UM para UM ou mais; UM para ZERO ou UM; ZERO para ZERO, UM ou mais; ZERO para UM ou mais; ZERO para ZERO ou UM.

31. EXEMPLO DE MODELO DE DADOS COMPLETO

32. REGRAS PARA A MODELAGEM DE DADOS: ENTIDADES Unicidade e não nulificação das chaves primárias Chaves primárias são os identificadores únicos de cada registro. Podem ser compostas por quantos atributos forem necessários para garantir a unicidade de identificação, sem, porém, conter valores nulos nos elementos que a compõe. Processos Define quais eventos e como os processos de negócio acessam, modificam, excluem e incluem as ocorrências das entidades. A partir dessas regras, em conjunto às Regras do Negócio, são definidas as estruturas de functions e stored procedures do Modelo de Dados. Estado e Transição de Estado Define os estados possíveis de serem assumidos pela entidade, aumentando o entendimento sobre a dinâmica de seu mecanismo. Define também as causas que motivam as mudanças de estado das entidades, permitindo identificar eventos temporais e mecanismos disparadores associados (triggers) .

33. REGRAS PARA A MODELAGEM DE DADOS: RELACIONAMENTOS Também chamada de “Integridade Referencial”, define o comportamento das entidades em relação as operações de inclusão, deleção e modificação nas entidades relacionadas. São opções de configuração para as regras de relacionamento: CASCADE; RESTRICT; SET NULL; SET DEFAULT; NONE.

34. REGRAS PARA A MODELAGEM DE DADOS: ATRIBUTOS Nomenclatura O nome do atributo deve ser claro e suficientemente descritivo a fim de retratar a semântica de seu conteúdo. Hierarquia e filiação Os atributos devem ser definidos de forma coesa, pertencendo a uma ou mais entidades, dependendo da sua função (identificação, relacionamento ou qualificação). Formatação e validação Os atributos devem ser definidos dentro do conceito de domínio, onde são explicitados o seu formato, regras de derivação, validação e manipulação, valores iniciais, formatação e apresentação.

35. REGRAS PARA A MODELAGEM DE DADOS: DERIVAÇÃO Definem os meios de obtenção de um registro. A partir delas é possível obter um dado a partir de outros dados, seus relacionamentos, domínios e máscaras. Registros simples são obtidos de maneira direta em sua entidade de origem; Registros complexos geralmente têm suas regras de derivação compostas por combinações de fórmulas de cálculo e lógicas de associação.

36. REGRAS PARA A MODELAGEM DE DADOS: NEGÓCIOS São regras específicas que uma empresa estabelece para funcionamento do seu negócio. Objetivamente, estabelecem as regras validação das entidade identificadas, seus atributos e relacionamentos. Além disso, são as regras de negócio que definem e especificam as interrelações do Modelo de Dados com a Aplicação, assim como da Aplicação com o Usuário. Regras de Negócios bem definidas auxiliam ainda na interpretação semântica da aplicação e do banco de dados e seus componentes lógicos (classes, triggers, functions, stored procedures, etc.) , garantindo melhores perspectivas para futuro reaproveitamento e encapsulamento de procedimentos comuns.

37. INTEGRIDADE REFERENCIAL Uma vez que um banco relacional se apóia em entidades e seus atributos para implementar relacionamentos (FOREIGN KEY) , a integridade dos dados nos atributos chave (PRIMARY KEY) é fundamental. Após a definição das entidades e seus relacionamentos, o passo mais importante do processo é definir a regra de propagação destes. Para cada um deles é necessário definir qual ação deve ser tomada em caso de inserção, alteração ou deleção do registro pai. O slide a seguir define cada uma das configurações possíveis para a propagação de alterações nas PRIMARY KEYS .

38. CASCADE Sempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha sofre a mesma ação, por cascata. RESTRICT Modificações na entidade-pai são proibidas caso existam instâncias de relacionamento em qualquer entidade-filha. SET NULL Sempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha recebem o valor NULL. SET DEFAULT Sempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha recebem o valor padrão definido para aquele atributo. NONE Independente da modificação na entidade-pai, nenhuma ação é realizada no registro da entidade-filha.

39. NORMALIZAÇÃO DO MODELO DE DADOS É o conjunto de regras que objetiva o maior refinamento possível do Modelo de Dados inicial, garantindo que o resultado final não contenha qualquer redundância lógica. Importante: um Modelo de Dados completamente normalizado não leva em conta considerações de performance, nem o SGBD onde o sistema será implementado. Durante o desenvolvimento do projeto, a análise de performance poderá provocar modificações do modelo canônico.

40. NORMALIZAÇÃO DO MODELO DE DADOS: 1ª FORMA NORMAL Identificar todos os grupos repetitivos; Atomizar os grupos repetitivos a partir do estabelecimento de dependências funcionais entre as entidades.

41. NORMALIZAÇÃO DO MODELO DE DADOS: 2ª FORMA NORMAL Aplicar a 1ª FORMAL NORMAL em sua totalidade; Eliminar dependências parciais entre os atributos e a chave primária.

42. NORMALIZAÇÃO DO MODELO DE DADOS: 3ª FORMA NORMAL Aplicar a 2ª FORMAL NORMAL em sua totalidade; Garantir a dependência exclusiva entre os atributos e a totalidade da chave primária.

43. NORMALIZAÇÃO DO MODELO DE DADOS: 3ª FORMA NORMAL

44. MODELAGEM DE DADOS: boas práticas! Em modelagem de dados em particular, assim como em desenvolvimento de sistemas em geral, é extremamente importante adotar e seguir padrões de nomenclatura de objetos . O dispêndio de tempo e esforço com esta preocupação rende um modelo conciso, claro e sem ambiguidades. Definir as entidades de um modelo é mais do que criar sua estrutura, escolher chaves e criar relacionamentos. É preciso também criar informação que sirva para documentar a função da existência daquela entidade . Assim como nas entidades, a definição de atributos deve ser feita de maneira clara, e valem as mesmas regras. Assim, as definições de atributos também pedem a mesma coisa: descrição, exemplo e comentários. Além disso, as definições devem ter, sempre que possível, regras de validação .

45. LEIS DE CONSISTÊNCIA DE DADOS As tabelas componentes do modelo estarão na 3ªFN. Se o modelo for desnormalizado posteriormente, controles procedurais adicionais deverão ser incluídos e documentados. Não existirão duas tabelas com a mesma chave. Se aparecerem, elas devem ser agrupadas e re-normalizadas Se Y é um subconjunto da chave de uma tabela T1 e tem sentido isoladamente, deve existir uma segunda tabela T2 tendo Y como chave; Se X, um atributo simples ou composto, é chave de uma tabela T1, ele é chamado atributo primário. Nesse caso ele pode aparecer em outras tabelas, onde é chamado de chave estrangeira. Se X não é chave de nenhuma tabela, ele é um atributo secundário ou não primário e só pode aparecer em uma única tabela.

46. LEIS DE CONSISTÊNCIA DE DADOS Se X, atributo simples ou composto, é chave de uma tabela T1 e aparece como atributo em uma outra tabela T2, existe uma relação hierárquica subordinando T2 a T1 segundo X; Se X , atributo simples ou composto, é chave de uma tabela T1 e Y, um atributo cujo domínio é o mesmo de X, aparece em uma tabela T2, então: Y não pode isoladamente ser chave de T2; Existe uma relação hierárquica subordinando T2 a T1, segundo T1.X <=> T2.Y

47. OBRIGADO PELA PRESENÇA! DIEGO THOMAZ FLORES [email_address] www.ecrayon.com.br