1

VIRGLIO SOLANO SILVA MAGALHES

APLICAO DOS MODELOS DE PROCESSO CASCATA, XP e PU NO DESENVOLVIMENTO DE SISTEMAS WEB: ESTUDO DE CASO

PATOS DE MINAS 2011

VIRGLIO SOLANO SILVA MAGALHES

APLICAO DOS MODELOS DE PROCESSO CASCATA, XP e PU NO DESENVOLVIMENTO DE SISTEMAS WEB: ESTUDO DE CASO

Trabalho de Concluso de Curso apresentado como exigncia parcial para obteno do ttulo de graduado em Sistemas de Informao pelo Centro Universitrio de Patos de Minas, sob orientao do Professor Me. Fernando Corra de Mello Jnior.

PATOS DE MINAS 2011

Dedico este trabalho a descendncia qual fao parte, a todos os seres que iluminam meu caminho, aos que buscam aprender mais a cada dia e a humildade presente no corao de todas as pessoas presentes neste mundo.

AGRADECIMENTOS

Sou grato a todos os seres e mestres que mostram a cada dia o caminho a seguir.

A verdadeira educao comea pela ao de nossos atos. Silencie e conhea-te. Voc . (Virglio Solano)

RESUMO
Este trabalho consistiu na anlise dos processos de desenvolvimento de sistemas Cascata, XP e PU com a finalidade de mensurar a qualidade do produto gerado na utilizao de cada processo, avaliando os mtodos utilizados por cada um destes, o tempo de desenvolvimento, o impacto das mudanas durante o ciclo de vida, a participao do cliente como um rpido retorno das atividades desenvolvidas, a complexidade de gesto envolvida em cada processo e mensurar o nvel de documentao necessria para o desenvolvimento de um sistema. A fase de desenvolvimento do projeto foi baseada nas aplicaes de Engenharia de Software utilizando os mtodos definidos por cada processo realizando a obteno e especificao de requisitos atravs da UML, baseado nos padres IEEE, tendo como produto gerado o documento de especificao de requisitos de cada sistema, composto pelos casos de uso e cartes de histrias como prope o XP. Para o desenvolvimento dos sistemas foram utilizadas as linguagens de programao PHP, Java, Ajax e JavaScript apoiadas por um conjunto de frameworks que permitiram agilizar o processo de programao, concentrando na lgica de negcio da aplicao. Foi realizada a utilizao de padro de projeto como MVC, adotando a programao orientada a objetos e utilizando frameworks Objeto Relacional entre a aplicao e o banco de dados. O resultado deste trabalho um documento que permite aos estudantes da rea de TI obter uma referncia sobre qual processo de desenvolvimento utilizar no desenvolvimento do seu TCC, bem como servir de referncia para profissionais da mesma rea, que no dia a dia se perdem na maneira de gerir o desenvolvimento dos seus projetos.

PALAVRAS-CHAVE: Engenharia de Software. Cascata. XP. PU. Processos. Metodologia.

LISTA DE FIGURAS

Figura 1- Componentes ou funes de um sistema .................................................................. 19 Figura 2 - Engenharia de Software em Camadas ..................................................................... 22 Figura 3 - Ciclo de vida de software ........................................................................................ 23 Figura 4 - O custo das modificaes aumentam exponencialmente ao longo do tempo .......... 26 Figura 5 - O modelo em Cascata .............................................................................................. 27 Figura 6 - O modelo incremental .............................................................................................. 28 Figura 7 - Fases do desenvolvimento XP ................................................................................. 31 Figura 8 - Fases e disciplinas do PU ........................................................................................ 33 Figura 9 - Leitores de diferentes tipos de especificao ........................................................... 37 Figura 10 - Tipos de requisitos no funcionais......................................................................... 39 Figura 11 - Processo de engenharia de requisitos .................................................................... 41 Figura 12 - Modelo em espiral dos processos de engenharia de requisitos .............................. 42 Figura 13 - Gerenciamento de qualidade e processo de software ............................................ 43 Figura 14 - Qualidade baseada em processo ............................................................................ 44 Figura 15 - reas de Processo na Representao Contnua e na Representao por Estgios. 46 Figura 16 - Representao dos nveis de maturidade do modelo MR-MPS em relao ao CMMI ....................................................................................................................................... 50 Figura 17 - Ciclo de vida do projeto ......................................................................................... 53 Figura 18 - Tringulo de ferro, com as principais variveis de um projeto. ............................ 54 Figura 19 Perfil de utilizao de recursos e tempo durante as fases do projeto .................... 55 Figura 20 - classificao dos diagramas da UML .................................................................... 57 Figura 21 Vises do sistema .................................................................................................. 58 Figura 22 Caso de Uso que modela o contexto do sistema do Website Ayurvida ................ 63 Figura 23 Caso de Uso MANTER Postagens ........................................................................ 66 Figura 24 Relacionamento das Entidades Postagem e Categoria presentes no DER lgico do sistema ...................................................................................................................................... 68 Figura 25 Viso geral do Sistema do Website da Ayurvida .................................................. 69 Figura 26 Pgina Gerenciar Postagem, resultado do caso de uso MANTER Postagens....... 70 Figura 27 Pgina Gerenciar Postagem, resultado do caso de uso MANTER Postagens....... 72 Figura 28 Caso de Uso que modela o Contexto do Sistema Tupi Negcios Imobilirios .... 77 Figura 29 Primeiro Carto de Histria escolhido pelo cliente............................................... 79

Figura 30 DER do Sistema Tupi Negcios Imobilirios ....................................................... 80 Figura 31 Trigger Insere Parcela Web................................................................................... 81 Figura 32 Prottipo da Tela Cliente que j possui loteamento .............................................. 82 Figura 33 - Fluxos de atividades do padro MVC.................................................................... 83 Figura 34 Camadas geradas pelo framework Jarchitecture ................................................... 84 Figura 35 Camadas geradas pelo framework Jarchitecture ................................................... 86 Figura 36 Arquivos controlados pelo VRaptor ..................................................................... 87 Figura 37 Cdigo fonte que retorna as informaes da venda para o cliente........................ 88 Figura 38 Cdigo fonte que retorna uma lista de parcelas .................................................... 88 Figura 39 Cdigo fonte da classe ParcelaWebRepository..................................................... 89 Figura 40 Cdigo fonte da classe genrica Repository<T> .................................................. 89 Figura 41 Caso de Uso que modela o contexto do Sistema de Controle Financeiro ............. 93 Figura 42 Caso de Uso MANTER Receita Despesa ............................................................. 95 Figura 43 DER lgico que representa as tabelas MANTER Receita/Despesa ...................... 97 Figura 44 Pgina que representa o caso de uso Manter Receita/Despesa ............................. 98 Figura 45 Cdigo fonte que retorna as informaes para a pgina Receita/Despesa ............ 99 Figura 46 Cdigo fonte da pgina index de Receita/Despesa ............................................. 100 Figura 47 Cdigo fonte da pgina formulrio que recebe os dados de GrupoReceitaDespesa ................................................................................................................................................ 100 Figura 48 Cdigo fonte da pgina tabela.jsp que recebe os dados de TipoReceitaDespesa 101

LISTA DE QUADROS

Quadro 1 - Fases do Ciclo de vida............................................................................................ 25 Quadro 2 - Atributos de qualidade de software ........................................................................ 45 Quadro 3 - Comparao entre os Nveis de Capacidade e os Nveis de Maturidade. .............. 47 Quadro 4 - Definio e descrio dos nveis de maturidade do modelo MR-MPS .................. 50 Quadro 19 - Descrio dos Casos de Usos do Sistema Web Site AYURVIDA ...................... 63 Quadro 21 - Descrio das funes do subsistema Controlar Contedo.................................. 65 Quadro 22 Descrio do Caso de Uso MANTER Postagens ................................................ 66 Quadro 23 Cdigo Fonte responsvel pela funo Listar Postagem .................................... 71 Quadro 24 Cdigo Fonte responsvel pela funo Cadastrar Postagem ............................... 72 Quadro 25 Cronograma de Alteraes ................................................................................. 75 Quadro 26 Descrio dos Atores do Sistema Tupi Negcios Imobilirios ........................... 78 Quadro 27 - Descrio dos Casos de Uso do Sistema Tupi Negcios Imobilirios................. 78 Quadro 28 Cronograma do Sistema Tupi Negcios Imobilirios ......................................... 90 Quadro 29 - Descrio dos Casos de Usos do Sistema de Controle Financeiro ...................... 93 Quadro 30 Descrio do Caso de Uso MANTER Receita Despesa ....................................... 95 Quadro 31 Anlise das atividades desenvolvidas nos processos Cascata, XP e PU ........... 102

10

LISTA DE ABREVIATURAS E SIGLAS

APF CA CMMI CRC CRUD DER ER FPA IAs IIs IOGE MPS.BR MA-MPS MN-MPS MANTER MR-MPS OOD OOP PU SGBD SEI SOFTEX SQA SW-CMM UCP

Anlise de Ponto de Funo Consultores de Aquisio Capability Maturity Model Integration Classe-Responsabilidade-Colaborao Criao, consulta, atualizao e excluso dos dados Diagrama de Entidade e Relacionamento Engenharia de Requisitos Function Point Analisys Instituies Avaliadoras Instituies Implementadoras Instituies Organizadoras de Grupos de Empresas Melhoria do Processo de Software Brasileiro Modelo de Avaliao Melhoria de Processo de Software Modelo de Negcio Melhoria de Processo de Software Realizar as funes CRUD de crias, ler, atualizar de excluir registros Modelo de Referncia Object Oriented Design Object Oriented Programming Processo Unificado Sistema de Gerenciamento de Banco de Dados Software Engineering Institute Associao para a Promoo da Excelncia do Software Brasileiro Software Quality Assurance Capability Maturity Model para Software Use Case Points

11

UML XP

Unified Modeling Language Extrema Programao

12

SUMRIO

1 1.1 1.2 1.2.1 1.2.2 2 2.1 2.2 2.3 2.4 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.7 2.8 2.9 2.10 2.11 2.12

INTRODUO.......................................................................................................... 15 JUSTIFICATIVA ....................................................................................................... 16 OBJETIVOS ............................................................................................................... 16 Objetivo Geral ............................................................................................................ 16 Objetivos Especficos ................................................................................................. 17 REFERENCIAL TERICO....................................................................................... 18 FUNDAMENTOS DE SISTEMAS ........................................................................... 18 ENGENHARIA DE SISTEMAS ............................................................................... 21 ENGENHARIA DE SOFTWARE ............................................................................. 22 CICLO DE VIDA DO DESENVOLVIMENTO DE SISTEMAS ............................. 23 MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SISTEMAS............ 25 O modelo em Cascata................................................................................................. 26 O modelo Incremental ................................................................................................ 28 Processos de Desenvolvimento gil ........................................................................... 29 Extrema Programao (XP)....................................................................................... 31 Processo Unificado (PU) ........................................................................................... 33 Comparao entre as metodologias Cascata, XP e PU............................................. 34 ENGENHARIA DE REQUISITOS ........................................................................... 36 Requisitos Funcionais ................................................................................................ 38 Requisitos No-Funcionais ........................................................................................ 38 Requisitos de Domnio................................................................................................ 40 Processos de Engenharia de Requisitos ..................................................................... 40 QUALIDADE DE SOFTWARE................................................................................ 43 CMMI ......................................................................................................................... 45 MPS.BR (MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO) ........... 48 GERNCIA DE PROJETOS ..................................................................................... 52 ORIENTAO A OBJETOS (OO)........................................................................... 56 UML (UNIFIED MODELING LANGUAGE) ............................................................ 56

13

2.13 3 4 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7

SGBD (SISTEMA DE GERENCIAMENTO DE BANDO DE DADOS) ................ 59 METODOLOGIAS .................................................................................................... 61 DESENVOLVIMENTO E APRESENTAO DOS RESULTADOS .................... 62 CASCATA SISTEMA AYURVIDA ...................................................................... 62 Atividades da fase de definio de requisitos ............................................................ 62 Atividades da Fase de Projeto e de Sistemas de Software ......................................... 64 Atividades da fase de construo da Implementao e teste de Unidade .................. 69 Integrao e Teste de Sistema .................................................................................... 74 Operao e Manuteno ............................................................................................ 74 XP EXTREMA PROGRAMAO SISTEMA TUPI ........................................ 76 Atividade da Fase de Planejamento ........................................................................... 76 Atividade da fase de Projeto ...................................................................................... 79 Atividade da Fase de Codificao.............................................................................. 83 Atividades da Fase de Finalizao ............................................................................ 90 Atividade da fase de produto final ............................................................................. 90 PROCESSO UNIFICADO ......................................................................................... 92 Concepo .................................................................................................................. 92 Elaborao ................................................................................................................. 94 Construo ................................................................................................................. 98 Transio .................................................................................................................. 101 ANLISE ................................................................................................................. 102 Gesto do trabalho ................................................................................................... 103 Comprometimento da Equipe ................................................................................... 103 Participao do Cliente............................................................................................ 104 Nmero de Falhas e Correes ................................................................................ 104 Quantidade de Integraes ...................................................................................... 105 Tamanho do Projeto ................................................................................................. 105 Complexidade ........................................................................................................... 105

14

4.4.8 4.4.9 4.4.10 4.4.11 4.4.12 4.4.13 4.5

Fluxo de Documentao ........................................................................................... 105 Satisfao do Cliente ................................................................................................ 106 Avaliao da Equipe ................................................................................................ 106 Utilizao de Framework ......................................................................................... 106 Aprendizado no Decorrer do Processo .................................................................... 106 Qualidade do Projeto ............................................................................................... 107 CONCLUSO.......................................................................................................... 107

REFERNCIAS ................................................................................................................... 110 ANEXOS ............................................................................................................................... 113 APNDICE A DOCUMENTO DE ESPECIFICAO DE REQUISITOS AYURVIDA TERAPIAS NATURAIS ...................................................................................................... 118 APNDICE B DOCUMENTO DE ESPECIFICAO DE REQUISITOS TUPI NEGCIOS IMOBILIRIOS ............................................................................................ 163 APNDICE C DOCUMENTO DE ESPECIFICAO DE REQUISITOS SISTEMA CONTROLE FINANCEIRO .............................................................................................. 196 APNDICE D DOCUMENTO DE TESTES UNITRIOS DO SUBSISTEMA ACESSAR REA RESTRITA ............................................................................................ 204 APNDICE E DOCUMENTO DE TESTES UNITRIOS DO SUBSISTEMA MANTER POSTAGENS ..................................................................................................... 212

15

INTRODUO

As aes e reaes humanas resultantes de interaes coletivas e independentes geram informaes e conhecimentos que so repassados de gerao para gerao. Essas relaes entre pessoas e o meio no qual as mesmas sobrevivem, utilizam recursos e ferramentas para auxiliar em sua sobrevivncia. Os anos que antecederam a Revoluo Industrial foram marcados por constante aperfeioamento em sistemas automatizados que possibilitaram o desenvolvimento de um produto rapidamente e com qualidade, o que, com o tempo, veio a atender necessidades humanas. Estes sistemas necessitam de um conjunto de funcionalidades inter-agrupadas que relacionam-se entre si, sendo estas funcionalidades provindas do meio no qual o produto dever ser aplicado. A partir do surgimento de sistemas automatizados controlados por software (computadores), os processos utilizados tiveram que ser estudados e, consequentemente, adaptados para o desenvolvimento destes sistemas, os quais atendem a necessidades especficas que evoluem de acordo com as mudanas que ocorrem na sociedade. Dessa maneira, os processos necessitam constantemente serem melhorados. A melhoria dos processos surge da maturidade e percepo das pessoas que se encontram ligadas no decorrer do mesmo. Isto possibilitou descobrir que os processos de desenvolvimento de software existentes at 1996 eram caticos, a ponto de 42% de todos os projetos corporativos de Sistemas de Informao (SI) fossem abandonados antes da concluso (STANDISH GROUP, 1996 apud PRESSMAN, 2006). Isto ocorreu devido descoberta de que o custo das mudanas no desenvolvimento de sistemas aumenta exponencialmente de acordo com o final do projeto, e ainda ocorre devido complexidade do sistema que ser desenvolvido e falta de clareza nos requisitos levantados. Neste contexto, o objetivo deste trabalho foi analisar as metodologias Cascata, XP (Extrema Programao) e PU (Processo Unificado) as quais so utilizadas como um conjunto de informaes que auxiliam no processo de desenvolvimento de sistemas de softwares automatizados. Objetiva-se, tambm, entender qual a metodologia que deve ser aplicada em um determinado projeto, de acordo com os recursos e ferramentas utilizados pelo mesmo, a fim de servir como referncia de estudo para demais estudantes e profissionais da rea de SI.

16

1.1

JUSTIFICATIVA

O desenvolvimento de sistemas utiliza mtodos e recursos, conhecidos tambm como processos e artefatos, para obteno de um produto que tenha qualidade e que atenda s necessidades do cliente. No entanto, o tempo decorrido entre a definio do que o cliente precisa e a fase de desenvolvimento do mesmo acabam gerando inconsistncia nas solicitaes e dificuldade de compreenso do que foi pedido, de tal maneira que o produto final deixa a desejar em grande parte devido as solicitaes levantadas. Diante destas consideraes, a anlise entre as metodologias de desenvolvimento de sistemas Cascata, XP e PU visa identificar os problemas ocorridos no processo de desenvolvimento, da mesma maneira identificar os recursos a serem utilizados para solucionar possveis problemas e aumentar a qualidade do produto final. Por meio de uma anlise bem estruturada possvel compreender quando utilizar cada um destes, pois no processo de definio que ser utilizada, poder ocorrer escolha de uma metodologia que no se encaixe no perfil do projeto, fazendo com que o mesmo atrase e perca o foco do produto a ser entregue. Dessa forma, aconselha-se que seja feito um estudo do processo que ser aplicado.

1.2

OBJETIVOS

Esta seo indica a finalidade e quais foram os resultados obtidos com o desenvolvimento deste trabalho. Nesta seo exposta uma viso geral do que foi desenvolvido neste trabalho, alm de apresentar, de maneira detalhada, os objetivos especficos alcanados pelo desenvolvimento dos Sistemas.

1.2.1 Objetivo Geral

O objetivo geral deste trabalho foi realizar uma comparao entre trs metodologias de desenvolvimento de sistemas, que foram aplicadas no desenvolvimento de trs sistemas web. Visou-se realizar um estudo de caso no qual permitiu identificar quando aplicar a metodologia em um tipo especfico de sistemas web, levando em considerao o tamanho do projeto, complexidade, tempo para entrega e recursos utilizados em cada metodologia.

17

1.2.2 Objetivos Especficos

Com a finalidade de atingir o objetivo geral, os seguintes objetivos especficos foram realizados:

Realizar o estudo entre trs metodologias de desenvolvimento de sistemas; Compreender a aplicabilidade de cada metodologia; Especificar quais so os mtodos e recursos utilizados em cada uma das metodologias; Quais sero os resultados obtidos a partir da utilizao destes recursos; Identificar os pontos positivos e negativos a partir do resultado da anlise de utilizao dos recursos e mtodos; Documentar atravs da comparao entre os recursos e mtodos o resultado da anlise; A partir do levantamento das comparaes, aplicar os resultados no desenvolvimento de trs sistemas web; Especificar o resultado da anlise de cada sistema web.

18

REFERENCIAL TERICO

Este captulo aborda os conceitos e temas necessrios a respeito da rea de desenvolvimento do trabalho. Todos os itens aqui citados fora de total importncia para garantir o sucesso dos Sistemas desenvolvidos.

2.1

FUNDAMENTOS DE SISTEMAS

Toda matria atmica presente no universo est organizada de tal forma que seus elementos conseguem interagir entre si. Desta forma, toda interao provm um produto resultante da organizao sistmica da matria. Partindo da necessidade de compreender esta organizao sistmica, a que tudo d forma, so apresentado abaixo segundo Yordon (1990), as definies bsicas do termo sistema: Um grupo de itens que interagem entre si ou que sejam interdependentes, formando um todo unificado como: Um grupo de corpos que interagem entre si sob a influncia de foras relacionadas; Uma mistura de substncias em equilbrio ou que tende para o equilbrio; e Um grupo de objeto ou foras naturais relacionados entre si.

Neste contexto OBrien (2004) define sistemas como um grupo de elementos inter-relacionados ou em interao que formam um todo unificado, trabalhando rumo a uma meta comum, recebendo insumos e produzindo resultados em um processo organizado de transformao. Um sistema dessa ordem (s vezes chamado sistema dinmico) possui trs componentes ou funes que so descritos abaixo e analisados na Figura 1:

Entrada: envolve a captao e reunio de elementos que ingressam no sistema para serem processados. Por exemplo, matrias-primas, energia, dados e esforo humano devem ser organizados para processamento;

Processamento: envolve processos de transformao que convertem insumo (entrada) em produto. Entre os exemplos se encontram um processo industrial, o processo da respirao humana ou clculos matemticos; e

