SHOITI SANO (1.099Mb)

Texto

(1)UNIVERSIDADE PRESBITERIANA MACKENZIE. SHOITI SANO. METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PRESCRITIVO X ÁGIL. São Paulo 2012.

(2) SHOITI SANO. METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PRESCRITIVO X ÁGIL. Monografia apresentada ao Programa de Pós-Graduação Lato Sensu da Escola de Engenharia da Universidade Presbiteriana Mackenzie, como requisito parcial para a obtenção do Título de Especialista em Gestão de Projetos.. São Paulo 2012.

(3) À minha mãe, pela constante cobrança e apoio na conclusão deste trabalho..

(4) AGRADECIMENTOS. Agradeço a todos os meus familiares que, compreenderam todas as minhas ausências as festas e confraternizações, bem como minha reclusão.. À minha mãe, Mitsue, que me permitiu dar foco a esta monografia.. À professora Kassya, ao professor Domingos e ao professor Bira por seus direcionamentos e suas incríveis disposições para ajudar e aconselhar..

(5) RESUMO. No atual cenário global, empresas que não conseguirem entregar seus produtos tão ou mais rápido do que seus concorrentes, a custos e qualidade compatíveis, perderão espaço no mercado. Por isso ter um processo ágil e flexível que permita às empresas desenvolver seus sistemas de forma a que eles cheguem ao mercado no tempo, custo e qualidades corretos tornou-se crítico. As metodologias de desenvolvimento de sistemas tem um papel importante não só na entrega dos sistemas dentro dos prazos exigidos pelo negócio, mas também no controle dos custos e escopo, por esse motivo o presente trabalho busca, a partir de um estudo de caso, identificar as melhores práticas das mais conhecidas metodologias de desenvolvimento de sistemas Prescritivas e Ágeis e apresentar uma nova metodologia de desenvolvimento de sistemas que foi criada no estudo de caso apresentado, com base em algumas dessas melhores práticas. Palavras-chave: Metodologias. Desenvolvimento. Sistemas. Ágil. Prescritiva.

(6) ABSTRACT. In the present global scenario, companies that are not able to deliver their products as fast as or faster than their competitors, at compatible costs and quality, will lose space in the market. That is why having a quick and flexible process that allows companies to develop their systems in a way that they arrive in the market, on time as well as at correct cost and quality has become critical. The methodologies of systems development have an important role, not only at delivering systems according to the deadlines of the business, but also at controlling the costs and scope, therefore this work proposes, through a case study, to identify the best practices from the most known methodologies of Prescriptive and Agile systems development and introduce a new methodology of systems development which was accomplished in the case study presented, based on some of these best practices. Key-words – Methodologies. Development. Systems. Agile. Prescriptive..

(7) Lista de ilustrações. Figura 1: Despesas e Investimentos com Tecnologia................................................12 Figura 2: O modelo em cascata.................................................................................16 Figura 3: O modelo incremental ................................................................................17 Figura 4: Tipos de protótipo........................................................................................19 Figura 5: O modelo de prototipagem..........................................................................19 Figura 6: O modelo espiral.........................................................................................20 Figura 7: O extreme programming.............................................................................28 Figura 8: Seleção de estórias para o Sprint...............................................................31 Figura 9: O fluxo de processo SCRUM......................................................................32 Figura 10: Modelo de diagrama entidade-relacionamento.........................................35 Figura 11: Exemplo de representação mínima de uma classe..................................36 Figura 12: Exemplo de classe com atributos..............................................................37 Figura 13: Exemplo de uma classe com três divisões...............................................38 Figura 14: Exemplo de diagrama de caso de uso......................................................40 Figura 15: Exemplo de diagrama de classes.............................................................42 Figura 16: Exemplo de diagrama de objetos..............................................................43 Figura 17: Exemplo de diagrama de sequência.........................................................44 Figura 18: Exemplo de diagrama de estados.............................................................45 Figura 19: Exemplo de diagrama de atividades.........................................................46 Figura 20: Exemplo de diagrama de implantação......................................................47.

(8) Figura 21: Escopo de fornecimento da fábrica de software.......................................48 Figura 22: Metodologia do Tipo Prescritiva Incremental do Banco A........................53.

(9) Lista de siglas. ASD. Desenvolvimento Adaptativo de Software. BC. Banco Central. Ciab Febraban. Congresso e Exposição de Tecnologia da Informação das Instituições Financeiras. DSDM. Método Dinâmico de Desenvolvimento de Sistemas. FDD. Desenvolvimento Guiado por Características. KIS. Mantenha a simplicidade. MA. Modelagem Ágil. MER. Modelo Entidade Relacionamento. SCRUM. Metdologia Ágil. UML. Linguagem de Modelagem Unificada. XP. Extreme Programming.

(10) Sumário. 1. INTRODUÇÃO_________________________________________________________ 11 2. METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS________________ 15 2.1. METODOLOGIAS PRESCRITIVAS _________________________________________ 15 2.1.1. Cascata _______________________________________________________________________ 15 2.1.2. Incremental ____________________________________________________________________ 16 2.1.3. Evolucionários _________________________________________________________________ 17 2.1.3.1. Prototipagem ______________________________________________________________ 18 2.1.3.1. Espiral ____________________________________________________________________ 20 2.1.4. Conceitos comuns ______________________________________________________________ 21 2.1.4.1. Comunicação ______________________________________________________________ 21 2.1.4.2. Planejamento ______________________________________________________________ 23 2.1.4.2. Modelagem ________________________________________________________________ 25 2.1.4.2. Construção ________________________________________________________________ 26 2.1.4.2. Implantação _______________________________________________________________ 27. 2.1. METODOLOGIAS ÁGEIS __________________________________________________ 27 2.1.1. Extreme Programming (XP) ______________________________________________________ 28 2.1.2. SCRUM _______________________________________________________________________ 30. 3. CONCEITOS E PRODUTOS ____________________________________________ 33 3.1. SISTEMAS DE BANCOS DE DADOS _______________________________________ 33 3.1.1.. Modelos de dados __________________________________________________________ 33.

(11) 3.1.1.1. O modelo entidade-relacionamento ___________________________________________ 34. 3.2. ORIENTAÇÃO A OBJETOS ________________________________________________ 35 3.2.1. Classes de objetos______________________________________________________________ 36 3.2.2. Atributos ou Propriedades de uma Classe _________________________________________ 36 3.2.3. Métodos ou Comportamentos de uma Classe ______________________________________ 37. 3.3. UML – UNIFIED MODEL LANGUAGE _______________________________________ 38 3.3.1. Modelos estáticos ______________________________________________________________ 39 3.3.2. Modelos dinâmicos _____________________________________________________________ 43. 3.4. FÁBRICA DE SOFTWARE _________________________________________________ 47 3.4.1. Fábrica de programas ___________________________________________________________ 49. 4. METODOLOGIA DE DESENVOLVIMENTO própria DO BANCO A __________ 52 4.1. FASES DA METODOLOGIA DO TIPO PRESCRITIVA INCREMENTAL DO BANCO A ___________________________________________________________________________ 54 4.1.1. Escopo e estimativa_____________________________________________________________ 54 4.1.2. Análise ________________________________________________________________________ 56 4.1.3. Desenho Físico _________________________________________________________________ 57 4.1.4. Construção ____________________________________________________________________ 58 4.1.5. Testes _________________________________________________________________________ 58 4.1.6. Implantação ____________________________________________________________________ 60. 5. CONCLUSÃO _________________________________________________________ 62 Referências _____________________________________________________________ 65.