19

Sada: envolve a transferncia de elementos produzidos por um processo de transformao at seu destino final. Produtos acabados, servios humanos e informaes gerenciais devem ser transmitidos aos seus usurios.

Para cada considerao explcita, os componentes ou funes so partes fundamentais para que um sistema exista. No entanto, o processamento o componente chave para que exista um produto que ir atender uma especfica necessidade humana.
Figura 1- Componentes ou funes de um sistema

Fonte: Adaptado de OBrien (2004, p. 9)

Observa-se na Figura 1 que a entrada de insumos no sistema pode ser produzida pelo resultado de uma sada. Compreendendo esta organizao, a entrada de informaes em um sistema ser provinda do processamento de um terceiro sistema ou dele prprio. Deste modo pode ser compreendido que todos os sistemas se correlacionam de tal maneira que suas sadas so entradas para outros sistemas. Diante das caractersticas apresentadas, podem ser analisadas semelhanas comuns inerentes a qualquer sistema. Yordon (1990) define que o estudo dessas caractersticas comuns conhecido como teoria geral dos sistemas, apresentando os seguintes princpios gerais para quem constri sistemas automatizados de informao:

Quanto mais especializado um sistema, menos capaz ele de se adaptar a circunstncias diferentes. Este princpio permite compreender que se um sistema est adepto a um ambiente, por exemplo: um peixe s pode viver dentro dgua. Quer dizer que, ao mudar o ambiente, o mesmo sistema no poder sobreviver. Da mesma maneira, se um sistema abrange uma totalidade de eventos, o mesmo deixa de responder a um evento especfico, sendo este raciocnio aplicado nas duas direes.

20

Quanto maior for um sistema, maior o nmero de seus recursos que sero destinados manuteno diria. Da mesma maneira que para fabricar um carro de brinquedo sejam utilizados recursos bsicos, ao fabricar um carro automatizado a quantidade de recursos, especialistas e detalhes especficos ser maior em relao ao carro de brinquedo, o que leva a entender que se parte desse sistema passa a interferir no funcionamento de outras partes, a manuteno e verificao do mesmo constante. Os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em sistemas menores. Pode ser compreendido tambm por um hospital, em que o sistema como um todo formado pelas diversas reas da medicina, como exemplo, alguma destas reas: Pediatra, Cirurgio, Oftalmologista e Clnico Geral. Somando suas partes correlacionadas, estas formam um sistema maior. Os sistemas crescem. Naturalmente isso no pode ser verdadeiro para todos os sistemas ou isso violaria um princpio geral de sistemas muito conhecido: a lei de conservao de energia (YORDON, 1990). No entanto, como a quantidade de informaes no mundo cresce constantemente de acordo com as descobertas cientficas, os sistemas que armazenam e processam essas informaes tambm crescem na mesma proporo. Os princpios gerais permitem compreender que ao desenvolver um sistema devem ser levados em considerao detalhes especficos como: Quem o sistema ir atender? Qual o produto ser gerado por este sistema? Quais sero as entradas deste sistema? Quais caractersticas culturais influenciam sobre sistema? Como prever o crescimento do sistema?

Levando em considerao os princpios gerais que regem sobre qualquer sistema, o processamento resultado de uma engenharia complexa, envolvendo detalhes especficos de acordo com a sada que ser produzida. Como descrito anteriormente, essa sada atende uma necessidade humana, direta ou indiretamente.

21

Para que os elementos de um sistema sejam organizados sistematicamente e que o processamento produza a sada esperada, necessrio o auxlio e acompanhamento de outras reas do conhecimento que compreenda esta organizao. Uma dessas reas que compreende parte da totalidade de um sistema conhecida como Engenharia. O termo Engenharia definido como a aplicao de conhecimentos cientficos e empricos, e certas habilitaes especficas, criao de estruturas, dispositivos e processos para converter recursos naturais em formas adequadas ao atendimento das necessidades humanas. (FERREIRA, 2001) Neste sentido, a Engenharia fator principal na elaborao e concepo de qualquer sistema. Ao se tratar de Sistemas Automatizados de Informao, o termo engenharia entendido como Engenharia de Sistemas e posteriormente como Engenharia de Software, sendo esta, responsvel por compreender atravs de ferramentas, modelos e mtodos, todas as caractersticas e fundamentos presentes no processamento do sistema.

2.2

ENGENHARIA DE SISTEMAS

A Engenharia de Sistemas a atividade de especificao, projeto, implementao, validao, implantao e manuteno de sistemas sociotcnicos (SOMMERVILLE, 2007). Envolve tanto hardware e software quanto as pessoas que iro lidar diretamente com o sistema, que so denominadas operadores do sistema. Por envolver pessoas em todo o processo, necessrio compreender o ambiente em que o sistema ir operar estando correlacionado com fatores sociolgicos que influenciaram diretamente sobre o mesmo. Para White (1993 apud SOMMERVILLE, 2007) os engenheiros de software devem ter algum conhecimento de sistemas sociotcnicos e engenharia de sistemas. Isto permite compreender que o desenvolvimento de sistemas no uma parte isolada do todo, uma vez que compreendemos um dos princpios gerados pela teoria de sistemas, em que colocado que um sistema est dentro de outro sistema. Isolar o conhecimento social e focar somente em conhecimento baseado em sistemas resultar em um produto que no atende sua finalidade. No entanto, Thayer (1997 apud SOMMERVILLE, 2007) ressalta que os engenheiros de software precisam compreender a engenharia de sistemas, pois os problemas da engenharia de software so, muitas vezes, resultado de decises de engenharia de sistemas.

22

2.3

ENGENHARIA DE SOFTWARE

O estudo da Engenharia de Software pode ser definido como uma coleo de experincias e observaes adquiridas constantemente, apoiado por um conjunto de ferramentas, mtodos e processos, de modo a possuir a capacidade de desenvolver software com os melhores recursos disponveis focando na qualidade. Esta engenharia a aplicao sistemtica, disciplinada e com abordagem quantitativa para o desenvolvimento de software SOMMERVILLE (2007). A utilizao de recursos no desenvolvimento de sistemas pelo engenheiro de software existe pela necessidade de compreender o sistema que ser desenvolvido, a maneira como ser desenvolvido, definio de escopo e projeto para desenvolvimento e, acima de tudo, gerar um produto focado em qualidade, reduzindo a probabilidade de desenvolver um sistema que no atende s necessidades do usurio ou que de alguma maneira foge da realidade. Segundo Pressman (2006), a engenharia de software uma tecnologia em camadas. Como mostra a Figura 2, a base da engenharia de software est sob o foco na qualidade, as abordagens que so utilizadas devem buscar constante aperfeioamento. Os mtodos ditam a maneira como fazer, sendo as ferramentas instrumentos de apoio automatizados ou semi-automatizados dando suporte aos mtodos e processos.

Figura 2 - Engenharia de Software em Camadas

Pressman(2006, p. 19)

Assim, Pressman (2006) elucida o processo como sendo a camada de processo o alicerce da engenharia de software. Este o adesivo que mantm unidas as camadas de tecnologia e permite o desenvolvimento racional e oportuno de softwares de computador como mostrado na Figura 2. Os processos de software formam a base para o controle gerencial de projetos de software e estabelecem o contexto no qual os mtodos tcnicos so

23

aplicados, os produtos de trabalho (modelos, documentos, dados, relatrios, formulrios etc.) so produzidos, os marcos estabelecidos, a qualidade assegurada e as modificaes so adequadamente geridas. As ferramentas, mtodos e processos sero aplicados em cada fase do ciclo de vida do desenvolvimento de sistemas, onde cada um ir auxiliar na concepo dos artefatos gerados, mantendo foco constante na qualidade do sistema. Por essa razo, foram surgindo os processos de desenvolvimento de sistemas, baseados na experincia constante dos engenheiros de software ao desenvolver projetos semelhantes, para auxiliar no entendimento e desenvolvimento sistemas.

2.4

CICLO DE VIDA DO DESENVOLVIMENTO DE SISTEMAS

O ciclo de vida do desenvolvimento de sistemas (SLDC) o processo de compreenso de um SI que pode suprir as necessidades da empresa, projetar o sistema, constru-lo e entreg-lo aos usurios (DENNIS; WIXOM, 2005). A palavra ciclo de vida remete analogia com o prprio ciclo de vida do ser humano, quando algumas etapas so desenvolvidas de forma semelhantes e outras sendo especficas de cada sistema. Deste modo, as mesmas etapas que um ser humano realiza em uma determinada atividade, como por exemplo: o processo de ingesto e digesto de alimentos pode ser relacionado com as etapas do ciclo de vida de um software, pois as mesmas possuem incio, meio e fim. Para compreender estas fases, a Figura 3 representa o ciclo de vida do desenvolvimento do software.

Figura 3 - Ciclo de vida de software

Adaptado de Sommervile (2007, p.44)

24

Segundo Sommerville (2007) as atividades do ciclo de vida mostradas na Figura 3, podem ser definidas como:

1. Anlise e definio de requisitos: os servios, restries e objetivos do sistema so definidos por meio de consulta aos usurios do sistema. Eles so, portanto, definidos detalhadamente e servem como uma especificao de sistema. 2. Projeto de sistema e software: o processo de projeto de sistema divide os requisitos em sistemas de hardware ou de software. Ele estabelece uma arquitetura geral do sistema. O projeto de software envolve a identificao e a descrio das abstraes fundamentais do sistema de software e suas relaes. 3. Implementao e teste de unidade: durante esse estgio, o projeto de software realizado como um conjunto de programas ou unidades de programa. O teste unitrio envolve a verificao de que cada unidade atende sua especificao. 4. Integrao e teste de sistema: as unidades individuais de programa ou os programas so integrados e testados como um sistema completo para garantir que os requisitos de software foram atendidos. Aps os testes, o sistema de software liberado para o cliente. 5. Operao e manuteno: Geralmente (embora no necessariamente) esta a fase mais longa do ciclo de vida. O sistema instalado e colocado em operao. A manuteno envolve a correo de erros no detectados nos estgios anteriores do ciclo de vida, no aprimoramento da implementao das unidades de sistema e na ampliao dos servios de sistema medida que novos requisitos so identificados.

No entanto, o SLDC possui um conjunto similar de quatro fases fundamentais: planejamento, anlise, projeto e implementao. Estas fases so trabalhadas de maneiras diferentes dependendo do processo (metodologia) de desenvolvimento definido. Dennis e Wixom (2005) resumem as quatro fases de acordo com o Quadro 1.

25

Quadro 1 - Fases do Ciclo de vida

Planejamento
Por que construir o sistema? Solicitao de Sistema Dados: Fonte do trabalho

Anlise
Quem, o qu, quando, onde ser o sistema? Proposta de Sistema

Projeto
Como o sistema funcionar? Especificao de sistema

Implementao
Entrega do Sistema Sistema instalado

O SLDC um processo de melhoria contnua que permite em cada fase refinar os dados levantados para produo do sistema, buscando obter qualidade. Diante das fases de desenvolvimento de sistemas, foram criados processos, conhecidos tambm como metodologia de desenvolvimento de sistemas, que aprimoram e melhoram o desenvolvimento de acordo com as definies especficas de cada projeto.

2.5

MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SISTEMAS

Os modelos de processo de desenvolvimento de sistemas definem a maneira como sero trabalhadas as fases de desenvolvimento de sistemas. Estes modelos relacionam-se com o tipo de sistema que ser desenvolvido, cada um aborda uma metodologia prpria que vai em direo obteno de qualidade e entrega de um produto que realmente atenda as necessidades do cliente. Segundo Sommerville (2007) um modelo de processo de software uma representao abstrata de um processo de software. Cada modelo de processo representa um processo sob determinada perspectiva e, dessa forma, fornece somente informaes parciais sobre esse processo. Modelos prescritivos (convencionais) de processo definem um conjunto distinto de atividades, aes, tarefas, marcos e produtos de trabalho que so necessrios para fazer engenharia de software com alta qualidade. Esses modelos de processo no so perfeitos, mas efetivamente fornecem um roteiro til para o trabalho de engenharia de software. (PRESSMAN, 2006). Os modelos de processo definem atividades que devem ser desenvolvidas em cada etapa. No entanto, a quantidade de recursos e esforos se altera entre estas fases, de modo que, cada fase possui um determinado custo para manter estes recursos e esforos. A partir da, o adiamento das mudanas tende a aumentar o custo do projeto.

26

Estas mudanas podem ser melhor compreendidas ao visualizar a Figura 4 que mostra atravs da curva o custa das mudanas.

Figura 4 - O custo das modificaes aumentam exponencialmente ao longo do tempo

Adaptado de Beck (2004, p. 39)

Como pode ser observado na Figura 04, medida que o sistema avana nas atividades, o custo de correo ou modificao aumenta o que possibilita compreender que quanto mais cedo for detectado um erro ou modificao, mais barato ser o desenvolvimento em relao a detect-lo mais no final do processo. Os modelos de desenvolvimento existentes tendem a minimizar o custo das modificaes de acordo com o tipo de sistema que ser desenvolvido.

2.5.1 O modelo em Cascata

O modelo em Cascata parte do princpio que os requisitos do sistema foram bem compreendidos, de modo que a comunicao e o trabalho se desenvolvem razoavelmente em modo linear. Este modelo como sendo um dos primeiros, originou-se dos processos gerais de engenharia de software (SOMMERVILLE, 2007). No entanto, Pressman (2006) ressalta que o modelo em cascata o paradigma mais antigo da engenharia de software. Como maneira de compreender o modelo cascata, a Figura 5 ilustra este modelo divido por suas fases em modo linear. A Figura 5 permite compreender que o fluxo segue ao trmino de uma fase, os requisitos so definidos todos de uma vez, o planejamento aborda toda a viso do sistema, a

27

fase de projeto constri diretamente todo o sistema e somente na fase de implantao que sero verificadas inconsistncias, correes e entrega.

Figura 5 - O modelo em Cascata

Adaptado de Pressman (2006, p.39)

Primeiro realizado o levantamento de requisitos. Somente ao trmino do levantamento de requisitos que se inicia a fase de Planejamento, quando so definidas as estimativas, cronograma, monitorao e trabalhado o escopo do projeto. A modelagem define a anlise do sistema e projeto, como devero ser desenvolvidos os requisitos levantados, quais sero os recursos a serem utilizados. Ao incio da fase de construo, tambm conhecida como implementao, fase em que o sistema ser desenvolvido e testado. Aps passarem os testes o sistema est pronto para ser entregue. Inicia-se a fase de implantao. Geralmente esta a fase mais longa do ciclo de vida (Sommerville, 2007), pois a fase de manuteno neste modelo constante se verificado que os requisitos no ficaram esclarecidos, o feedback por base a resposta do cliente se o sistema realmente atende suas necessidades e o que precisa ser melhorado. Mesmo que o modelo cascata seja o paradigma mais antigo, este possui alguns problemas que prejudicam constantemente projetos grandes de desenvolvimento de sistemas. Pressman (2006) destaca os principais problemas:

Projetos reais raramente seguem o fluxo sequencial que o modelo prope. Apesar de o modelo linear poder acomodar a interao, ele o faz indiretamente. Como resultado, as modificaes podem causar confuso medida que a equipe de projeto prossegue.

Em geral, difcil para o cliente estabelecer todos os requisitos explicitamente. O modelo em cascata exige isso e tem dificuldade de acomodar a incerteza natural que existe no comeo de muitos projetos.

28

O cliente precisa ter pacincia. Uma verso executvel do(s) programa(s) no vai ficar disponvel at o perodo final do intervalo de tempo do projeto. Um erro grosseiro pode ser desastroso se no for detectado at que o programa executvel seja revisto.

Como o modelo cascata foi desenvolvido a muito tempo, no momento ele j no consegue atender s necessidades de desenvolvimento de sistemas que trabalham com prazos longos e mudanas constantes na definio de requisitos. No entanto, se os requisitos foram compreendidos e o projeto consegue seguir at o fim de modo linear, o modelo Cascata pode ser estabelecido.

2.5.2 O modelo Incremental

O modelo Incremental define um processo de desenvolvimento em que o projeto divido por funcionalidades do sistema, em que cada funcionalidade definida e explorada. O desenvolvimento segue de forma que todas as fases estabelecidas no ciclo de vida sejam executadas para a funcionalidade que foi selecionada. Ao trmino do desenvolvimento de uma funcionalidade gera uma verso do sistema, a prxima funcionalidade mais importante e colocada em desenvolvimento, at que o conjunto de verses desenvolvidas gere um sistema completo. A Figura 6 ilustra o modelo de maneira objetiva. (PRESSMAN, 2006)

Figura 6 - O modelo incremental

Fonte: Pressman (2006)

Este modelo geralmente aplicado a projetos em que o usurio no tenha tanta clareza sobre os requisitos, podendo avaliar cada verso do produto desenvolvido. Para

29

Pressman (2006) o modelo Incremental combina elementos do modelo em Cascata aplicado de maneira iterativa. Como podem ser observados na Figura 6, os incrementos iniciais no geram propriamente dito, um produto executvel como um software. Nesta fase so gerados como produto os documentos de levantamento de requisitos e modelagem dos mesmos. A partir do momento em que so validados, estes passam para fase de projeto, o qual ir gerar ainda alguns modelos de anlise de requisitos. Porm, esta fase j parte para o projeto em si de todo o desenvolvimento. Na fase de implementao, cada interao gera um pedao do sistema que ser testado para que este faa parte da verso final do produto para produo, at que todas as partes do sistema estejam completas. O produto final resultado de uma srie de incrementos e estes se desenvolvem de forma linear. possvel observar que cada fase est destacada com uma cor diferente, permitindo compreender que todas as fases so executadas em uma interao, gerando ao final o produto da funcionalidade escolhida, obtendo em sequncia o retorno do cliente, para saber se o resultado corresponde ao que foi solicitado. Este processo tambm pode ser compreendido como um processo em repetio e evolucionrio. (PRESSMAN, 2006)

2.5.3 Processos de Desenvolvimento gil

Os processos de desenvolvimento gil surgiram no ano de 2001 e foram estabelecidos de acordo com o Manifesto gil (MA) e seus princpios. O grupo de estudos que coordenou as pesquisas e estabeleam estes valores e princpios so conhecidos como Aliana gil (Agille Alliance). Qualquer processo que receba denominao de um processo gil deve estar de acordo com o Manifesto gil que descrito a seguir, pelo manifesto gil: Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o ns mesmos e ajudando outros a fazerem o mesmo. Atravs deste trabalho, passamos a valorizar: Indivduos e interaes mais que processos e ferramentas Software em funcionamento mais que documentao abrangente Colaborao com o cliente mais que negociao de contratos Responder a mudanas mais que seguir um plano

30

Mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. (AA, 2001). Isto quer dizer que o conceito do texto que est destacado mais valorizado do que o texto no destacado. O desenvolvimento gil permite compreender que o foco est nas pessoas envolvidas no processo e a comunicao entre elas. Faz referncia contnua a quantidade de documentos que so gerados a partir de outros processos, focando ento na modelagem necessria para compreenso do sistema naquele instante. Possui ainda flexibilidade para se adequar as mudanas e permitir mudana de requisitos durante o ciclo de vida. Os Princpios geis permitem ter uma compreenso mais abrangente sobre desenvolvimento gil. De acordo com a Aliana gil estes princpios so descritos a seguir:

1. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado. 2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no

desenvolvimento. 3. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente. 4. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia a menor escala de tempo. 5. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 6. Construa projetos em torno de indivduos motivados. 7. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho. 8. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face. 9. Software funcionando a medida primria de progresso. 10. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. 11. Contnua ateno excelncia tcnica e bom design aumenta a agilidade. 12. Simplicidade a arte de maximizar a quantidade de trabalho no realizado - essencial.

31

13. As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizveis. 14. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo.

De acordo com os tpicos descritos, os princpios geis buscam otimizar o desenvolvimento de sistemas, focando no que realmente tem valor para o negcio e para o cliente.

2.5.4 Extrema Programao (XP)

A XP uma metodologia de desenvolvimento interativo e incremental, focado no cliente, orientado a codificao e aos testes. Possui abordagem nos princpios do Manifesto gil e define alguns prprios como: feedback rpido, simplicidade presumida, mudanas incrementais, aceitao das mudanas e alta qualidade. Como o foco da XP est voltado para a programao e testes. A Figura 7 ilustra o ciclo de vida da metodologia XP.

Figura 7 - Fases do desenvolvimento XP

Adaptado de Pressman(2006, p.64)

32