(12) 11. 1. INTRODUÇÃO A redução na quantidade de instituições financeiras e dos juros pelo BC 1 estão reduzindo a margem de lucro das instituições financeiras. Para aumentar o lucro, antes fácil devido aos juros altos, as instituições financeiras precisam agora reduzir custos, o que significa melhorar o Índice de Eficiência, que é medido internacionalmente pela divisão da soma das despesas de pessoal e administrativas pela soma da receita de juros e serviços.. Para reduzir custos com tecnologia da informação, uma área estratégica para as instituições financeiras, pois a tecnologia representa muitas vezes o diferencial competitivo entre uma instituição e sua concorrente, as instituições financeiras passaram a buscar formas de desenvolver uma quantidade maior de sistemas, em menos tempo, com melhor qualidade e gastando menos.. Segundo pesquisa apresentada como lançamento do Ciab FEBRABAN 20112, revela que com base no cenário descrito e na distribuição das despesas e investimentos de 2010 divulgado pela Febraban ( 2011), representada na Figura 1 – em que é constatado que os itens “Softwares In House” e “Softwares de 3os” representam 31% dos gastos e investimentos. – maior até que o gasto e. investimento em Hardware, que representa 29%.. 1. Banco Central.. 2. Congresso e Exposição de Tecnologia da Informação das Instituições Financeiras..

(13) 12. Figura 1: Despesas e Investimentos com Tecnologia Fonte: FEBRABAN – CIAB 2011 – A Tecnologia Além da Web, 2011, p. 9. O objetivo desta monografia é apresentar os conceitos de algumas das metodologias de desenvolvimento de sistemas mais conhecidas, tais como a cascata, a incremental, a prototipagem, a espiral, o XP e o SCRUM, e o estudo de caso em uma instituição financeira, que estruturou sua própria metodologia de desenvolvimento a partir das existentes, misturando partes específicas delas às diferentes particularidades de cada um de seus projetos, obtendo como resultado sistemas entregues dentro do prazo, custo e qualidades desejados.. Existem dois tipos de metodologias de desenvolvimento de sistemas, as metodologias prescritivas e as ágeis, onde a primeira descreve produtos que devem ser desenvolvidos para todos os projetos, enquanto a segunda não exige que se desenvolvam todos os produtos para todos os projetos, apenas os necessários; para descobrir se é possível conciliá-las de forma a se extrair o que há de melhor em.

(14) 13 cada uma delas juntando-as em uma única metodologia, utilizarei um estudo de caso de uma instituição financeira chamada Banco A3.. O autor deste trabalho é um analista de sistemas do Banco A que se utiliza dessa metodologia de desenvolvimento própria.. Vale salientar que, a monografia baseia-se em referências bibliográficas que forneceram as informações, tanto para o desenvolvimento da fundamentação teórica, quanto para o estudo de caso; destacam-se entre as referências, o livro “Engenharia de Software” e o “Guia de Metodologia de Desenvolvimento de Sistemas” do Banco A, dos quais grande parte das demais referências se originaram.. A metodologia utilizada nesta monografia está em inicialmente fundamentar-se teoricamente com as diversas referências existentes da engenharia de software e com o estudo de caso, alinhar a teoria às práticas, bem como realizar análises sobre o desenvolvimento e utilização dos modelos criados com a implantação da metodologia adaptada dentro da instituição financeira estudada.. Sendo que esta monografia está dividida em 5 capítulos: introdução, descrição das principais metodologias de desenvolvimento de software, conceitos e produtos, descrição da metodologia própria do Banco A e conclusões.. O Capítulo 1 apresenta o objetivo do trabalho e os motivos que levaram o autor à escolha deste tema.. 3. A instituição financeira em questão não me autorizou a citar seu nome. Referências ao nome da. instituição serão então substituídas pelo termo Banco A..

(15) 14 O capítulo 2 tem como objetivo descrever as principais metodologias de desenvolvimento de sistemas existentes que serviram de base para a criação da metodologia própria adotada pelo Banco A.. O capítulo 3 tem como objetivo descrever os principais conceitos e produtos gerados em cada uma das fases das metodologias. O capítulo 4 relaciona cada fase da metodologia de desenvolvimento própria do Banco A às fases, atividades e produtos das metodologias.. O capítulo 5 tem o objetivo de realizar as considerações finais sobre o tema proposto, usando o estudo de caso como exemplo de que é possível extrair o que há de melhor entre as diversas metodologias de desenvolvimento de software, criando uma metodologia híbrida que permite a construção de sistemas com maior adequação com relação a prazo, custo e qualidade..

(16) 15 2. METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS. As metodologias de desenvolvimento de sistemas nada mais são do que modelos a serem seguidos, padronizando dessa forma o desenvolvimento de sistemas, conforme declara Pressman (2006, p. 38):. Toda organização de engenharia de software deveria descrever um conjunto específico de atividades de arcabouço para o(s) processo(s) de software que adota. Deveria preencher cada atividade de arcabouço com um conjunto de ações de engenharia de software e definir cada ação em termos de um conjunto de tarefas que identifique o trabalho (e produtos de trabalho) a ser realizado para satisfazer às metas de desenvolvimento. Deveria, então, adaptar o modelo de processo resultante para acomodar a natureza específica de cada projeto, o pessoal que vai fazer o trabalho e o ambiente no qual o trabalho vai ser conduzido.. 2.1. METODOLOGIAS PRESCRITIVAS. Chamamos as metodologias Cascata, Incremental e Evolucionárias de prescritivas, pois elas prescrevem um conjunto de atividades, produtos de trabalho e mecanismos de controle de qualidade e de controle de mudanças, os quais devem ser realizados e entregues em um determinado fluxo de trabalho (Pressman, 2006).. 2.1.1. Cascata. A metodologia cascata exige que os requisitos de negócio estejam claros e bem definidos desde o início devido a sua natureza sistemática e linear de desenvolvimento, conforme podemos observar abaixo na Figura 2..

(17) 16. Figura 2: O modelo em cascata Fonte: Pressman, 2006, p. 39. Porém, em geral, como é possível observar nos projetos de desenvolvimento de software, é difícil para os clientes estabelecer todos os requisitos no início do projeto, e como o cliente só recebe uma versão executável do programa na fase final do projeto, caso algum erro seja detectado nesta, será preciso retornar às fases anteriores (PRESSMAN, 2006).. 2.1.2. Incremental. A metodologia incremental permite a entrega do sistema aos clientes de forma modular, ou seja, entrega-se o sistema por conjunto de funcionalidades ordenados por priorização, ela também permite refinar e expandir funcionalidades em versões subsequentes (Pressman, 2006).. Ela exige que os requisitos de negócio estejam claros e bem definidos, porém, não para o escopo total do projeto, pois, conforme já foi dito, esta metodologia permite o desenvolvimento por módulos, ou seja, partes prontas do sistema são entregues a cada passagem completa de todas as fases (Comunicação, Planejamento, Modelagem, Construção, Implantação) desta metodologia, conforme podemos observar abaixo na Figura 3..

(18) 17. Figura 3: O modelo incremental Fonte: Pressman, 2006, p. 40. No. processo. de. desenvolvimento. incremental,. os. clientes identificam. as. funcionalidades a serem fornecidas pelo sistema, as classificam definindo quais são as mais importantes e devem ser desenvolvidas primeiro, assim os clientes não precisam detalhar todas as funcionalidades de uma única vez (Sommerville, 2004). 2.1.3. Evolucionários. Como os requisitos de negócio e produto não estão congelados no tempo, não esperando que o sistema esteja pronto para então “evoluir”, as metodologias evolucionárias surgiram com o intuito de “acomodar” tais mudanças (Pressman, 2006)..

(19) 18 2.1.3.1. Prototipagem. Quando os clientes tem dificuldade em definir os requisitos de negócio, ou o desenvolvedor está inseguro sobre como o sistema afetará as práticas de trabalho do cliente, um protótipo, que é uma versão inicial do sistema pode ser desenvolvido (Sommerville, 2004).. Os protótipos permitem que o desenvolvedor e o cliente encontrem a melhor maneira de se implementar requisitos de negócio complexos e validar se todos os requisitos de negócio estão contemplados nas funcionalidades.. Os protótipos podem ser de dois tipos:. . Evolucionários: o objetivo deste protótipo é fornecer um sistema funcional ao cliente;. . Descartáveis: apesar de muitas vezes fornecer um sistema funcional, o objetivo deste protótipo é validar requisitos complexos do sistema, sendo que os requisitos simples nem precisam ser prototipados e uma vez tendo cumprido seu papel ele deve ser substituído.. O protótipo evolucionário começa com um sistema simples, que implementas as funcionalidades básicas do sistema e evolui para a versão final do sistema (Sommerville, 2004)..

(20) 19 Na prototipação descartável, os desenvolvedores geralmente reusam componentes de outros aplicativos e deixam de pensar na performance, porém como os clientes tem uma versão funcional do sistema, eles relutam em descartá-lo e substituí-lo por outro (Pressman, 2006).. O processo de escolha por um dos dois tipos de prototipação pode ser visto abaixo na Figura 4.. Figura 4: Tipos de protótipo Fonte: Sommerville, 2004, p. 147. As fases da metodologia de prototipagem podem ser vistas abaixo na Figura 5:. Figura 5: O modelo de prototipagem Fonte: Sommerville, 2004, p. 146.

(21) 20 2.1.3.1. Espiral. A metodologia espiral combina prototipagem com cascata. As atividades se dão em um circuito em espiral, que se inicia pelo centro evoluindo para fora conforme cada evolução é feita, conforme Firgura 6 abaixo (Pressman, 2006).. Figura 6: O modelo espiral Fonte: Pressman, 2006, p. 45. A primeira volta na espiral pode resultar na especificação funcional do sistema, a segunda em um protótipo e as voltas subsequentes em versões executáveis uma mais sofisticada que a outra (Pressman, 2006).. A prototipagem pode ser utilizada em qualquer volta da espiral e é também utilizada como mecanismo de redução de risco, que é obrigatória nesta metodologia (Pressman, 2006)..

(22) 21 2.1.4. Conceitos comuns. As. metodologias. Cascata,. Incremental. e. Espiral. apresentam. as. fases. Comunicação, Planejamento, Modelagem, Construção e Implantação em comum, e por esse motivo são descritas uma única vez neste tópico.. 2.1.4.1. Comunicação. Segundo Pressman (2006) a fase de comunicação se caracteriza por entender o que o. cliente. deseja,. analisando. as. necessidades. de. negócio,. avaliando. a. exequibilidade, negociando condições razoáveis, especificando a solução de uma maneira que não seja ambigua, validando a especificação e a tranformando em um sistema, sendo realizado através de sete funções distintas:. 1. Concepção – a maioria dos projetos surge de uma necessidade de negócio e o objetivo é estabelecer um entendimento básico do problema, identificar os interessados no projeto, a natureza da solução desejada e a definição dos canais de comunicação e colaboração entre cliente e desenvolvedor;. 2. Levantamento – consiste na coleta dos requisitos de negócio de forma organizada, de forma a se evitar os seguintes problemas:. . Problemas de escopo – limite do sistema é mal definido;. . Problemas de entendimento – clientes tem dificuldade em explicar as necessidades de negócio ao engenheiro de sistemas, omitem informações, especificam requisitos de negócio conflitantes com as necessidades de outros clientes/usuários ou ambíguos e;.

(23) 22 . Problemas de volatilidade – os requisitos de negócio mudam com o decorrer do tempo.. 3. Elaboração – expansão e refinamento dos requisitos de negócio.. A. elaboração é guiada pela criação e refinamento de cenários do usuário que descrevem como o usuário final e outros atores vão interagir com o sistema. O produto da elaboração é um modelo de análise que define o domínio do sistema a ser desenvolvido de forma funcional e comportamental;. 4. Negociação – o desenvolvedor deve relacionar. os requisitos solicitados,. identificar os requisitos conflitantes entre os diferentes clientes solicitantes e reconciliar estes conflitos, o desenvolvedor deve negociar com os clientes em qual sequência os requisitos devem ser desenvolvidos.. Os riscos envolvidos no desenvolvimento de cada requisito e uma estimativa grosseira de esforço de desenvolvimento é feita para avaliar o impacto de cada requisito no custo do projeto e no prazo de entrega;. 5. Especificação – uma especificação pode ser um documento escrito, um modelo gráfico, um modelo matemático formal, uma coleção de cenários de caso de uso, um protótipo ou qualquer combinação destes elementos. Para sistemas grandes e complexos, um documento escrito combinado com descrições em linguagem natural e modelos gráficos pode ser o mais adequado, enquanto cenários de caso de uso, podem ser o suficiente para sistemas menores.. A especificação é o produto final produzido pelo desenvolvedor, servindo de fundamento para as atividades de desenvolvimento subsequentes. Ela descreve a função e o desempenho de um sistema baseado em computador e as restrições que guiarão seu desenvolvimento;.

(24) 23 6. Validação – a validação de requisitos examina a especificação para garantir que todos os requisitos de negócio tenham sido especificados de modo não ambíguo; que as inconsistências, omissões e erros tenham sido detectados e corrigidos e que os produtos gerados estejam de acordo com as normas definidas para o processo, o projeto e o produto;. 7. Gestão de requisitos – os requisitos de negócio mudam e o desejo de mudálos persiste ao longo da vida do sistema e a gestão de requisitos é o conjunto de atividades que ajudam a equipe do projeto a identificar, controlar e rastrear requisitos e suas modificações ao longo da vida do sistema.. 2.1.4.2. Planejamento. Segundo Pressman (2006) definido o objetivo e as metas gerais do projeto na fase de Comunicação, a fase de Planejamento inclui um conjunto de práticas gerenciais e técnicas que permitem à equipe de desenvolvimento definir um roteiro para que se atinjam as metas estratégicas e objetivos táticos. O planejamento não deve ser excessivo nem minimalista demais, devendo ser conduzido com moderação suficiente para fornecer um direcionamento útil à equipe de desenvolvimento. Os seguinte princípios abaixo sempre se aplicam:. 1. Entenda o escopo do projeto - se você não souber para onde está indo não poderá montar um roteiro. O escopo fornece à equipe de desenvolvimento um destino;. 2. Envolva o cliente na atividade de planejamento – o cliente é quem define as prioridades e oferece as restrições do projeto. O desenvolvedor deve negociar a ordem de entrega, prazos e outros tópicos relacionados ao projeto com o cliente;.

(25) 24 3. Reconheça que o planejamento é iterativo – um plano de projeto não está gravado em pedra. É muito provável que as coisas se modifiquem e como consequência, o plano deve ser ajustado para acomodar tais modificações;. 4. Estime com base no que é sabido – forneça uma indicação do esforço, do custo e da duração de tarefas com base no entendimento atual da equipe quanto ao trabalho a ser realizado;. 5. Considere riscos à medida que define o plano – planeje um plano de contingência para os risco do projeto. O plano do projeto e o cronograma devem ser ajustados para acomodar a probabilidade de um ou mais riscos virem a ocorrer;. 6. Seja realista – problemas de entendimento ocorrem, pessoas não trabalham 100% de cada dia, omissões e ambiguidades ocorrem, modificações ocorrem, desenvolvedores cometem erros. Estas e outras ocorrências devem ser consideradas no plano de projeto;. 7. Ajuste a granularidade à medida que você define o plano – o nível de detalhe do plano move-se do mais fino4 para o mais grosso5 acompanhando o andamento do projeto;. 8. Defina como você pretende garantir a qualidade – defina com a equipe como será feita a garantia da qualidade;. 9. Descreva como você pretende acomodar as modificações – a equipe deve definir como as modificações devem ser acomodadas à medida que o trabalho prossegue;. 4. Fornece detalhes significativos das tarefas de trabalho.. 5. Fornece detalhes mais amplos das tarefas de trabalho..