Como mostra a Figura 7 o ciclo de vida da XP definido em 4 fases, sendo elas: planejamento, projeto, codificao e teste. Na fase de planejamento, os requisitos so levantados mediante as histrias dos usurios, conhecidas tambm como metforas, uma forma de entender o sistema. No entanto, os requisitos na XP so adotados como funcionalidades. De acordo com o nvel de importncia de cada funcionalidade o cliente define as principais funcionalidades do sistema. Uma vez que foram definidas as funcionalidades, define-se o plano de interao, a ordem na qual cada funcionalidade ser implementada. Segue-se ento para a fase de projeto quando as solues sero definidas, utilizase cartes CRC para especificao de classes de orientao a objetos para facilitar na implementao do sistema, os detalhes de como fazer resolvido aqui. A codificao na XP introduz um conceito novo, este conceito conhecido como programao em pares. Enquanto uma pessoa programa, a outra fica analisando a programao de modo como seria integrado ao sistema, alm de propor solues na definio de mtodos e funes. A programao em pares opcional (PRESSMAN, 2006). Uma vez que foi programada uma funcionalidade, o programador observa se o cdigo est bem escrito em relao ao restante do programa. Caso seja necessrio reorganizar o cdigo, este comea uma tarefa chamada de refatorao que visa organizar o cdigo de tal maneira que fique compreensvel para todos na equipe. O cdigo passado por testes de unidade em que verificado se as funes e mtodos respondem adequadamente. Caso um teste falhe, o cdigo verificado e se necessrio, reescrito. O teste sendo validado o sistema obtm uma verso (release) que corresponde a uma funcionalidade do sistema. A fase de planejamento inicia novamente medindo o tempo de desenvolvimento do projeto, analisando e organizando os requisitos mais importantes, de modo que o prximo requisito que tenha maior relevncia possa ser desenvolvido. O processo XP necessita de constante presena do cliente para validar as funcionalidades solicitadas. Ao chegar fase de teste, o cliente solicitado a verificar a funcionalidade desenvolvida. O projeto somente continua se o cliente confirmar o que foi pedido, caso contrrio os requisitos so revisados e ordenados. O processo XP define algumas prticas a serem utilizadas. As principais prticas so descritas a seguir:

33

programao em pares: o cdigo desenvolvido por dois programadores em um mesmo computador, enquanto um codifica o outro analisa e pensa na rotina que est sendo escrita; testes contnuos: isto quer dizer que um teste pode ser escrito antes da codificao, de modo que cdigo seja desenvolvido com base nos testes criados e sempre que for criado um mtodo, fazer com que este seja testado; feedback rpido: as interaes no devem durar meses, podem ser definidas em um prazo de 2 a 3 semanas.

2.5.5 Processo Unificado (PU)

O PU surge no intuito de ser um processo popular para o desenvolvimento de software visando construo de sistemas orientados a objetos, tendo como apoio a linguagem de modelagem unificada (UML), desenvolvendo a anlise e programao orientada a objetos (AOO/POO) e como modelo de processo, os conceitos de desenvolvimento interativo e incremental (LARMAN, 2004). Neste contexto, o PU utiliza constantemente modelos de caso de uso como uma maneira de dirigir todo o trabalho de desenvolvimento, desde a captao inicial e negociao de requisitos at a aceitao do cdigo. Juntamente com os casos de uso, define que a arquitetura o alicerce fundamental sobre o qual ele se erguer, devendo ser observado com ateno pela equipe de projeto (SCOTT, 2003).

Figura 8 - Fases e disciplinas do PU

Adaptado de Larman (2004. P. 44)

34

O ciclo de vida e desenvolvimento no PU esto organizados sob o conceito de fases e disciplinas, em que em cada fase os esforos so concentrados nos produtos gerados pelo conjunto de disciplinas presentes no modelo. A Figura 8 mostrada anteriormente ilustra o ciclo de vida do PU. Este composto por uma srie de interaes, que podem ser definidas como ciclos, os quais implementam sobre cada interao, uma quantidade de esforos sobre cada disciplina, variando de acordo com a fase em que se encontra. Cada interao gera um produto o qual testado e avaliado de modo que o produto final seja o incremento de vrias etapas de iteraes. Neste modelo a fase de concepo permite verificar a viabilidade do sistema, avaliando os riscos e anlise econmica do projeto, com base em estimativas de custo, cronograma e qualidade do produto, alm de definir uma possvel arquitetura. Os esforos nesta etapa so menores, de modo que os requisitos comeam a ser selecionados. A fase de elaborao evolui sob a fase de concepo de modo que possui a capacidade para construir o novo sistema. Os esforos sobre as disciplinas de requisitos, anlise e projeto aumentam nesta etapa, com o objetivo de capturar os requisitos funcionais com a utilizao de caso de uso e definir uma arquitetura para o desenvolvimento contnuo do sistema (LARMAN, 2004). A fase de construo concentra seus esforos na atividade de implementar e construir o sistema, possuindo esforos nas atividades de teste, de modo que todo o produto de uma interao seja testado e validado, para ento ser gerado um pedao do produto e consequentemente o produto final. A fase de transio o momento em que ocorre a entrega do sistema para o cliente. No entanto, grande parte dos esforos dos testes vem da fase de construo e termina nesta fase, devido a necessidade de correo de falhas que foram encontradas, bem como ajustes entre verses dos incrementos.

2.5.6 Comparao entre as metodologias Cascata, XP e PU

A principal diferena significativa entre a metodologia Cascata em comparao com as metodologias XP e PU o modelo do ciclo de vida destes processos. Enquanto o Cascata aborda o modelo linear, o XP e PU adotam o modelo interativo e incremental. O principal resultado desta diferena que os problemas de inconsistncia de requisitos e a quantidade falhas encontradas no Cascata so muito superiores em relao aos modelos

35

interativos, resultando em produto de baixa qualidade. Grande parte dos problemas encontrados no desenvolvimento de sistemas utilizava a abordagem Cascata. A ideia central no contexto de desenvolvimento interativo conhecer o caminho a seguir e ajust-lo na medida em que o projeto caminhe de tal modo que possveis erros possam ser descobertos no incio do projeto, fazendo com que o mesmo no chegue prximo a fase de entrega e seja descoberto que h falhas significativas, a ponto dos custos aumentarem significativamente. Enquanto o modelo PU focado na documentao e modelagem, o modelo XP aborda que modelos de viso sejam construdos de acordo com a necessidade. Em contrapartida o XP foca na programao e nos testes de modo que o resultado seja um produto que tenha alta qualidade. Da mesma maneira, o PU aborda a fase de teste tanto nos modelos visuais quanto no cdigo propriamente dito, possibilitando em cada interao controlar a qualidade do produto. No modelo Cascata, os testes so realizados somente na fase de construo, o que pode gerar inconsistncia tanto na integrao de sistemas desenvolvidos em grupo quanto no entendimento da documentao desenvolvida. Enquanto as abordagens interativas XP e PU definem o requisito mais importante a cada incio de interao para ser desenvolvido, o Cascata define, planeja e constri todos de uma vez, de modo que se os requisitos do projeto mudarem ou caso o cliente mude de ideia, as mudanas iro surtir efeitos significativos no custo do projeto. XP e PU defendem a mudana nos requisitos para adequar as necessidades do cliente e desenvolver um sistema que realmente seja funcional. No entanto, estas mudanas so controladas. No Cascata isto no possvel. A implementao do PU a fase de codificao do XP. O XP defende e adota a programao em pares juntamente com a refatorao do cdigo, sempre pensando na qualidade do produto final. Uma prtica que a XP e PU adotam juntamente so os testes de unidade e integrao contnua, resultando em um produto em que a qualidade medida em cada interao. Estes no so abordados no modelo Cascata (PRESSMAN, 2006). Enquanto o PU e Cascata utilizam os diagramas UML para representao formal dos requisitos dos usurios, o XP adota cartes de histrias como forma de documentar os requisitos e entend-los. Nestas duas abordagens XP e PU cada interao escolhe sempre o requisito que tenham o maior grau de importncia para construo do sistema (BECK, 2004). As interaes no PU so definidas em um tempo significativamente maior que no XP, geralmente de 4 a 6 semanas. No XP estas so definidas no prazo mximo de 2 a 3 semanas. Cada interao no XP precisa de um retorno do cliente para dar sequncia no

36

desenvolvimento. No PU isto ocorre de forma imparcial de modo que a comunicao com o cliente tenha algumas folgas. Assim, define que a presena deste necessria. No Cascata esta mesma abordagem s seria possvel na fase de entrega. Utiliza-se PU e XP quando os requisitos no so definidos e compreendidos em sua totalidade, de modo que o desenvolvimento tenha quer ir ajustando de acordo com as mudanas solicitadas pelo cliente. O PU recomendado em projetos em que a equipe grande e precisa de uma quantidade de documentao maior no sentido de comunicar e manter a evoluo do sistema. Geralmente adotado por empresas que preciso fornecer grande quantidade de detalhes em documentao na entrega do produto (KRUCHTEN, 2003). O XP recomendado quando o projeto precisa ser entregue mais rpido desde que a equipe seja pequena e a comunicao e entendimento do sistema no fique preso modelagem. Pode ser utilizado quando o projeto no necessita entregar grande ndice de documentao ao cliente (BECK, 2004). O Cascata como um dos primeiros modelos tornou-se obsoleto em vista dos novos modelos existentes. Isto no quer dizer que este modelo no possa ser utilizado. Desde que o tamanho do projeto seja pequeno e todos os requisitos forem compreendidos, este pode ser utilizado (PRESSMAN, 2007).

2.6

ENGENHARIA DE REQUISITOS

Engenharia de Requisitos consiste no processo de descobrir, analisar, documentar e verificar os servios e restries que o sistema apresentar de acordo com as necessidades do cliente. Esta constri uma ponte para o projeto e a construo (PRESSMAN, 2006). Para Denis e Wixon(2005) a finalidade mais importante da definio de requisitos definir o escopo do sistema e atravs do documento de requisitos descrever exatamente o que o sistema precisa fazer. A engenharia de requisitos uma atividade que est efetivamente ligada ao planejamento e a anlise do sistema de acordo com o ciclo de vida do sistema. O processo de levantamento de requisitos consiste em um processo interativo e contnuo, o qual analistas de sistemas e usurios definem as funcionalidades do sistema s quais sero refinadas e analisadas e documentadas posteriormente, de modo a priorizar as principais funcionalidades do sistema.

37

Este um momento em o analista de sistemas estar diante do cliente anotando todas as funcionalidades que o sistema dever conceber. No entanto, parte do problema de desenvolvimento de software comea por aqui, pois na maioria das vezes o cliente no sabe o que quer, e quando sabe uma informao que para ele tida como simples, esta pode ser ocultada, o que prejudicar na fase de desenvolvimento, gerando processos inconsistentes e/ou alto custo para realizar modificaes. As necessidades do cliente so tambm conhecidas como Requisitos de Usurio o qual demonstra o sistema em uma linguagem natural com diagramas que permitem comunicar o sistema que ser desenvolvido. A Figura 9 exibe a organizao dos leitores de requisitos de acordo com o tipo de especificao, ilustra atravs da figura, o entendimento dos requisitos em uma linguagem natural e de alto nvel por parte dos requisitos de usurio, os quais expressam as necessidades que precisam ser atendidas pelo sistema e em uma linguagem formal, detalhada e de alto nvel os requisitos do sistema que ser utilizado por quem est diretamente ligado ao desenvolvimento do mesmo (SOMMERVILLE, 2007). Os requisitos de sistemas juntamente com os requisitos de usurio podem ser classificados em: requisitos funcionais, requisitos no-funcionais e requisitos de domnio. Estas trs definies permitem compreender como ser definida a abrangncia dos processos no nvel de funcionalidade, restrio e contextualizao.

Figura 9 - Leitores de diferentes tipos de especificao

Sommerville (2007, pg. 81)

Cada uma das classificaes destes requisitos se prope a determinada compreenso do sistema. A diferena bsica entre estes que os funcionais descrevem as funcionalidades do sistema, os no-funcionais restringem a maneira como essas funcionalidades devero operar e o de domnio so provenientes de caractersticas do sistema.

38

2.6.1 Requisitos Funcionais

Os requisitos funcionais em sua essncia descrevem o que o sistema deve fazer, as suas funcionalidades de acordo com as entradas e sadas que devero ser produzidas, levando em considerao que o Engenheiro de Sistemas necessita compreender o sistema que dever ser produzido. Assim sendo, um dos gargalos na especificao de requisitos a impreciso dos mesmos e a ambiguidade obtida na especificao, o que consequentemente gera atraso na entrega e aumento dos custos. Esta especificao deve ser completa, permitindo que todos os servios exigidos pelo usurio possam ser definidos e sejam consistentes, mostrando que os requisitos no podem apresentar definies contraditrias (SOMMERVILLE, 2007). Na prtica, sistemas grandes e complexos tendem a conter o maior nmero de requisitos inconsistentes, devido a omisso de informaes por parte dos stakeholders. Estas inconsistncias so descobertas por uma anlise mais detalhada, ou at mesmo quando o sistema j est em desenvolvimento. Se for descoberto na fase de desenvolvimento, haver um alto custo para trabalhar sob estas mudanas.

2.6.2 Requisitos No-Funcionais

Como o prprio nome menciona, os requisitos no-funcionais esto ligados indiretamente s funcionalidades do sistema, impondo restries sob as quais funcionalidades devem operar. Estes requisitos tendem a atender as caractersticas gerais do sistema como um todo, raramente tratam uma caracterstica em especfico (SOMMERVILLE, 2007). Os requisitos no-funcionais podem ser compreendidos como um controle sob os requisitos funcionais, sua relao com o meio externo e restries prprias impostas ao sistema, de acordo com o nvel de aplicao ao meio em que estar atuando Os requisitos no-funcionais podem ser subdivididos em trs principais subreas: Requisitos de produto, Requisitos organizacionais e Requisitos externos, os quais grande parte dos sistemas depende. No necessariamente estes requisitos devem ser implementados, sempre deve se fazer a anlise do tipo de sistema que est sendo desenvolvido e verificar de acordo com as solicitaes do cliente, em que cada requisito no-funcional classificado de acordo com a tabela. Estas subdivises so apresentadas pela Figura 10.

39

Como ilustra a Figura 10, as primeiras subdivises dos requisitos no-funcionais permitem entender a abordagem destes requisitos.

Figura 10 - Tipos de requisitos no funcionais

Adaptado de Sommerville( 2007, pg. 82)

Requisitos de produto: determinam as qualidades necessrias de um sistema como facilidade de uso, eficincia (desempenho e espao para armazenamento), confiabilidade e portabilidade (opera em qualquer sistema operacional). Requisitos organizacionais: tratam das diretrizes da organizao como entrega (o que deve ser e como entregue) e implementao, quais sero os processos utilizados e padres que sero aplicados no desenvolvimento. Requisitos externos: tratam a comunicao do sistema com outros sistemas, valores apresentados pelos mesmos sob definies ticas regidas pela sociedade ligadas segurana das informaes que devem ser mantidas pelo mesmo.

So os requisitos no-funcionais que ditam a qualidade do sistema. Podem ser includos no documento de requisitos, metas do cliente junto aos requisitos, permitindo compreender prioridades do cliente, estas prioridades influenciam sob o andamento do projeto.

40

2.6.3 Requisitos de Domnio

Os requisitos de domnio esclarecem o contexto no qual o sistema ser colocado para rodar. So conhecimentos especficos de cada aplicao que so fundamentais para seu funcionamento, envolvem caractersticas culturais e operacionais nas quais uma funcionalidade produzir um produto. Os desenvolvedores devem ter conhecimento especfico de qual aplicao ser aplicada (ambiente). Um exemplo que pode ser colocado no controle de trfego areo, o que permite que um avio decole somente aps a verificao de todos os processos envolvidos. O sistema deve compreender a ordem em que esses processos so organizados e validados para que o comandante do avio receba sinal para ento iniciar o vo (SOMMERVILLE, 2007). O domnio neste caso pode ser entendido como as regras e restries que envolvem todo processo para que um avio possa voar, assim como em qualquer sistema as caractersticas de definio no qual o sistema ser aplicado influenciam no desenvolvimento do mesmo.

2.6.4 Processos de Engenharia de Requisitos

O objetivo do processo de engenharia de requisitos criar e manter um documento de requisitos de sistema. O processo geral desta engenharia envolve quatro subprocessos:

1. Estudo de viabilidade O estudo de viabilidade ir avaliar o resultado da implantao do novo sistema, tecnologia a ser utilizada para desenvolvimento, levando em considerao os prazos que foram propostos e a comunicao com sistemas j existentes na organizao. Esta etapa analisada em todo o decorrer do processo (SOMMERVILLE, 2007).

2. Elicitao e anlise (obteno de requisitos) A elicitao consiste no levantamento e obteno dos requisitos por parte dos analistas de sistemas juntamente com os stakeholders. Neste momento, so feitas perguntas aos interessados pelo sistema, de modo seja possvel obter um conjunto de possveis funcionalidades para o sistema.

41

3. Especificao A especificao de requisitos classifica e organiza os requisitos de acordo com o nvel de proximidade e relao. Este mtodo ajuda os analistas a descobrirem requisitos ambguos, alm de refinar os mesmos de modo detalhado. Fechando a etapa de elicitao e anlise de requisitos os mesmos so documentados, produzindo documentos formais.

4. Validao Esta a ltima etapa antes que seja gerado o documento de requisitos do sistema. Aqui os requisitos so validados juntamente com o cliente atravs de diagramas de caso de uso e de sequncia que permitem comunicar como ir funcionar o sistema. De acordo com os processos escolhidos, o prottipo apresentado tornando mais fcil a compreenso por parte do cliente.

Os processos de engenharia de requisitos podem ser compreendidos sob dois aspectos levando em considerao a metodologia escolhida, sendo estruturada ou interativa. O modelo convencional apresentado na Figura 11.

Figura 11 - Processo de engenharia de requisitos

Sommerville(2007, pg. 96)

A Figura 11 mostra a comunicao entre cada sub-processo aps o trmino de cada um, iniciando com o estudo de viabilidade, gerando ao final o documento de requisitos.

42

No entanto, os requisitos durante o desenvolvimento do sistema mudam, o que acaba gerando a re-estruturao dos mesmos e organizao, sendo conhecida esta etapa como gerenciamento de requisitos. A Figura 12 apresenta uma perspectiva alternativa do processo de engenharia de requisitos em relao Figura 11. Neste modelo, o processo apresentado divido em 4 passos. O primeiro passo segue com o estudo de viabilidade do sistema, verificando se o mesmo til para a empresa. Caso seja til, segue a sequncia com a Elicitao de requisitos, o qual ir desempenhar um maior esforo que ser aplicado no entendimento dos requisitos de negcio, requisitos do usurio e requisitos do sistema. Ao trmino deste passo, inicia-se um maior esforo na especificao dos requisitos divididos como mostrado na Figura 11. Este o momento em que os requisitos so refinados e modelados. No quarto passo, os requisitos so revisados e validados, de modo a gerar o documento de requisitos do sistema (SOMMERVILLE, 2007). Caso o processo de desenvolvimento escolhido utilize prototipao, nesta etapa que o prottipo ser gerado de modo que o cliente possa ter uma viso mais detalhada do sistema.
Figura 12 - Modelo em espiral dos processos de engenharia de requisitos

Adaptado de Sommerville(2007, pg. 96)

A partir do momento em que o documento de requisitos de sistema est concludo, o projeto passa para a parte de implementao e construo, o qual ir desenvolver todas as funcionalidades definidas neste documento.

43

2.7

QUALIDADE DE SOFTWARE

O termo qualidade institui-se do ponto de vista de quem ir utilizar determinado produto. Este utilizador tambm conhecido como consumidor determina o grau de exigncia para que um produto possa ter qualidade, estando sempre ligado ao ambiente no qual o mesmo ser consumido de modo que o produto no sofra alterao por este meio e mantenha os padres no qual foi submetido para o seu desenvolvimento. O termo qualidade para o desenvolvimento de software foi estabelecido sob a Gesto de qualidade (Quality Management) conhecida tambm por garantia de qualidade de software (Software Quality Assurence - SQA), o qual possui o objetivo de remover problemas de qualidade no software (PRESSMAN, 2006). Dentro de uma empresa, o SQA representado por uma equipe que auxilia (apoia) a equipe de desenvolvimento de software de modo que possa ser gerado um produto de alta qualidade. No gerenciamento de qualidade de software, a sua estrutura pode ser definida em trs atividades principais, sendo estas: garantia de qualidade, planejamento de qualidade e controle de qualidade. A garantia de qualidade pode ser garantida a partir da definio de um conjunto de procedimentos organizacionais e padres que conduzem a um software de alta qualidade. O planejamento parte para a seleo dos procedimentos e padres definidos na garantia de qualidade. O controle de qualidade garante que a equipe de desenvolvimento de software tenha seguido os procedimento e padres definidos no planejamento.

Figura 13 - Gerenciamento de qualidade e processo de software

Adaptado de Sommerville (2007, pag. 425)

A SQA parte da unio com um processo de desenvolvimento de software que deve ser seguido de modo que a qualidade seja estabelecida sobre os conceitos, ferramentas e mtodos compreendidos por este processo. Dessa maneira, o processo de desenvolvimento de

44