(26) 25. 10. Acompanhe o plano com frequência e faça ajustes quando necessário – acompanhe o progresso diariamente e ajuste o plano quando um desvio for identificado.. 2.1.4.2. Modelagem. Segundo Pressman (2006), modelos são criados para se obter um melhor entendimento daquilo que precisa ser construído. Quando pensamos em construir um edifício, por exemplo, podemos construir um modelo idêntico em forma e aspecto, mas em menor escala. No entanto, para software os modelos devem apresentar diferentes visões para os pontos de vista dos clientes e, depois visões mais técnicas para os desenvolvedores.. Para o desenvolvimento de sistemas, duas classes de modelo são criadas: modelos de análise e modelos de projeto.. . Modelos de análise – representam os requisitos de negócio do cliente, exibindo-os em três domínios diferentes: o domínio de informação, o domínio funcional e o domínio comportamental e;. . Modelos de projeto – representam as características do software, auxiliando os desenvolvedores em sua construção, exibindo-os nos seguintes domínios: arquitetura6, interface do usuário e detalhes em nível de componentes.. 6. Maneira pela qual componentes de dados e componentes procedimentais colaboram entre si..

(27) 26 2.1.4.2. Construção. Segundo Pressman (2006) a fase de construção engloba um conjunto de tarefas de codificação e teste que levam ao software operacional a ser entregue ao cliente.. A codificação pode ser: . A criação direta do código fonte em linguagem de programação;. . A. geração. automática. de. código-fonte. usando. uma. representação. intermediária do código a ser construído e; . A geração automática de código executável usando linguagem de quarta geração.. A tarefa de codificação envolve conceitos como estilo de programação, linguagem de programação e métodos de programação.. Segundo Pressman (2006) teste é um processo de execução de um programa com a finalidade de encontrar um erro, um bom caso de teste é o que tem alta probabilidade de encontrar um erro ainda não descoberto e um teste bem-sucedido é o que descobre erros que ainda não haviam sido identificados.. O objetivo da tarefa de testes é projetar testes que descubram diferentes classes de erros com uma quantidade mínima de esforço.. Testes que enfocam os requisitos de negócio7 devem ser realizados com base nos cenários identificados durante a fase de comunicação.. 7. Conhecido também como testes funcionais..

(28) 27 2.1.4.2. Implantação. A implantação engloba três ações: entrega, suporte e feedback, para as metodologias evolucionárias, em que a implantação ocorre a cada incremento do software as ações de entrega, suporte e feedback ocorrem tantas vezes quanto forem a quantidade de incrementos.. 2.1. METODOLOGIAS ÁGEIS. A metodologia ágil baseia-se na prática para modelagem e documentação eficaz de sistemas, ela não define processos detalhados sobre como criar um modelo em específico, fornecendo conselhos sobre como ser um modelador melhor (Ambler, 2004).. Existem diversas metodologias de desenvolvimento de sistemas que se baseiam no conceito de documentação e prática de modelagem eficazes, tais como: Extreme Programming (XP), DAS – Desenvolvimento Adaptativo de Software 8, MDDS – Método de Desenvolvimento Dinâmico de sistemas9, Scrum, Crystal, DGC – Desenvolvimento Guiado por características10 e MA - Modelagem Ágil11, porém o autor irá conceituar somente o Scrum e o XP por serem as metodologias cujas características são utilizadas como base para a criação da metodologia de desenvolvimento própria do Banco A.. 8. Adaptative Software Development – ASD.. 9. Dynamic systems Development Method – DSDM.. 10. Feature Driven Development – FDD.. 11. Agile Modeling – AM..

(29) 28 Segundo Ambler (AMBLER, 2004, p.34):. A MA não é um ataque à documentação. Os modeladores ágeis criam documentação que maximiza seu investimento na criação e manutenção. A documentação ágil é tão simples quanto possível, tão mínima quanto possível, tem um propósito distinto que está diretamente relacionado com o sistema em desenvolvimento e tem um público definido cujas necessidades são conhecidas.. 2.1.1. Extreme Programming (XP). A metodologia XP utiliza a abordagem orientada a objetos como forma preferencial de desenvolvimento e possui quatro fases: planejamento, projeto, codificação e teste, conforme podemos observar abaixo na Figura 7 (Pressman, 2006).. Figura 7: O extreme programming Fonte: Pressman, 2006, p. 64.

(30) 29 Descrevo abaixo sucintamente cada fase da metodologia XP:. . Planejamento: Nesta fase o cliente cria um conjunto de histórias que descrevem as funcionalidades e características requeridas pelo software a ser contruído, atribuindo-lhes prioridades, ou seja, quais histórias devem ser desenvolvidas primeiro, os membros da equipe XP avaliam cada história e lhe atribuem um custo – medido em semanas de desenvolvimento. que não. devem exceder a três semanas, caso a estimativa da história exceda esse limite, pede-se ao cliente que a divida em histórias menores para que elas possam ser desenvolvidas dentro do prazo máximo de três semanas. Novas histórias podem ser escritas a qualquer momento;. . Projeto: Seguindo rigorosamente o princípio KIS12, projetos simples são sempre preferíveis a representações de soluções mais complexas. O projeto XP também fornece diretrizes para que as histórias sejam implantadas apenas com as funcionalidades descritas, nada a mais e nada a menos. Caso um problema de projeto difícil seja encontrado como parte de uma história, o XP recomenda a criação imediata de um protótipo operacional, daquela parte do projeto. Com isso, melhora-se a estimativa da história que contém o problema, reduzindo-se o risco de implementação desta;. . Codificação: Uma vez finalizadas as histórias, é recomendado que se desenvolva uma série de testes unitários que exercitarão cada uma das histórias que devem ser desenvolvidas nesta fase, isso auxilia o desenvolvedor no momento da codificação a focar no que precisa ser implementado para que o código passe nos testes. O XP recomenda que duas pessoas trabalhem juntas em uma mesma estação de trabalho na criação do código correspondente a uma história, pois isso fornece um mecanismo de solução de problemas e de garantia da qualidade em tempo real;. 12. Keep it simple – mantenha a simplicidade..

(31) 30. . Teste: Nesta fase os testes unitários criados na fase de Codificação devem ser implementados de forma que possam ser automatizados. Os testes de aceitação do XP, são especificados pelos clientes com base nas histórias criadas por eles, focalizando as características e funcionalidades globais do sistema, visíveis e passíveis de revisão pelo cliente.. 2.1.2. SCRUM. O nome Scrum é derivado de uma atividade do jogo de Rugby, onde um grupo de jogadores se forma ao redor da bola e os companheiros de equipe trabalham juntos para mover a bola pelo campo (Pressman, 2006).. O processo de desenvolvimento do Scrum incorpora as seguintes atividades de arcabouço:. requisitos, análise, projeto, evolução e entrega. As tarefas de cada. atividade ocorrem dentro de um padrão de processo denominado Sprint.. O Scrum usa um conjunto de “padrões de processo de software” que se mostraram efetivos para projetos com prazos apertados, requisitos mutantes e criticalidade de negócio (Pressman, 2006).. Os padrões de processo são:. . Pendência. ou Product backlog – lista de requisitos, estórias ou. características de negócio definidas e priorizadas pelo cliente (Kniberg, 2007);.

(32) 31 . Sprints – unidades de trabalho necessárias para satisfazer a um item da pendência que precisa ser cumprido em um intervalo de tempo pré-definido de tempo, normalmente 30 dias. Durante o Sprint, o item da pendência em questão não pode ser alterado, ou seja, ele fica temporariamente congelado (Pressman, 2006). Uma das principais atividades do Sprint é definir quais itens do Product backlog devem ser incluídas no Sprint backlog, que nada mais são que a lista de estórias a serem desenvolvidas no Sprint (Kniberg, 2007), a figura 8 abaixo exibe de forma gráfica a escolha dos itens a serem desenvolidas no Sprint, onde cada retângulo, representa uma estória e seu tamanho o esforço necessário para o desenvolvimento dela;. Figura 8: Seleção de estórias para o Sprint Fonte: Kniberg, 2007, p. 22. . Reuniões Scrum – segundo Pressman (2006), reuniões de Scrum são reuniões de curta duração, normalmente 15 minutos, feitas diariamente pela equipe. Onde três questões padrões devem ser respondidas por todos os integrantes da equipe. Sendo elas:. . O que você fez desde a última reunião de equipe?. . Quais obstáculos você está encontrando?.

(33) 32 . O que você planeja fazer até a próxima reunião de equipe?. As equipes Scrum tem um líder, que é chamado de Scrum master, o qual tem as seguintes responsabilidades: liderar as reuniões e avaliar as respostas de cada pessoa.. As reuniões Scrum são úteis para descobrir potenciais problemas, disseminar conhecimento e promover sinergia na equipe .. . Demos – são entregas de incrementos de software ao cliente, onde as funcionalidades implementadas possam ser demonstradas e testadas pelo cliente. Apenas as funcionalidades finalizadas no intervalo da Sprint são entregues nas Demos (Pressman, 2006).. A Figura 9 abaixo exibe o fluxo de processo Scrum:. Figura 9: O fluxo de processo SCRUM Fonte: Pressman, 2006, p. 70.

(34) 33 3. CONCEITOS E PRODUTOS. Este capítulo descreve os principais conceitos e produtos gerados para cada uma das fases das metodologias de desenvolvimento e que ao final se tornarão a documentação do projeto.. 3.1. SISTEMAS DE BANCOS DE DADOS. Podemos dizer que dados são informações sobre um determinado empreendimento que necessitam ser armazenadas, acessadas e alteradas de forma conveniente, eficiente e segura, o conjunto destas informações é normalmente chamado de banco de dados, um sistema de banco de dados provê o ambiente necessário para isso (Kortth e Silberschatz, 1994).. Um sistema gerenciador de banco de dados é composto de programas e uma coleção de arquivos inter-relacionados que permitem aos usuários fazer uso dessas informações, e é projetado para trabalhar com um grande quantidade de informações. Ele fornece uma visão abstrata da informação, ou seja, o usuário não precisa saber detalhes de como os dados são armazenados e mantidos (Korth e Silberschatz, 1994).. 3.1.1. Modelos de dados. São. ferramentas. conceituais. fundamentais. para. descrição. de. dados,. relacionamentos de dados, semântica de dados e restrições de consistência. Existem vários modelos de dados propostos, sendo que eles se dividem em três.

(35) 34 diferentes grupos: modelos lógicos baseados em objetos, modelos lógicos baseados em registros e modelos de dados físicos (Korth e Silberschatz, 1994).. Neste trabalho examinaremos apenas o modelo entidade-relacionamento, do grupo modelo lógico baseado em objetos, que é o utilizado pelo banco A.. 3.1.1.1. O modelo entidade-relacionamento. Este modelo consiste em uma coleção de objetos básicos chamados de entidades, e em relacionamentos entre estes objetos; cujas entidades são baseadas em percepções do mundo real (Kother e Silberschatz, 1994).. Uma entidade por sua vez é distinguível de outra por seus atributos, por exemplo, os atributos número da conta corrente e saldo da conta corrente descrevem uma conta corrente em particular. Um relacionamento descreve uma associação entre duas ou mais entidades, por exemplo, o relacionamento entre cliente e conta corrente pode se chamar ClienteConta, onde este associa o cliente a sua, ou suas contas correntes.. A estrutura lógica geral de um banco de dados do modelo entidade-relacionamento pode ser representada graficamente, onde:. . Retângulos representam conjuntos-entidades;. . Elipses representam atributos;. . Losangos representam relacionamentos entre conjuntos-entidade e;. . Linhas ligam atributos a conjuntos-entidade e conjuntos-entidade a relacionamentos..

(36) 35 A Figura 10 abaixo ilustra um modelo entidade-relacionamento, consistindo em clientes e contas que eles possuem.. Figura 10: Modelo de diagrama entidade-relacionamento Fonte: Korth e Silberschatz, 1994, p. 8. 3.2. ORIENTAÇÃO A OBJETOS. A Orientação a Objetos engloba diversos conceitos, tais como: Classificação, Abstração, Instanciação, Classes de Objetos, Atributos ou Propriedades, Métodos ou Comportamentos, Visibilidade, Herança , Herança Múltipla e Polimorfismo, porém este trabalho conceituará apenas as Classes de Objetos, os Atributos ou Propriedades e os Métodos ou Comportamentos, havendo interesse nos demais conceitos, o leitor deve buscar maiores detalhes em outras fontes, por exemplo, consultando as obras utilizadas neste trabalho.. Segundo Guedes (2004) ao conceituarmos pessoa, carro e casa, por exemplo, estamos definindo classes, ou seja, grupo de objetos, sendo que cada objeto é um exemplo de um determinado grupo, possuindo as mesmas características e comportamentos de qualquer outro objeto de um mesmo grupo..

(37) 36 3.2.1. Classes de objetos. Uma classe representa uma categoria e os objetos os membros ou exemplos desta categoria.. A classe é representada por um retângulo que pode possuir até 3 divisões, onde:. . A primeira divisão armazena o nome da classe;. . A segunda divisão armazena a relação dos possíveis atributos da classe e;. . A terceira divisão armazena a relação dos possíveis métodos da classe.. A representação mínima para uma classe é um retângulo com o nome desta classe, a Figura 11 abaixo exibe um deste tipo de representação.. Figura 11: Exemplo de representação mínima de uma classe Fonte: Guedes, 2004, p. 39. 3.2.2. Atributos ou Propriedades de uma Classe. As classes possuem atributos ou propriedades. Os atributos representam as características de uma classe, para a classe Carro, por exemplo, o atributo cor.

(38) 37 permite diferenciar um objeto de outro da mesma classe devido a variação de valor de seu atributo cor.. Todas as instâncias13 de uma mesma classe possuem exatamente os mesmos atributos, porém estes atributos podem assumir valores diferentes para diferentes objetos desta classe, a Figura 12 abaixo exibe um exemplo de classe com os atributos Cor e Número de Portas para a classe Carro.. Figura 12: Exemplo de classe com atributos Fonte: Guedes, 2004, p. 39. 3.2.3. Métodos ou Comportamentos de uma Classe. Um método representa uma atividade que um objeto de uma classe pode executar. O método pode receber parâmetros14 e retornar valores, que representam o resultado da operação executada ou apenas indicar que o processo foi concluído com sucesso ou não. A Figura 13 abaixo exibe um exemplo de classe com o comportamento Transportar Pessoas para a classe Carro.. 13. Objetos com as características de uma classe.. 14. Valores que são utilizados durante a execução do método..

(39) 38. Figura 13: Exemplo de uma classe com três divisões Fonte: Guedes, 2004, p. 40. 3.3. UML – UNIFIED MODEL LANGUAGE. A UML é uma linguagem de modelagem visual que surgiu da necessidade de se ter uma notação padronizada e eficaz para o desenvolvimento de aplicações, que não tem como objetivo substituir as definições textuais e suas características, mas fornecer uma estrutura gráfica para a organização da construção e análise de projetos, para então definir as construções por meio de textos apropriados (Wada, 2005).. A UML possui diversos diagramas, onde cada diagrama fornece uma visão sobre um determinado aspecto do sistema a ser modelado, fornecendo dessa forma multiplas visões sobre esse sistema, permitindo que cada diagrama complemente os outros (Guedes, 2004).. Segundo Wada (2005) a UML permite modelar dois tipos diferentes de diagramas: estáticos e dinâmicos..