software evolui sob o processo de gerenciamento de qualidade, como mostra a Figura 13 tornando possvel compreender este acompanhamento, nos quais os padres e procedimentos so organizados, institudos no plano de qualidade e seguidos pelas etapas de desenvolvimento. Aps cada etapa, segue o controle de qualidade gerando os relatrios de reviso qualidade. A Figura 14 ilustra a qualidade baseada em processo.

Figura 14 - Qualidade baseada em processo

Adaptado de Sommerville (2007, pag. 425)

Segundo Sommerville (2007) deve-se medir a qualidade do produto e mudar o processo at o nvel de qualidade que voc precisa que seja atingido. Esta afirmao pode ser melhor comprovada atravs da Figura 14 mostrada anteriormente. De acordo com a Figura 14 o processo de desenvolvimento definido. Logo so selecionados os procedimentos a serem seguidos para ento desenvolver o produto. Assim o produto avaliado segundo os procedimentos de qualidade escolhidos. Caso o resultado seja positivo, o processo seguido padronizado para ser utilizado; caso o resultado seja negativo, o processo deve ser aprimorado de modo que os procedimentos so reavaliados e verificados onde a qualidade no cumpriu com o esperado (SOMMERVILLE, 2007). A garantia de qualidade define dois padres que podem ser aplicados de acordo com o processo de garantia de qualidade, sendo os padres de produto e padres de processo. Os padres de produto se aplicam ao desenvolvimento do software, estando ligado a padres de documentao e codificao. Por outro lado, os padres de processo definem quais so os processos a serem seguidos durante o desenvolvimento, podendo incluir especificaes e validaes para este. O Planejamento de qualidade o momento em que so selecionados os padres organizacionais que sero aplicados no produto e no processo de desenvolvimento. H alguns atributos de qualidade de softwares potenciais que devem ser considerados durante o processo de planejamento (SOMMERVILLE, 2007). Estes atributos podem ser verificados no Quadro 2.

45

Quadro 2 - Atributos de qualidade de software Segurana Facilidade de compreenso Proteo Confiabilidade Facilidade de recuperao Facilidade de testes Adaptabilidade Modularidade

Portabilidade Facilidade de uso Facilidade de reuso Eficincia Facilidade de aprendizado

Robustez Complexicidade Fonte: Sommerville (2007, pg. 431)

No entanto caso, algum dos atributos disponveis na tabela no seja necessrio, o mesmo no precisa ser implementado no planejamento de qualidade, levando em considerao que o processo de qualidade pode ser verificado em fases e este pode aplicar determinados atributos de acordo com requisies e necessidades desta fase que sero verificados. O controle de qualidade ir monitorar o planejamento proposto de modo a verificar que os mesmos esto sendo seguidos. Uma equipe pode revisar a documentao e os processos utilizados para o desenvolvimento do software, verificando tambm os padres estabelecidos. Caso algum desvio seja percebido, este repassado para o gerente de projeto. Um outro modo de avaliao por automatizao de software, o que permite processar os documentos produzidos e o software de modo a gerar medies comparativas. Como a QA necessita de um modelo de processo de qualidade para ser aplicado, surge em 1991 o CMMI (Capability Maturity Model Integration), Integrao dos Modelos de Maturidade e Capacidade para Software, como modelo de qualidade para o processo de engenharia de software. Desde ento, as empresas tinham uma referncia para o desenvolvimento de softwares com qualidade (PRESSMAN, 2006).

2.8

CMMI

O CMMI (Capability Maturity Model Integration Integrao dos Modelos de Capacidade de Maturidade) surge como um modelo integrado de recomendaes, procedimentos e boas prticas que permite melhorar os processos e atividades organizacionais, abordando produtos desenvolvidos bem como servios prestados, nas fases de concepo, desenvolvimento, aquisio, entrega e manuteno, com a inteno de ser um framework de aprimoramentos de processos que tm aplicabilidade ampla por meio de uma variedade de empresas (SOMMERVILLE, 2007).

46

O modelo aborda tanto o nvel de maturidade de uma organizao quanto a capacitao de suas reas de processos, estabelecendo prioridades e implementando melhoria para estas. Deste modo, o modelo eleva o potencial das empresas permitindo que seus processos sejam revisados e controlados, atendendo as demandas do mercado e permitindo que as empresas possam desenvolver produtos com qualidade e com alto valor agregado. Este modelo possui duas abordagens para que as empresas possam implantar as recomendaes solicitadas. Estas abordagens vo ao encontro do perfil de cada empresa e estabelecem caractersticas prprias, as quais permitem as empresas escolherem entre uma abordagem ou outra. Estas abordagens foram definidas como: por Estgio e Contnua (SOMMERVILLE, 2007).

Figura 15 - reas de Processo na Representao Contnua e na Representao por Estgios

Fonte: CMMI para Desenvolvimento(2006, pg.42)

Como pode ser observada a seguir na Figura 15, a representao Contnua permite a empresa focar seus esforos para a melhoria de uma rea de processo em especfico que vai ao encontro com os objetivos estratgicos da organizao. No entanto, algumas reas de processo so dependentes de outras reas. Dessa maneira, um processo s poder ser aplicado se outro processo j estiver sido comtemplado. Analisando a representao por Estgio fica

47

claro a representao por nveis de maturidade, que seria o mesmo que o grau de domnio da empresa sobre os processos no qual o nvel aborda. possvel visualizar, como exemplo no Nvel de Maturidade 2, o conjunto de processos que este nvel aborda. Da mesma maneira, os demais nveis possuem um mesmo conjunto que vai ao encontro com a capacidade das empresas em cumprir os requisitos impostos por estes nveis. Embora o modelo contnuo permita uma empresa certificar por reas de processos separadamente, o modelo por estgio define que para um nvel ser contemplado a organizao deve cumprir satisfatoriamente os requisitos definidos para este nvel. S possvel passar para o nvel adiante a partir do momento em que o nvel abaixo foi contemplado. Todas as prticas estabelecidas por um nvel devem ser seguidas no nvel acima de modo que seja possvel chegar ao nvel 5 de maturidade. O Quadro 5 compara os nveis de capacidade entre as abordagens Contnua e por Estgio (CMMI para Desenvolvimento, 2006).

Quadro 3 - Comparao entre os Nveis de Capacidade e os Nveis de Maturidade. Representao Contnua Representao por Estgio Nvel Nveis de Capacidade Nveis de Maturidade Nvel 0 Nvel 1 Nvel 2 Nvel 3 Nvel 4 Nvel 5 Incompleto Executado Gerenciado Definido Gerenciado Quantitativamente Em otimizao No se aplica Inicial Gerenciado Definidio Gerenciado Quantitativamente Em otimizao

Fonte: Adaptado de CMMI para Desenvolvimento (2006, pg.33)

Como pode ser observado existem 4 nveis nas duas abordagens que so iguais e estes so aplicados da mesma forma. No entanto, o Nvel 0 da representao por Estgio no aplicado devido esta representao iniciar a partir do Nvel 1. Embora a representao por Estgio inicie no nvel 1, este nvel no garante capacidade de avaliao. Desta maneira, a representao por Estgio avaliada somente a partir no nvel 2.

De acordo com o CMMI para Desenvolvimento, a descrio de cada nvel dado abaixo:

0) Incompleto: Um objetivo ou um conjunto de objetivos especficos no so contemplados satisfatoriamente, no cumpre os requisitos estabelecidos.

48

1) Representao Contnua - Executado: O processo contempla todas as metas avaliadas em sua rea de processo. 1) Representao por Estgio - Inicial: Os processos neste nvel ainda no possuem um controle gerencivel de modo que possam ser controlados, na maioria das vezes extrapolam prazos e so definidos como caticos. 2) Gerenciado: este nvel define as prticas relacionadas a gesto dos processos na organizao, de modo que esta ainda est aprendendo o modo como os processos funcionam, assim como o gerenciamento dos projetos

desenvolvidos, necessitando aprender a estimar os custos e estabelecer uma base que fornea controle e gerenciamento efetivos. 3) Definido: O processo gerenciado e ajustado a partir de um definido pela organizao que, por sua vez, est em evoluo. 4) Gerenciado Quantitativamente: O processo definido e controlado atravs de mtodos qualitativos e quantitativos, focando atingir os objetivos quantificveis de desempenho dos processos e da qualidade dos mesmos. 5) Em otimizao: Processo quantitativamente gerenciado, estruturado para elevar os objetivos atuais e orientado para os negcios, evoluindo de maneira incremental possibilitando melhorias e inovaes, levando em considerao o surgimento de causas comuns de variaes originados por anlises.

Aps a abordagem das duas representaes de aplicao do CMMI, pode ser compreendido que a representao por estgios define que a empresa trabalhe os diferentes estgios de cada vez, de modo que esta aplicao possui direo ascendente. No entanto, a representao contnua permite que as empresas tenham maior flexibilidade e aprendizagem no modo como o modelo trabalha, permitindo dar maior nfase para uma determinada rea de processo da empresa.

2.9

MPS.BR (MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO)

O MPS.BR surge da necessidade de criar um programa que possui como principal objetivo o aprimoramento dos modelos de melhoria e avaliao dos processos de software, tendo como foco s micro, pequenas e mdias empresas, buscando atender s suas

49

necessidades de negcio e possuir reconhecimento como um modelo a ser seguido tanto nacional quanto internacionalmente.(SOFTEX, 2009). Este modelo constitudo por um conjunto de normas, as quais fornecem subsdios necessrios para a constituio do mesmo. Estas normas so: ISO/IEC 12207:2008 e ISSO/IEC 15504-2. Alm das normas como base para o modelo, este foi estruturado de acordo com o modelo CMMI, seguindo a mesma estrutura de definida por estgios ou nveis de maturidade. O modelo MPS formado por trs componentes os quais possuem definies prprias como mtodo de organizao do contedo utilizado, sendo definidos atravs de guias e documentos que constituem o modelo. De acordo com a SOFTEX, estes componentes so conhecidos como:

1) Modelo de Referncia (MR-MPS): a base para implementao do MPS nas empresas, sendo um guia de referncia que define os nveis de maturidade. Este contm os requisitos necessrios que as empresas devem seguir, a fim de alcanar os objetivos de negcio, atuais e futuros, estando em conformidade com os atributos de processo associado a cada nvel de maturidade. 2) Mtodo de Avaliao (MA-MPS): formado pelos processos, mtodos de avaliao, juntamente com os requisitos necessrios para os avaliadores do modelo. A base dos processos e mtodos utilizados est ligada a norma internacional ISSO/IEC 15504-2. 3) Modelo de Negcio (MN-MPS): Descreve as regras de negcio para implementao do MR-MPS pelas Instituies Implementadoras (II), avaliao seguindo o MA-MPS pelas Instituies Avaliadoras (IA), organizao de grupos de empresas pelas Instituies Organizadoras de Grupos de Empresas (IOGE) para implementao do MR-MPS e avaliao MA-MPS, certificao de Consultores de Aquisio (CA) e de programas anuas de treinamento do MPS.BR por meio de cursos, provas e workshops.

Assim como o modelo CMMI o MPS.BR est organizado sob nveis de maturidade, o qual estabelece 7 nveis, visando o atendimento das pequenas, mdias e grandes empresas, de modo que seja possvel implementar e avaliar estas sob o modelo. A escala de maturidade inicia no nvel G e ascende at o nvel A, de modo oposto ao CMMI que inicia no

50

nvel 1 e termina no nvel 5. O alcance de um determinado nvel de maturidade do MR-MPS obtido quando os requisitos propostos para este nvel so atendidos e satisfeitos, gerando os resultados esperados. O Figura 17 ilustra os 7 nveis de capacidade do MR-MPS em comparao com os nveis do modelo CMMI.

Figura 16 - Representao dos nveis de maturidade do modelo MR-MPS em relao ao CMMI

Fonte: http://qualidadebr.files.wordpress.com/

Os setes nveis representados pelas letras G A na Figura 16 definem cada nvel de maturidade, a descrio de cada nvel possui semelhana ao modelo CMMI. A seguir, o Quadro 4 define e descreve cada nvel de maturidade, comeando pelo nvel G.

Quadro 4 - Definio e descrio dos nveis de maturidade do modelo MR-MPS Nvel Nvel G Nvel de Maturidade Parcialmente Gerenciado Descrio - Este nvel composto pelos processos Gerncia de Projetos e Gerncia de Requisitos. - Este nvel composto pelos processos do nvel G, acrescidos com os processos de Aquisio, Garantia da Qualidade, Gerncia de Configurao, Gerncia de Portflio de Projetos e Medio.

Nvel F

Gerenciado

Continua na pgina seguinte.

51

Continuao do Quadro 4 - Definio e descrio dos nveis de maturidade do modelo MR-MPS - Este nvel composto pelos processos dos nveis de maturidade anteriores (G e F), acrescidos dos processos Avaliao e Melhoria do Processo Organizacional, Definio do Processo Organizacional, Gerncia de Recursos Humanos e Gerncia de Reutilizao. - Este nvel composto pelos processos dos nveis de maturidade anteriores (G ao E), acrescidos dos processos Desenvolvimento de Requisitos, Integrao do Produto, Projeto e Construo do Produto, Validao e Verificao. - Este nvel composto pelos processos dos nveis de maturidade anteriores (G ao D), acrescidos dos processsos Desenvolvimento para Reutilizao, Gerncia de Decises e Gerncia de Riscos. - Este nvel composto pelos processos dos nveis de maturidade anteriores (G ao C). O processo de Gerncia de Projetos evolui afim de satisfazer os requisitos deste nvel. Este nvel no possui processos Especficos. - Este nvel de maturidade composto pelos processos dos nveis de maturidade anteriores (G ao B). Este nvel evolui sob requisitos de processos que viso otimizar todas as suas etapas. Este nvel no possui processos especficos.

Nvel E

Parcialmente Definido

Nvel D

Largamente Definido

Nvel C

Definido

Nvel B

Gerenciado Quantitativamente

Nvel A

Em otimizao

Fonte: Adptado de (SOFTEX, 2009)

O programa MPS.BR em comparao com o CMMI permite que micros, pequenas e mdias empresas possam ter acesso a um modelo de melhoria de processos de modo que possa atender as solicitaes do mercado, a fim de competir com empresas de grande porte que adotam tanto o MPS.BR quanto o CMMI. Tendo como base CMMI, as empresas certificadas no MPS.BR possuem uma maior capacidade de implementar os processos definidos no CMMI como melhoria contnua, ao contrrio das empresas que ainda no so certificados por nenhuma melhoria de processo e tentam implementar o modelo na primeira vez. Portanto, o MPS.BR alm de garantir melhoria ascendente aos processos das empresas, facilita adoo do modelo CMMI, aprimorando continuamente os processos empresariais (SOFTEX, 2009).

52

2.10

GERNCIA DE PROJETOS

O gerenciamento de projetos pode ser entendido como uma atividade que visa controlar os recursos envolvidos em um projeto atravs da aplicao de conhecimento, habilidades, ferramentas e tcnicas a fim de atender aos seus requisitos. De acordo com o PMBOK, para obter uma organizao e controle sobre os processos de trabalho que so aplicados no gerenciamento de projetos, estes foram organizados em 5 grupos, sendo estes:

Processos de Iniciao: define e autoriza o projeto ou uma fase do projeto. Processos de Planejamento: define e refina os objetivos, o planejamento e a estratgia de implementao, assim como a programao das atividades, prazos, custos, riscos e formao da equipe.

Processos de Execuo: coordena as pessoas e recursos para execuo do plano do projeto. Processos de Monitoramento e Controle: mede e monitora regularmente o progresso do projeto visando identificar desvios em relao ao planejamento, de forma que possam ser implementadas aes corretivas para trazer o projeto de volta ao seu caminho planejado.

Processos de Encerramento: formaliza a aceitao dos produtos e servios entregues, ou qualquer outro resultado importante do projeto ou de uma fase.

Estes grupos de processo acompanham o ciclo de vida do projeto e esto organizados por fases em que em cada fase possui um conjunto de atividades a ser desenvolvida. Este modo de organizao facilita o gerenciamento do projeto e mantm os processos organizados. Cada empresa pode definir o ciclo de vida que ser utilizado em um determinado projeto. Algumas deixam a critrio da equipe que ir desempenhar o trabalho, em outras as restries do mercado e ramo de negcio definem qual modelo de ciclo de vida seguir (MARTINS, 2011). O ciclo de vida estabelece quais sero as atividades a serem realizadas em cada fase do projeto, definindo as entregas que so os produtos de cada fase e realizando a validao das mesmas, organizar os recursos humanos e mtodos de controle e aprovao para cada fase.

53

A Figura 17 ilustra o ciclo de vida do projeto comparando os Riscos e Recursos utilizados.

Figura 17 - Ciclo de vida do projeto

Martins(2011, pg. 6)

Como pode ser observado na Figura 17, o ciclo de vida do projeto definido de acordo com os grupos de processos citados anteriormente. No entanto, o grupo de monitoramento e controle ocorre ao trmino de cada fase, sendo este processo constante. Em cada fase definido um conjunto de atividades que sero realizadas. H dois fatores importantes que devem ser levados em considerao: os riscos e recursos. O risco no incio de um projeto grande, pois pode haver incertezas quanto ao desenvolvimento do produto e, ao mesmo tempo, podem ocorrer mudanas organizacionais, polticas e temporais que venham influenciar no mesmo. Estas ocorrncias tendem a serem reduzidas com o andamento do projeto, devido a estabilizao destes fatores. No entanto, os recursos utilizados aumentam na fase de construo ou realizao, sendo que, nesta fase, se obtm um produto concreto. Qualquer mudana significativa nesta fase, podendo ser por requisitos mal compreendidos, eleva o custo do projeto de tal maneira que este possa se torna invivel. Ao gerenciar projetos, devem ser levadas em considerao as partes interessadas no mesmo, de tal forma que estas podem influenciar continuamente no desenvolvimento do projeto, positiva ou negativamente. Algumas influenciam em fases especficas do projeto outras em todas as fases. Segundo definio do PMI, estas partes so chamadas de stakeholders (MARTINS, 2011).

54

Os stakeholders so divididos em: primrios e secundrios. Os primrios so aqueles que tm uma obrigao contratual ou legal com o projeto, enquanto que os secundrios so aqueles que tm apenas um interesse no projeto e no tm nenhuma relao formal. (MARTINS, 2011). Um projeto possui trs variveis que definem continuamente a qualidade do mesmo. Estas variveis so conhecidas como: escopo, prazo e custo. A representao destas trs variveis conhecida como Tringulo de ferro e representado pela Figura 18.
Figura 18 - Tringulo de ferro, com as principais variveis de um projeto.

Fonte: Martins(2011, pg. 120)

Como pode ser analisado na Figura 18, as trs variveis citadas encontram-se em destaque e estas esto diretamente ligadas, de tal forma que o estado de uma influencia a outra. Caso o escopo seja alterado, o prazo e o custo aumentam em proporo a alterao, ou, quando o prazo precisa ser reduzido, o escopo comprimido e o custo aumentado. As demais variveis se alteram em funo das variveis principais, sempre que estas sofrem alterao as outras precisam ser revisadas. Quando ocorre reduo no prazo de entrega, a equipe deve ser aumentada, caso queira manter o mesmo escopo. Neste caso, quanto maior for a equipe e mais dispersa, maior ser a necessidade de comunicao; quanto menor o prazo e maior a equipe, maiores sero os riscos. O nvel de qualidade ir depender do equilbrio destas variveis. A gerncia de projetos depende de planejamento e medidas para anlise e acompanhamento dos projetos, como por exemplo, o tringulo de ferro citado anteriormente. Neste contexto, ao gerenciar projetos frequentemente utilizado avaliar o perfil tpico do uso

55

de recursos e tempo durante as fases do projeto, que so relativamente padronizados (MARTINS, 2011). Deste modo a Figura 19 ilustra a representao do uso dos recursos e tempo em cada ase do projeto, acompanhando o ciclo de vida mostrado anteriormente na Figura 17.

Figura 19 Perfil de utilizao de recursos e tempo durante as fases do projeto

Adaptado de Martins (2005, p. 246)

Como pode ser observada na Figura 19, cada fase demanda de uma quantidade de esforo e tempo. Estas podem alterar de acordo com o perfil do projeto. No entanto, a proporo entre estas se mantm prximas. A fase de Concepo demanda menor tempo devido ser a fase em que o projeto iniciado, os requisitos principais so definidos e parcerias so realizadas. O esforo menor devido a quantidade a qualidade de recursos que so utilizados neste momento. A fase de Elaborao demanda um tempo maior que a fase de Concepo, pois nesta fase que os requisitos sero modelados, bem como a arquitetura do projeto ser definida. A quantidade de recursos aumenta em consequncia os esforos tambm. A fase de Construo a fase quando metade do tempo do projeto destinado. Da mesma maneira, a quantidade de esforos se concentra aqui, pois o momento em que o produto do projeto gerado, similarmente a fase de construo de um prdio. A fase de Transio, sendo a ltima fase, entrega o produto que foi construdo de tal maneira que o tempo e os recursos utilizados so analisados e o projeto mensurado. Utilizando um modelo interativo e incremental, esta fase entrega partes do produto final, de modo que, o projeto termina com o produto revisado em cada interao e seja obtida a qualidade desejada (MARTINS, 2005).

56

Portanto, gerenciar projetos uma atividade que pode ser desenvolvida atravs de organizao e disciplina, de tal maneira que os objetivos definidos sejam alcanados dentro do escopo previsto e que estes possam atender s necessidades das partes interessadas.

2.11

ORIENTAO A OBJETOS (OO)

A Orientao a Objetos surgem como um conceito evolutivo dos mtodos de programao, como um paradigma para substituio dos mtodos tradicionais, de modo que permitem melhorar o desenvolvimento de software, uma vez que, promovem a reutilizao de cdigo, facilitando e agilizando o desenvolvimento. Este tipo de paradigma utiliza os conceitos de objeto, que pode ser entendido como a abstrao de alguma coisa em um domnio de problemas, exprimindo as capacidades de um sistema de manter informaes sobre ela, interagir com ela ou ambos; um encapsulamento de valores e atributos e de seus servios exclusivos (LEITE, apud COAD E YORDON, 1991). Em comparao com os mtodos de programao estruturados, o modelo orientado a objetos segue o mesmo padro de leitura de cima para baixo. No entanto, a maneira como as linguagens orientadas a objetos (LOO) trabalham podem ser definidas como dinmicas, pois ao contrrio das linguagens de programao tradicionais, o modelo OO trabalha a leitura do cdigo e dos mtodos em tempo de execuo. Isto quer dizer que o cdigo interpretado medida que as chamadas no programa vo sendo requisitadas. Os benefcios da LOO permitiram a criao de bibliotecas de cdigos-fonte s quais so conhecidas como frameworks. Estes so compartilhados pela comunidade de desenvolvimento espalhada por todo o mundo, de modo que uma determinada funcionalidade desenvolvida por um conjunto de pessoas em um determinado pas, possa ser utilizada da mesma maneira por outras pessoas em outro pas. De modo que no haja necessidade de comear um trabalho do zero, e sim, que possa ser reaproveitado, como foi citado anteriormente, este um dos pilares deste paradigma.

2.12

UML (UNIFIED MODELING LANGUAGE)

A UML uma linguagem de modelagem que surgiu a partir dos conceitos da linguagem de programao orientada a objetos. Possui a finalidade de comunicar a estrutura

57

do sistema atravs de modelos visuais, os quais especificam e constroem o conceito do sistema que ser desenvolvido, permitindo documentar estes artefatos de modo que possam servir de referncia para as entidades envolvidas no projeto. Possui a capacidade de minimizar as falhas e dvidas no processo de desenvolvimento, ajudando a equipe a construir uma funcionalidade correta. (BOOCH, RUMBAUGH e JACOBSON, 2000). A UML formada por um conjunto de diagramas que representam graficamente os elementos que permitem visualizar o sistema de modo geral e especfico. Estes diagramas comunicam por diferentes maneiras uma viso do sistema. O interrelacionamento entre estes diagramas, fornece uma leitura mais objetiva, rica e clara a respeito do que deve ser desenvolvido. Entretanto, cada modelo pode ser utilizado independentemente, levando em considerao a necessidade de compreenso especfica do que deve ser entendido. De acordo com BOOCH, RUMBAUGH e JACOBSON (2000) os diagramas so apenas projees visuais, revelando um aspecto interessante especfico do sistema. Estes no so o final, mas o meio para compreenso de um todo. Os modelos podem ser utilizados para gerar cdigo escrito em diferentes linguagens, como Java e C#, e tabelas em banco de dados relacionais (MARTINS, 2011).

Figura 20 - classificao dos diagramas da UML

Adaptado de Fowler(2005, pg. 34).

Como ilustra Figura 20 os diagramas podem ser representados dividindo-se em dois grupos: Diagramas de comportamento e Diagramas de estrutura. Os diagramas de comportamento permitem representar de modo conceitual a execuo do sistema, enquanto os

58

diagramas de estrutura representam as caractersticas s quais envolvem os artefatos que esto ligados ao comportamento do sistema. Complementado a Figura 20 e possibilitando compreender a aplicao destes diagramas, a Figura 21 ilustra as cinco vises sobre a arquitetura do sistema, de modo que, pode ser o artefato mais importante a ser utilizados com o objetivo de gerenciar estes diferentes pontos de vista, tornando possvel controlar o desenvolvimento durante o ciclo de vida. BOOCH(2000).
Figura 21 Vises do sistema

Adaptado de Booch(2000, pg. 33)

A definio de cada viso descrita a seguir de acordo com BOOCH(2000). Viso do caso de uso: abrange os casos de uso que descrevem o comportamento do sistema conforme visto pelos seus usurios finais, analistas e pessoal de teste. Especifica as foras que determinam a forma da arquitetura do sistema. Os aspectos estticos desta viso so capturados em diagramas de caso de uso, enquanto os dinmicos por diagramas de interao, diagramas grficos de estados e diagramas de atividades. Viso do projeto: abrange classes, interfaces e colaboraes que formam o vocabulrio do problema e de sua soluo. Proporciona suporte aos requisitos funcionais, descritos na seo 4.6.4. Os aspectos estticos so captados por diagramas de classes e objetos, enquanto os dinmicos por diagramas de interao, diagramas de grfico de estados e diagramas de atividades.

59

Viso do processo: cuida principalmente de questes referentes ao desempenho, escalabilidade e aos processos que formam concorrncia e sincronizao do sistema. Os aspectos estticos e dinmicos so captados nos mesmos tipos de diagramas da viso do projeto, mas com foco voltado para classes ativas que representam processos. Viso de implementao: abrange os componentes e os arquivos utilizados para a montagem e fornecimento do sistema fsico. Envolve o gerenciamento da configurao das verses, compostas por componentes e arquivos. Os aspectos estticos so capturados em diagramas de componentes, enquanto os dinmicos em diagramas de interaes, grfico de estados e de atividades. Viso de implementao: abrange os ns que formam a topologia de hardware em que o sistema executado. Essa viso direciona principalmente a distribuio, o fornecimento e a instalao das partes que constituem o sistema fsico .Os aspectos estticos so capturados em diagramas de interaes, de grfico de estados e diagramas de atividades.

Portanto, a UML pode ser entendida como um conjunto de modelos interrelacionados ou independentes para modelagem de sistemas, facilitando a comunicao e entendimento das partes envolvidas, e possibilitando de tal forma compreender as regras de negcio e especificaes dos sistemas, abordando desde a fase de anlise de requisitos at as fases de desenvolvimento e testes finais (MARTINS, 2011).

2.13

SGBD (SISTEMA DE GERENCIAMENTO DE BANDO DE DADOS)

Um banco de dados (BD) uma coleo de dados relacionados (ELMASRI E NAVATHE, 2005). Estes dados so gerados por ocorrncias dirias, tais como: transaes comerciais, registro de notcias e desenvolvimento do conhecimento. Os mesmos precisam ser organizados de tal forma que o acesso a estes seja facilitado. Da mesma maneira, a arquitetura em que ficaro armazenados estes dados, deve permite que estes estejam seguros e que mantenham sua integridade mesmo com a ocorrncia de fenmenos externos. Como maneira de manipular estes dados de forma segura, surge o SGBD, constitudo por um conjunto de programas para acesso a estes dados, permitindo recuperar e armazenar de maneira eficiente os dados provindos do meio externo. Criado com o principal

60

objetivo de eliminar os problemas ocorridos por mtodos de armazenamento tradicionais, como por exemplo: inconsistncia e redundncia de dados, dificuldade de acesso, problema de integridade, controle de acesso concorrente e problemas de segurana. Os SGBDs so desenvolvidos para gerenciar um alto volume de informaes, de modo que isto implica na definio das estruturas de armazenamento das informaes e dos mecanismos de manipulao, mantendo a segurana das informaes contra eventuais problemas com o sistema, alm de manter um controle de acesso ao BD.( SILBERSCHATZ, KORTH e SUDARSHAN, 2008). A definio e restrio de uma base de dados so armazenadas em um catlogo do SGBD, que contm a estrutura de cada arquivo, o tipo e o formato de armazenamento de cada item de dado, alm de suas restries. Este conjunto de informaes definido como metadados e um dos principais meios no qual o SGBD trabalha para recuperar as informaes no BD. (ELMASRI E NAVATHE, 2005). A meta bsica de um SGBD proporcionar um ambiente conveniente e eficiente para recuperao e armazenamento de informaes e como principal objetivo proporcionar aos usurios uma viso abstrata dos dados (SILBERSCHATZ, 2008). De acordo com estas definies, o SGBD implementa suporte a definio, manipulao, integridade, segurana, recuperao e concorrncia dos dados, alm de otimizar a execuo e acesso, implementa o dicionrio de dados e melhora o desempenho (DATE, 2004).

61

METODOLOGIAS

De acordo com o tema deste projeto a metodologia seguida foi definida a partir dos seguintes tpicos:

Escolha dos processos a serem analisados; Anlise terica de cada processo; Definio dos sistemas a serem desenvolvidos; Utilizao do processo em Cascata, que foi aplicado no desenvolvimento do projeto da clnica Ayurvida Terapias Naturais;

Utilizao do processo em XP, que foi aplicado no desenvolvimento do projeto da empresa Tupi Negcios Imobilirios;

Utilizao do Processo em PU, que utilizado para o desenvolvimento do projeto de Controle Financeiro;

Planejamento para aplicao de cada processo nos sistemas definidos e desenvolvimento;

Execuo do desenvolvimento dos sistemas com base nas caractersticas de cada processo;

Avaliao do resultado do desenvolvimento de cada sistema com base na quantidade de alteraes e falhas encontradas;

Definio dos aspectos positivos e negativos de cada processo com base no produto final de cada sistema;

Resultado final com a escolha de um processo que obteve melhor resultado ao ser aplicado.

62

DESENVOLVIMENTO E APRESENTAO DOS RESULTADOS

Este captulo descreve as etapas seguidas no desenvolvimento dos sistemas que foram submetidos sob a anlise dos processos, Cascata, XP e PU, onde a estrutura de cada sistema ser apresentada de acordo com a metodologia exposta e seguindo os mtodos utilizados por cada processo.

4.1

CASCATA SISTEMA AYURVIDA

O processo de desenvolvimento Cascata foi definido neste documento no captulo 4 tpico 4.5.1. Para melhor entendimento do processo consulta a Figura 5.

4.1.1 Atividades da fase de definio de requisitos

As atividades concebidas pela fase definio de requisitos foram:

Levantamento de requisitos.

Esta atividade foi realizada atravs de uma reunio formal com o gerente da empresa Ayurvida Terapias Naturais, na pessoa de Paulo Henrrique Nunes Caixeta, o qual especificou quais eram as funcionalidades a serem desenvolvidas para o Website da empresa. O produto gerado por esta atividade foi o documento de especificao de requisitos, o qual est disponvel no APNDICE A deste relatrio. Como resultado deste documento foi possvel conceber as atividades restantes presentes nesta fase, sendo elas: Identificar os requisitos funcionais e no funcionais Listar os requisitos funcionais Modelar o Caso de Uso que visualiza o contexto do sistema

A Figura 22 ilustra este caso uso, o qual foi modelado a partir do levantamento de requisitos, onde possvel identificar as funes macro do sistema, identificando os atores que participam do sistema do Website da Ayurvida, demonstrando o limite deste sistema atravs de sua fronteira.

63

Figura 22 Caso de Uso que modela o contexto do sistema do Website Ayurvida

Fonte: Dados do trabalho

Como pode ser observado na Figura 22 o ator Usurio(Internauta) interage com os casos de uso Visualizar Contedo e Participar da Newsletter. O caso de uso Visualizar Contedo permitir ao Usurio(Internauta) navegar pelo contedo do site disponibilizado atravs do caso de uso que Controla o Contedo que gerenciado pelo ator Funcionrio da empresa. O Usurio(internauta) tambm participa do caso de uso Participar da Newsletter, o qual permite que o mesmo receba em sua caixa de e-mail informaes relacionadas ao dia a dia da empresa, sendo estas informaes manipuladas pelo caso de uso Controlar Newsletter que tambm gerenciado pelo Funcionrio da empresa. O Quadro 19 apresenta a descrio dos casos de uso do sistema do Website Ayurvida.

Quadro 5 - Descrio dos Casos de Usos do Sistema Web Site AYURVIDA

Caso de Uso Controlar Contedo

Descrio Este caso de uso permite que o Funcionrio da empresa controle e gerencie o contedo que ser inserido no sistema, bem como os usurios que utilizaro o mesmo. Este caso de uso permite ao ator Funcionrio da empresa controlar as funcionalidades disponveis na Newsletter.

Controlar Newsletter

Continua na pgina seguinte.

64

Continuao Quadro 6 - Descrio dos Casos de Usos do Sistema Web Site AYURVIDA

Visualizar Contedo

Este caso de uso permite ao ator Usurio (Internauta) visualizar e interagir com contedo do site, que gerenciado pelo caso de uso Controlar Contedo. Este caso de uso permite ao ator Usurio (Internauta) participar da Newsletter gerenciada pelo Funcionrio da empresa.

Participar da Newsletter
Fonte: Dados do Trabalho

Como resultado desta fase foi possvel compreender os seguintes tpicos:

As necessidades do cliente para a elaborao do sistema; As funcionalidades macro que controla o sistema em um todo; Os atores envolvidos e o modo de interao com as funcionalidades do sistema;

O documento de requisitos inicial atravs do diagrama de contexto, definio dos atores e casos de uso macro. Este documento est disponvel no APNDICE A e contm os casos de uso especficos e suas especificaes.

4.1.2 Atividades da Fase de Projeto e de Sistemas de Software

De acordo com os produtos gerados na fase de definio de requisitos, foram realizadas as seguintes atividades nesta fase:

Refinamento dos requisitos encontrados em cada requisito macro no diagrama de contexto; Modelagem e especificao dos casos de uso de cada requisito refinado, bem como a definio dos fluxos principal e alternativo de cada um, juntamente com a pr e ps condio e se h ocorrncia de requisitos no funcionais que caracterizam as particularidades do sistema. Elaborao do DER lgico do banco de dados do sistema, que permite identificar as entidades envolvidas no sistema e suas dependncias atravs do relacionamento das tabelas e seus atributos.

65

Criao do Template do Web site e do sistema gerenciador de contedo. Estes esto disponveis no Documento de Especificao de Requisitos disponvel no (APENDICE A).Finalizao do documento de especificao de requisitos. Como resultado da quebra dos casos de uso macro Controlar Contedo e refinamento dos requisitos, foi gerado uma lista de Requisitos Funcionais dos subsistemas, e como exemplo, apresentado a seguir no Quadro 21 a lista de casos de uso do subsistema Controlar Contedo.

Quadro 7 - Descrio das funes do subsistema Controlar Contedo

Requisito MANTER Usurios

Descrio Este caso de uso permite ao ator Funcionrio da empresa controlar os usurios que iro acessar o sistema que gerencia o contedo, permitindo realizar as funes CRUD e listar os usurios. Este caso de uso permite ao ator Funcionrio da empresa realizar as funes CRUD e listar as categorias de cadastradas. Estas categorias sero utilizadas no caso de uso Manter Postagens. Este caso de uso permite ao ator funcionrio realizar as funes CRUD e listar as postagens de acordo com as categorias cadastradas. Este caso de uso permite ao ator funcionrio realizar as funes CRUD na galeria de fotos e listar as galerias cadastradas. Este caso de uso permite ao ator funcionrio realizar as funes CRUD do lbum de fotos na galeria de fotos e lista-las.

MANTER Categorias

MANTER Postagens

MANTER Galeria de Fotos MANTER lbum

Fonte: Dados do Trabalho

Como descrito no Quadro 21 os usurios que tero acesso ao sistema so trabalhados atravs do caso de uso MANTER Usurios. a partir deste caso de uso que os outros casos de uso passam a realizar as suas funes no sistema, devido necessidade de controle de permisso para controlar o contedo que estar disponvel no site. A grande quantidade de informaes disponveis no Website da Ayurvida ser trabalhada atravs do caso de uso MANTER Postagens. O diagrama de caso de uso que define as funes deste subsistema ilustrado a seguir na Figura 23. Esta Figura precedida da especificao de requisitos deste caso de uso, onde definido o fluxo principal e os fluxos alternativos, bem como as pr e ps condies que executam no sistema e ao final da especificao composto pelas regras de negcio.

66

Como ilustrado na Figura 23 o caso de uso MANTER Postagens possui um <<include>> para a funo Listar Postagens, isto quer dizer que ao acessar este caso de uso ser executado em um determinado momento a funo Listar Postagens, que gera uma lista das postagens cadastradas, permitindo alterar ou excluir cada item da lista. Tambm compe este caso de uso um <<extend>> para a funo selecionar categoria, este <<extend>> pode ser executado em duas funes do MANTER Postagens, no cadastrar e alterar Postagem.

Figura 23 Caso de Uso MANTER Postagens

Fonte: Dados do Trabalho Quadro 8 Descrio do Caso de Uso MANTER Postagens

Identificao: CSU004 Mdulo: Gerenciar Contedo Descrio Resumida:

Nome do Caso de Uso: MANTER Postagens Funo: Programa Vinculado

Este caso de uso permite que o ator Funcionrio da empresa realize as funes CRUD na entidade Postagens. Atores: Funcionrio Empresa

67

Pr-condies: Deve haver pelo menos uma categoria cadastrada. Fluxo Principal: 1. 2. 3. 4. 5. 6. 7. 8. 9. Ator clica no menu Postagens.

Ps-condies: As informaes disponveis para serem visualizadas pelo Usurio(Internauta).

Sistema apresenta uma lista de Postagens cadastradas. Ator clica no boto Adicionar. Sistema apresenta tela para informar os dados da postagem. Sistema carrega as categorias cadastradas. Ator selecione uma categoria. Ator insere dados da postagem no formulrio. Ator clica no boto Cadastrar. Sistema emite a mensagem MSG001.

10. Sistema carrega a lista de postagens cadastradas. 11. O caso de uso encerrado. Fluxos alternativos: 3.1 Editar Postagens 3.1.1 Ator clica no boto Editar 3.1.2 Sistema carrega os dados da postagens para serem alterados 3.1.3 Ator altera os dados da postagem 3.1.4 Ator clica no boto Atualizar 3.1.5 Sistema emite a mensagem MSG002 3.1.6 Sistema retorna ao item 2. 3.2 Excluir Postagens 3.2.1 Ator clica no boto Excluir 3.2.2 Sistema emite a MSG003. 3.2.3 Ator clica no boto Sim. 3.2.4 Sistema emite a mensagem MSG004. 3.2.5 Sistema retorna ao item 2. Regras de Negcio:

Ao cadastrar uma postagem antes deve ter cadastrado uma categoria

Fonte: Dados do Trabalho

68

De acordo com o Quadro 22 o Fluxo principal composto pela atividade de realizar cadastro, pode ser observado no item 2 deste fluxo que o <<include>> executado neste momento ao listar as Postagens. Da mesma maneira o <<extend>> para a funo Selecionar Categoria executado no item 6. Este caso de uso ainda possui dois fluxos alternativos, sendo o Editar Postagens e Excluir Postagens, disponveis a partir das postagens listadas. O respectivo DER lgico que armazena as informaes geradas por este caso de uso pode ser visualizado a seguir na Figura 24, composto pelas tabelas Postagem e Categoria atravs de um relacionamento 1:N um para muitos entre a tabela Categoria e tabela Postagem.

Figura 24 Relacionamento das Entidades Postagem e Categoria presentes no DER lgico do sistema

Fonte: Dados do trabalho

A tabela Categoria caracteriza nenhuma ou vrias postagens atravs da sua descrio, representado pela coluna DescricaoCategoria, a qual identificada na tabela postagem atravs do IdCategoria, sendo esta coluna uma chave estrangeira da ligao entre Categoria e Postagem. A coluna IdPostagem chave primria na tabela Postagem e identifica nica e exclusivamente uma Postagem. A tabela Postagem tambm composta por outra chave estrangeira IdPessoaUsuario que identifica o usurio que realizou a Postagem, sendo este usurio definido como Autor da Postagem na aplicao. Um exemplo seria definir uma Categoria com a descrio de Terapias Ayurvdicas e para esta categoria realizar vrias

69