(40) 39 3.3.1. Modelos estáticos. Os modelos estáticos modelam as propriedades internas dos objetos e as relações entre elas (Wada, 2005).. Os modelos ditos estáticos são: Diagrama de caso de uso, Diagrama de classes, Diagrama de objetos, Diagrama de componentes, Diagrama de pacotes, Diagrama de distribuição e Diagrama de composição estrutural.. Neste trabalho são apresentados o Diagrama de caso de uso, o Diagrama de classes e o Diagrama de objetos, pois são os diagramas utilizados pela metodologia de desenvolvimento do Banco A.. . Diagrama de caso de uso – este diagrama apresenta as funcionalidades de negócio mapeadas através dos requisitos de negócio definidos pelo cliente (Wada, 2005).. Por ser o diagrama mais geral e informal da UML, apresentando uma linguagem simples e de fácil compreensão por parte dos usuários, ele é normalmente utilizado nas fases de Levantamento e Análise de Requisitos do Sistema (Guedes, 2004).. O diagrama de caso de uso fornece uma visão geral do comportamento do sistema, seus usuários, outros sistemas ou até mesmo algum equipamento especial, bem como as ações que o sistema disponibilizará aos atores, conforme podemos observar na Figura 14 abaixo..

(41) 40. Figura 14: Exemplo de diagrama de caso de uso Fonte: Pressman, 2006, p. 157. Segundo Wada (2005) Os diagramas de caso de uso devem ter suas respectivas descrições de casos de uso, que são descrições dos passos necessários para a realização de uma determinada funcionalidade, e devem ser definidas visando o que o sistema faz e não como ele faz. Não há uma regra na UML que diga o quanto devemos detalhar os casos de uso, neste caso é prudente detalhar os requisitos de domínio do cliente. Abaixo é apresentada uma sugestão para a espeficação de casos de uso:. 1. Nome – nome do caso de uso; 2. Finalidade ou objetivo – descrição da finalidade ou objetivo do caso de uso; 3. Atores – lista de atores identificados que interagem com o caso de uso em questão; 4. Pré-condições – descritivo que informa as condições preliminares para que o caso de uso possa ser executado; 5. Evento inicial – descrição do primeiro passo para que o caso de uso possa ser iniciado; 6. Fluxo principal – descrição dos passos para que um caso de uso seja executado com sucesso;.

(42) 41 7. Fluxo alternativo – descrição que indica situações que representem um caminnho diferente de um dos passos do fluxo principal, ou seja, que altere o comportamento do caso de uso; 8. Fluxo de exceção – descrição de situações que representem uma exceção ao fluxo principal, ou seja, uma interferência que não permita a finalização com sucesso do caso de uso; 9. Pós-condições – descrição que informa o que pode ocorrer após a execução com sucesso do caso de uso; 10. Casos de teste – descrição de todas as situações que podem ocorrer dentro do caso de uso.. Diagrama de classes – segundo Guedes (2004) o diagrama de classes representa a estrutura lógica, as características e ações de cada objeto, além de estabelecer como as classes se relacionam e trocam informações, a Figura 15 abaixo mostra um exemplo de diagrama de classe..

(43) 42. Figura 15: Exemplo de diagrama de classes Fonte: Pressman, 2006, p. 170. Diagrama de objetos – o diagrama de objetos é praticamente um complemento do diagrama de classes, pois o diagrama de objetos fornece uma visão dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento da execução de um processo de software (Guedes, 2004). A Figura 16 abaixo exibe um exemplo do diagrama de objetos..

(44) 43. Figura 16: Exemplo de diagrama de objetos Fonte: Guedes, 2004, p. 28. 3.3.2. Modelos dinâmicos. Segundo Wada (2005) os modelos dinâmicos representam o comportamento do sistema e podem ser modelados de duas formas diferentes:. 1.. Representando o histórico de vida de um objeto e como este interage com os demais objetos e;. 2.. Verificando os padrões de comunicação entre os objetos que estão conectados e a forma como eles interagem entre si.. Os modelos ditos dinâmicos são: Diagrama de sequência, Diagrama de colaboração, Diagrama de estados, Diagrama de implantação, Diagrama de atividades e Diagrama de tempo..

(45) 44 Neste trabalho são apresentados o Diagrama de sequência, o Diagrama de estados, o Diagrama de atividades e o Diagrama de implantação, pois são os diagramas utilizados pela metodologia de desenvolvimento própria do Banco A.. Diagrama de sequência – este diagrama exibe a sequência das ações que ocorrem entre os componentes em função do tempo e as mensagens que são trocadas entre os objetos envolvidos durante um determinado processo. Ele se baseia nos diagramas de caso de uso, nos diagramas de classes e nos diagramas de objetos, identificando também os atores responsáveis por esta ação e os métodos disparados pelas mensagens enviadas entre os objetos, na Figura 17 abaixo temos um exemplo do diagrama de sequência.. Figura 17: Exemplo de diagrama de sequência Fonte: Pressman, 2006, p. 180. Diagrama de estados – segundo Guedes (2004) o diagrama de estados representa os possíveis estados de um objeto em função do tempo. O estado representa a situação em que um objeto se encontra em um determinado momento durante a participação dele em um processo, podendo passar por diversos estados durante um mesmo processo, podendo demonstrar:.

(46) 45. . A espera pela ocorrência de um evento;. . A reação a um estímulo;. . A execução de alguma atividade e;. . A satisfação de alguma condição.. A Figura 18 abaixo exibe um exemplo de diagrama de estados:. Figura 18: Exemplo de diagrama de estados Fonte: Guedes, 2004, p. 30. Diagrama de atividades – segundo Guedes (2004) o diagrama de atividades descreve os passos a serem percorridos para a conclusão da ação de um método ou algorítimo específico e não de um processo por completo como é o caso dos Diagramas de sequência, ou seja, concentra-se na representação do fluxo de controle de uma atividade, conforme podemos observar na Figura 19 abaixo..

(47) 46. Figura 19: Exemplo de diagrama de atividades Fonte: Guedes, 2004, p. 155. Diagrama de implantação – o diagrama de implantação representa a questão da organização da estrutura física sobre a qual o software será implantado e executado em termos de hardware , ou seja, as máquinas15 que suportarão o sistema, definindo também como estas máquinas estarão conectadas e através de quais protocolos se comunicarão, transmitindo informações (Guedes, 2004). A Figura 20 abaixo exibe um exemplo de Diagrama de implantação.. 15. Computadores pessoais, servidores, etc..

(48) 47. Figura 20: Exemplo de diagrama de implantação Fonte: Guedes, 2004, p. 178. 3.4. FÁBRICA DE SOFTWARE. O presente trabalho apresenta apenas uma breve descrição sobre o que é uma fábrica de software e a conceituação do modelo de Fábrica de programas, pois é o modelo utilizado pelo estudo de caso em questão.. Segundo Fernandes e Teixeira (2009) a expressão Fábrica de Software surgiu em meados da década de 80, sendo que no Brasil, o conceito começou a ser aplicado no início da década de 90 em empresas de prestação de serviços em tecnologia da informação, intensificando-se desde então.. Muitas empresas de prestação de serviços têm sua fábrica, e há casos em que a fábrica é estruturada internamente em empresas cuja finalidade final não é o desenvolvimento de software..

(49) 48 A intenção da Fábrica de Software é criar uma manufatura de software nos mesmos moldes de uma linha de montagem de automóveis.. O objetivo da fábrica é a geração dos produtos requeridos por seus clientes, com o mínimo de defeitos possível e a um preço competitivo.. A fábrica pode ter vários escopos de atuação, podendo ser classificadas em quatro tipos: Fábrica de Projetos, Fábrica de Projetos de Software, Fábrica de Projetos Físicos e Fábrica de Programas, conforme Figura 21 abaixo, dependendo das fases de desenvolvimento de software que são contempladas pela fábrica. A complexidade da gestão da fábrica é maior quanto maior for o escopo de sua atuação.. Figura 21: Escopo de fornecimento da fábrica de software Fonte: Fernandes e Teixeira, 2009, p. 118.