Postagens relacionada ao assunto Terapias Ayurvdicas. O DER completo do sistema est disponvel no Documento de Especificao de Requisitos no APNDICE A. Ao final desta fase foi possvel desenvolver a viso geral do projeto do sistema do Website da Ayurvida que pode ser visualizado na Figura 25. Esta Figura representa o funcionamento da Internet atravs das requisies e respostas HTTP adaptado pelo sistema do Website da Ayurvida, o qual o ator Funcionrio da empresa alimenta a base de dados no servidor da Ayurvida atravs do sistema que gerencia o contedo do site, representado pelo caso de uso macro Controlar Contedo, onde estas informaes sero recuperadas no momento em que o Usurio(Internauta) acessar o site, estando representado esta interao pelo caso de uso Visualizar Contedo e tambm podendo enviar seus dados para participar da Newsletter, onde so armazenados na base de dados do servidor da Ayurvida e recuperados pelo Funcionrio da empresa, representando os casos de uso macro Participar da Newsletter e Controlar Newsletter consecutivamente.
Figura 25 Viso geral do Sistema do Website da Ayurvida

Fonte: Dados do Trabalho

4.1.3 Atividades da fase de construo da Implementao e teste de Unidade

Toda esta fase foi concebida de acordo com as atividades desenvolvidas na fase de projeto, seguindo fortemente a arquitetura que permite ter uma viso geral do sistema exemplificada na Figura 25.

70

Foi realizada a programao do sistema com base no Documento de Especificao de Requisitos disponvel no APENDICE A e a gerao do banco de dados fsico do sistema. A Figura 26 ilustra a tela que representa o caso de uso MANTER Postagens, onde a partir desta possvel executar as aes do fluxo principal e fluxos alternativos definidos no documento de especificao de requisitos. As marcaes 1, 2 e 3 representam no caso de uso MANTER Postagens as funes CRUD disponveis atravs do boto de cada marcao numerada, sendo elas:

1. Boto Adicionar: representa o fluxo principal do caso de uso, chama uma nova tela para Cadastrar Postagens. 2. Boto Editar: representa o Fluxo Alternativo 3.1 Editar Postagens. 3. Boto Excluir: representa o Fluxo Alternativo 3.2 Excluir Postagens

A marcao 4 representa o <<include>> Listar Postagem e est sendo referenciada no Fluxo Principal item 2, mostrando que toda vez que est tela for acessada, ser mostrada a lista de Postagens cadastradas.

Figura 26 Pgina Gerenciar Postagem, resultado do caso de uso MANTER Postagens

Fonte: Dados do trabalho

O cdigo fonte que implementa o caso de uso Listar Postagem pode ser visualizado a seguir no Quadro 23. A linha 10 representa uma instanciao de uma conexo com o banco de dados atravs da varivel $conexao que passada como parmetro ao

71

instanciar a classe PostagemRepository, qual possui os mtodos CRUD referente tabela Postagem ilustrada na Figura 26. Uma varivel $rs criada para receber os dados da consulta executado pelo objeto $ModelPostagem onde so retornados todos os registros de Postagem existentes na tabela. Uma varivel $row criada para verificar se foi retornado algum registro ou linha de dados da tabela, caso tenha retornado, estes dados so escritos dentro da tabela que gera a lista de registros de postagens, referente ao <<include>> Listar Postagem.

Quadro 9 Cdigo Fonte responsvel pela funo Listar Postagem