(50) 49 3.4.1. Fábrica de programas. Segundo Fernandes e Teixeira (2009) o objetivo da fábrica de programas é codificar e testar programas, o cliente16 envia para a fábrica uma ordem de serviço, bem como uma estimativa para conclusão do serviço baseado em tabelas padrões 17, ou seja, o cliente já sabe quanto tempo vai ser despendido para receber os programas codificados.. Geralmente, acordos de nível de serviço definem as tabelas padrões de tempo de atendimento, padrão de programas, critérios de qualidade e padrões para aceitação da especificação recebida.. Para que a fábrica de programas consiga ter consistência no atendimento às ordens de serviço, ser lucrativa ou ter uma operação de baixo custo, é preciso que alguns fatores-chave sejam entendidos, tais como: demanda, ordens de serviço, regras de comunicação e de interfaces com o cliente, estimativas, novos serviços e novas linhas, acordos de níveis de serviços, métricas, flexibilidade, suprimento de recursos humanos, controle da produtividade, uso de padrões internos, questão dos riscos e da segurança, certificações da qualidade, compartilhamento de recursos, busca por locais de baixo custo, automação da fábrica de software, alternativa de estrutura organizacional e organização da produção.. Este trabalho aborda apenas os seguintes itens: demanda, ordens de serviço, regras de comunicação e de interfaces com o cliente, estimativas, acordos de níveis de serviços e questão dos riscos. 16. Neste caso, o cliente é o desenvolvedor solicitante.. 17. Baseadas em experiência do próprio pessoal ou comparação com outras fábricas.

(51) 50 . Demanda – o volume da demanda deve ser negociada com os clientes externos ou internos, devendo haver uma demanda mínima mensal para que a operação não apresente prejuízo;. . Ordens de serviço – a fábrica de programas deve possuir seu próprio padrão de ordens de serviço e especificação de programas18, para que não haja necessidade de ajustes internos nos processos da fábrica, caso uma ordem de serviço fora do padrão seja aceita;. . Regras de comunicação e de interfaces com o cliente – deve haver apenas um ponto de contato entre o cliente e a fábrica.. . O contato do lado do cliente é responsável por organizar a demanda, enviá-la à fábrica, gerenciar os níveis de serviço, as questões contratuais e demais negociações do dia-a-dia e;. . O contato do lado da fábrica é responsável por receber as ordens de serviço e pela expedição do produto ao contato do lado do cliente.. . Estimativas – a fábrica deve ter tabelas padrões de estimativas de tempo de atendimento de uma ordem de serviço; devem haver tabelas específicas para cada tipo de linguagem de programação, e o cliente deve usar estas tabelas de estimativa quando enviar suas ordens de serviço para a Fábrica de Programas;. . Acordos de níveis de serviços – os acordos de níveis de serviço balizam o desempenho e o faturamento da Fábrica de Programas, sendo os seus principais tipos:. 18. Cada tipo de linguagem deve ter seu tipo de especificação de programas..

(52) 51 . Atendimento aos tempos padrões das ordens de serviço;. . Atendimento no prazo prometido para entrega da ordem de serviço;. . Percentual de ordens de serviço que retornaram por problemas de qualidade e;. . . Ordens de serviço recebidas pela fábrica fora do padrão.. Questão dos Riscos e da Segurança – a fábrica deve zelar pelas especificações de seus clientes evitando o acesso indevido a eles por terceiros ou empresas concorrentes..

(53) 52. 4. METODOLOGIA DE DESENVOLVIMENTO PRÓPRIA DO BANCO A. A metodologia de desenvolvimento própria do Banco A incorpora atividades e fases extraídas das metodologias modelo apresentadas no capítulo 2 deste trabalho, além dos produtos descritos no capítulo 3.. O autor deste trabalho é funcionário da instituição financeira utilizada neste estudo de caso e obteve as informações em manuais e intranet corporativa, sendo que o autor utiliza esta metodologia em seu dia a dia de trabalho.. A metodologia de desenvolvimento própria do Banco A une técnicas das metodologias prescritiva e ágil.. Cabe ressaltar que o escopo deste trabalho se limita a projetos de sistemas novos e com o uso da industrialização19, não tratando manutenção evolutiva e correções de sistema.. Ressalto também que este é apenas um estudo de caso bem específico e que existem outras formas de se trabalhar com a metodologia de desenvolvimento própria do Banco A, onde por exemplo, há uma maior utilização da metodologia ágil Scrum e a utilização de outros tipos de fábrica de software e não só o da fábrica de programas.. A metodologia de desenvolvimento própria do Banco A utilizado neste estudo de caso mistura elementos das metodologias Prescritivas e Ágeis, sendo que o primeiro. 19. Projetos desenvolvidos com fábrica de software..

(54) 53 destes elementos é da metodologia Ágil, que é a tentativa de se trazer o cliente para mais perto do processo de desenvolvimento, fazendo com que ele se torne parte mais ativa de todo o processo, aumentando seu nível de comprometimento com a entrega, reduzindo também o risco de entregarmos algo que ele não pediu, pois conforme declara Ambler (2004):. [...] nossos clientes não entendem como o software é desenvolvido [...] Além disso, nossos clientes geralmente não estão interessados em participar de processos complexos que não entendem bem e, nestas situações, preferem deixar os detalhes para nós, de forma que eles possam voltar às suas ocupações. Aceitam que seu envolvimento seja limitado aos requerimentos no início do projeto, [...], envolvendo-se em testes de aceitação um pouco antes da entrega e finalmente recebendo o sistema, muitas vezes atrasado e acima do orçamento. [...] O que eles estão pedindo é um software que supra suas necessidades de forma eficaz [...]. [...] Em outras palavras, a prática habitual é entregar o que queremos entregar, não o que os clientes estão pedindo. [...] é possível (e necessário) que os clientes estejam ativamente envolvidos; apenas temos que assegurar que o processo de desenvolvimento seja aceitável para eles.. Neste estudo de caso, o projeto a ser desenvolvido possui uma clara definição de escopo, requisitos, custo e prazo, por estes motivos o caminho a se trilhar puxa para uma metodologia do tipo prescritiva incremental, conforme Pressman (2004), onde os requisitos de negócio mais críticos devem ser desenvolvidos primeiro, a Figura 22 abaixo exibe as fases desta metodologia do tipo prescritiva incremental do Banco A.. Figura 22: Metodologia do Tipo Prescritiva Incremental do Banco A Fonte: Banco A, 2010.

(55) 54 Um questionário em planilha eletrônica é utilizado para definição dos processos, documentos a serem gerados e atividades necessárias, pois, por exemplo, se o projeto de um sistema não possuir interface com o usuário, ou seja, em que o usuário não precise interagir com o sistema, não há a necessidade de se gerar documentação sobre interfaces com o usuários20; conseguindo dessa forma flexibilizar os entregáveis21 desta metodologia puxada para o tipo prescritiva incremental, sem que com isso a desfiguremos.. 4.1. FASES DA METODOLOGIA DO TIPO PRESCRITIVA INCREMENTAL DO BANCO A. Conforme podemos notar as fases desta metodologia seguem os mesmos passos e possuem os mesmos entregáveis descritos no capítulo 2, item 2.1.4. Conceitos comuns; a diferença está entre os incrementos de software, onde podemos notar a possibilidade clara de utilização de partes das metodologias ágeis XP e SCRUM.. 4.1.1. Escopo e estimativa. Durante a fase de escopo e estimativa, a demanda é analisada de forma rápida e em profundidade o suficiente para se elaborar uma declaração de demanda, envolver outras áreas e sistemas impactados, gerando-se uma estimativa de esforço para o projeto (BANCO A).. Ao final do processo um documento formalizando a demanda com o seguinte conteúdo é gerado:. 20. Telas e relatórios.. 21. Produtos..

(56) 55. . Escopo – Itens farão parte da solução a ser desenvolvida;. . Requisitos – lista de necessidades de negócio a serem atendidas pelo projeto;. . Regras de Negócio – regras de negócio a serem seguidas pela solução;. . Volumetria – quantidade atual e esperada de informações geradas e períodos de pico;. . Premissas – relação de Coisas que se presume como verdadeiras;. . Riscos – relação de Coisas que podem impactar o projeto de forma positiva ou negativa;. . Stakeholders – relação de todos os impactados pelo projeto de forma positiva ou negativa;. . Sistemas impactados – relação de sistemas que serão impactados pelo projeto;. . Itens fora do escopo – relação de itens que não farão parte da solução a ser desenvolvida;. . Análise de viabilidade – análise de viabilidade técnica e financeira sobre o desenvolvimento ou não da solução;. . Prazo – prazo desejado para entrega do projeto e;. . Custo – custo estimado para o projeto.. A existência do projeto é formalizada e é dado ao gerente permissão e autoridade para seguir adiante, caso a estimativa de esforço seja aprovada pela área solicitante..

(57) 56 4.1.2. Análise. Durante a fase de análise, os requisitos são definidos em detalhe 22, conforme Wada (2005), a infra-estrutura23. e a documentação necessária24, conforme Pressman. (2006) são definidas, desenvolvidas e refinadas.. Caso hajam outros sistemas impactados, os mesmos devem, também, refinar os requisitos, a infra-estrutura e a documentação necessárias se for o caso, fornecendo uma estimativa de esforço para atender a demanda deste projeto (BANCO A).. Os documentos gerados durante esta fase devem ser validados e aprovados pelos solicitantes, mesmo os gerados por outros sistemas impactados se for o caso (BANCO A).. Com a aprovação dos documentos, a estimativa de esforço é revisada, somando-se o esforço dos demais sistemas impactados se for o caso, pois agora com um maior nível de detalhes é possível dar uma estimativa de esforço mais precisa; que deve ser novamente aprovada pelos solicitantes (BANCO A).. 22. Casos de uso e suas descrições.. 23. Hardware – servidor de alta e/ou baixa plataforma, espaço em disco, rede, etc, e Software –. sistema operacional, sistema de banco de dados, linguagem de programação, etc. 24. Protótipos, diagramas de atividades, classes e sequência..

(58) 57 4.1.3. Desenho Físico. Nesta fase é realizada a modelagem de dados, onde todos os objetos de dados processados pelo sistema e os relacionamentos entre estes é modelado. Criando-se o MER25 utilizando como base os requisitos de negócio, conforme Kother e Silberchatz (1993).. Com base no MER, é gerado então o banco de dados para o projeto, conforme Kother e Silberchatz (1993).. Protótipos descartáveis, casos de testes funcionais, diagramas de sequência e diagramas de estados são desenvolvidos e refinados; há casos em que os diagramas de estados não precisam ser desenvolvidos, caso seus objetos não apresentem muitos estados que precisem ser demonstrados, conforme Pressman (2006), Wada (2005) e Banco A (2010).. Durante a fase de desenho físico, a solução técnica sobre como a solução será desenvolvida é definida e detalhada, este produto é conhecido como diagrama de implantações, conforme Wada (2005).. A documentação gerada nesta fase é submetida a uma verificação por uma equipe interna da fábrica de software do Banco A.. 25. Modelo Entidade Relacionamento..

(59) 58 4.1.4. Construção. Durante a fase de construção, a solução é construída conforme definido nas fases anteriores e testada de modo unitário e integrado, conforme Pressman (2006).. A construção, testes unitários e integrados e diagramas de classes são desenvolvidos pela fábrica de software26, que pode ser uma equipe interna de desenvolvedores do Banco A ou uma empresa terceira contratada; onde a escolha por uma ou outra é definida em função da equipe interna ter ou não capacidade para atender a demanda exigida pelo projeto.. A construção só se inicia, caso a equipe interna da fábrica de software do Banco A tenha aprovado as documentações geradas nas fases anteriores.. 4.1.5. Testes. A fase de testes só se inicia após a entrega da codificação 27, dos diagramas de classes, das evidências de que os testes unitários e integrados foram realizados com sucesso, ou seja, os prints28 do resultados dos testes. Todos estes produtos são validados pela equipe interna da fábrica de software do Banco A.. Aprovados pela equipe interna de da fábrica de software do Banco A, a solução é testada funcionalmente, conforme Pressman (2006), pela equipe de analistas que a 26. Apesar do nome fábrica de software, o serviço utilizado neste estudo de caso é do tipo fábrica de. programas. 27. Construção.. 28. Imagem congelada do que aparece na tela em um dado momento..

(60) 59 solicitaram, e caso erros sejam encontrados, estes são encaminhados à fábrica de software que o desenvolveu, sendo que o prazo de garantia para reparo de erros é de 90 dias corridos a partir da aprovação pela equipe interna da fábrica de software, conforme Banco A.. Uma opção chamada de “Operação de Assistência”29, permite que mudanças no escopo do projeto sejam realizadas. Ao se escolher esta opção a solução perde a garantia de 90 dias corridos, uma vez que o código fonte é alterado.. A “Operação de Assitência” se assemelha muito às metodologias ágeis XP e SCRUM, conforme Pressman, pois requer que os desenvolvedores trabalhem junto ao analista solicitante, de preferência em uma máquina ao lado deste, e uma nova versão de software seja entregue em sprints de até 15 dias; porém ele não exige que um representante da área de negócio trabalhe de forma integral no projeto durante esta fase, conforme Banco A.. A “Operação de Assistência” é opcional e quando contratada, ocorre entre os incrementos de software, ou seja, se alterações no escopo do projeto que impactem incrementos já entregues, estas podem ser desenvolvidas e entregues durante esta fase.. Após a realização dos testes funcionais, conforme Pressman (2006), por parte dos analistas solicitantes, a solução é então disponibilizada aos clientes 30, que realizarão a homologação da solução, utilizando como guia os testes funcionais.. 29. Nome fictício dado pelo autor deste trabalho para não ficar por demais evidente o nome da. instituição. 30. Representantes da área de negócio..

(61) 60 4.1.6. Implantação. Caso a solução seja aprovada pelos clientes após a homologação, estes devem autorizar sua implantação em ambiente de produção, esta aprovação é formal e deve ser feita através de uma aplicação desenvolvida pelo Banco A que tem esta como uma de suas funcionalidades, sem esta formalização a solução não pode ser implantada.. O Banco A definiu um calendário com intervalos de datas em que intervenções no ambiente produtivo podem ser realizadas, esta medida visa reduzir o impacto de que uma implantação mal sucedida gere indisponibilidade ou lentidão nos aplicativos de seus clientes (Banco A).. O analista solicitante combina com o cliente a melhor data para implantação da solução no ambiente de produção, respeitando as datas boas para alterações no ambiente produtivo, conforme calendário citado, e um período de acompanhamento pós-implantação.. Combinada a data de implantação, o analista solicitante:. . Envolve outras áreas, caso haja necessidade, tais como a área de produção31, de banco de dados32 e de outros sistemas que possam vir a ser impactados pela mudança;. . Cria um roteiro de retorno33 da implantação, para o caso da implantação apresentar alguma divergência em relação ao que foi definido e seja preciso voltar ao estado inicial, anterior ao da implantação e;. 31. Equipe responsável pelos servidores.. 32. Equipe responsável pelos softwares gerenciadores de bancos de dados..