1. <?php 2. session_start(); 3. require('../../../util/seguranca.php'); 4. Seguranca::VerificaAutenticacao(); 5. 6. require('../../../conexao.php'); 7. require('../../../funcoes.php'); 8. require('../../../models/PostagemRepository.php'); 9. 10. $conexao = new Conexao(); 11. 12. $ModelPostagem = new PostagemRepository($conexao); 13. $rs = $ModelPostagem->getTodos(); 14. $row = mysql_num_rows($rs); 15. 16. if ($row > 0) { 17. <!-- inicio center_content --> 18. <div class="center_content"> 19. <div id="efeito"> 20. <table width="auto" id="resultado" cellpadding="1" cellspacing="1" style="ma rgin-left:4px;"> 21. <thead> 22. <td class="titis_tabs">Registros</td> 23. <td width="6%" align="center" class="titis_tabs">Editar</td> 24. <td width="6%" align="center" class="titis_tabs">Excluir</td> 25. </thead> 26. 27. <?php while ($obj = mysql_fetch_object($rs)){ ?> 28. <tr id="linha">

Fonte: Dados do trabalho

72

Ao clicar no boto Adicionar ser carregada a tela cadastrar Postagem que pode ser visualizada a seguir na Figura 27.

Figura 27 Pgina Gerenciar Postagem, resultado do caso de uso MANTER Postagens

Fonte: Dados do trabalho

A Figura 27 ilustra o processo do Fluxo Principal do Caso de Uso Manter Postagem, representando os passos de 4 a 7 deste caso de uso. Ao carregar a pgina o sistema lista as opes referentes as categorias cadastradas que so armazenadas na tabela Categorias, demonstrada anteriormente na Figura 26. Aps salvar os dados so validados e posteriormente salvo no banco de dados na tabela Postagem. O cdigo fonte responsvel por cadastrar os dados no banco de dados apresentado a seguir no Quadro 24.

Quadro 10 Cdigo Fonte responsvel pela funo Cadastrar Postagem

1. <?php 2. class PostagemRepository 3. { 4. private $conexao; 5. public function PostagemRepository($conexao) 6. { 7. $this->conexao = $conexao; 8. } 9. public function incluir($titulo, $titulo_home, $sintese, $data_inicio

73

, $data_fim, $texto) 10. { 11. $this->conexao->AbreConexao(); 12. $this->conexao->SelecionaBanco(); 13. $sql ="Insert into Postagem (titulo, titulo_home, sintese, data_inicio, data_fim, texto) 14. values ('$titulo', '$titulo_home', '$sintese', '$data_inicio', '$data_fim', '$texto')"; 15. return mysql_query($sql); 16. 17. } 18. public function alterar_imagens($id, $img_principal, $img_lat_um, $ img_lat_dois) 19. { 20. $this->conexao->AbreConexao(); 21. $this->conexao->SelecionaBanco(); 22. $sql ="Update Postagem set img_principal='{$img_principal}', 23. img_lateral_um='{$img_lat_um}', 24. img_lateral_dois='{$img_lat_dois}' 25. Where id= $id;"; 26. return mysql_query($sql); 27. } 28. ?>

Fonte: Dados do Trabalho

Aps validar os dados do formulrio o mtodo public function incluir disponvel na linha 9 invocado recebendo como parmetro os dados do formulrio onde so concatenados pelo comando sql disponvel na linha 13. Caso exista imagens passadas no formulrio chamado o mtodo alterar imagens, disponvel na linha 18 o qual ir atualizar a tabela Postagem com o nome das imagens passadas no formulrio comparando com o Id gerado pelo mtodo incluir executado na linha 9. Realizado a insero no banco de dados o sistema retorna a mensagem de dados cadastrados com sucesso, encerrando o caso de uso. Os testes unitrios realizados ao longo do desenvolvimento do sistema foram satisfatrios, no havendo qualquer problema encontrado como resultado por estes.

74

4.1.4 Integrao e Teste de Sistema

Como atividades da fase de Integrao e Teste de sistema foi realizado a instalao do site no servidor web da empresa Ayurvida, bem como a instalao do banco de dados fsico. A atividade de integrao foi concluda com xito. Entretanto a fase de Teste do Sistema foi aplicado de duas formas. A primeira foi realizar os testes relacionados aos casos de uso macro que possui interao com o Funcionrio da empresa. Neste teste foi encontrado uma falha ao rodar a lgica de acesso ao sistema no servidor web online. A falha encontrada estava na lgica que controla o login do usurio no sistema, como neste estava sendo utilizado tecnologia Ajax para validar os dados no servidor, o retorno da mensagem de validao no era executada da maneira correta, alm de possuir vulnerabilidade no aspecto de segurana do sistema. Dessa maneira optou-se por mudar a lgica e utilizar os mtodos convencionais de validao de usurio, onde uma requisio enviada ao servidor e toda a pgina carregada novamente com a resposta do mesmo, dessa maneira alguns elementos da pgina so carregados novamente. A segunda parte foi realizar os teste relacionados aos casos de uso macro que possui interao com o ator Usurio(internauta). Os testes realizados foram executados com xito.

4.1.5 Operao e Manuteno

Esta fase foi executada com a correo de erros necessrios antes da entrega para o cliente. Foi realizado uma reunio formal com o gerente da clnica Ayurvida na pessoa de Paulo Henrrique Caixeta, para apresentao e entrega do Website de acordo com os requisitos levantados na Fase de Requisitos. Foram avaliadas as funcionalidades desenvolvidas resultando na solicitao de alterao das mesmas e acrscimo de novas funcionalidades. Estas funcionalidades esto descritas no Quadro 25 juntamente com a anlise de viabilidade de quais solicitaes so necessrias serem implementadas de imediato e quais sero postergadas para manutenes futuras, levando em considerao os aspectos de usabilidade, necessidade e tempo para manuteno. Como resultado desta manuteno ser gerado uma nova verso do documento de especificao de requisitos. O cronograma completo do desenvolvimento do Website AYURVIDA pode ser visualizado no APNDICE A deste relatrio.

75

Quadro 11 Cronograma de Alteraes

DATA 26/07/2011 26/07/2011 26/07/2011 26/07/2011 26/07/2011

ALTERAO Opo de Clique para udio ex.: (clique e acalme-se). Efeito Fade slides Logo, mudana identidade visual. Mapa do Site Mudanas chamadas principal HOME (Boxes): Cotidiano Ayurvida; Agenda 2 semestre 2001; Dicas de Bem Viver; Artigos.

APROVADA SIM SIM SIM SIM SIM

26/07/2011

Imagem Slides (Yoga, AYURVIDA, Constelaes em uma s imagem).

SIM

26/07/2011

Boxs HOME: Ttulo em Negrito; Datas da cor do box; Texto em Cinza.

SIM

26/07/2011 26/07/2011 26/07/2011 26/07/2011 26/07/2011 28/07/2011 28/07/2011

Horrios somente com a hora registrada Acrescentar teste DOSHA no site Acrescentar gif com sol mexendo no horrio Cadastrar msica atravs do gerenciador rea atendimento online Link com tooltip nos menus com saiba mais Colocar imagens mais distribudas no Espao Patos de Minas

SIM SIM SIM SIM NO NO SIM

28/07/2011

Acrescentar FITOTERAPIA no menu SATHYA CULINRIA

SIM

28/07/2011

Acrescentar dentro de ALIMENTOS NATURAIS, onde encontrar

SIM

28/07/2011 28/07/2011

Adicionar lado direito do site banners dos Parceiros Email de contato ser: contato@ayurvidaterapias.com.br

SIM SIM

Continua na pgina seguinte.

76

Continuao Quadro 25 Cronograma de Alteraes 28/07/2011 Alterar frase de Agradecimento para: (Obrigado por entrar em contato conosco) 28/07/2011 28/07/2011 Acrescentar flash ou gif no menu CONTATO Acrescentar Redes Sociais: Canal YouTube; Twitter; Facebook; Google Mais.
Fonte: Dados do Trabalho

SIM

SIM SIM

4.2

XP EXTREMA PROGRAMAO SISTEMA TUPI

O processo de desenvolvimento XP foi definido neste documento no captulo 4 tpico 4.5.4. Cada uma das fases deste processo ser detalhada a seguir de acordo com os mtodos utilizados em cada uma. Para maior entendimento de cada fase, consulte a Figura 7 disponvel neste documento.

4.2.1 Atividade da Fase de Planejamento

A Fase de Planejamento foi iniciada com uma reunio formal com o diretor da empresa Tupi Negcios Imobilirios, na pessoa de Joo Wander da Silva, para realizar o levamentamento de requisitos do sistema, o que para o XP conhecido como histrias do usurio. A partir deste levamento, os requisitos foram organizados em cartes de histrias. Foi realizada uma segunda reunio para determinar a ordem destes cartes como prioridade para o desenvolvimento, onde tanto o cliente quanto a equipe de desenvolvimento, definiram o valor de cada histria resultando na ordem destes cartes para dar incio a primeira iterao de desenvolvimento do produto. Todos os cartes de histrias esto disponveis no documento de especificao de requisitos que se encontram no APENDICE B deste documento, juntamente com os cartes de histrias impressos utilizados na reunio para definir a ordem de prioridade de desenvolvimento.

77

Com base nos cartes de histrias foi possvel definir o escopo inicial do sistema que apresentado na Figura 28 atravs do caso de uso que modela o contexto.

Figura 28 Caso de Uso que modela o Contexto do Sistema Tupi Negcios Imobilirios

Fonte: Dados do Trabalho

De acordo com a Figura 28 o sistema web da empresa Tupi Negcios Imobilirios possui 3 atores e 5 casos de uso macro. O ator Cliente participa dos casos de uso Visualizar Contedo - referente ao contedo institucional disponvel no site e Acessar rea Restrita, o qual possui as informaes de compra de loteamento para serem visualizadas. O ator Funcionrio Administrador interage com os casos de uso Gerenciar Informaes de Contedo - referente ao contedo que ficar disponvel no site para o cliente visualizar - Manter Usurios controle dos usurios que tero acesso ao sistema Realizar Pesquisas e Listagens referente as informaes disponveis no sistema local da empresa. O ator Gerente interage com o caso de uso Realizar Pesquisas e Listagens, referente as informaes disponveis no sistema local da empresa. A descrio dos atores do sistema e os casos de uso macro so apresentados a seguir nos quadros 26 e 27 respectivamente.

78

Quadro 12 Descrio dos Atores do Sistema Tupi Negcios Imobilirios

Ator Cliente

Descrio Este ator tem a opo de visualizar o contedo do site e visualizar as informaes da rea restrita.

Funcionrio Administrador

Este ator tem a responsabilidade de realizar a Matriz CRUD no caso de uso Gerenciar Contedo, e ainda realizar as tarefa de Matriz CRUD tambm no MANTER Usurio e Realizar Pesquisa e Listagens referentes s informaes cadastradas no Sistema.

Gerente

Este ator tem a responsabilidade de Realizar Pesquisa e Listagens referentes s informaes cadastradas no Sistema.

Fonte: Dados do Trabalho

Quadro 13 - Descrio dos Casos de Uso do Sistema Tupi Negcios Imobilirios

Caso de Uso Visualizar Contedo

Descrio Este caso de uso possibilita o cliente visualizar e interagir com contedo do site.

Acessar rea restrita

Este caso de uso possibilita o cliente visualizar sua rea restrita no site.

Gerenciar Informaes Contedo MATER Usurio

Este caso de uso possibilita o ator Funcionrio Administrativo, cadastrar, listar, alterar e excluir dados do sistema.

Este caso de uso permite o ator Funcionrio Administrativo, realizar as tarefas CRUD e listar os Usurios.

Realizar Pesquisas e Listagens

Este caso de uso permite o ator Funcionrio Administrativo e o Gerente a visualizar as informaes cadastradas no sistema referentes ao dados do cliente.

Fonte: Dados do Trabalho

A primeira iterao do sistema foi definida com base na necessidade de negcio da empresa em atender especificamente quem a alimenta, neste caso o prprio cliente. Para tanto, a primeira iterao definida foi desenvolver o acesso do ator Cliente as informaes de compra do loteamento. Esta iterao foi definida pela escolha do carto de histria Cliente que j comprou o loteamento, que composto por outros requisitos que formam a base deste. O carto de histria da primeira iterao pode ser visualizado a seguir pela Figura 29, que ilustra a estrutura de um carto de histria composto pelo Nome do Projeto -

79

Empresa Tupi Negcios Imobilirios, Ttulo do Carto - Cliente que j comprou loteamento, Descrio - O que deve ser feito nesta iterao e os requisitos funcionais que devem desenvolvidos.

Figura 29 Primeiro Carto de Histria escolhido pelo cliente

Fonte: Dados do Trabalho

De acordo com a Figura 29 que representa a primeira iterao o cliente ter acesso rea administrativa do cliente que dever conter informaes do mesmo relacionadas compra, que ser acessada atravs do CPF e Senha, sendo possvel visualizar as parcelas geradas pelo contrato, realizar a impresso dos boletos para pagamento, imprimir segunda via do contrato e listar as informaes do mesmo. Definido o plano de iterao, a prxima fase no processo XP e a elaborao do projeto para o carto de histria definido.

4.2.2 Atividade da fase de Projeto

As atividades desenvolvidas na fase de projeto podem ser definidas em 3 etapas compostas por: Desenvolvimento do DER lgico do bando de dados Desenvolvimento das Triggers

80

Desenvolvimento do Prottipo da Tela Administrativa do Cliente Viso Geral inicial do funcionamento do sistema

Para o desenvolvimento do DER lgico foi utilizado o Case Studio como ferramenta para elaborar os relacionamentos entre as tabelas do banco, bem como na gerao do script SQL para posteriormente execuo no banco de dados. Foi levado em considerao ao criar os campos de cada tabela o mesmo tipo de dado existente no banco de dados do sistema local da empresa, para que no momento em que os dados fossem populados neste banco no houvesse erros de tipos de dados. A seguir a Figura 30 ilustra o DER do banco de dados.
Figura 30 DER do Sistema Tupi Negcios Imobilirios

Fonte: Dados do Trabalho

Como pode ser visualizado na Figura 30 o DER do Sistema Tupi Negcios Imobilirios composto por 7 tabelas, onde a tabela ClienteWeb possui um relacionamento de 1:N com a tabela Endereco, sendo o campo Codigo_Cliente chave primria(PK) na tabela ClienteWeb e chave estrangeira(FK) na tabela endereo. A tabela ClienteWeb faz ligao com a tabela Usuario onde possui relacionamento de 1:1, neste caso um cliente um usurios, sendo identificado pela PK Cdigo_Cliente, desta maneira a tabela Usuario armazena alm

81

da chave primria e estrangeira(PFK) a Senha de acesso do cliente ao sistema. Alm destes relacionamento a tabela ClienteWeb relacionada com a tabela VendaWeb por um relacionamento de 1:N, neste caso o ClienteWeb pode possui mais de uma venda. A PK Codigo_Cliente passa para a tabela VendaWeb como FK, identificando assim o cliente que possui a venda. A tabela VendaWeb ainda possui um relacionamento de 1:N com a tabela ParcelaWeb, no qual uma venda possui vrias parcelas, sendo a parcela identifica pela FK IdVenda que referente a PK IdVenda da tabela VendaWeb. Ainda a tabela VendaWeb composta por outro campo o IdLote, sendo uma FK do relacionamento de 1:N entre LoteWeb com VendaWeb, onde uma venda pode conter vrios lotes. Uma vez que a estrutura do banco de dados lgico estava pronta, foi possvel montar as Triggers. As Triggers so utilizadas como tarefas que so executadas pelo prprio banco de dados, neste caso toda vez que o sistema local da empresa Tupi efetuar algum tipo de funo CRUD nas tabelas que contm as informaes para popular as tabelas do banco de dados online, estas Triggers sero executadas. A seguir na Figura 31 pode ser visualizado o cdigo que cria a Trigger para inserir os dados na tabela ParcelaWeb.

Figura 31 Trigger Insere Parcela Web

Fonte Dados do Trabalho

Ao visualizar a Figura 31 podemos identificar alguns comandos importantes na criao da Trigger, so eles: CREATE TRIGGER define o nome de criao da Trigger AFTER INSERT ON define a condio para execuo da Trigger, neste caso depois da execuo de um comando Insert sobre a tabela Parcela FOR EACH ROW insert into define que para cada linha inserida na tabela Parcela ser realizada uma insero no banco de dados imobiliariaweb na tabela parcelaweb sendo passado os valores que foram inseridos na tabela anterior.

82

Criando o projeto focado no carto de histria definido para a primeira iterao, o prximo passo foi criar o prottipo da interface que o cliente ir visualizar ao acessar o sistema que disponibiliza as informaes de compra do lote. Este prottipo tem como base todos os requisitos definidos no carto de histria ilustrado na Figura 29. A Figura 32 ilustra este prottipo.

Figura 32 Prottipo da Tela Cliente que j possui loteamento

Fonte: Dados do Trabalho

O prottipo ilustrado na Figura 32 pode ser dividido em 5 partes de acordo com os requisitos solicitados na Figura 29. Essas partes so descritas a seguir:

Dados do cliente recuperados da tabela ClienteWeb ao validar o usurio comparando com os dados da tabela Usurio; Dados referente as parcelas geradas pela compra do lote. Estes dados so recuperados a partir do campo Codigo_Cliente que compes a tabela VendaWeb e por sua vez possui o relacionamento com a tabela ParcelaWeb citado anteriormente na Figura 29;

Lista de parcelas a serem quitadas. Esta lista obtida atravs de todos os registros encontrados na tabela ParcelaWeb onde o IdVenda desta comparado com o IdVenda da tabela VendaWeb.

83

Formulrio de contato para solicitao da 2 via do contrato gerado pela compra do lote e demais solicitaes;

Boto Imprimir Boleto disponvel para que ao selecionar uma parcela listada, ao pressionar o mesmo possa ser gerado o boleto referente esta parcela. Boto Marcar todos permite selecionar todos os itens listados para que possa ser gerado as parcelas destes itens selecionados. Boto Desmarcar todos permite desmarcar os itens selecionados na lista de parcelas.

4.2.3 Atividade da Fase de Codificao

De acordo com os resultados desenvolvidos na fase de projeto, as atividade da fase de codificao foram realizadas seguindo a implementao fsica do DER, a implementao do sistema e refatorao do cdigo fonte. A implementao do sistema foi baseada no padro de projeto MVC (Model, View, Controller). Este padro tem como finalidade dividir a aplicao em camadas, facilitando o entendimento do cdigo fonte e agilizando manutenes futuras , uma vez que a lgica da aplicao, o acesso aos dados e a interface com o usurio definida em camadas diferentes. A Figura 33 representa o fluxo de atividades do padro MVC.

Figura 33 - Fluxos de atividades do padro MVC.

Fonte: Dados do trabalho

84

Com base na Figura 33 so definidas abaixo as camadas que compe o MVC de forma simplificada: Camada Modelo (Model) possui o cdigo referente a lgica da aplicao, como mtodos e regras de negcio, bem como as entidades da aplicao; Camada Viso (View) possui o cdigo referente a interface com o usurios, onde cada usurio requisita e recebe os dados da aplicao; Camada Controlador (Controller) possui o cdigo que faz a unio entre a camada Modelo e a Viso, controla a passagem de dados entre a Viso e o Modelo e vice-versa.

Foram utilizados um conjunto de 3 Frameworks integrados para facilitar no processo de desenvolvimento deste projeto. Estes frameworks so conhecidos como: Jarchitecture, Hibernate e VRaptor.

O Jarchitecture um framework baseado no padro MVC, possui a implementao de outras camadas que ser mostrada adiante. A partir de um arquivo com extenso .dmx que gerado pelo software de criao do banco de dados lgico, este processado pelo Jarchitecture que verifica quais foram as tabelas criadas no banco de dados e suas restries, e a partir destas informaes gera o cdigo da aplicao organizado em camadas. As camadas geradas por este framework e utilizadas neste projeto so apresentadas a seguir na Figura 34.

Figura 34 Camadas geradas pelo framework Jarchitecture

Fonte: Dados do trabalho

85

A descrio de cada camada gerada pelo framework Jarchitecture e exibidas na Figura 34 so listadas e definidas a seguir:

Camada Business (Negcio): esta camada possui as entidades de

negcio que foram extradas do arquivo .dmx do banco de dados. Representa as tabelas do banco de dados mapeadas como classes em Java, contendo as restries de valores definidos para cada campo da tabela. Camada Data (Dados): esta camada possui um modelo de funes

CRUD para acessar o banco de dados. responsvel por controlar a conexo com o banco de dados sempre que uma funo CRUD for executada por qualquer entidade de negcio. Esta camada comunica com a camada Business. Camada Application (Aplicao): esta camada possui os mtodos e

regras de negcio da aplicao. Comunica com as camadas Data e Business, recebe os dados passados pelo controlador e envia os dados retornados da camada Data.

Camada Web (Controlador): esta camada responsvel por realizar o

controle dos dados entre a viso e a camada de aplicao. Gerenciando o que o usurio solicita e as repostas que devem ser enviadas para o mesmo. Esta camada importa todas as outras camadas e comunica somente com a Application. Neste modelo caso fosse necessrio desenvolver a mesma aplicao para Desktop ou Mobile, seria necessrio trabalhar somente na camada Web (Controller) pois as regras de negcio da aplicao e o acesso a dados ficam em camadas diferentes.

O Hibernate um framework ORM(Object Relational Mapping) que realiza o mapeamento objeto relacional entre as tabelas do banco de dados e a aplicao. Este framework compe a arquitetura do framework Jarchitecture e o resultado desta composio so as classes que esto localizadas na camada Business, bem como o arquivo de configurao do Hibernate que contm o mapeamento das classes com suas respectivas tabelas do banco de dados.

86

A estrutura do arquivo de configurao do Hibernate representada a seguir na Figura 35.

Figura 35 Camadas geradas pelo framework Jarchitecture

Fonte: Dados do trabalho

Como caractersticas do Hibernate pode ser visualizado na Figura 35 da linha 16 at a 19 a definio do mapeamento das classes da aplicao. Um outro recurso importante do Hibernate que uma vez gerado as classes da aplicao de acordo com o banco de dados, no h necessidade em uma instalao configurar o banco de dados manualmente. Na linha 8 ao passar o caminho do banco de dados verificado se o mesmo existe, caso no existe o Hibernate cria o banco de dados e as respectivas tabelas de acordo com as classes mapeadas.

O outro framework utilizado o VRaptor, este framework compe a camada Web (Controller) . Possui a responsabilidade de controlar a aplicao e funciona da seguinte maneira: Todas as classes controller possuem o nome da classe junto com Controller, sendo ClienteController Cada pgina jsp requisitada um mtodo na classe Controller, dessa maneira uma pgina como o nome de alterarSenhaFormulario.jsp, possue um mtodo corresponde com o mesmo nome na classe Controller.

87

Para exibir uma pgina que altera a senha do cliente a url seria a seguinte: www.tupi.com.br/cliente/alterarSenhaFormulario, o VRaptor vai interpretar essa url como, www.tupi.com.br a pasta raiz da aplicao, cliente um controlador que existe na pasta raiz, neste caso ClienteController e a requisio da pgina alterarSenhaFormulario interpretado como um mtodo dentro da classe ClienteController.

A viso geral deste funcionamento pode ser visualizado a seguir na Figura 36 com os arquivos gerenciados em destaque.

Figura 36 Arquivos controlados pelo VRaptor

Fonte: Dados do trabalho

De acordo com a explicao do VRaptor anteriormente, ser mostrado a seguir na Figura 37, o cdigo referente a requisio da pgina principal que contm os dados de compra do lote pelo cliente.

88

Figura 37 Cdigo fonte que retorna as informaes da venda para o cliente

Fonte: Dados do trabalho

De acordo com a Figura 37, o mtodo ndex() possui um conjunto de operaes para retornar as informaes para o cliente. A linha de nmero 179 retorna para a pgina ndex um objeto cliente atravs do mtodo result.include(), onde busca os dados do cliente em um outro mtodo chamado busca(). A partir da linha 181 at 186 criado uma consulta na tabela parcela onde passado como parmetro uma venda que contm o cliente que efetuou o login no sistema. Uma vez que foi retornado uma lista de registro de parcelas verificado da linha 188 at 191 o total de parcelas que foram pagas. Finalizando o mtodo ndex() foram executados trs mtodos result.include(), sendo enviado para pgina ndex do cliente a quantidade parcelas pagas, o total de registro de parcelas e uma lista contedo os dados de todas as parcelas. O mtodo que retorna a lista de parcelas executado ao passar pela linha 186, onde chamado o mtodo listarParcelaWeb() na classe ParcelaWebApplication atravs de um objeto que contm os critrios para execuo da consulta pelo Hibernate. A Figura 38 exibe o mtodo listarParcelaWeb() na classe ParcelaWebApplication.
Figura 38 Cdigo fonte que retorna uma lista de parcelas

Fonte: Dados do trabalho

O parmetro com os critrios da consulta so passados no mtodo e retornado pela execuo do mtodo find(criteria), que executado na classe ParcelaWebRepository que se encontra na camada Data. Esta classe extende a classe que possui os mtodos CRUD e

89

implementa a interface com a assinatura dos mtodos, passando como parmetro o tipo de objeto que neste caso referente a uma entidade de negcio que se encontra na camada Business, sendo ento a classe ParcelaWeb. A Figura 39 exibe esta ocorrncia.

Figura 39 Cdigo fonte da classe ParcelaWebRepository

Fonte: Dados do trabalho

E por fim o cdigo da classe Repository que recebe um tipo de objeto para ser trabalho, esta classe uma classe genrica e ser exibida a seguir na Figura 40, possui todos os mtodos referente a matriz CRUD para execuo no banco de dados.
Figura 40 Cdigo fonte da classe genrica Repository<T>

Fonte: Dados do trabalho

90

4.2.4 Atividades da Fase de Finalizao

Nesta fase foram executados os testes unitrios especificados no Documento de Testes Unitrios Apndice D deste relatrio. Devido a falta de comunicao com o cliente e dificuldades para reunir, somente o primeiro teste de aceitao foi realizado. No entanto foi realizado os testes necessrios para verificar a integridade das funcionalidades do sistema, onde foi possvel identificar falhas na lgica de gerao de boleto pelo cliente na rea administrativa.

4.2.5 Atividade da fase de produto final

A verso final do produto gerado por esta iterao encontrou problemas para ser gerenciado, tanto pelo tempo de desenvolvimento quanto pelo sistema de controle de verso utilizado e falta de comprometimento por parte dos integrantes da equipe. O Quadro 28 o qual apresentado a seguir, mostra as datas das atividades executadas durante o desenvolvimento do projeto. A verso final deste projeto ainda se encontra em desenvolvimento.

Quadro 14 Cronograma do Sistema Tupi Negcios Imobilirios

DATA 04/05/2011

PRESENTES Mislene Dalila da Silva, Nelson Akio de Souza e Virglio Solano Silva Magalhes

LOCAL UNIPAM

ASSUNTO ABERTURA PROJETO

01/07/2011

Mislene Dalila da Silva e Virglio Solano Silva Magalhes

UNIPAM

LEVANTAMENTO REQUISITOS

13/07/2011

Mislene Dalila da Silva e Virglio Solano Silva Magalhes

UNIPAM

APRESENTAO CARTES DE HISTRIA E PRIORIDADES

15/07/2011

Mislene Dalila da Silva, Nelson Akio de Souza e Virglio Solano Silva Magalhes

CASA MISLENE

PLANEJAMENTO PROJETO

Continua na pgina seguinte.

91

Continuao Quadro 28 - Cronograma do Sistema Tupi Negcios Imobilirios 23/07/2011 Mislene Dalila da Silva, Nelson Akio de Souza e Virglio Solano Silva Magalhes 29/07/2011 Mislene Dalila da Silva, Nelson Akio de Souza e Virglio Solano Silva Magalhes 06/08/2011 Mislene Dalila da Silva e Virglio Solano Silva Magalhes 07/08/2011 Mislene Dalila da Silva e Virglio Solano Silva Magalhes 13/08/2011 Mislene Dalila da Silva e Virglio Solano Silva Magalhes 18/08/2011 Mislene Dalila da Silva e Virglio Solano Silva Magalhes 20/08/2011 Mislene Dalila da Silva e Virglio Solano Silva Magalhes 25/08/2011 08/09/2011 Mislene Dalila da Silva Mislene Dalila da Silva e Virglio Solano Silva Magalhes 14/09/2011 Mislene Dalila da Silva e Virglio Solano Silva Magalhes
Fonte: Dados do Trabalho

CASA MISLENE

PLANEJAMENTO PROJETO

CASA MISLENE

DESENVOLVIMENTO DER

CASA MISLENE CASA MISLENE CASA VIRGILIO

CARREGAMENTO DER FERRAMENTA JARCHITECTURE ESTUDO FRAMEWORK VRAPTOR DESENVOLVIMENTO A PARTIR DAS PRIORIDADES DOS CARTES DE HISTRIA

UNIPAM

CRIAO TRIGERS, PARA INTEGRAO DOS DADOS DO SISTEMA LOCAL COM O WEB

CASA MISLENE UNIPAM UNIPAM

LIGAO DOS DADOS COM REA DO CLIENTE PRIMEIRA ITERAO XP APRESENTAO SISTEMA CLIENTE

UNIPAM

FINALIZAO PRIMEIRA ITERAO

92

4.3

PROCESSO UNIFICADO

O processo de desenvolvimento PU foi definido neste documento no captulo 4 tpico 4.5.5. Cada uma das fases deste processo ser detalhada a seguir de acordo com os mtodos utilizados em cada uma. Para maior entendimento de cada fase, consulte a Figura 8 disponvel neste documento. Como plano de iterao foi definido o modelo [1 1 1 1] sendo, sequencialmente, as fases de Concepo, Elaborao, Construo e Transio

4.3.1 Concepo

A fase de concepo foi realizada em uma iterao, tendo como produto gerado o documento inicial de especificao de requisitos, que est disponvel no APNDICE C deste relatrio. No fluxo de Requisitos foram realizadas as seguintes aes:

Levantamento de requisitos do sistema. Identificao dos requisitos no funcionais; Criao do Caso de Uso que modela o contexto.

O prximo passo foi o desenvolvimento do Caso de Uso que modela o contexto, uma vez que foram compreendidos os requisitos do sistema. Este Caso de Uso est disponvel a seguir na Figura 41, onde possvel verificar os casos de uso macro do sistema, bem como a ligao entre o ator cliente e o caso de uso controle financeira e a fronteira entre os mesmos.

93

Figura 41 Caso de Uso que modela o contexto do Sistema de Controle Financeiro

Fonte: Dados do Trabalho

O sistema possui um nico ator chamado de Cliente que pode interagir com os demais casos de uso realizando basicamente as funes CRUD atravs da definio MANTER inicializada no nome de cada caso de uso. Inicialmente o sistema deve ser alimentado para que tenha informaes necessrias para ser trabalho o caso de uso MANTER Movimento Financeiro. A documentao de especificao de requisitos do Sistema de Controle Financeiro est disponvel no APENDICE C deste relatrio. A descrio dos casos de uso macro do sistema exibida a seguir atravs do Quadro 29.

Quadro 15 - Descrio dos Casos de Usos do Sistema de Controle Financeiro

Caso de Uso MANTER Integrao

Descrio Este caso de uso permite que o cliente gerencie a integrao permitindo que realize as tarefas CRUD na Integrao e listar as Integraes cadastradas. Este caso de uso permite ao ator cliente realizar as funes CRUD e listar os Favorecidos cadastrados. Este caso de uso permite ao ator cliente realizar as funes CRUD no Centro de Custo e listar os centro de custos cadastradas.

MANTER Favorecido MANTER Centro de Custo

Continua na pgina seguinte.

94

Continuao Quadro 29 - Descrio dos Casos de Usos do Sistema de Controle Financeiro

MANTER Tipo Receita

Este caso de uso permite ao ator cliente realize as funes CRUD no Tipo Receita, listar esses tipos receitas aps cadastradas, listar as receitas e selecionar Grupo de Receita Despesa. Este caso de uso permite ao ator cliente realizar a funes CRUD no movimento financeiro, listar os lanamentos cadastrados, calcular a movimentao e ainda selecionar a movimentao por ms/ano. Este caso de uso permite o ator cliente gerar relatrios e informar parmetros para os mesmos. Este caso de uso permite ao ator cliente realizar as funes CRUD no fechamento, listar os fechamentos adicionados, abrir um novo fechamento e finalizar fechamento.

MANTER Movimento Financeiro Gerar Relatrios

MANTER Fechamento

Fonte: Dados do Trabalho

4.3.2 Elaborao

A fase de elaborao foi realizada em paralelo com a fase de construo devido ao curto prazo para desenvolvimento deste projeto. Como resultado do fluxo de trabalho do refinamento dos requisitos, foi atualizado o documento de especificao de requisitos do Sistema Financeiro que est disponvel no APNDICE C deste relatrio. O fluxo de trabalho realizado na fase de anlise resultou no DER lgico do sistema que tambm est disponvel no APENDICE C. A seguir exibida a Figura 42 que ilustra o caso de uso MANTER Receita Despesa que permite ao ator cliente cadastrar os tipos Receita/Despesa que so trabalhadas no dia a dia da empresa.

95

Figura 42 Caso de Uso MANTER Receita Despesa

Fonte: Dados do Trabalho

Para compreender o cenrio principal, fluxo alternativo e regras de negcio envolvidas e demais ocorrncias no caso de uso representado na Figura 42, apresentado a seguir a descrio deste caso de uso no Quadro 30.

Quadro 16 Descrio do Caso de Uso MANTER Receita Despesa

Identificao: CSU005 Mdulo: Controle Financeiro Descrio Resumida:

Nome do Caso de Uso: MANTER Receita Despesa Funo: Programa Vinculado

Este caso de uso permite que o ator Cliente realize as funes CRUD na entidade Receita/ Despesa Atores: Cliente

96

Pr-condies:

Ps-condies:

Fluxo Principal: 1. 2. 3. 4. 5. 6. 7. 8. 9. Ator clica no menu Receita/Despesa. Sistema apresenta uma lista de Receita/Despesa cadastradas. Ator clica no boto Novo para criar Receita/Despesa. Sistema apresenta tela para informar os dados da Receita/Despesa. Ator insere dados da Receita/Despesa no formulrio. Ator clica no boto Salvar. Sistema emite a mensagem MSG001. Sistema carrega a lista de Receita/Despesa cadastradas. O caso de uso encerrado.

Fluxos alternativos: 3.1 Editar Receita/Despesa 3.1.1 Ator clica no boto Editar 3.1.2 Sistema carrega os dados da Receita/Despesa para serem alterados 3.1.3 Ator altera os dados da Receita/Despesa 3.1.4 Ator clica no boto Salvar 3.1.5 Sistema emite a mensagem MSG002 3.1.6 Sistema retorna ao item 2. 3.2 Excluir Receita/Despesa 3.2.1 Ator clica no boto Excluir 3.2.2 Sistema emite a MSG003. 3.2.3 Ator clica no boto Sim. 3.2.4 Sistema emite a mensagem MSG004. 3.2.5 Sistema retorna ao item 2. Regras de Negcio: necessrio selecionar um tipo Receita/Despesa, que poder ser do Tipo: C Crdito, D- Dbito, I Informativo; preciso ter cadastrado uma integrao para acessar receita/despesa. O campo descrio receita/despesa obrigatrio.
Fonte: Dados do Trabalho

97

Ao visualizar a Figura 42 e realizar a leitura do Quadro 30 que possui a descrio da especificao do caso de uso, possvel notar a partir do fluxo principal e demais que ao interagir com o caso de uso logo executado a funo Listar Receita/Despesa que representada por um <<include>> e listado no item 2 do fluxo principal, referente aos cadastros existentes. Um outro <<include >> tambm executado ao realizar o cadastro e um novo tipo de Receita/Despesa, que neste caso caracteriza como: Receita, Despesa ou Informativo e deve ser selecionado pelo ator ao realizar o cadastro. A seguir na Figura 43 so exibidas as tabelas do DER lgico que armazenam os valores que so trabalhados por este caso de uso, o DER completo pode ser visualizado no documento de especificao de requisitos disponvel neste relatrio no APNDICE C.

Figura 43 DER lgico que representa as tabelas MANTER Receita/Despesa

Fonte: Dados do Trabalho

Ao visualizar a Figura 43 pode ser visualizado o relacionamento de 1:N (um para muitos) entre a tabela GrupoReceitaDespesa e TipoReceitaDespesa, que neste caso quer dizer que uma ou vrias definies de receita ou despesa deve ser do tipo Crdito, Dbito ou Informativo, caracterizado pela chave primria (PK) CodigoGrupoReceitaDespesa da tabela GrupoReceitaDespesa como chave estrangeira (FK) na tabea TipoReceitaDespesa. A tabela Integrao compe a tabela TipoReceitaDespesa atravs de um relacionamento de 1:N que neste caso representa que uma Integrao pode te mais de um Tipo de Receita ou Despesa registrado para a mesma, permitindo que ao realizar os lanamentos estas informaes possam aparecer de acordo com cada usurio logado no sistema e a Integrao definida. Compe a tabela Integrao o IdUsuario que permite identificar que uma Integrao pertence a um derterminado Usurio do sistema, que nese caso referente ao ator Cliente.

98

4.3.3 Construo

Como foi descrito anteriormente a Fase de Construo foi desenvolvida em paralelo com a Fase de Elaborao e com respostas rpidas referentes ao desenvolvimento. Esta fase ainda est em processo de desenvolvimento, possuindo at o momento como artefato o banco de dados fsico, bem como 90% dos casos de uso macro implementados. A implementao do sistema est sendo baseada no padro de projeto MVC e foram utilizados os mesmo recursos e ferramentas citados no processo de desenvolvimento XP na fase de Codificao. Por este motivo ser apresentado somente o cdigo fonte gerado para o diagrama de caso de uso Manter Receita/Despesa. A pgina que ilustra o caso de uso Manter Receita/Despesa exibida a seguir na Figura 44.

Figura 44 Pgina que representa o caso de uso Manter Receita/Despesa

Fonte: Dados do Trabalho

Ao visualizar a Figura 44 pode ser notado diretamente os dois <<include>> citados anteriormente sendo executado, o Listar Receita/Despesa atravs dos registros na tabela abaixo na pgina e o Listar Tipo Receita/Despesa representado pela lista de opes disponvel no formulrio no item Tipo Receita/Despesa. De acordo com os fluxos alternativos Editar e Excluir, so exibidos junto a cada registro os botes referentes a estas funes,

99

permitindo a execuo das mesmas. Basicamente todas as funes CRUD esto representadas nesta tela. A seguir na Figura 45 ser exibido o cdigo fonte que permite carregar as informaes para serem exibidas na pgina mostrada anteriormente na Figura 44.

Figura 45 Cdigo fonte que retorna as informaes para a pgina Receita/Despesa

Fonte: Dados do Trabalho

Na Figura 45 da linha 51 at 53 criado um critrio para realizao de uma consulta no banco de dados. Este critrio define que a consulta deve retornar os dados que possuem a Integrao corrente definida. A partir das linha 55 e 56 realizada duas consulta ao banco de dados para retornar uma lista de registros das tabelas TipoReceitaDespesa e GrupoReceitaDespesa, onde para a consulta do TipoReceitaDespesa passado os critrios definios como parmetro e na consulta GrupoReceitaDespesa retornado todos os registros contidos nesta tabela. Estes dados so recebidos na pgina ndex da Receita/Despesa onde so utilizados em dois arquivos separados, um com o nome de formulario.jsp onde a consulta GrupoReceitaDespesa utilizada e outro tabela.jsp onde a consulta TipoReceitaDespesa utilizada. A Figura 46 ilustra exibe o cdigo fonte da pgina ndex.

100

Figura 46 Cdigo fonte da pgina index de Receita/Despesa

Fonte: Dados do Trabalho

A Figura 47 que ser exibida adiante possui o cdigo da pgina formulario.jsp, para onde retornado o GrupoReceitaDespesa.

Figura 47 Cdigo fonte da pgina formulrio que recebe os dados de GrupoReceitaDespesa

Fonte: Dados do Trabalho

As linhas 16 a 18 recebem os dados que foram passados como resultado da consulta no mtodo ndex() e realizado uma interao com estes para gerar a lista dentro do combobbox para que o usurio selecione um tipo de receita ou despesa ao cadastrar um novo registro. A Figura 48 exibe os dados retornados o mtodo ndex() contendo a interao do conjunto de dados resultantes da consulta TipoReceitaDespesa cadastrados.

101

Figura 48 Cdigo fonte da pgina tabela.jsp que recebe os dados de TipoReceitaDespesa

Fonte: Dados do Trabalho

A partir da linha 20 verificado se existe algum registro retornado do banco de dados, caso tenha o nome da varivel que possui a lista retornado passado para uma nova varivel de acordo com cada registro encontrado e a partir da escrito nas linhas abaixo os valores contidos nesta varivel que um objeto do tipo ListReceitaDespesa.

4.3.4 Transio

A fase de transio ainda no foi efetuada devido o projeto estar em desenvolvimento at o momento. No entanto esta fase ser desenvolvida levando em considerao testes unitrio e de integrao. Esta parte que est sendo desenvolvida ser resultado da primeira iterao e compe a base deste sistema.

102

4.4

ANLISE

A Anlise deste projeto definida a partir das informaes contidas no Quadro 31, seguindo das definies encontradas em cada processo e posteriormente a apresentao dos resultados baseados nos valores definidos nos grficos.
Quadro 17 Anlise das atividades desenvolvidas nos processos Cascata, XP e PU

Atividades x Processo 1 2 3 Gesto de Trabalho Comprometimento da Equipe Participao do Cliente

Cascata
Muito Alto Alta Fase de Requisitos e Entrega

XP
Baixo Baixa Planejamento Inicial e Iterao 1 1 1 Pequeno Alta Baixa Mdio Excelente Sim Mdio

PU
Baixo Alta Constante

4 5 6 7 8 9 10 11 12

N de Falhas/Correes Quantidade Integraes Tamanho do Projeto Complexidade Fluxo Documentao Satisfao Cliente Avaliao da Equipe Utilizao de Framework Aprendizado no Decorrer do Processo Qualidade do projeto

19 1 Mdio Baixa Alta Baixa Pssimo No Baixo

0 2 Pequeno Mdia Mdia Alta Bom Sim Alto

13

Mdia

Alto

Alto

Fonte: Dados do trabalho De acordo com o Quadro 31 ser explicado a seguir como foi realizada cada atividade em relao ao valor definido para cada uma em relao ao processo escolhido.

103

4.4.1 Gesto do trabalho A Gesto do Trabalho desenvolvido em cada processo teve como base os mtodos que so definidos em cada um. O processo Cascata teve um grande fluxo de trabalho devido a quantidade de requisitos levantados, seguindo as fases de projeto e implementao, foi desenvolvido os requisitos com base na ordem de importncia para funcionamento do sistema. Em comparao com os outros processos houve muito tempo disponibilizado para desenvolvimento da documentao. O processo XP foi definido com a gesto de trabalho baixa devido escolha do requisito necessrio para a primeira iterao, deste modo o foco foi em desenvolver o que foi pedido e verificar a qualidade do mesmo junto ao cliente. Entretanto aps a primeira iterao no foi possvel manter contato com o cliente constantemente, o que prejudicou em parte a anlise deste processo. O fazer cada parte do sistema de modo iterativo e incremental permitiu maior domnio das informaes trabalhadas no projeto e a direo necessrias a seguir. O processo PU foi definido com a gesto de trabalho baixa devido ao modo como foi desenvolvido o projeto. No foi possvel executar as fases e disciplinas do PU corretamente devido ao tempo para o desenvolvimento deste ltimo processo. No entanto a gesto de trabalho deste foi executado muito semelhante aos mtodos propostos pelo XP, devido a interao constante com o cliente e entregas rpidas, alm do direcionamento do projeto em vista a qualidade e aos testes unitrios de cada parte do sistema.

4.4.2 Comprometimento da Equipe

A equipe de trabalho para o desenvolvimento deste trabalho foi iniciada com 3 integrantes. O projeto executado com o processo Cascata obteve um maior rendimento quanto s funcionalidades desenvolvidas e comprometimento da equipe quanto a diviso e execuo do trabalho. Entretanto neste processo j era verificado uma falta de equilbrio entre conhecimento pelos integrantes da equipe. O projeto executa com o processo XP obteve rendimento baixo, pois no XP a equipe deve estar ciente de todo fluxo que est sendo executado e da mesma maneira comprometido em integrar o que foi definido para cada um. Por a equipe ser pequena o fluxo de trabalho contribui, entretanto o desfalque por parte do comprometimento entre os integrantes da equipe comprometeu o rendimento neste processo.

104

Por ser o ltimo processo e sendo necessrio a concluso do mesmo para realizao de comparao do projeto, o empenho da equipe superou as ocorrncias do processo XP, entretanto neste processo a equipe tinha somente dois integrantes, sendo que o terceiro foi excludo do time por falta de comprometimento com o mesmo.

4.4.3 Participao do Cliente

A participao do cliente no processo Cascata foi realizada somente no levantamento de requisitos e entrega do sistema final. Esta falta de comunicao durante o processo de desenvolvimento dificultou o trabalho em partes devido existncia de dvidas durante o mesmo. Esta falta de comunicao dificultou tanto o desenvolvimento por parte da equipe quanto pela falta e conhecimento do que estava acontecendo por parte do cliente.

A participao do cliente no processo XP ocorreu somente na fase inicial para levantamento dos requisitos do sistema e na primeira iterao para definir a prioridade dos requisitos serem desenvolvidos, avaliar o prottipo que foi desenvolvido e ao final da interao validar o produto desenvolvido. Neste caso as demais interaes ficaram comprometidas no havendo sequncia na comunicao com o cliente.

Como foi citado anteriormente no fluxo de trabalho PU, neste processo o cliente esteve constantemente junto equipe de desenvolvimento, definindo os requisitos serem desenvolvidos, bem como validando a implementao dos mesmos. Este jogo de acompanhamento assemelhou-se muito com as caracterstica definidas no XP. 4.4.4 Nmero de Falhas e Correes O nmero de falhas e correes encontradas no processo Cascata aps a entrega para o cliente superou as expectativas da equipe, pois grande parte das funcionalidades desenvolvidas possuam algum tipo de erro ou j no fazia sentido e necessidade para o cliente. A quantidade de falhas encontradas no XP foi considerada devido a concentrao no desenvolvimento de apenas uma funcionalidade do sistema. No PU como as validaes com o cliente eram constantes e o foco estava em desenvolver cada requisito de acordo com a ordem definida pelo cliente, este no gerou nenhuma falha nas validaes do mesmo.

105

4.4.5 Quantidade de Integraes A quantidade de integraes est ligada diretamente a quantidade de entregas para o cliente. Neste caso devido as caractersticas do Cascata houve at o momento somente uma entrega. Para o XP somente uma entrega devido a falta de comunicao com o cliente e sequncia do desenvolvimento das demais funcionalidade do sistema. O PU com a presena constante do cliente resultou em 2 iteraes sendo a primeira entrega das funcionalidades necessrias que alimentam os dados para realizao do movimento financeiro, que foi realizado em uma segunda interao.

4.4.6 Tamanho do Projeto O tamanho do projeto utilizando o processo Cascata foi definido como mdio devido a quantidade de requisitos levantados para desenvolvimento do sistema. Em contrapartida os projetos desenvolvidos utilizando XP e PU no seu contexto geral possuam uma quantidade baixa de requisitos para serem desenvolvidos. 4.4.7 Complexidade A complexidade encontrado no sistema que utilizou o processo Cascata foi baixa, devido aos tipos de funcionalidades desenvolvidas, basicamente funes CRUD no sistema. Entretanto em oposio ao tamanho do projeto a complexidade envolvida no projeto utilizando XP foi maior devido ao desenvolvimento de algumas funcionalidades e regras de negcio da aplicao. O projeto utilizando PU recebeu complexidade mdia devido somente ocorrncia de um dos requisitos possuir uma quantidade maior de detalhes na criao da sua lgica de negcio. 4.4.8 Fluxo de Documentao

O Fluxo de Documentao seguida pelo Cascata foi alta devido as caractersticas deste processo, entretanto como o processo XP focado em programao e no produto final, a quantidade de documento gerado foi mnima resultando somente no diagrama de contexto e cartes de histria. O projeto utilizando o PU recebeu avaliao mdia devido as casos de uso desenvolvido e especificao dos requisitos, levando em considerao o tamanho do projeto.

106

4.4.9 Satisfao do Cliente

A avaliao do cliente que solicitou o desenvolvimento do sistema aplicando o Cascata foi baixa. O mesmo reclamou da falta de comunicao durante o desenvolvimento do projeto, informando quais partes do projeto estariam sendo executadas, ficando de certa maneira sem saber o andamento do mesmo. Entretanto como o XP e o PU possuem comunicao constante com o cliente a satisfao do mesmos foram Excelente e Boa. Para o XP a entrega da iterao 1 correspondeu ao requisito solicitado e para o PU boa devido ao porte do projeto e execuo prevista das funcionalidades solicitadas. 4.4.10 Avaliao da Equipe De acordo com a equipe de desenvolvimento trabalhar com o processo Cascata no projeto que foi desenvolvido foi uma pssima escolha devido a quantidade de requisitos solicitados, a gerao de dvidas na implementao dos mesmos e a falta de comunicao constante com o cliente resultando em um maior nmeros de mudanas e falhas. Ao trabalhar com o XP a avaliao foi definida como excelente, uma vez que o desenvolvimento foi focado em um nico requisito para ser desenvolvido e o entendimento por parte da equipe foi mais simples ao trabalhar com um nico requisito a cada iterao. Como o PU foi praticamente executado com base nas caractersticas do XP a avaliao final foi tida como Bom devido necessidade de criao de documentao para especificar os requisitos do sistema. 4.4.11 Utilizao de Framework Ao utilizar framework no desenvolvimento do projeto XP e PU o ganho na produtividade foi muito grande, o que permitiu a equipe focar somente na lgica de negcio do sistema, o desenvolvimento foi muito superior em comparao com o projeto que utilizou o Cascata como processo, pois por escolha dos integrantes da equipe no foi utilizado framework. 4.4.12 Aprendizado no Decorrer do Processo Ao trabalhar com o Cascata o aprendizado no decorrer do processo foi baixo devido o conhecimento das funcionalidades a serem desenvolvidas no mesmo. Em

107

contrapartida no processo XP e PU como havia requisitos que no fossem de conhecimento geral, estes eram aprendidos a cada implementao desenvolvida.

4.4.13 Qualidade do Projeto A qualidade dos projetos desenvolvidos foram definidas como Mdia, Alta e Alta de acordo com Cascata, XP e PU. Mesmo diante da quantidade de mudanas solicitadas no Cascata, o projeto em si possui uma qualidade satisfatvel de modo que poderia ser melhorado com a utilizao de frameworks. Os projetos conduzidos utilizando XP e PU tiveram uma alta qualidade avaliada diante dos recursos utilizados e o baixo acoplamento entre os cdigos gerados, resultando em aplicaes robustas e de fcil manuteno.

4.5

CONCLUSO

A concluso deste trabalho subjetiva e baseada na experincia de analisar o desenvolvimento de trs sistemas aplicando em cada um, um processo de desenvolvimento. Desta maneira qualquer que seja as citaes definidas na literatura, o resultado encontrado foi baseado no sentimento gerado pelo desenvolvido este trabalho. Baseando-se nas anlises descritas anteriormente e no fluxo de trabalho gerado pelos processos utilizados possvel concluir que o processo de desenvolvimento XP obteve um melhor resultado no seu desenvolvimento, pois os mtodos que so definidos neste processo foram similarmente empregados no desenvolvimento utilizando o processo PU. O fato de que o cliente define qual o requisito inicial que agregue valor para o seu sistema facilita grande parte do trabalho por parte dos desenvolvedores, uma vez que a base do sistema passa a ser desenvolvida. Um outro fator que contribuiu para definir o XP como melhor processo foi na execuo da fase de projeto, onde no h necessidade de criar documentos que no sero utilizados, um fato que comprova isto so os documentos de especificao de requisitos e caso de uso gerados no sistema que utilizou o modelo Cascata como abordagem e obteve cerca de 19 ocorrncias de falhas e mudanas para serem trabalhadas. A ocorrncia de no ter gerado uma grande quantidade de documentos no XP no quer dizer que o mesmo no precise ser documentado, muito pelo contrrio, o que definido que se faa o necessrio para o momento da iterao que se segue.

108

Como os requisitos so iterados constantemente, isto permitiu aprender o funcionamento do sistema em cada iterao, facilitando o entendimento pelos integrantes da equipe. Neste caso a equipe concentrou-se com o que era necessrio para ser desenvolvido e no preocupou-se com os outros requisitos que existiam para serem desenvolvidos. Entretanto, como o XP um processo que se baseia mais no resultado do produto final com qualidade e minimiza a utilizao de documentao, a equipe composta por dois integrantes facilitou neste projeto, uma vez que todos tinham conscincia do estado em que se encontrava o desenvolvimento e o que cada integrante estava desenvolvendo. Trabalhar com cartes de histrias no lugar de casos de uso, foi outra experincia desenvolvida que permitiu agilizar o desenvolvimento do projeto, uma vez que no necessrio utilizar padres ou linguagens especiais para elaborao do mesmo, a nica diferena que vai definir um ttulo e simplesmente falar o que o requisito definido vai fazer. Ao desenvolver o prottipo para poder validar o requisito que o cliente tinha solicitado, foi possvel agilizar o desenvolvimento, uma vez que a prpria interface que seria utilizada estava pronta, concentrando somente na programao da lgica que ir dar sentido a aplicao. Pode ser considerado como um dos principais valores da metodologia XP, a comunicao, pois esta definiu tanto o relacionamento com o cliente quanto com os membros que fizeram parte do time de desenvolvimento. Isso foi fator importante para a concepo, desenvolvimento e concluso deste trabalho Pela aplicao destes trs processos de desenvolvimento foi gerado trs sistemas para web, sendo um sistema que controla o contedo disponvel no site da Ayurvida Terapias Naturais, um segundo sistema desenvolvido para a empresa Tupi Negcios Imobilirios, o qual disponibiliza informaes de compra de loteamento para os clientes e o terceiro sistema gerado foi para controlar as entradas e sadas de dinheiro, tanto pessoal quanto empresarial, onde que este resulta em um sistema de fluxo de caixa. No desenvolvimento destes sistemas a grande dificuldade encontrada foi no comprometimento e cumprimento das tarefas serem desenvolvidas entre os integrantes da equipe, permitindo compreender que um produto de alta qualidade desenvolvido por um grupo de pessoa, necessita de disciplina quanto ao comprometimento do desenvolvimento das tarefas. Portanto, o desenvolvimento deste trabalho foi importante para compreender e abstrair os conceitos e prticas envolvidas no desenvolvimento de sistemas baseados em processos distintos, podendo compreender e aprender as caractersticas que constitui cada um,

109

e, como aplic-las no dia a dia do desenvolvimento de sistemas, a importncia da comunicao na equipe, sendo necessrio comprometimento total dos integrantes afim de obter um produto com alta qualidade. Como resultado, este trabalho uma referncia para os demais alunos da rea T.I. e profissionais, podendo aplicar os conceitos aqui observados e analisados no desenvolvimento dos seus projetos.

110

REFERNCIAS AGILE: Aliance Princpios do desenvolvimento gil e Praticas. 2011. Disponvel em: <http://www.agilealliance.org/> Acessado em: 06 mar. 2011

BECK, Kent. Programao Extrema (XP) explicada. 1 ed. Porto Alegre: Bookman, 2004. 168 p.

CAELUM, Ensino e Inovao. VRAPTOR. Disponvel em: < http://www.caelum.com.br/apostilas/>. Acesso em: 08/08/2011.

DATE, C. J. Introduo a sistemas de bancos de dados. Rio de Janeiro: Elsevier, 2004.

DENNIS, Alan; WIXOM, Barbara. Anlise de projeto de Sistemas. Traduo de Michele Geinhart; reviso tcnica Otavio Santo Cupertin Duro. 2 ed. Rio de Janeiro: LTC, 2005.

ELMASRI, Ramez E.; NAVATHE, Shamkant. Sistema de Banco de Dados - Fundamentos e Aplicaes. 4 ed. So Paulo: Addison-Wesley, 2005.

FERNANDES, Aguinaldo A.; ABREU, Vladimir Ferraz. Implantando a Governana de TI. 2 ed. Rio de Janeiro: Brasport, 2008.

FERREIRA, Aurlio Buarque de Holanda. Miniaurlio Sculo XXI Escolar. 4.ed. Rio de Janeiro: Nova Fronteira, 2001. p.267.

FOWLER, Martin. UML essencial: um breve guia para a linguagem-padro de modelagem de objetos. 3 ed. Porto Alegre: Bookman, 2005.

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos e ao Processo Unificado. Traduo de Luiz Augusto Meirelles Salgado e Joo Tortello. 2 ed. Porto Alegre: Bookman, 2004.

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos e ao Processo Unificado. Traduo de Luiz Augusto Meirelles Salgado e Joo Tortello. 2 ed. Porto Alegre: Bookman, 2007.

LEITE, Mrio. Tcnicas de Programao: Uma abordagem Moderna. 1 ed. So Paulo: Brasport, 2006.

111

LUCINDA, Marco Antnio. Qualidade Fundamentos e Prticas. 1 ed. So Paulo: Brasport, 2010.

MARTINS, Jos Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. 2 ed. rev. Rio de Janeiro: Brasport, 2005.

MANIFESTO: gil - Manifesto para Desenvolvimento gil de Software. 2001. Disponvel em: <http://www.agilemanifesto.org/iso/ptbr/manifesto.html> Acessado em 07 abr. 2011.

OBRIEN, James A. Sistemas de Informao e as Decises Gerenciais na Era da Internet. 2 ed. So Paulo: Saraiva, 2004. REZENDE, Denis Alcides. Engenharia de software e sistemas de informao. 3 ed. Rio de Janeiro: Brasport, 2005.

SCOTT, Kendall. O processo unificado explicado. Porto Alegre: Bookman, 2003.

SHALLOWAY, Alan; TROTT, James. Explicando Padres de Projeto. 1 ed. Porto Alegre: Bookman, 2004.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3 ed. So Paulo: Makron Books, 1999.

SOFTEX: MPS.BR - Melhoria do Processo de Software Brasileiro. 2009. Disponvel em: <http://www.softex.br> Acessado em: 15 mai. 2011.

SOMMERVILLE, Ian. Engenharia de software. Traduo de Andr Maurcio de Andrade Ribeiro. 6 ed. So Paulo: Addison Wesley, 2003.

SOMMERVILLE, Ian. Engenharia de software. 8 ed. So Paulo: Pearson Education - Br, 2007. THAYER, Richard H. Gerenciamento Projeto de Engenharia de Software. 2 ed. Paperback, 1997.

PRESSMAN, Roger S. Engenharia de software. 3 ed. Rio de Janeiro: Makron Books, 1995.

PRESSMAN, Roger S. Engenharia de software. 6 ed. Rio de Janeiro: McGraw-Hill, 2006.

112

YOURDON, Edward. Anlise Estruturada Moderna. So Paulo: Campus, 1990. WHITE, Richard L. & PERCIVAL, Jeffrey W. 1993, Proc. SPIE Vol. 2199, p. 703-713, Tecnologia Avanada de Telescpios pticos; Ed. Compression and progressive transmission of astronomical images.

113

ANEXOS