Home

UNIVERSIDADE PRESBITERIANA MACKENZIE

1. 55 CAP VI CONCLUS O ibo ias a e ERO 56 CAP VII REFERENCIAS ANEXOS eene u uuu 58 7 1 Refer ncias Bibliogr ficas u ALLI esee sene esten stores ne sene en naiona aan sean asas e on ts iai 58 7 2 Bibliografia Complementar se come seen mesmen esee seen seen me cmon ee sene se suse se caneca sesso sees suse se cemeseoeeeemeseoseses 59 ANEXO A FASE CONCEP O u ner u u 60 ERD EA ELE 60 AT E V18a0 Geraldo Problema sorer nu anun uiay LEQUE ND SDS Una Pads sduhet 60 A1 2 Descri o dos Envolvidos e dos Usu rios er e ere e meren rene ee nennen rennen 60 A12 Ts Restumo dos ENVOIVIAOS nuseve esee ite e ee cor edere Exe tec i ripe dd der 60 AT 2 2 Resumo dos USUATIOS n v einer eee cor ete Eee ied rese deed ti feed e eov ee eva 61 A1 3 Lista de Casos de Uso identificados UC 62 ALA Requisitos Funcionais RE y an tere ertet eee tip core eese cai e etae bue nece 62 A1 5 Requisitos N o Funcionais RN 62 A1 6 Vis o Geral do Sistema Proposto cooocoooconoconononnnonnennoon neser r r r enen et ee entente res retro mre sere sere r r n rene ros n ese 63 A1 6 1 Caracter sticas do Sistema Proposto one core one e ne een ecen eee re en nc eene nemen nennen nennen nre 63 A1 6 2 Ambiente ALVO Satin o p ERR RR E CR DOR ELS ERRR sod n anes seek cata en 63 AZ Casos de USO EP
2. aa Cour dos IS Ov peuo pun paren P koss usngo peuo PUN pane I I NS gt I 607 oueuopunJ Bo pejob sopensepeo pf oupuopuny Vera q te i Qaisvavo ON osia ido Ep gt 1 A gt Sei Y jjouisuopururmeps5 i sl T oueuopundoueuopunueupeo H OUguopunj E EE gt Te EET EE T Fadas en i i qe po Jopeistumupy pueuopungensepes SUN DIOONSEPET SEET SAA Da ayas ES ci peu Jensepeo ps REFER NCIAS ANEXOS 93 ionario Desativar Func ebyoueupun yeanesep De I IdyousupurkueAtEssp HOME sos 1s CES E Speaedubjsseso ueuo SUN eque EEE Qcbjoueup ngremesep ORO euo pura mro oueupun_pernesep E uO UNy EENG OS dii punsioopennesap dels omg utupy 94 REFER NCIAS ANEXOS B2 1 2 UCO2 Vincular Permiss es er boot pur segssquuiag op 1511 door bje ere so ua ena op oueuopui i a I Ten rampa TA owetopun4 Le JicbJouerergocesuuo seo par gegen oom sen eme EB nsn wad dos 1s nsn usas aos 1s Bins vd aos as
3. OVA ESSA LA 193 lqosseuishgoessuediesijion FPPESBJUOISSOSOESSUSAES UDA wa seessuuu q Jegen 800N PS 110 REFER NCIAS ANEXOS B2 1 9 UCO9 Gerar Log de Acesso 607 oueuopuna bo yessb 601 oueuo puny boes 601 oueuorouny4 B0 ye196 607 oueuo ppun4 Bo yelsb SIqossauisnabotiensiben ss ov 9p 607 18195 600N PS REFER NCIAS ANEXOS 111 B2 1 10 UC10 Consultar Andamento do Projeto vjela posa fo sopegresenq ol loig Iso Eeer ou 1 Gobjajuasegiogsoja buerg E gtt H Ql loidpoo oleloudsopecueosnq ol loud bg A Qdojewereoiogsote buenq Em 018 lug poo ojo fosopecuesna ol louq sa BEER E SSSursreore eent EA OerekueOag L ee dee dojeiuerecyo sore lod exsng pr Es Eorsvoieexasopeaueosngr 1 aaeb op sojefaid enq oy o1dsopep oio paion a dsl ds pa sop lid ep quais 9ieleia op ouawepuy AENNSUCO OLN PS Ieper mue MA ejare jojeurepuv egare oueuuepuvieden e Lg Dr EECH e n jore yoreurepuv ejare Lous ewe erg DEER ejore 1puvpoo BJA ojueuepuyecenq ejare jojueurepuy sl yore puvpcojeare EVENT Epi onuautepuy
4. and tar data Data do andamento da tarefa and tar descricao Descri o do andamento da tarefa fun cpf C digo do funcion rio que efetuou o andamento da tarefa B3 2 5 Tabela FUNCIONARIO Campo Descri o fun cpf CPF e c digo do funcion rio fun nome Nome do funcion rio fun rg Registro Geral do funcion rio fun senha Senha de acesso ao sistema fun dt nascimento Data de nascimento do funcion rio fun cargo Cargo na empresa fun ddd telefone C digo DDD do telefone fun num telefone N mero do telefone fun email contato E mail para contato fun rua Endere o do funcion rio fun numero N mero da casa do funcion rio fun bairro Bairro onde o funcion rio mora fun cidade Cidade onde o funcion rio mora 122 REFER NCIAS ANEXOS fun estado Estado onde o funcion rio mora fun pais Pa s onde o funcion rio vive fun complemento Complemento do endere o fun cep CEP do endere o dep codigo C digo do departamento fun tipo Tipo de funcion rio 1 Administrador 2 Diretor 3 Gerente de Projetos 4 Usu rio fun status Status do Funcion rios A Ativo I Inativo B3 2 6 Tabela DEPARTAMENTO Campo Descri o dep codigo C digo do departamento dep nome Nome do departamento dep descricao Descri o do departamento B3 2
5. Atrav s da defini o acima pode se dizer que um sistema representa algo que est sendo elaborado podendo ser visualizados de diversas formas e perspectivas e para fazer essa repre senta o s o utilizados os diagramas Segundo Jacobson Rumbaugh e Booch 2005 p 95 para visualizar as partes est ticas de um sistema utilizam se os seguintes diagramas Diagrama de classes Diagrama de componentes Diagrama de estrutura composta Diagrama de objetos Diagrama de implanta o Diagrama de artefatos E para visualizar as partes din micas Diagrama de caso de uso Diagrama de seq ncia Diagrama de comunica o Diagrama de gr fico de estados Diagrama de atividades UML UNIFIED MODELING LANGUAGE 29 Os diagramas que mostram as partes est ticas de um sistema s o nomeados como dia gramas estruturais E os diagramas que mostram as partes din micas de um sistema s o nomea dos diagramas comportamentais 3 3 1 Diagramas de Classes Jacobson Rumbaugh e Booch 2005 definem o diagrama de classes como sendo um dos dia gramas mais utilizados na modelagem de sistemas orientados a objetos por mostrar um conjunto de classes interfaces e colabora es e seus relacionamentos Os diagramas de classes tamb m s o utilizados como base para a constru o de dois outros diagramas os de componentes e os de implanta o Como pode se ver na figura 3 1 o diagrama de classes possibilita a
6. FAN FUNCIONARIO PERMISSAO e 9 fun cpf INTEGER FK per codigo INTEGER FK DEPARTAMENTO M LOGACAO o vy log id INTEGER 19 fun cpf INTEGER FK log ip INTEGER 9 log descricao V amp RCHAR 255 Q log data DATE 120 REFER NCIAS ANEXOS B3 2 Dicionariza o do Modelo B3 2 1 Tabela EMPRESA Campo Descri o emp codigo C digo da empresa emp nome Nome da empresa emp nome resp Nome do respons vel da empresa emp descricao Breve descri o de como a empresa emp site Site da empresa emp num telefone N mero de telephone emp ddd telefone DDD do n mero de telefone emp email contato E mail de contato da empresa emp rua Rua onde localiza a empresa emp numero N mero do local onde a empresa est situada emp bairro Bairro onde a empresa est situada emp cidade Cidade onde a empresa est situada emp estado Estado onde a empresa est situada emp pais Pa s onde a empresa est situada emp complemento Complemento do endere o da empresa emp cep CEP da rua onde est localizada a empresa emp cnpj CNPJ da Empresa B3 2 2 Tabela PROJETO Campo Descri o pro codigo C digo do projeto emp codigo C digo da empresa que est solicitando o projeto pro dt inicio Data de in cio do projeto pro dt final Data final de t rmino do projeto pro d
7. Lea ejare puypo9Jejare ousurepuyessna jae queuepuy GERIR PR PYES TJI JONE ougren Peouauepuvoroeiaje Fjoauouepuvson gapuvyooeoesoje Vuw ONV dosis Eur ONV dos 1s Ovgepeuuew ebessen speoesuorss sepsuetamuew PreB ragss ursngej arers tumeW a onovessierousuepuvyaeosng sho cp di B2 1 11 UC11 Manter Andamento da Tarefa 112 REFER NCIAS ANEXOS Alterar Andamento da Tarefa pg op ouseusepuq ema PS REFER NCIAS ANEXOS 113 Cadastrar Andamento da Tarefa ejare Queurepuv ejare joueurepuyimou NENNEN eak oxueurepuv ejose o1ueurepuyain put ejere poo e eue asse Bo ureBequearogrecsnq e No ejar pos ejare 1ossalDo1quISbeJuODIO 7e014 eT ejar Quewepuy ejare ojusurepuyain pur Legg 607 euer Bref w gt et epe Iolueuuepuy ejare ojueurepuyin pur ejare pooJejare Leef ef euer men lt ejare 1pcojejere oseiBoxdueBelueolocuessnq Ou BE jem ojueurepue pepeo Sas sss asss zh ag ejer ep osaibaid ep webejuead Caro EN KEE operen prerepuviensepeo feja epuyyoonsepeo EL oHod vosna dos 1S HvL Oo dos is OvaejeieLieuew peeseguossesejerepiewuepr
8. Se voc adquirir ou reutilizar qualquer pacote ou biblioteca de classes Java de uma fonte externa certifique se de que seja 100 Java Com a imposi o desse padr o voc ter certeza de que o que est sendo reutilizado funcionar em todas as plataformas nas quais queira implan t lo poss vel obter classes pacotes ou applets Java de v rias fontes seja uma empresa de de senvolvimento de terceiros especializada em bibliotecas Java ou outro departamento ou equipe de projeto da organiza o Imposta o de classes A instru o de importa o permite o uso de curingas para indicar os nomes das classes Por exemplo a instru o import java awt Aciona todas as classes do pacote java awt de uma vez Na realidade isso n o comple tamente verdadeiro O que realmente ocorre que todas as classes do pacote java awt ser o inse ridas no seu c digo quando ele for compilado As classes n o utilizadas n o ser o inseridas Em bora pare a ser uma boa caracter stica ela diminui a legibilidade do c digo Otimiza o de c digos Java A otimiza o do c digo uma das ltimas tarefas a serem consideradas pelos programa dores e n o a primeira Deixando a otimiza o para o fim voc otimizar apenas o c digo que precisar ser otimizado Com frequ ncia uma pequena porcentagem do c digo resulta em grande parte do tempo de processamento e esse o c digo que voc dever otimizar Um erro cl ssico cometi
9. Ssossmad SIS Pvoosssuusamsun x Ee Tess queira em bjo veres ene Queuopu ul E Le H sac Lua seas na B e TT oossuuagopemaur a ssossqued PEA PA lt F dope LUV seossuuaa senoun zoon ps REFER NCIAS ANEXOS 95 B2 1 3 UCO3 Vincular Funcion rios 607 oueuo pun bo pe b 1 sn ejar poo ejase joungejnouia SOU ep IST doo ejare poo ejae joueuojpunssojnouiAInpxo i la EN Pyare j poo ejare soueuo nune nou M ejar poojejere so euo PUNEO ou uin pxe i da En gier 1poosejer so peuo pune noui i r lt 1 d Gelee gt I EN emp jpoopejase soueuo PUNE NOUA Cat ejar LPEE 504600 DU pOu f HE E gt mpx ejar poo ejare so ueuo punJso nou MIN Oxa WH VAJAV dos 1S q MH V43uvr dos LS B ossa snage Oe EE i i i 1 i 1 i i i i i i i 1 i 1 i H PEE EN uogoyejere SUN EMS CeOepIgt seng i j ejarel e soueuo puny enoun mE Ee i L sabado soueuopuny Jeosnq DOE sojololg ap ouso Soueuoroun Iert EGON PS 96 REFER NCIAS ANEXOS B2 1 4 UCO4 Manter Tarefas Buscar Tarefas oj
10. Use a terminologia aplic vel ao dominio em quest o Se os usu rios se referirem aos clientes como empresa use o termo Empresa para a classe e n o Cliente Muitos desenvolvedores cometem o erro de criar termos gen ricos para conceitos quando j existem termos satisfat rios em uso no mercado ou no dom nio Combine letras mai sculas e min sculas para facilitar a leitura dos nomes Use letras min sculas em geral mas mai scula para a primeira letra dos nomes de classe e de interface assim como para a primeira letra de palavras n o iniciais KAN97 N o abuse das abrevia es use as de forma inteligente Isso significa que voc de ve manter uma lista de formas abreviadas padr o abrevia es escolh las com dis cernimento e us las consistentemente Por exemplo se voc quiser usar uma forma abreviada da palavra n mero escolha num documente sua prefer ncia n o importa qual e use somente essa Evite nomes longos lt 15 caracteres o ideal Embora o nome da classe Cadastro FuncionarioBusinessDelegate possa parecer satisfat rio no momento em que criado ele muito longo por seguir uma padroniza o Classes que representam os Bean s devem seguir esta conven o Evite nomes semelhantes ou cuja nica diferen a sejam as letras mai sculas ou min sculas Por exemplo os nomes de vari vel persistentObject e persistentObjects n o devem ser usados ao mesmo tempo nem anSqlDatabase e anSQLDatabas
11. o redigir os coment rios antes de escrever o c digo Dessa forma voc poder pensar sobre como o c digo funcionar antes de escrev lo e garantir o prepa ro da documenta o Como op o voc tamb m pode documentar o c digo medida que o escreve Como a documenta o facilita a compreens o do c digo voc poder utiliz la ao desenvolver o c digo Se voc pretende investir tempo no preparo da do cumenta o deve pelo menos tirar algum proveito disso AMB98 Documente n o apenas o que est sendo feito mas tamb m por que est sendo feito Por exemplo o c digo do Exemplo 1 abaixo mostra que um desconto de 5 foi oferecido aos pedidos iguais ou superiores a R 1 000 00 Por que fazer isso Existe alguma regra de neg cio que imponha desconto aos pedidos maiores Esse desconto por tempo limitado ou um programa permanente O programador original estava a penas sendo generoso Voc s saber responder se o motivo estiver documentado se Ja no pr prio c digo fonte ou em um documento externo Tipos de coment rios em JAVA Java tem tr s estilos de coment rios 1 Coment rios de documenta o que come am com e terminam com 126 REFER NCIAS ANEXOS 2 Coment rios de estilo C que come am com e terminam com 3 Coment rios em uma nica linha que come am com e seguem at o fim da li nha do c digo fonte A tabela a seguir um sum rio de uso sugerido para ca
12. privada Um m todo privado s Quando o m todo oferece comportamento pode ser disparado por outros m todos da classe na qual ela est definida mas n o nas subclasses que espec fico para a classe Os m todos privados geralmente s o o resultado da refatora o ou reorganiza o do comportamento de outros m todos contidas na classe para encapsular um comportamento espec fico Documenta o de m todos A maneira como voc documenta um m todo costuma ser um fator decisivo para deter minar se ele ser entendido e portanto se poder ser mantida e ampliada O cabe alho dos m todos Todo m todo em Java deve incluir algum tipo de cabe alho denominado documenta o da fun o de membro na parte superior do c digo fonte que documente todas as informa es que s o vitais para sua compreens o Essas informa es incluem entre outras as seguintes ques t es O que o m todo executa e por qu Ao documentar o que um m todo executa voc permite que outros usu rios determinem se o c digo poder ser reutilizado Documen tar os motivos pelos quais ela executa permite que outros usu rios insiram seu c digo no contexto Voc permite tamb m que outros determinem se uma nova mudan a de ver ser realmente efetuada em um trecho do c digo talvez o motivo para a nova mu dan a entre em conflito com o motivo pelo qual o c digo foi escrito inicialmente Qual m todo deve ser passa
13. 2005 p 255 Existem duas caracter sticas que diferenciam o diagrama de seqii ncia do diagrama de comunica o a exist ncia da linha de vida do objeto e do foco de controle Observando a figura 3 9 pode notar uma linha tracejada na vertical essa linha a de vida do objeto sendo que essa linha de vida deve ser visualizada de cima para baixo da esquerda para a direita J o foco de controle o ret ngulo que fica sobre a linha de vida do objeto A parte superior do ret ngulo in dica o in cio da a o e a parte inferior o fim As setas que v o da esquerda para a direita s o mensagens que passam por cada foco de controle As setas que v o da direita para a esquerda s o as respostas que s o passadas de um fo co de controle para outro assim como as mensagens 3 3 9 Diagrama de comunica o Jacobson Rumbaugh e Booch 2005 p 259 definem diagrama de comunica o como o diagra ma que enfatiza organiza o dos objetos que participam de uma intera o O diagrama de comunica o possui duas caracter sticas que o diferem do diagrama de se qu ncia a exist ncia do caminho na qual representado o caminho correspondente a uma asso ciac o e do n mero de seqii ncia que indica a ordem temporal da mensagem Pode se observar essas caracter sticas na figura 3 10 36 UML UNIFIED MODELING LANGUAGE 7 objeto o Se N N 1 create restri a0N v nculo 2 setActions a d 0 de caminho N 3
14. 64 ADA EE 64 A2 2 Lista de Casos de USOS iconos 64 A2 3 NCASOs de USOS ii sad 64 A2 4 Especifica o dos Casos de Usos enen 66 A2 4 1 UCO1 Manter Funcion rio aaa nan aaa aaa eee even even re vene ever eee vere eren eee entere entente entere 66 A2 4 2 UCO2 Vincular Permiss es aasma a y a vere eee eee 69 A2 4 3 UCO3 Vincular Funcion rios eee eee eee ene eee rere eee 70 A244 C04 Manter Tarefas y n nn eee ere ina w ole hes ve vetvetor 71 A2Z 4 9 COS Manter PIOJ TOS en nenit tesh pt err dd t 73 A2 4 6 UC06 Manter Empresa ns an sado oh e ee t Teen dereen 75 A2 4 7 UC07 Realizar Login enge Ree e EE as n i na RS TI A2 4 8 UCO8 Verificar Permiss es eee one a En eee enen eren 78 A2 4 9 UCO9 Gerar Log de Acesso eee enen eee eee 79 A2 4 10 UC10 Consultar Andamento do Droteto eee 80 A2 4 11 UC11 Manter Andamento da Tarefa n ns nennen eene 81 A2 4 12 UCI2 Visualizar Tarefas ee tete assasi sassa re esen 83 A2 4 13 UC13 Visualizar Andamento de Tarefas sss 84 A2 4 14 UC14 Exibir dados dos projetos em andamento ra 85 ANEXO B FASE ELABORA CATQ 86 B1 Documento de arquitetura de software 86 BLL Objetivo cid Ii 86
15. Voc n o deve precisar ler o c digo inteiro em uma estrutura de controle para determinar o que ele executa Basta verificar uma ou duas linhas de co ment rios que o antecedem O que o c digo executa e por qu Ao verificar um trecho do c digo voc sempre pode saber o que ele faz Contudo se o c digo n o for bvio raramente ser poss vel definir o motivo de determinada a o Por exemplo voc pode verificar uma linha de c digo e determinar facilmente que um desconto de 5 est sendo aplicado ao valor total de um pedido Isso f cil O que n o f cil perceber POR QUE esse desconto est sendo aplicado Obviamente h uma regra de neg cio que determina a aplica o do desconto Portanto essa regra deve ser pelo menos mencionada no c digo para que os outros desenvolvedores possam entender o motivo w Vari veis locais Embora esse assunto seja abordado mais detalhadamente no cap tulo 5 cada vari vel local definida em uma fun o de membro deve ser declarada em sua 134 REFER NCIAS ANEXOS pr pria linha de c digo e geralmente deve ter um coment rio in line que descreva seu uso C digo dif cil ou complexo Se voc perceber que n o poss vel reescrev lo ou caso n o tenha tempo para isso documente completamente os c digos complexos de uma fun o de membro Como regra pr tica geral se o c digo n o for bvio preciso do cument lo A ordem de processamento Se houver ins
16. destroy PA N t local mensagem e proxy global p ODBDProxy M ob jeto 2 1 setValues d 3 4 2 2 setValues a CO o S n mero seq encial Figura 3 10 Exemplo de Diagrama de Comunica o Fonte Jacobson Rumbaugh e Booch 2005 p 259 3 3 10 Diagrama de gr fico de estados O diagrama de gr fico de estados um dos cinco diagramas da UML que s o utilizados para a modelagem da vis o din mica de sistemas Segundo Jacobson Rumbaugh e Booch 2005 o di agrama de gr fico de estados permite a visualiza o do comportamento de objetos que caracte rizado por sua resposta a eventos ativados externamente do seu contexto chamado de objetos re ativos Como pode se visualizar na figura 3 11 o diagrama de gr fico de estado enfatiza o fluxo de controle de um estado para o outro tranaink transicao fansi o Receiving ringing Processing checkSumOk Transmitting evento entry pickUp exit disconect error I printReport 9 estado a o estado composto Figura 3 11 Exemplo de Diagrama de Gr fico de Estados Fonte Jacobson Rumbaugh e Booch 2005 p 343 UML UNIFIED MODELING LANGUAGE 37 3 3 11 Diagrama de atividades Assim como o diagrama de gr fico de estados o diagrama de atividades um dos cinco diagra mas da UML que permite a visualiza o dos aspectos din micos de um sistema Difer
17. o o objetivo desta fase capturar todos os requisitos ainda n o identifica dos e definir uma arquitetura s lida que permita a evolu o do sistema nas fases se guintes Constru o nesta fase tanto o sistema quanto sua documenta o s o criados em con junto a uma vers o de testes do sistema a primeira vers o do manual do usu rio e da ajuda O manual de opera o e instala o do sistema e o material para o curso de trei namento devem tamb m come ar a ser preparados nesta fase Transi o garante que o software atenda s necessidades do usu rio Isto inclui testes do produto antes de seu lan amento por meio de vers es beta e ajustes baseados nas respostas do usu rio quanto vers o beta testada Neste ponto do projeto o foco a sintonia fina do produto configura o instala o e quest es de usabilidade qualquer grande quest o estrutural j deve ter sido tratada bem antes desta fase RUP RATIONAL UNIFIED PROCESS 41 4 4 Fluxos de Atividades Os processos do RUP definem pap is atividades artefatos e os procedimentos que devem ser executados Os pap is est o associados a quem s o as pessoas que ir o executar o projeto sendo que uma mesma pessoa pode executar mais de um papel no mesmo projeto Estes pap is definem as responsabilidades e as tarefas que ser o executadas e cada um requer um conjunto de compet n cias por parte do respons vel Como pode se ver na figura 4 1 o eixo horiz
18. ram esses atrasos e tamb m continuar utilizando a mesma metodologia em projetos de n veis de complexidade distintos faz se necess rio a escolha de apenas alguns dos diversos documentos que podem ser gerados ao longo do ciclo de vida do projeto Prado 2003 Vargas 2006 E devido import ncia deste tema o RUP foi adotado para o desenvolvimento deste tra balho 1 2 Objetivos Este trabalho tem por objetivo mostrar as facilidades e dificuldades s o encontradas no processo de desenvolvimento de sistemas com a utiliza o da metodologia RUP Para este estudo ser implementado um gerenciador de projetos web na plataforma Java Enterprise Edition JEE uti lizando alguns conceitos b sicos de gerenciamento de projetos abordados neste trabalho INTRODU O 15 1 3 Procedimentos metodol gicos O procedimento metodol gico escolhido foi a elabora o de um estudo de caso Este estudo compreende a implementa o de um sistema de gerenciamento de projetos utilizando com base de desenvolvimento a orienta o a objetos Como metodologia de desenvolvimento ser utiliza do o RUP e em cada fase do ciclo de vida do projeto ser o gerados os documentos que forem Julgados necess rios 1 4 Organiza o do Trabalho No cap tulo 2 Gerenciamento de Projetos ser feita uma breve introdu o sobre o t tulo em quest o informando sua import ncia os problemas encontrados e as formas de gerenciamento No cap tulo 3
19. uma breve introdu o s caracter sticas e utiliza o da Unified Modeling Language UML ser apresentada pelo fato de o RUP utiliz la para gerar os artefatos Ser o estudadas as quatro fases do RUP concep o elabora o constru o e transi o no cap tulo 4 como os artefatos s o gerados ao longo de seu ciclo de vida que compreende desde modelos c digos fontes at diagramas Todos estes documentos s o de extrema import ncia pa ra o controle no processo de desenvolvimento de software No cap tulo 5 ser abordado o projeto em quest o discutindo sobre quais artefatos foram escolhidos e como foi o processo de elabora o e execu o desde seu in cio at sua conclus o Ser o expostas tamb m as dificuldades encontradas ao longo do desenvolvimento e os motivos das escolhas de determinados caminhos que o projeto seguiu entre eles artefatos e tecnologias utilizadas E por fim no cap tulo 6 Conclus o ser o apresentados os resultados obtidos atrav s do desenvolvimento do estudo de caso aqui descrito 16 GERENCIAMENTO DE PROJETOS Cap II Gerenciamento de Projetos Executar projetos ou executar empreendimentos uma caracter stica de sobreviv ncia da empresa moderna Prado 2003 Nos tempos atuais a competitividade existente entre as empresas para a conquista de clientes e a dificuldade na entrega de produtos ou servi os tem crescido Prado 2003 afirma que isso se deve ao fato
20. 4 4 4 Implementa o Durante este processo ser o desenvolvidas v rias vers es do sistema ou partes dele de modo que representem sua funcionalidade Cada uma destas vers es constru da atrav s da integra o de componentes novos ou subsistemas Os componentes s o constru dos separadamente e poste riormente combinados criando subsistemas que por sua vez s o combinados montando um sis tema A ltima vers o a operacional a que ser instalada no cliente Segundo Kruchten 2004 p 158 a meta assegurar que este modelo seja organizado de tal maneira que fa a o desenvolvimento de componentes e o processo de constru o t o livres de conflitos quanto poss vel Este processo tem quatro objetivos principais Definir a organiza o do c digo fonte no tocante ao desenvolvimento dos subsistemas Implementar classes objetos e componentes Executar testes de unidade nos componentes desenvolvidos Integrar os elementos implementados pelos programadores em arquivos execut veis 46 RUP RATIONAL UNIFIED PROCESS Os seguintes artefatos s o trabalhados neste processo Subsistemas implementados Componentes Plano de integra o das vers es 4 4 5 Teste A fase de testes n o uma atividade isolada nem uma fase do projeto na qual se executam todos os testes Se os desenvolvedores desejarem ter retorno sobre a programa o em tempo real de vem executar testes a cada ciclo de desenvolvime
21. 7 Tabela PERMISSAO Campo Descri o per codigo C digo da permiss o per pagina P gina JSP do sistema per descricao Descri o da permiss o B3 2 8 Tabela LOG ACAO Campo Descri o log id C digo do log log descricao Descri o do log log ip IP do computador de onde est gerando o log log data Data da gera o do log fun cpf C digo do funcion rio REFER NCIAS ANEXOS 123 B4 Guia de programa o B4 1 Padr es de programa o em Java B4 1 1 Objetivo Este documento descreve um conjunto de padr es conven es e diretrizes para escrever um c digo Java s lido Eles se baseiam em princ pios de engenharia de melhorados Al m disso com o uso desses padr es de codifica o sua produtividade como desenvolvedor Java dever aumen tar significativamente A experi ncia demonstra que o tempo dedicado escrita de c digos de al ta qualidade desde o in cio facilitar a modifica o do c digo durante o processo de desenvolvi mento Por fim o uso de um conjunto comum de padr es de codifica o garante maior consis t ncia e aumenta a produtividade das equipes de desenvolvedores Primeira e Ultima Diretriz Use o bom senso Quando n o houver nenhuma regra ou diretriz dispon vel quando a regra n o puder ser aplicada por motivos bvios ou quando todo o resto falhar use o bom senso e verifique os princ pios fundamentais Essa regra se sobrep e a todas a
22. B12 EE E UE 86 B1 3 Objetivos e Limita es da Aroutteturg en aeennevneevnee oreve e ene e enes ene ere core cone error re vere vrerin 86 B14 Visao EE 86 BI A 1 Apr s nta ao cintia ii dc 86 B1 4 2 Projeto dos Pacot s ici eda puedo de WERDE RR 87 B1 5 Vis o de Implantagao celoso eter i peto dia tp ema 88 B1 6 Vis o de Implement gc o sn oue nete I teta DH eet DR PERDE 89 B2 Modelo d design a aaa dd e paa ios wq de de cese posu ad sagt ea Cata sed apa Pose sida adiado 90 B2 1 Diagrama de Seql ncia ccoo nata terree retener tantae eoe ee des ov s etuer reple ete 90 B2 1 1 UCOI Manter Funcion rio esses er pene eter eie ete tiere eee Pn edens 90 B2 1 2 UC 02 Vinculat PermisSOes u nicer eei re etre Oe Ueber n eene 94 B2 1 3 UCO3 Vincular Funcion rios seen nre nennen ente error 95 B2 1 4 UCOA4 Manter Taretas u t rente nea ee ertet rm etre P e D pre He ERES 96 B2 1 5 UC05 Manter Projeto ucraniana cedet 100 B2 1 6 UC 06 Manter Empi sa suu ht dr eee ette rie tcs 104 B2 1 7 UCO07 Reahzar Eom em ntt rer as 108 B2 1 5 UCOS Verificar Permissoes deeem mro eri Rer ruere EE ERREUR 109 B2 1 9 UCO9 Gerar Log d ACESSO jus riot enim eres 110 B2 1 10 UC10 Consultar Andamento do Projeto eres 111 B2 1 11 UC11 Manter Andamento da Tarefa e neo ene ee neo eee o eren e cen enne 112 B2 1 42 UCI2 Visualizar Tarefas ege 115 B2 1 13 UC13
23. Comunica o eee ee ren rere 36 Figura 3 11 Exemplo de Diagrama de Gr fico de Estados sse 36 Figura 3 12 Exemplo de Diagrama de Atividades neo once ore e nese vezeve eee eee ren re cono en nono rene 37 Figura 4 1 Nove fluxos centrados no Processo vere veren eee reve eee al Figura 5 1 Comparativo de sistemas de gerenciamento de projetos eneve ne eee eee 51 Figura 5 2 Comparativo de sistemas de gerenciamento de projetos neo eneve n eee eee enen 51 Figura 9 35 Realiza es coe SR e DERE ou a EE ue 53 Tabela 1 1 LISTA DE TABELAS Comparativo de sistemas de gerenciamento de projetos 14 INTRODU O Cap I Introdu o 1 1 Justificativa do Tema As organiza es constantemente executam projetos Seja no desenvolvimento de um novo pro duto ou servi o na implanta o de um novo sistema gerencial ou at mesmo em mudan as orga nizacionais Os profissionais da rea de gerenciamento de projetos tem enfrentado grande dificuldade em controlar e administrar estes projetos O fracasso come a a se tornar algo muito frequente e solu es para que estas estat sticas mudem t m sido incorporadas s empresas Vargas 2006 Segundo Prado 2003 p 19 a obten o de sucesso em projetos se tornou algo muito im portante para as empresas pois atrav s disto ela pode se tornar mais competitiva no mercado e seus objetivos s o rapidame
24. PROJETO 51 i Arquivo Editar Exibir Inserir Formatar Registros Ferramentas Janela Ajuda Br j 3 2 x EIA EAR Tarefa Horas Trabalhadas to Prog Andamento Data Descri o Registro 14 1 gt W r det Figura 5 1 Comparativo de sistemas de gerenciamento de projetos vum Editar Exibir Favoritos i EE oo REO Ke sa uda i Endere o cuiF1esimarcosiMackenzie TGIIProjetolelaboracaoiprototipolprototiposiindex htmi Figura 5 2 Comparativo de sistemas de gerenciamento de projetos 52 PROJETO 5 2 2 Arquitetura de Software Este documento fornece uma vis o geral da arquitetura que pode modelar os diferentes aspectos do sistema E utilizado tamb m para a comunica o do arquiteto de software com os outros membros do projeto A cria o da hierarquia de pacotes foi fundamental neste documento quando foi definida a vis o l gica do sistema O intuito era dividir e organizar as classes que seriam implementadas posteriormente e por isso os pacotes foram criados seguindo um padr o conforme o exemplo abaixo net sgp empresa Pacote respons vel pelo cadastro de clientes empresas Neste artefato foram descritos tamb m a representa o objetivos e limita es da arquite tura A representa o da arquitetura esta baseada na arquitetura de refer ncia JEE Java Enter prise Edition da empresa Sun Microsystems Devido a este fato muitos dos mecanismos t cni cos
25. Rumbaugh e Booch 2005 o diagrama de artefatos usado comu mente para 32 UML UNIFIED MODELING LANGUAGE Fazer a modelagem de c digo fonte figura 3 4 Fazer a modelagem de vers es execut veis figura 3 5 Fazer a modelagem de banco de dados f sicos figura 3 6 Fazer a modelagem de sistemas adapt veis figura 3 7 signal h signal h signal h version 3 5 version 4 0 version 4 1 IN N Signal cpp No version 4 1 Li E device cpp Figura 3 4 Exemplo de Diagrama de Artefatos modelagem de c digo fonte Fonte Jacobson Rumbaugh e Booch 2005 p 402 m path dll collision dll Path manifest s lt S S 1 1 1 I I i i y IDrive S Driving Figura 3 5 Exemplo de Diagrama de Artefatos modelagem de vers es execut veis Fonte Jacobson Rumbaugh e Booch 2005 p 404 manifest lt a driver dll version 8 1 3 2 UML UNIFIED MODELING LANGUAGE 33 school db course department instructor school student Figura 3 6 Exemplo de Diagrama de Artefatos modelagem de banco de dados f sicos Fonte Jacobson Rumbaugh e Booch 2005 p 406 O banco de dados school no Servidor B replica o banco de dados no Servidor A Servidor A Servidor B Figura 3 7 Exemplo de Diagrama de Artefatos modelagem de sistemas adapt veis Fonte Jacobson Rumbaugh e Booch 2005 p 407 3 3 7 Diagrama de caso de
26. Selecionada Este fluxo ocorre quando n o foi selecionada nenhuma tarefa para as op es de alterar ou excluir Emitir mensagem Selecione uma tarefa para alterar ou excluir Tarefa com andamento cadastrado Este fluxo ocorre quando existe um ou mais registros de andamento de tarefa para a tarefa que se deseja excluir Emitir mensagem N o poss vel excluir a tarefa selecionada pois existem andamento de tarefas cadastrados Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como administrador ou gerente de projetos Condi es Posteriores Ap s a execu o do caso de uso gerar log da opera o executando caso de uso UCO9 Gerar Log de Acesso REFER NCIAS ANEXOS 73 A2 4 5 UC05 Manter Projetos Breve Descri o Este caso de uso tem como finalidade cadastrar alterar ou excluir Projetos do sistema proposto Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o administrador ou o Gerente do Projeto vai cadastrar alterar ou excluir um projeto no sistema Cadastrar Projetos O Gerente de Projetos dever informar os seguintes dados no formul rio 1 Empresa 6 Data final 2 Nome do projeto 7 Prioridade 3 Descri o 8 Status Ativo Inativo 4 Ger Projeto respons vel 9 Or amento 5 Data de in cio Campos obrigat rios Depois disso dever clicar no bot o Incluir Alterar Projetos O administrad
27. Software Livre O programa faz parte do Gnome Office estando assim inclu do em diversas distribui es Linux As caracter sticas e interface lembram muito o MSPro ject O banco de dados utilizado o PostgreSQL recomendado para usu rios que trabalham com esta es Linux possuem conhecimentos de informativas mais avan ados e necessitam cal cular o caminho cr tico de um projeto IMENDIO 2007 O Real Time Project tem como pontos fortes o cronograma a estrutura anal tica do proje to o controle de recursos e o controle de custos Est dispon vel para Unix Linux Windows e Macintosh em forma de bin rios espec ficos Sua interface bastante amig vel e o competidor direto do MSProject recomendado para empresas ou usu rios que necessitem de uma solu o abrangente de gerenciamento de projetos AMS 2007 E por fim pode se citar o MSProject da Microsoft N o diferente de muitas outras solu es Microsoft o MSProject n o Open Source Pode se importar dados de planilhas e bases de dados transformando os em informa es de folhas de projetos Possibilita a integra o com as demais ferramentas Office da Microsoft tais como Outlook Excel e Word um dos softwares de gerenciamento de projetos mais utilizados e vendidos no mercado MICROSOFT 2007 No mundo da web 2 0 pouco importa onde est o usu rio num PC num celular ou em qualquer ou tro dispositivo que entenda o significado da palavra rede O softwar
28. Y tar codigo INTEGER FK Y fun cpf INTEGER FK PRONTO mm x N pro codigo INTEGER fun cpf INTEGER FK lt emp codigo INTEGER FK 9 pro dt inicio DATE 9 pro dt final DATE Q pro descricao VARCHAR 255 Q pro prioridade INTEGER Q tar hs estimadas FLOAT BI H Q pro status BOOL pro progresso FLOAT pro nome VARCHAR 30 Q pro orcamento FLOAT ANDAMENTO TAREFA 7 Y and tar codigo INTEGER fun cpf INTEGER FK gt t Q fun email contato VARCHAR 30 gt H 9 tar codigo INTEGER FK Q and tar hs trabalhadas INTEGER and tar data DATE 9 and tar descricao VARCHAR 255 N FUNCIONARIO Y N fun cpf INTEGER 4 dep codigo INTEGER FK 9 fun nome VARCHAR 30 fun rg INTEGER 9 fun senha VARCHAR 10 9 fun dt nascimento DATE 9 fun_cargo VARCHAR 15 fun ddd telefone INTEGER fun num telefone INTEGER 19 fun rua VARCHAR 30 9 fun numero VARCHAR 20 fun bairro VARCHAR 30 fun cidade VARCHAR 30 fun estado VARCHAR 30 fun pais VARCHAR 30 9 fun complemento VARCHAR 30 fun cep INTEGER 9 fun tipo INTEGER 9 fun status VARCHAR 1 H 9 dep nome VARCHAR 30 9 dep descricao VARCHAR 255 PERMISSAO ki t per codigo INTEGER 9 per descricao VARCHAR 255 Q per pagina VARCHAR 3D
29. adotados como persist ncia ambiente e distribui o utilizar o esta arquitetura de refer ncia O documento de arquitetura de software contemplou tamb m as vis es de implementa o e implanta o onde procurou representar graficamente como o sistema dividido em camadas implanta o e como est o alocas as classes implementa o 5 2 3 Modelo de Design O modelo de design uma abstra o da implementa o do sistema proposto Nele foram defini das as realiza es dos Casos de usos e as classes est ticas do sistema As classes est ticas do sis tema foram representadas graficamente no diagrama de classes recurso da UML conforme a nexo B As entidades Empresa Funcion rio Projeto entre outras e suas rela es entre si de a grega o e composi o foram identificadas Para cada entidade foram identificados os seus atri butos e seus tipos de dados como Integer Double e String A cria o deste diagrama foi basea da na leitura e interpreta o do documento de caso de uso da fase de Concep o Somente atra v s dos Casos de usos pode se levantar as entidades relevantes e a partir da identificar os seus atributos Nem todos os atributos est o de forma expl cita Alguns como o c digo do Projeto fo ram colocados no intuito de ter um atributo nico no objeto instanciado para diferenciar de ou tros objetos de mesmo tipo Outro item importante neste documento foram as realiza es tamb m conhecidas
30. aspecto da vis o est tica de caso de uso do sistema Cont m somente os casos de uso e atores essenciais compreens o desse aspecto Fornece detalhes consistentes com seu n vel de abstra o N o t o minimalista que informe mal o leitor sobre a sem ntica que importante Para definir um diagrama de caso de uso Jacobson Rumbaugh e Booch 2005 p 250 tamb m sugerem que Dar um nome capaz de comunicar seu prop sito Distribuir seus elementos para minimizar o cruzamento de linhas Organizar seus elementos espacialmente de maneira que os comportamentos e pap is semanticamente relacionados apare am pr ximos fisicamente Usar notas e cores como indica es visuais e chamar aten o para caracter sticas im portantes do diagrama UML UNIFIED MODELING LANGUAGE 35 Tente n o mostrar muitos tipos de relacionamentos Em geral se existir relacionamen tos de inclus o e estendido complicados colocar esses elementos em outro diagrama 3 3 8 Diagrama de seqii ncia Segundo Jacobson Rumbaugh e Booch 2005 um diagrama de segii ncia enfatiza a ordem tem poral das mensagens Isso pode ser visualizado melhor na figura 3 9 c Client I p ODBCProxy create Transaction setActions a d o setValues d 3 4 setValues a CO commited demoro SK pe Se Figura 3 9 Exemplo de Diagrama de Seqii ncia Fonte Jacobson Rumbaugh e Booch
31. atributos s o declarados como protegidos existe a possibilidade de eles serem acessados diretamente por m todos das subclasses aumentando de forma eficaz o acoplamento em uma hierarquia de classes Como esse procedimento dificulta a manuten o e a implementa o de melhorias nas classes deve ser evitado Os atributos nunca devem ser acessados direta mente Para acess los use m todos de acesso veja abaixo Visibilidade Descri o Uso adequado P blico Pode ser acessado por outro m todo em N o crie atributos p blicos outro objeto ou classe Protegido Pode ser acessado por m todo da classe N o crie atributos protegidos REFER NCIAS ANEXOS 137 na qual ele est declarado ou por qualquer m todo definido em subclasses dessa classe Privado Pode ser acessado por m todos da classe Todos os atributos devem ser na qual ele est definido mas n o nas privados e acessados por m todos subclasses getter e setter acessos N o ocultar nomes Ocultamento de nome se refere pr tica de atribuir a uma vari vel local a um argumento ou a um atributo um nome igual ou semelhante ao de outro com escopo mais amplo Por exem plo se um atributo foi denominado firstName n o crie um par metro ou vari vel local denomi nado firstName ou parecido com firstNames ou fistName Isso dificultar a compreens o do c digo e ele ficar sujeito a erros porque os outro
32. como diagramas de segii ncia O diagrama de seqii ncia tamb m um recurso da UML e visa ter um panorama da implementa o dos Casos de usos Para cada Caso de uso implementado o diagra ma mais importante que os desenvolvedores tinham em m os era o de seq ncia Neste diagrama est o previstos os objetos e suas trocas de mensagem m todos em tempo de execu o assim como as passagens de par metros necess rias para se ter algum processamento no sistema Nestas realiza es foi aplicado um pattern para que o sistema fosse inteiramente padro nizado possibilitando que o c digo fonte ficasse entend vel e que os objetos n o tivessem muita liga o ou seja acoplamento O pattern escolhido foi o MVC Model View Controller que de fine uma camada de apresenta o JSP Java Server Pages Servlet outra de controle EJB Enterprise Java Beans e objetos de neg cio e a ltima de persist ncia acesso ao banco de da dos Cada camada tem um objetivo espec fico PROJETO 53 A camada de apresenta o respons vel em receber as solicita es dos usu rios e di recion las aos objetos de neg cios Ap s o processamento das informa es os resul tados s o mostrados ao usu rio na tela do browser nesta camada que o usu rio inte rage com o sistema A camada de controle respons vel em controlar toda a transa o que foi ativada por um usu rio no sistema Esta camada recebe as solicita es da camada a
33. de Membro Descreve as exce es que uma fun o de membro description aciona Use uma marca por exce o e informe o nome completo da classe referente exce o O param name Fun es de Membro Usada para descrever um par metro passado para description uma fun o de membro inclusive seu tipo ou classe e sua utiliza o Use uma marca por par metro return description Fun es de Membro Descreve o valor de retorno se houver de uma fun o de membro Indique o tipo ou a classe e os poss veis usos do valor de retorno since Classes Fun es de Indica o tempo de exist ncia do item ou seja Membro desde o JDK 1 1 see ClassName Classes Interfaces Gera um link de hipertexto na documenta o para Fun es de Membro a classe especificada Voc pode e Campos provavelmente deve usar um nome de classe 128 REFER NCIAS ANEXOS totalmente qualificado see ClassName member functionName Classes Interfaces Fun es de Membro Campos Gera um link de hipertexto na documenta o para a fun o de membro especificada Voc pode e provavelmente deve usar um nome de classe totalmente qualificado 9 version text Classes Interfaces Indica as informa es sobre vers o de determinado trecho do c digo A maneira como voc documenta o c digo causa grande impacto tanto na sua produtivi dade quanto na produtividade d
34. de os projetos serem cada vez mais complexos e com prazos mais curtos para seu desenvolvimento O gerenciamento de projetos possibilita atrav s de diversas metodologias o cumprimento destes prazos alcance de metas e a conquista de credibilidade junto ao cliente Os projetos existem em todos os momentos desde o pessoal at o profissional na organi za o de uma festa no lan amento de um novo produto ou no desenvolvimento de um novo sis tema Prado 2003 Prado 2003 p 57 afirma que um projeto pode ser definido como bem sucedido quando Atingiu as metas estabelecidas Atendeu s expectativas dos envolvidos no projeto Obteve m nimas mudan as em seu escopo N o violentou valores ou cultura da organiza o N o violentou o fluxo usual da organiza o Segundo Prado 2003 p 19 o gerenciamento de projetos surgiu na d cada de setenta e desde ent o tem evolu do constantemente estando presente hoje em dia em quase todos os ramos de atividade como mecanismo fundamental para atingir o sucesso Uma grande dificuldade encontrada em gerenciamento de projetos fazer com que este n o atinja o fracasso Pesquisas t m comprovado que a ocorr ncia de fracassos muito comum em algumas reas de ne g cios os n meros chegam a assustar Por exemplo na ind stria de desenvolvimento de software pesquisas da Gartner Group apontam que apenas 20 dos projetos s o bem sucedidos Prado 2003 Vargas 2006 p
35. descri o data e horas trabalhadas do andamento da tarefa Cada andamento da tarefa dever conter um link para poder ser alterado UC11 Manter Andamento da Ta refa Somente os andamentos que foram cadastrados por outro usu rio da mesma tarefa n o poder o ter link para altera o Fluxos alternativos Nenhum Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema Condi es Posteriores Nenhuma REFER NCIAS ANEXOS 85 A2 4 14 UC14 Exibir dados dos projetos em andamento Breve Descri o Este caso de uso tem como finalidade mostrar dados de todos os projetos que a empresa est administrando Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o diretor da empresa quer ver os projetos que est o em andamento O sistema ir capturar todos os projetos que est o em andamento e apresentar na tela uma lista contendo o nome descri o e progresso de andamento do projeto Ap s isso o dire tor ter a possibilidade de visualizar mais informa es como data de in cio data de t r mino prioridade cliente e status atual do projeto clicando em Detalhes na lista Fluxos alternativos Nenhum Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como diretor Condi es Posteriores Nenhuma 86 REFER NCIAS ANEXOS ANEXO B FASE ELABORA O B1 Documento de arquitetura de software B1 1 Objetivo
36. do desenvolvimento em ferramentas processos e m todos neste processo que definida a sistem tica de sele o aquisi o instala o e configu ra o de ferramentas pertinentes ao processo de desenvolvimento cria o e evolu o dos pro cessos manuten o de infra estrutura procedimentos de c pias de seguran a e outras rotinas pertinentes ao desenvolvimento Artefato trabalhado neste processo Modelo de Desenvolvimento PROJETO 49 CAP V Projeto Devido aos fatos anteriormente mencionados neste trabalho ser desenvolvido um Sistema de Gerenciamento de Projetos com caracter sticas e funcionalidades semelhantes aos demais exis tentes por m com foco diferenciado Como o objetivo estudar a metodologia RUP com desenvolvimento orientado a objetos n o ser desenvolvida uma ferramenta complexa de gerenciamento de projetos e sim ser abor dado de forma acad mica as dificuldades que os stakeholders enfrentam em seu cotidiano Neste cap tulo ser explorado como o projeto foi desenvolvido 5 1 Fase Concep o O objetivo desta fase a identifica o do que ser constru do quais ser o as funcionalidades do sistema determinar pelo menos uma poss vel solu o definir o prazo o custo e os riscos decidir qual processo seguir e quais ferramentas e tecnologias ser o utilizadas Nesta fase foram elaborados os seguintes artefatos Documento de Vis o ver Anexo A Caso de Uso ver Anex
37. eje poo ejare aqpojuewepuyiessng ST a i i Jere poo ejare ecsojueurepuyuecsnq ET i i i i i I DEEL Es Ovqejarej TEE EEN Sejem ap ojueurepue ecsnq 7 i H i 1 i ess DEE CEET 1 ouersn louer sojuauepuyao A ds Saa ep ojweurepuy Elei SION ps REFER NCIAS ANEXOS 117 B2 1 14 UC14 Exibir dados dos projetos em andamento ojaloid op ojusulepuy Je nsuo O LON OU opelu uu lduu ep Sojo biclsopoLi A ds Sususpuw uie sojo load sop sopeg Jara tION PS 118 REFER NCIAS ANEXOS B2 2 Diagrama de classes Bums Imeu Jebeju oBipoo POH ojusuedo yeoly ossaubold Jobaju euojeje j uunu Jobeju euojeje 1ppp Jeu snis Jobeju ounJdi Buus oe SIE Ou u SeN pP Buus euues Jobeju jdo JoBoju Di J4eDeju ojueureyedep Bums euou BUMS oeouosep Buus auwou JeBeju obipoo L jenesuoc al inssod Buys oeouosop leq eiep oH sepeyjeqeljsu Jee poo BJEJELOJUALEPUY Duus euiDed Buus oeouosep Jobeju obipoo 1oBajuj obipoo ayeq jep Buus oeoLosop 186sjuj di 0 uesjoog sns JoBoju epepuoud emu jeump erg opupp Buys oeouosop JoBaJu ajuapsoa gejele L Buus oleloidetuou 1oBajuj oDipoo in sod
38. executa dentro do sistema uma fun o espec fica ou pode ser criado para trabalhar com outros componentes j existentes 3 3 3 Diagrama de estrutura composta Jacobson Rumbaugh e Booch 2005 p 97 definem um diagrama de estrutura composta o dia grama que apresenta a estrutura interna de uma classe ou colabora o Esse diagrama possui pouca diferen a em rela o ao diagrama de componentes e Jacobson Rumbaugh e Booch 2005 tratam os dois como diagrama de componentes 3 3 4 Diagrama de objetos O diagrama de objetos definido por Jacobson Rumbaugh e Booch 2005 p 188 como sendo o diagrama que faz a modelagem de inst ncias de itens contidos em diagramas de classes Em ou tras palavras pode se dizer que o diagrama de objetos mostra o conjunto de objetos e relaciona mentos em determinado ponto no tempo Assim como o diagrama de classes possibilita a visualiza o de maneira est tica por m atrav s de inst ncias reais ou protot picas figura 3 2 c Empresa departamento di Departamento departamento d2 Departamento rane a d3 Departamento nome Vendas EUA gerente p Pessoa nome Ee c digoFuncion rio 4362 cargo Vice presidente de Vendas d Informa esDeContato contato endere o 1472 Miller St Figura 3 2 Exemplo de Diagrama de Objetos UML UNIFIED MODELING LANGUAGE 31 Fonte Ja
39. gerenciamento Prado 2003 define metodologia como I conjunto de t cnicas regras e m todos orientados para um fim em comum I Sendo assim pode se dizer que uma metodologia o mecanismo utilizado para definir um padr o a ser seguido por todos os stakeholders e muito necess ria para que um projeto pos sua maiores chances de atingir seu principal objetivo o sucesso A metodologia a ser utilizada no gerenciamento de projetos pode ser desenvolvida pela organiza o ou simplesmente pode se adotar metodologias j existentes no mercado Segundo Prado 2003 p 140 uma metodologia de gerenciamento de projetos deve con templar os processos de gerenciamento e as reas de atua o gerencial ou seja deve se utilizar uma metodologia que possibilite que o gerente de projeto tenha o maior controle poss vel sobre este desde o in cio at a conclus o 2 1 PMBOK O Project Management Body of Knowledge PMBOK do Project Management Institute PMI n o uma metodologia e sim um guia do conjunto de conhecimentos em gerenciamento de pro jetos O guia PMBOK identifica os pontos pertinentes que s o aplic veis na maioria dos proje tos em boa parte do tempo Apresenta uma vis o geral e n o algo com muitos detalhamentos 18 GERENCIAMENTO DE PROJETOS Mostra que com a aplica o correta de habilidades ferramentas e t cnicas as chances de um projeto atingir o sucesso s o grandes A estrutura do guia PMBOK orga
40. m todo withdraw de uma conta banc ria modifica o saldo dessa conta Essas informa es s o necess rias para que outros programadores Java saibam exata mente como o disparo de um m todo afetar o objeto de destino Evite o uso de cabe alhos que contenham informa es como autor n meros de te lefone datas de cria o modifica o e localiza o de unidades ou nome de arquivo porque elas ficam rapidamente obsoletas Coloque os avisos de direitos autorais no fim da unidade Por exemplo os leitores n o querem percorrer duas ou tr s p ginas de tex to que n o s o teis para a sua compreens o do programa nem querem passar por tex to que n o contenha qualquer informa o espec fica do programa como um aviso de direitos autorais Evite o uso de barras verticais ou quadros e caixas fechados pois eles apenas criam confus o visual e s o dif ceis de manter a consist ncia Use uma ferra menta de gerenciamento de configura o para manter um hist rico de unidades Exemplos de como disparar o m todo se apropriado Uma das maneiras mais f ceis de determinar como um trecho do c digo funciona verificar um exemplo Con sidere a possibilidade de incluir um ou dois exemplos sobre como disparar um m todo Precondi es e p s condi es aplic veis Precondi o uma restri o segundo a qual um m todo funcionar corretamente P s condi o uma propriedade ou afirma tiva que ser verdadeira depois d
41. o 2 Data 4 Progresso de andamento da tarefa Campos obrigat rios Depois disso dever clicar no bot o Incluir OBS Funcionalidade que qualquer usu rio do sistema pode realizar desde que tenha al guma tarefa vinculada ao mesmo Alterar Andamento da Tarefa O administrador dever selecionar o andamento da tarefa que deseja alterar Os dados do andamento da tarefa ser o carregados na tela Ap s alterar os dados o usu rio poder cli car no bot o Alterar para que os dados possam ser alterados no sistema Excluir Andamento da Tarefa O administrador dever selecionar o andamento da tarefa que deseja excluir e clicar no bot o Excluir para que os dados possam ser exclu dos no sistema Fluxos alternativos Dados Incompletos Este fluxo ocorre quando algum campo obrigat rio n o foi preenchido no formul rio 82 REFER NCIAS ANEXOS Emitir mensagem dos dados que est o faltando e colocar o foco no primeiro campo incor reto Andamento da Tarefa N o Selecionada Este fluxo ocorre quando n o foi selecionado nenhum andamento de tarefa para a op o de excluir ou alterar Emitir mensagem Selecione um andamento de tarefa para excluir ou alterar Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema Condi es Posteriores Ap s a execu o do caso de uso gerar log da opera o executando caso de uso UCO9 Gerar Log de Acesso Tamb m dev
42. o distribu dos entre os n s da rede Modelo de implementa o descreve como os elementos do sistema ser o desenvol vidos Modelo de Neg cio mostra como o neg cio visto pelos atores externos da UML Modelo de teste descreve como os componentes do Modelo de implementa o ser o testados 4 3 Fases No RUP o projeto composto por quatro fases Concep o Elabora o Constru o e Transi o Estas fases n o t m que seguir uma seqii ncia tradicional que consiste em requisitos anali se programa o integra o e testes Segundo Kroll e Kruchten 2003 p 35 cada uma das fases do RUP tem um marco e um conjunto de objetivos bem definidos Deve se fazer uso destes objetivos como um guia para a decis o de quais atividades devem ser levadas a diante e quais artefatos devem ser produzidos Cada fase termina em um marco relevante para o projeto como um todo em que uma de cis o importante dever ser tomada continuar e aprovar os recursos para a pr xima fase ou can celar o projeto Estas fases s o executadas em um ou mais ciclos de desenvolvimento abordagem esta que foi criada para ser din mica e adaptativa podendo acomodar mudan as de objetivos e estra t gias de desenvolvimento muito comuns nos projetos de sistemas Concep o nesta fase a preocupa o estabelecer uma vis o do sistema do ponto de vista do neg cio permitindo avaliar se o projeto ou n o vi vel Elabora
43. objetivo desta fase assegurar que a arquitetura os requisitos e os planos sejam est veis o su ficiente Nesta fase os riscos devem ser diminu dos a fim de determinar com seguran a o custo e a programa o para a conclus o do desenvolvimento e produzir um prot tipo naveg vel do sis tema Nesta fase foram desenvolvidos os seguintes artefatos Prot tipo naveg vel Documento de arquitetura de software Modelo de design Modelo de dados Guia de programa o 5 2 1 Prot tipos O prot tipo tem como objetivo fornecer uma apar ncia visual do sistema Os aspectos analisados na produ o do prot tipo naveg vel foram defini o de padr es de layout como p ginas de ca dastro e de cadastro e utiliza o de cores Inicialmente a prototipa o do sistema foi elaborada no software Access 2003 da empresa Microsoft Esta decis o foi tomada pelo fato do software possuir v rios recursos para se montar um modelo de p gina rapidamente Neste momento foram concentrados os esfor os para identi ficar como ficaria a disposi o dos componentes no formul rio e quais informa es de texto se riam postas nas p ginas ver Figura 5 1 Depois de definido essas vari veis o prot tipo foi re constru do para portar a plataforma web Tecnologias como o HTML Hyper Text Markup Lan guage CSS Cascading Style Sheets foram utilizadas para dar a visualiza o navega o e usa bilidade do sistema ver Figura 5 2
44. omun mE PoaqimueW ppeseuoissssojslo1g sua alebajegsssursngoje o1 deque sojalaidjeosnq sn SO baq Jeosna ps REFER NCIAS ANEXOS 101 Alterar Projeto T oistouajoiefoicsopecreien te 17 Gplouig oploxsopeomiae de I orlomoelocsopegriap 018 fBucpoojors laico pequena oia foid asfacposjojs oi popegesna eru LL ojeloigposjorelaipopegjesenq ele Le A A ore e1dorsfai sopeqreraye Sesaidugjesnq er EE gt Gi luqpoo otploissopacueosnq oeod eie Caro aos 1s S orroud dos 1s TETE UT S pone EH NH Gelee eem zl op auawa ema mim ps 102 REFER NCIAS ANEXOS Cadastrar Projeto H T i H I 1 A gt i f i i gt x i Qebuj o buueisepeo i eo g oje lo qrensepeo q i i e i D 01a foug oie a grensepeo 1 i 1 alo djojelo persepeo I e H TEIBEPED i i i I EE i i i I i i i Jensepeo Soiefod ap ouso ojo lo quensepeo preloicioonsepeo Polaroid dos 1s e TH 15535019 PIJEN srepsreasseursngore PIJEN joneve Pidrensepes dsp ds ei ojeloid Jensepeo ps REFER NCIAS ANEXOS 103 Exclui
45. processos e me canismos de concorr ncia e sincroniza o Implementa o correspondem aos componentes subsistemas e arquivos que ser o usados na composi o do sistema Implanta o o objetivo desta vis o fornecer informa es sobre a distribui o e ins tala o das partes f sicas do sistema 28 UML UNIFIED MODELING LANGUAGE 3 2 Utiliza o Segundo Sommerville 2005 a UML tem um vasto conjunto de utiliza o sua principal fun o a modelagem de regras de neg cio e especifica o de sistemas abrangendo tanto os aspectos estruturais como os din micos de um software utilizada para modelar os mais diversos tipos de sistemas fornecendo tamb m diferen tes vis es Pode ser aplicada em todas as fases do desenvolvimento desde a an lise de requisitos at os testes finais passando pela implementa o e especifica o t cnica Jacobson Rumbaugh e Booch 2005 Segundo Jacobson Rumbaugh e Booch 2005 p 17 a UML se destina principalmente a sistemas complexos de software tendo emprego de maneira efetiva em alguns casos tais como sistemas de informa es corporativos de telecomunica es cient ficos e de servi os banc rios e financeiros 3 3 Principais Diagramas Jacobson Rumbaugh e Booch 2005 definem como sendo um diagrama a apresenta o gr fica de um conjunto de elementos geralmente representada como um gr fico conectado de v rtices itens e arcos relacionamentos
46. ser documentados para cada m todo criado Documenta o interna Al m da documenta o de m todos voc tamb m precisa incluir coment rios que des crevam o seu trabalho O objetivo facilitar a compreens o a manuten o e a implementa o de melhorias nas fun es de membro H dois tipos de coment rios que podem ser usados para documentar as especifica es internas do c digo os coment rios de estilo C e e os coment rios em uma nica linha Como abordado anteriormente voc deve considerar a possibilidade de escolher um estilo de coment rios para documentar a l gica do neg cio do c digo e outro para comentar os c digos n o necess rios Utilize coment rios em uma nica linha para a l gica do neg cio pois esse esti lo pode ser usado para linhas de coment rios inteiras e para coment rios in line que continuem at o fim de uma linha de c digo Use os coment rios de estilo C para documentar linhas de c digo desnecess rio pois eles facilitam a retirada de v rias linhas do c digo com apenas um co ment rio Al m disso como os coment rios de estilo C s o muito semelhantes aos coment rios de documenta o sua utiliza o pode causar confus o reduzindo a compreens o do c digo Sendo assim n o os utilize com freq ncia Internamente voc sempre deve documentar o seguinte Estruturas de controle Descreva cada estrutura de controle como senten as de compara o e ciclos
47. uesjoog eniysnjes kat i yeoy sepeuregejsu f o Em IO Ssepeuns3sy erg WHP emg obunp yeoly ojueuepuyDoid Buus oeoucsep Jobeju epepuoud Buus suou BJoJeL wa Buus Imeu Buujs ojueujejduico 4eDeju euojejojuunu Jobeju deo Jebeju euojeje ppp Duue sed 19Bajuj un Buujs iopepa 4eDeju obipoo Buus pepp Buus ege Buus ou uuls 18 Buus oeunu L L Buus osouss p Buus en inssod Buujs eseidugeujou osalapuj essidua A PRO Rea po B3 Modelo de dados REFER NCIAS ANEXOS 119 B3 1 MER Modelo Entidade Relacionamento 9 emp codigo INTEGER Q emp nome VARCHAR 30 emp nome resp VARCHAR 30 emp descricao VARCHAR 255 Q emp site VARCHAR 30 4 emp num telefone INTEGER Q emp ddd telefone INTEGER 4 emp email contato VARCHAR 30 Q emp rua VARCHAR SO Q emp numero VARCHAR 20 emp bairro VARCHAR 30 emp cidade VARCHAR 30 Q emp estado VARCHAR 2 4 emp pais VARCHAR 30 Q emp complemento VARCHAR 30 Q emp cep INTEGER Q emp cnpj INTEGER TAREFA W tar codigo INTEGER pro codigo INTEGER FK Q tar prioridade INTEGER O tar descricao VARCHAR 255 PH 9 tar prog andamento FLOAT Q tar dt inicio DATE Q tar dt final DATE Q tar hs trabalhadas FLOAT Q tar status atual BOOL Q tar precedente INTEGER Q tar nome VARCHAR 30 eis TAREFA FUNCIONARIO v
48. 1 Manter Ae 777 Logs de Tarefas Ucos Verificar Lee Permiss es ci nolude ud Use Case Model UC05 Manter Projetos a indudes e E eee EN Es de Acesso er i UC04 Manter Ead Gerente de Proje Taretas D __ 7 include extend gt UCOS Vincular Funcion rios Cetro paliza UC08 Verificar Login indude Permiss es UC11 Manter UCOS Gerar Log Andamento da gt Ges Trea include SSO Usuario UC13 Visualizar UC12 Visualizar _ ee Andamento de Tarefas extend Tarefas 66 REFER NCIAS ANEXOS A2 4 Especifica o dos Casos de Usos A2 4 1 UC01 Manter Funcion rio Breve Descri o Este caso de uso tem como finalidade cadastrar alterar ou excluir funcion rios que utili zar o o sistema de gerenciamento de projetos Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o administrador vai cadastrar alterar ou excluir um fun cion rio Cadastrar Funcion rio O administrador dever informar os seguintes dados do funcion rio em um formul rio 1 Nome 10 Bairro 2 Departamento 11 Cidade 3 CPF 12 Estado 4 RG 13 Pais 5 Senha 14 CEP 6 E mail 15 DDD telefone 7 Rua 16 N mero do Telefone 8 N mero da casa 17 Data de nascimento 9 Complemento do endere o 18 Tipo funcion rio Campos obrigat rios Depois disso dever clicar no bot o Incluir Ap s a inclus o do funcion rio o adm
49. 4 4 8 Gerenciamento de Projeto Segundo Kruchten 2004 p 95 gerenciamento de projeto de software consiste em balancear ob jetivos concorrentes gerenciando o risco e todas as restri es do projeto para entregar um produ to que atenda as necessidades do cliente O fato de pouco projetos terem 100 de sucesso um indicador de como dif cil realizar esta tarefa Este modelo tem tr s prop sitos Prover uma estrutura para gerenciar projetos de software Prover guias para planejamento gerenciar as pessoas envolvidas no projeto execut lo e monitor lo Prover uma estrutura de gerenciamento de riscos No entanto esta disciplina do RUP n o tem por objetivo cobrir todos os aspectos do ge renciamento de projetos tais como contrata o de pessoal treinamento gerenciamento de or a mento contratos com fornecedores nem clientes O objetivo desta disciplina consiste em planejar um projeto iterativo atrav s do seu tempo de vida gerenciamento de riscos e monitora o do progresso e as medi es do progresso iterativo do projeto 4 4 9 Ambiente Este processo tem por objetivo definir os processos e ferramentas que proporcionem a imple menta o do sistema Deve se avaliar a cultura atual da empresa definir se uma lista de ferra mentas que podem ser utilizadas e modelos de documentos que ser o necess rios Segundo Kruchten 2004 p 190 a meta do fluxo de ambiente fornecer suporte ade quado para a organiza o
50. 44 diz que Projeto problem tico pode ser definido como um projeto cuja varia o entre o esperado e o realiza do excedeu os limites de toler ncia aceit veis As vezes definir o n o sucesso de um projeto como fracasso injusto at mesmo para com o gerente em quest o pois fatores externos e internos podem interferir na sua entrega como por exemplo um concorrente lan ar um produto com melhor competitividade de mercado Neste momento o projeto em quest o n o falhou e sim teve um desvio de meta Vargas 2006 p44 apresenta diversos fatores que podem identificar um projeto problema Esses indicadores podem estar relacionados com os stakeholders os recursos a do cumenta o o escopo os ricos os custos e s prazos Veja na figura abaixo o mapa mental dos indicadores de um projeto problem tico Var gas 2006 p45 Stakeholders Todos os envolvidos no projeto Como por exemplo gerentes consultores clientes analistas e programadores GERENCIAMENTO DE PROJETOS 17 insatisfa o evidente ou disfar ada com o projeto Aumento na informalidade dos B ol to do ci aixo envolvimento do cliente g mia tam toi lido io to A processos e no improviso Formaliza o e _ ES Stakeholders Documenta o Cliente n o est preparado para assumir suas pr prias responsabilidades no projeto Diminui o na frequ ncia e confiabilidade da atualiza o dos dados do plano
51. ETO 55 1 Cria o do banco de dados A partir do MER Modelo Entidade Relacional fo ram gerados os scripts SQL Structured Query Language 2 Cria o das procedures Nesta etapa foram criadas todas as consultas de acesso ao banco de dados 3 Carga na tabela PERMISS O Esta tabela contempla todas as permiss es que o sistema de gerenciamento de projetos ter As permiss es est o descritas no caso de uso UC02 Vincular Permiss es conforme anexo A Caso de Uso 4 Montagem do ambiente de desenvolvimento Nesta atividade foi criado na ferra menta de desenvolvimento Eclipse o ambiente do desenvolvedor Este ambiente compreende se basicamente na constru o do arquivo build xml respons vel em compilar e gerar o programa execut vel al m de copiar e compactar os arquivos do sistema como imagens javascripts arquivos do java arquivos XML Extended Markup Language entre outros Neste ambiente tamb m foi criado a estrutura de pacotes que est de acordo com o documento de arquitetura que se encontra no anexo B Como o programa utilizou o banco de dados MySQL 5 0 e o framework de apresenta o Struts da empresa Jakarta os arquivos JAR arquivos compacta dos tiveram que ser incorporados no classpath do Eclipse e ao projeto Com o ambiente praticamente terminado as estruturas das classes foram criadas nos seus respectivos pacotes 5 A partir da os Casos de usos foram codificados Primeiramente foram implemen ta
52. Este documento apresenta um panorama geral do sistema utilizando diferentes vis es de arquite tura que possam modelar os diferentes aspectos do sistema A inten o apresentar as decis es arquiteturais feitas sobre o sistema Tamb m s o representados diferentes n veis de abstra o do projeto bem como suas rela es B1 2 Representa o da Arquitetura A arquitetura de software a defini o e a representa o de uma estrutura para a composi o do sistema em termos de seus componentes propriedades e intera es A arquitetura deste sistema est baseada na arquitetura de refer ncia JEE da Sun Microsystems Portanto a representa o desta arquitetura contempla apenas aspectos particulares a este sistema que seguem as defini es da arquitetura de refer ncia Est o representados os casos de uso cr ticos agrupamento em pacotes e a implanta o do sistema B1 3 Objetivos e Limita es da Arquitetura Mecanismo de An lise Mecanismo de Projeto Mecanismo de Implementa o Conceitual Concreto Atual Persist ncia Banco de dados Relacional MyS JDBC via procedures QL Ambiente Servidor de Aplica es Weblogic 8 x ou JBoss 4 x x Distribui o RMI Java 1 4 da Sun ou superior B1 4 Vis o L gica A divis o de pacotes deste sistema segue a hierarquia definida na arquitetura de refer ncia Por tanto a defini o a seguinte Sistema sgp B1 4 1 Apresenta o Este sis
53. Implementa o Testes Distribui o Gerenciamento de configura o e mudan a Gerenciamento de projeto Ambiente 4 4 1 Modelagem do Neg cio Onde s o documentados os conceitos relativos ao neg cio Este documento ser refinado poste riormente medida que os casos de uso forem sendo detalhados Segundo Kruchten 2004 p 122 este modelo consiste em atores que representam pap is externos para o neg cio e os casos de uso s o os neg cios Os processos s o documentados atrav s de casos de uso enquanto as entidades pertinen tes s o representadas atrav s de diagramas de Entidade Relacionamento Este modelo mostra quem s o os participantes do neg cio os workflows as atividades as pessoas e suas fun es Segundo a Rational 2001 o modelo de neg cio tem os seguintes objetivos Modelar o neg cio como ele atualmente Descobrir redund ncias de atividades nos processos Identificar os gargalos Localizar possibilidades de melhorias nos processos Os artefatos que s o trabalhados neste processo s o os seguintes Documento da Vis o do Neg cio Modelo de Casos de Uso de Neg cio Modelo de Objetos do Neg cio Regras do Neg cio Gloss rio do Neg cio RUP RATIONAL UNIFIED PROCESS 43 4 4 2 Requisitos O processo de detecc o de requisitos tem v rios objetivos tais como estabelecer as fung es que o sistema deve desempenhar esbo ar a interface de usu
54. J 1997 The Java FAO Reading MA Addison Wesley Longman Inc LAF97 Laffra C 1997 Advanced Java Idioms Pitfalls Styles and Pro gramming Tips Upper Saddle River NJ Prentice Hall Inc LEA97 Lea D 1997 Concurrent Programming in Java Design Principles and Patterns Reading MA Addison Wesley Longman Inc MEY88 Meyer B 1988 Object Oriented Software Construction Upper Sad dle River NJ Prentice Hall Inc NAG95 Nagler J 1995 Coding Style and Good Computing Practices http wizard ucr edu nagler coding style html VIS96 Vision 2000 CCS Package and Application Team 1996 Coding Stan dards for C C and Java http v2ma09 gsfc nasa gov coding_standards html
55. Linux Windows Macintosh Planner Instala o Desktop Recursos de cronogramas rela Linux tivamente avan ados Windows Real Time Project Instala o Desktop Controle de cronograma estru Unix tura anal tica do projeto custos Linux e recursos Windows Macintosh MSProject Instala o Desktop Importa o de dados de plani Windows lhas e bases de dados trans formando os em informa es de folhas de projetos e a inte gra o com as demais ferra mentas da Microsoft Office Tabela 1 1 Comparativo de sistemas de gerenciamento de projetos UML UNIFIED MODELING LANGUAGE 27 CAP III UML Unified Modeling Language Ivar Jacobson James Rumbough e Grady Booch s o os fundadores da Unified Modeling Language ou UML como conhecida Esta linguagem utilizada como padr o de documenta o de projetos de software Sommerville 2005 Antes da jun o para a cria o da UML cada um deles estava desenvolvendo um m todo de documenta o diferente Ivar Jacobson da empresa Objectory desenvolvia o OOSE Grady Booch da empresa Rational Software Corporation o Booch e por fim James Rumbough da em presa General Eletrics o OMT Jacobson Rumbaugh e Booch 2005 Jacobson Rumbaugh e Booch 2005 iniciaram a cria o da linguagem por tr s motivos o primeiro porque os m todos j estavam evoluindo todos para uma mesma dire o O segundo porque a unifica o dos m todos traria alguma estab
56. R E Toast mp opeuopojes euspesad gjere e euopojas olad op sejarey se eosnq T loud o euopajes ol loxi o eosnq I i i i r H ejo1eLyOOnsepeo Ca EE sb esp iensepes dp sojefaid op eiae 5 P gjase Jensepeo ps REFER NCIAS ANEXOS 99 Excluir Tarefa D T ejare 1 poo ejere punpxo ejer 1pooje eue LINKS T I EC Sopenmsepeo ease ep soJuauepue LuAJSIXE siod epeuo ba es ejar e Amt IGAESOd 9 CEN Luef ein ovsmoxa vn outa ae fena ld I eja 1poo ejere Lunpxe j ejare Jpoo ejare Lunpxo O visHvi dos 1S waea jpeloosseuisngeje1eLieMelN JpeoesuoissesejeetaoiueIN REY FN UORO ejeJe IX jore n pxe opeuoperes ojelaid op sejais EES De Ojefaid o euopojes sojoloid sng amp joepyooesnioxe db ejomuamnioxe sb sojaloa ep equaled i PELI ps 100 REFER NCIAS ANEXOS B2 1 5 UCO5 Manter Projetos Buscar Projetos soiefaigreoeng Br1 soja foigessnq 817 soja fo qeosnq Br1 S SOL3roud dos LS Ovar
57. UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTA O E INFORM TICA BACHARELADO EM SISTEMAS DE INFORMA O Trabalho de Gradua o Interdisciplinar AN SIO RODRIGUES NETO MARCOS ALVES PEREIRA RODRIGO DE OLIVEIRA NEVES GERENCIADOR DE PROJETOS WEB JEE DESENVOLVIMENTO ORIENTADO A OBJETOS USANDO METODOLOGIA RUP UM ESTUDO DE CASO S o Paulo 2007 AN SIO RODRIGUES NETO MARCOS ALVES PEREIRA RODRIGO DE OLIVEIRA NEVES GERENCIADOR DE PROJETOS WEB JEE DESENVOLVIMENTO ORIENTADO A OBJETOS USANDO METODOLOGIA RUP UM ESTUDO DE CASO Trabalho de conclus o de Curso de Sistemas de Informa o da Universidade Presbiteriana Mackenzie apresentado como requisito parcial para a obten o do Grau de Bacharel em Sistemas de Informa o ORIENTADOR Prof MSc Vinicius Miana Bezerra S o Paulo 2007 UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTA O E INFORM TICA SISTEMAS DE INFORMA O Termo de Julgamento de Defesa de Trabalho de Gradua o Interdisciplinar Aos dias do m s de junho de 2007 s horas no pr dio sala da Universidade Presbiteriana Mackenzie presente a Comiss o Julgadora integrada pelos senhores Professores abai xo discriminados iniciou se a apresenta o do Trabalho de Gradua o Interdisciplinar do Grupo de Trabalho formado pelos alunos abaixo e conclu da a arglii o procedeu se ao julgamento na forma regulamentar tendo a Comiss o Julgadora atribu do as seguintes notas aos Ca
58. Visualizar Andamento de Tarefas esses 116 B2 1 14 UC14 Exibir dados dos projetos em apdamento rs 117 B22 Diagrama de class cional 118 B3 Modelo 119 B3 1 MER Modelo Entidade Relacionamento a 119 B3 2 Dicionariza o do Modelo ene en re vr ee ene e re ene boren eee rren nennen eee rrene bren eee 120 B3 2 1 Tabela EMPRESA cional 120 B3 2 2 Tabela PROJETO io discos 120 B3 2 3 Tabela TAREFA une egre date Tigi cis 121 B3 2 4 Tabela ANDAMENTO _TAREFA ennt ene veren none none venes 121 B3 2 5 Tabela FUNCIONARIO u a eroe conan derivon s r es Renee dn eret radio eee espere antas 121 B3 2 6 Tabela DEPARTAMENTO ivresse eeaeee netee d r tee tee idht itte tote d r sheutesd der 122 B3 24 Tabela PERMISS O ndasi siri test ed edo etr dhet ide trente ay la eres 122 B3 2 5 Tabela LOG ACA O instaba ed nt atento bt eite eds 122 ERSTEN 123 B4 1 Padr es de programa o em Java ane en eee neo eneve ee ore nnne nennen re eren eee 123 BA EL Objetivo nue Receta e Ue tae e nee tbe ed pd 123 B4 1 2 Padr es de Codificagao n nan nunay SB eene trennen tren 124 B4 1 3 Padr es para M todos E E P Ran Saa enne nennen tren 129 B4 1 4 Padr es para campos e propriedades sess 136 B4 1 5 Padr es para vari veis locais eee e enen rene ce
59. a rea cujo principal objetivo garantir que o projeto ser conclu do dentro da qualidade espera da garantindo desta forma a satisfa o de todos os envolvidos no projeto os stakeholders Os principais processos que correspondem ao Gerenciamento de Qualidade de Projeto s o PMBOK 2004 Planejamento da qualidade onde os padr es de qualidade que s o relevantes s o iden tificados e elaborada uma solu o de como satisfaz los Realizar a garantia da qualidade que o processo onde as qualidades que foram pla nejadas s o aplicadas nas atividades para garantir que o projeto empregue todos os processos necess rios para que atendam os requisitos Realizar o controle de qualidade que consiste no monitoramento para certificar que os padr es relevantes de qualidade est o sendo levados em considera o eliminando as sim um desempenho que n o seja satisfat rio Segundo o PMBOK 2004 Gerenciamento de Recursos Humanos do Projeto define os processo que organizam e gerenciam toda a equipe do projeto Paul Campbell Dinsmore e Fernando H Da Silveira Neto 2006 afirmam que GERENCIAMENTO DE PROJETOS 21 Se as pessoas falham em agir acompanhar tomar decis es analisar ou avaliar os projetos desvi am se do seu curso No fator humano pode se concentrar pelo menos metade dos problemas em projetos Ao dar se aten o a esse fator no gerenciamento de projetos pode se produzir lhe resultados positi vos P
60. acesso Sempre que uma classe externa precisar de acesso a um campo que o respectivo getter ou setter dever ser p blico para que esta classe possa modificar ou obter determinado valor des te campo REFER NCIAS ANEXOS 139 B4 1 5 Padr es para vari veis locais Uma vari vel local um objeto ou item de dados definidos no escopo de um bloco geralmente uma fun o de membro O escopo de uma vari vel local o bloco no qual ela est definida O padr o importante de codifica o para as vari veis locais enfatiza a declara o e conven o de documenta o que tem como conven o os elementos abaixo Declarar uma vari vel local por linha de c digo Isso est consistente com uma ins tru o por linha de c digo e possibilita documentar cada vari vel com um coment rio Documentar vari veis locais com um coment rio in line O uso de coment rios in line um estilo no qual um coment rio em uma nica linha denotado por vem logo ap s um comando na mesma linha de c digo procedimento este denominado comen t rio de fim de linha Documente para que onde e por que uma vari vel local deve ser usada Assim ser mais f cil entender o c digo Usar vari veis locais para um nico fim Sempre que voc usa uma vari vel local por mais de um motivo voc efetivamente diminui a coes o e dificulta a compreen s o Isso tamb m aumenta a probabilidade de introduzir erros no c digo causados por efei
61. al ou seja cada um tem a an lise de requisitos e riscos implementa o testes e implanta o Depois h outra itera o na qual novos requisitos s o tratados outros riscos s o considerados h mais an lise testes e implanta o at que o projeto seja conclu do ou cancelado Segundo Kruchten 2004 p 15 o problema b sico do desenvolvimento de software com as abordagens cl ssicas que o risco adiado tornando caro desfazer erros anteriores Esta abordagem permite um gerenciamento mais eficaz dos requisitos levando se em conta as constantes descobertas de necessidades que ocorrem ao longo do desenvolvimento do projeto mais f cil incluir novas id ias e necessidades ao projeto que desenvolvido de forma gradual produzindo se novos artefatos a cada itera o de desenvolvimento A equipe usa pro cessos repetitivos e previs veis que acaba convergindo para o objetivo final do projeto Kroll e Kruchten 2003 p 32 definem que com esta abordagem h dois grandes benef cios Permite que a equipe identifique os componentes que comp em o sistema de forma progressiva possibilitando que decida se quais ser o desenvolvidos internamente quais ser o reaproveitados e quais ser o comprados A integra o ao final do projeto n o considerada uma fase problem tica uma vez que os resultados de cada itera o s o integrados progressivamente ao longo de seu desenvolvimento O sistema final composto por v r
62. am Portfolio Management Rio de Janeiro n 10 p 42 49 ago set 2006 Bimestral REFER NCIAS ANEXOS 59 7 2 Bibliografia Complementar AHMED Khawar Zaman UMRYSH Cary E Desenvolvendo aplica es comerciais em Java com J2EE e UML Rio de Janeiro Moderna 2002 ALMEIDA Martinho Isnard Ribeiro de Manual de Planejamento Estrat gico Desenvolvimento de um Plano Estrat gico com a Utiliza o de Planilhas Excel 2 ed S o Paulo Atlas 2003 156p HELDMAN Kim Ger ncia de Projetos fundamentos um guia pr tico para quem quer certifica o em ger ncia de projetos Rio de Janeiro Elsevier 2005 319 p WAZLAWICK Raul Sidnei An lise e projeto de sistemas de informa o orientados a objetos 3 ed Rio de Janeiro Campus 2004 60 REFER NCIAS ANEXOS ANEXO A FASE CONCEP O Ai Documento de vis o A1 1 Vis o Geral do Problema Atualmente as empresas n o possuem uma ferramenta de qualidade para controlar e gerenciar seus projetos Na maioria das vezes os projetos fogem do escopo ou ultrapassam as datas de en tregas estabelecidas gerando assim insatisfa o dos clientes al m de acarretar muitos preju zos empresa executora do projeto A1 2 Descri o dos Envolvidos e dos Usu rios Al 2 1 Resumo dos Envolvidos Nome Descri o Responsabilidades Respons vel pela equipe no desenvolvimento do sistema Respons vel pelo cronograma e eventuais E Auditor e Vinicius Miana rev
63. ap s cinco segundos para carregar os dados Em outras palavras a maioria dos usu rios se disp e a esperar um pouco mais desde que eles obtenham algum feedback imediato essa uma informa o importante na hora de o timizar o c digo Nem sempre voc precisa fazer com que o c digo seja executado com mais rapidez para otimiz lo na presen a dos usu rios Embora a otimiza o possa significar uma diferen a entre o sucesso e o fracasso do apli cativo nunca se esque a de que bem mais importante que o c digo funcione corretamente Lembre se de que um software lento mas que funcione sempre prefer vel a um software r pido que n o funcione Cria o de teste em Java Teste orientado a objetos um t pico importante que tem sido totalmente ignorado pelos respons veis pelo desenvolvimento de objetos A realidade que voc ou outra pessoa ter de testar o software criado seja qual for a linguagem escolhida Um equipamento de teste o con junto de fun es de membro algumas incorporadas nas pr prias classes denominadas testes in ternos e outras em classes de teste especializadas usadas para testar o aplicativo Prefixe todos os nomes de fun es de membro de teste com o termo test Dessa forma voc poder encontrar rapidamente todas as fun es de membro de teste no c digo A vantagem dessa prefixa o facilitar a separa o entre as fun es de membro de teste e o c di go fonte antes de compila
64. ara distribui o Distribui o do software Instala o do software Treinamento dos usu rios e equipe comercial Migra o de dados para o novo sistema Os artefatos trabalhados neste processo s o Plano de Implanta o Software execut vel Artefatos de Instala o Documenta o Material de treinamento 4 4 7 Gerenciamento de Configura o de Mudan a O objetivo deste processo controlar as mudan as solicitadas para os artefatos do sistema de correntes de corre es de erros melhorias e inclus o de novos requisitos ou necessidades Todas as solicita es devem ser analisadas registradas recusadas ou aprovadas e desenvolvidas Caso isto ocorra dever ser feita uma an lise de impacto e redefini o das prioridades Segundo Kruchten 2004 p 175 os membros da equipe devem identificar e localizar ar tefatos selecionar a vers o apropriada conhecer sua hist ria para entender seu estado atual e as raz es para ter mudado e identificar seu atual respons vel Num processo iterativo os artefatos evoluem e s o atualizados constantemente os pro gramadores quando necess rio devem ter condi es de localizar suas v rias vers es com facili dade Os seguintes artefatos s o trabalhados neste processo de acordo com a Rational 2001 Plano de Gerenciamento de Mudan as Solicita es de Mudan a Modelo de Implementa o 48 RUP RATIONAL UNIFIED PROCESS
65. aso de uso tem como finalidade dar acesso ao sistema de acordo com as permiss es cadastradas de um determinado usu rio Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando qualquer usu rio em geral quer acessar o sistema Ap s validar login e senha este caso de uso entra em atividade verificando as permiss es de acesso colocando na p gina principal somente o que o usu rio logado tem acesso Fluxos alternativos Nenhum Condi es Pr vias Ter login e senha validados O usu rio dever ter login e senha validado pelo sistema Condi es Posteriores Nenhuma REFER NCIAS ANEXOS 79 A2 4 9 UCO9 Gerar Log de Acesso Breve Descri o Este caso de uso tem como finalidade gerar log de todas a es feitas pelos usu rios ca dastrados no sistema Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando qualquer usu rio em geral executa uma determinada funcionalidade no sistema Ap s executar qualquer funcionalidade no sistema este caso de uso inicia se gerando o log desta opera o O log dever conter os seguintes dados 1 C digo do funcion rio CPF 2 IP do computador do usu rio 3 Descri o da a o 4 Data da gera o do log Fluxos alternativos Nenhum Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sitema Condi es Posteriores Nenhuma 80 REFER NCIAS ANEXOS A2 4 10 UC10 Consul
66. aul Campbell Dinsmore e Fernando H Da Silveira Neto 2006 definem algumas formas de resultado positivo tais como gera o de sinergia forma o de contratos psicol gicos cria o de um arranjo produtivo elimina o de dificuldades organizacionais melhoria nas rela es com o cliente e gerenciamento de projetos mais eficaz Os principais processos que correspondem ao Gerenciamento de Recursos Humanos do Projeto s o PMBOK 2004 Planejamento de recursos humanos onde se identifica e documenta as fun es res ponsabilidades e rela es hier rquicas do projeto Contratar ou mobilizar a equipe do projeto que consiste na obten o do pessoal neces s rio para finalizar lo Desenvolver a equipe do projeto que preza a melhoria de compet ncias e intera o de membros da equipe para aprimorar o desempenho do projeto Gerenciar a equipe do projeto onde acompanha se o desempenho dos membros da e quipe buscando sempre melhorar o desempenho do projeto O Gerenciamento das Comunica es do Projeto conforme definido pelo PMBOK 2004 determina os processos necess rios para que as informa es sobre o projeto possam ser manipuladas de forma oportuna e adequada Todos os stakeholders devem entender como as comunica es afetam o projeto como um todo Os principais processos que correspondem ao Gerenciamento das Comunica es do Pro jeto s o PMBOK 2004 Planejamento das comunica es onde s o determinada
67. azos e custos com maior precis o Por m apesar dos benef cios que esta metodologia traz para o desenvolvimento de siste mas deve se antes fazer uma an lise para levantar se realmente necess ria utiliza o de tal metodologia no projeto em quest o O RUP uma metodologia muito complexa possui in meros documentos e para que funcione adequadamente necess rio seguir os quesitos das etapas do ciclo de vida do projeto assim como tamb m gerar corretamente os artefatos de cada etapa Al m disso necess rio tamb m um treinamento adequado da equipe para adapta o e assimila o da metodologia no contexto da empresa j que a metodologia utiliza e muito UML Unified Modeling Language para gerar os principais diagramas nas suas fases principalmente na Concep o e Elabora o Para projetos de pequeno porte a utiliza o do RUP pode n o ser a melhor escolha devi do complexidade identificada nos seus ciclos iterativos J para projetos de grande porte a utiliza o do RUP muito indicada pois possibilita maior controle tanto do projeto quanto dos stakeholders podendo assim obter um desenvolvi mento dentro dos custos prazos e n veis de qualidade desejados Cada empresa possui caracter sticas nicas e isso faz com que a utiliza o do RUP possa ser feita de forma customizada Em cada etapa do ciclo de vida do projeto muitos documentos s o gerados o que pode ocasionar atrasos na entrega de proje
68. carProjetos buscar AndamentoTarefas cadastrarEmpresas Empresa empresa Esta conven o resulta m todos cuja finalidade pode ser freqiientemente determinada por seus nomes Embora envolva um pouco mais de digita o por parte do desenvolvedor por que geralmente os nomes s o longos essa conven o conveniente por aumentar a compreens o do c digo Nomea o de M todos de Acesso Abordaremos mais detalhadamente os acessos isto m todos que obt m e definem os valores de campos campos ou propriedades As conven es de nomea o para os acessos en tretanto est o resumidas a seguir Getters Getters s o m todos que retornam o valor de um campo A palavra get deve ser usada como prefixo do nome do campo a menos que o campo seja boolean Nesse caso o prefixo do nome ser is e n o get Exemplos getNomeProjeto getCpfFuncionario getEnderecoEmpresa 130 REFER NCIAS ANEXOS De acordo com essa conven o de nomea o fica bvio que uma fun o de membro retornar um campo de um objeto No caso de boolean getters fica bvio que o valor retornado ser verdadeiro ou falso DES97 Setters Os setters s o m todos que modificam os valores de um campo Use a palavra set como prefixo para o nome do campo seja qual for o tipo de campo Exemplos setNomeProjeto String nomeProjeto setCpfFuncionario Integer cpf setEnderecoEmpresa Endereco enderecoEmpresa Co
69. cessos que correspondem ao Gerenciamento de Escopo de Projeto s o PMBOK 2004 Planejamento do escopo onde se cria um plano de gerenciamento de escopo do proje to que documente como o escopo ser definido Defini o do escopo onde se faz sua declara o detalhadamente Criar Estrutura Anal tica do Projeto EAP onde feita uma subdivis o das principais entregas do projeto em componentes menores e mais f ceis de serem gerenciados Verifica o do escopo que o processo de aceitar formalmente o trabalho do projeto conforme j definido em sua documenta o no escopo ou no contrato Controle do escopo onde feito o controle das mudan as no escopo do projeto garan tindo que mudan as sejam acordadas por todos e que possa ser determinado quando alguma mudan a ocorreu O guia PMBOK 2004 atrav s do Gerenciamento de Tempo de Projeto define os pro cessos necess rios para garantir que o projeto cumpra os prazos definidos em um cronograma de atividades e seja entregue dentro do prazo estipulado Os principais processos que correspondem ao Gerenciamento de Tempo de Projeto s o PMBOK 2004 Defini es da atividade onde s o feitas identifica es das atividades espec ficas do cronograma que necessitem ser executadas Seq nciamento de atividades que consiste na identifica o e documenta o das de pend ncias das atividades existentes no cronograma Estimativa de recursos da ati
70. cobson Rumbaugh e Booch 2005 p 189 3 3 5 Diagrama de implanta o Jacobson Rumbaugh e Booch 2005 p 411 definem o diagrama de implanta o como diagrama de classe que focaliza os n s do sistema em que na maior parte envolve a modelagem da topolo gia de hardware em que o sistema executado Em sua utiliza o o diagrama de implanta o importante para a visualiza o docu menta o e especifica o de sistemas embutidos cliente servidor distribu dos e at mesmo para o gerenciamento de sistemas execut veis por meio de engenharia reversa Jacobson Rumbaugh e Booch 2005 Pode se ver um exemplo de diagrama de implanta o na figura 3 3 Internet Modem bank processor caching server processor caching server conexao network local network processor primary server processor server processor server processor server Figura 3 3 Exemplo de Diagrama de Implanta o Fonte Jacobson Rumbaugh e Booch 2005 p 412 3 3 6 Diagrama de artefatos Jacobson Rumbaugh e Booch 2005 p 397 define o diagrama de artefatos como sendo diagra ma que mostra a vis o est tica de um sistema envolvendo a modelagem de itens f sicos residen tes em um n Esses itens podem ser programas execut veis bibliotecas tabelas arquivos e do cumentos o diagrama de classes que focaliza os artefatos do sistema Segundo Jacobson
71. como os coment rios de estilo C e os de uma nica linha ser o usados e siga o de forma consistente Use um tipo para REFER NCIAS ANEXOS 127 documentar a l gica do neg cio e outro para documentar o c digo antigo Use os coment rios de uma nica linha para a l gica do neg cio pois voc pode incluir a documenta o na mesma li nha do c digo esse procedimento conhecido como inser o em linha Use os coment rios de estilo C para documentar o c digo antigo e desnecess rio pois eles permitem desativar v rias li nhas de c digo de uma s vez Como os coment rios de estilo C s o bastante semelhantes aos coment rios de documenta o para evitar confus o n o os use em outros locais Uma vis o geral do javadoc No Sun Java Development Kit JDK est inclu do um programa denominado javadoc que processa arquivos de c digo Java e produz documenta o externa para os programas Java na forma de arquivos HTML O programa javadoc suporta um n mero limitado de marcas palavras reservadas que marcam o in cio de uma se o da documenta o Consulte a documenta o do javadoc JDK para obter mais detalhes Marca Usado para Finalidade O author name Classes Interfaces Indica os autores de determinado trecho do c digo Use uma marca por autor O deprecated Classes Fun es de Indica que a API da classe ficou obsoleta e Membro portanto n o deve mais ser usada exception name Fun es
72. da tipo de coment rio assim como tamb m o s o v rios exemplos Coment rio Uso Exemplo Documenta o Use os coment rios de documenta o imediatamente antes de de declara es interfaces classes fun es de membro e campos para document los Esses coment rios ser o processados pelo javadoc Veja a seguir como criar documenta o externa para uma classe Cliente qualquer pessoa ou organiza o a quem vendemos servi os e produtos author S W Ambler Si Estilo C Use os coment rios de estilo C para documentar linhas de c digo que n o s o mais aplic veis mas que voc ainda quer manter caso os usu rios mudem de id ia ou porque voc talvez queira desativ los temporariamente durante um processo de depura o Esse c digo foi desativado por B Gustafsson no dia 4 de junho de 1999 porque foi substitu do pelo c digo precedente Exclua o ap s dois anos caso ainda n o seja aplic vel o c digo fonte Se Linha nica Use coment rios em uma nica linha internamente nas fun es de membro para documentar a l gica do neg cio as se es do c digo e as de declara es vari veis tempor rias Aplicar desconto de 5 a todas as faturas acima de R 1 000 00 em fun o de campanha geral de descontos iniciada em fevereiro de 1995 E importante que sua organiza o defina um padr o para mostrar
73. das opera es de uma linguagem para entender o c digo fonte sinal de que h algo muito errado Isso um problema principalmente nas compara es l gicas em que AND e OR e diversos comparadores s o usados em conjunto Se voc usar linhas de comandos simples e curtas como sugerido anteriormente isso n o ser mais um problema 136 REFER NCIAS ANEXOS B4 1 4 Padr es para campos e propriedades O termo campo usado aqui se refere a um campo que o Bean Development Kit chama de propri edade DES97 Campos s o dados que descrevem um objeto ou uma classe Os campos podem ser tipos de dados b sicos como sequ ncias de caracteres ou flutuantes ou podem ser um objeto como um cliente ou uma conta banc ria Nomea o de campos Use um descritor completo para nomear os campos GOS96 e AMB98 explicando o que cada campo representa Campos que s o conjuntos como matrizes ou vetores devem rece ber nomes no plural para indicar que representam v rios valores Nomea o de constantes Em Java as constantes valores que n o mudam s o geralmente implementadas co mo campos de classes finais est ticos A conven o reconhecida o uso de palavras completas todas em mai sculas separadas por sublinhados GOS96 Exemplos TIPO FUNCIONARIO COD DEPTO MAX VALUE A principal vantagem dessa conven o ajudar a fazer a diferencia o entre constantes e vari veis Visibilidade de atributos Quando os
74. dentifica o de riscos 11 3 An lise qualitativa de riscos 11 4 An lise quantitativa de riscos 11 5 Planejamento de respostas riscos 11 6 Monitoramento e controle de riscos 6 Gerenciamento de tempo do projeto 6 1 Defini o da atividade 6 2 Sequenciamento de atividades 6 3 Estimativa de recursos da atividade 6 4 Estimativa de dura o da atividade 6 5 Desenvolvimento do cronograma 6 6 Controle do cronograma 9 Gerenciamento de recursos humanos do projeto 9 1 Planejamento de recursos humanos 9 2 Contratar ou mobilizar a equipe do projeto 9 3 Desenvolver a equipe do projeto 9 4 Gerenciar a equipe do projeto 12 Gerenciamento de aquisi es do projeto 12 1 Planejar compras e aquisi es 12 2 Planejar contrata es 12 3 Solicitar respostas de fornecedores 12 4 Selecionar fornecedores 12 5 Administra o de contrato 12 6 Encerramento do contrato Figura 2 2 Vis o geral das reas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos Fonte Guia PMBOK PMBOK 2004 24 GERENCIAMENTO DE PROJETOS 2 2 Ferramentas de gerenciamento de projetos Outro fator importante al m da metodologia utilizada o uso de Sistemas de Gerenciamento de Projetos SGP que possibilitam ao gerente de projetos diversas formas de gerenci lo entre e las Maior controle das atividades dos stakeholders Maior controle de prazos Verificar se o pr
75. do como par metro Tamb m preciso indicar quais par metros se houver devem ser passados para um m todo e como eles ser o usados 132 REFER NCIAS ANEXOS Essas informa es s o necess rias para que os outros programadores saibam quais in forma es devem ser passados para um m todo O que retornado por um m todo Documente o que o m todo retorna caso ela o fere a algum tipo de retorno para que outros programadores possam usar o valor ou o objeto de retorno corretamente Erros conhecidos Qualquer problema pendente com um m todo deve ser documen tado para que os outros desenvolvedores conhe am os pontos fracos e as dificuldades do m todo Se um erro se aplicar a mais de um m todo de uma classe ele dever ser documentado para a classe e n o para o m todo Documente toda e qualquer exce o que seja acionada por um m todo para que outros programadores saibam o que o c digo precisar obter Decis es de visibilidade Se voc achar que sua op o de visibilidade para um m todo ser questionada pelos outros desenvolvedores talvez voc tenha criado um m todo como p blico mesmo que nenhum outro objeto a dispare por enquanto documente sua decis o Isso tornar seu racioc nio claro para os outros desenvolvedores evitando que eles percam tempo preocupando se por que voc fez algo question vel Como um m todo altera o objeto Indique se um m todo altera um objeto Por e xemplo o
76. do por programadores inexperientes tentar otimizar todo o c digo mesmo aquele que j executado com bastante rapidez N o perca tempo otimizando c digos que n o s o importantes para ningu m Qual o objetivo da otimiza o do c digo Os fatores mais importantes s o carga fixa e desempenho em grandes entradas O motivo disso simples a carga fixa domina a velocidade do tempo de execu o para pequenas entradas enquanto o algoritmo domina para grandes entra das Segundo Koenig um programa que funcione bem com pequenas e grandes entradas prova velmente funcionar bem com entradas de m dio porte Os desenvolvedores que precisam criar software que funcione em v rias plataformas de hardware e ou sistemas operacionais devem estar cientes das idiossincrasias existentes em v rias 144 REFER NCIAS ANEXOS plataformas Opera es que pare am muito demoradas como por exemplo a maneira como a mem ria e os buffers s o manipulados geralmente demonstram varia es substanciais entre pla taformas E comum concluir que o c digo deve ser otimizado diferentemente para cada plata forma Outra quest o a ser considerada durante a otimiza o do c digo a prioridade dos usu rios porque as pessoas se incomodar o com certas demoras dependendo do contexto Por e xemplo os usu rios provavelmente ficar o mais felizes com uma tela que apare a e ap s oito segundos carregue dados em vez de uma tela que s apare a
77. do projeto que definem as funcionalidades que o futuro sistema ter Os casos de usos foram levantados tendo como base os sistemas de gerenciamento de projetos j existentes Foram identificadas as funcionalidades em comum e atrav s disto os ca 50 PROJETO sos de usos foram descritos Tamb m foram incorporados casos de usos que representam relat rios no sistema conforme estudos realizados sobre gerenciamento de projetos Para cada caso de uso escreveu se uma breve descri o e um fluxo de informa es o que chamamos de fluxo b sico Al m dos fluxos b sicos podem ocorrer os fluxos alternativos caso o fluxo b sico n o seja seguido corretamente por isso os fluxos alternativos tamb m foram i dentificados e escritos Tamb m foram descritas as sess es de condi es pr vias e condi es posteriores As condi es pr vias s o necess rias para que o sistema possa executar o caso de uso enquanto que as condi es posteriores s o partes que descreve se o que ser executado ap s o t rmino do caso de uso Para representar graficamente este documento utiliza se os recursos da UML de uma fer ramenta Case Enterprise Architect v4 1 para criar se os diagramas Este documento foi utilizado pela equipe de desenvolvimento para realizar os testes veri ficando se as funcionalidades foram implementadas corretamente para entender o comportamen to e aprovar os fluxos de eventos do sistema 5 2 Fase Elabora o O
78. do projeto F Atraso e ou estouro do Recursos s o evidentemente em or amento evidente e visivel quantidade inferior ao necess rio d e i Progresso insatisfat rio dentro Ve J Custo e Prazos Indicadores de um S Recursos Equipe de implementa o mostra das resin es do projeto inexperi ncia no projeto conduzido Aumento significativo no Tum Over dos membros da equipe do projeto Projeto Problem tico Aumento significativo na exposi o dos riscos Probabilidade e ou Impacto Mudan as significativas constantes nos Fracasso na implementa o de planos de requerimentos iniciais do projeto O onting ncia aos MSCOS Y Riscos A d al Falta de acordo entre as partes interessadas y quanto ao entendimento dos requerimentos e objetivos do projeto Escopo Figura 2 1 Mapa mental dos indicadores de um projeto problem tico Fonte Vargas 2006 p45 Todos os fatores citados acima segundo Ricardo Vargas 2006 p44 n o indicam se a nalisados isoladamente se um projeto possui algum tipo de problema Todos devem ser analisa dos para que a identifica o de um problema existente seja realmente v lida e concisa Entende se que para que um projeto alcance o seu principal objetivo o sucesso fatores internos e externos da organiza o devem ser levados em considera o assim como tamb m a utiliza o de uma metodologia e ferramentas que possibilitam um melhor
79. dom nio da organiza o original com o tipo de dom nio de n vel superior em letras mai sculas Por exemplo para distribuir os pacotes anteriores eles devem ser nomeados como com rational www persistence mapping relational e com rational www interface screens Voc deve manter um ou mais documentos externos que descrevam a finalidade dos pa cotes desenvolvidos pela sua organizac o Para cada pacote documente Os fundamentos do pacote Outros desenvolvedores precisam saber sobre o que se refere o pacote para que possam determinar se ir o us lo e caso ele seja um pacote compartilhado se pretendem melhor lo ou ampli lo As classes contidas no pacote Inclua uma lista das classes e interfaces contidas no pacote com uma r pida descri o de uma linha para cada item para que os outros de senvolvedores saibam o que o pacote cont m 142 REFER NCIAS ANEXOS B4 1 7 Tratamento de Erros e Exce es Como filosofia geral use exce es apenas para erros erros de l gica e de programa o erros de configura o dados corrompidos esgotamento de recursos e assim por diante Como regra geral em condi es normais e na aus ncia de sobrecarga ou falha de hardware os sistemas n o devem provocar exce es Use exce es para tratar erros de l gica e de programa o erros de configura o dados corrompidos e esgotamento de recursos Diminua o n mero de exce es exportadas de uma determinada abstra o E
80. dos os Casos de usos UC07 Realizar Login e UCO8 Verificar Permiss es pa ra que fosse poss vel utilizar o sistema Depois o Caso de uso UCO9 Gerar Log de Acesso foi incorporado ao sistema O restante dos Casos de usos foram codifi cados posteriormente pois estes possu am depend ncia dos anteriormente citados Alguns casos de usos como o UC01 Manter Funcion rios s o divididos em qua tro casos de usos Buscar Alterar Cadastrar e Excluir Para estes casos de usos codificamos primeiro o Buscar depois o Cadastrar Excluir e por ltimo Alterar 6 Testes A medida que os Casos de usos eram terminados o teste de valida o era verificado Para que o Caso de uso fosse homologado os analistas respons veis pelo projeto faziam todos os testes poss veis 5 4 Fase Transi o A fase de transi o a fase que busca como objetivo principal a implanta o efetiva do sistema que foi desenvolvido Como este trabalho visa uma pesquisa acad mica o software de gerencia mento de projetos proposto n o ser implantado e esta fase n o ser aplicada nesta pesquisa 56 CONCLUS O Cap VI Conclus o Com os estudos realizados durante o desenvolvimento deste trabalho pode se constatar que com a ado o do RUP Rational Unified Process como metodologia de desenvolvimento de sistemas pode se obter muitos benef cios tais como maior qualidade de software e controle no desenvol vimento possibilitando a estimativa de pr
81. e REFER NCIAS ANEXOS 125 Evite sublinhados iniciais ou finais Nomes com sublinhados iniciais ou finais ge ralmente s o reservados para uso do sistema e n o devem ser utilizados para nomes criados pelo usu rio exceto se o pr processador assim definir Mais importante ainda que os sublinhados confundem e dificultam a digita o Portanto tente evit los sempre que poss vel Conven es de documenta o Abordaremos tamb m as conven es de documenta o Para isso vamos definir alguns fundamentos Coment rios contribuem para a clareza do c digo O motivo de documentar o c digo torn lo mais compreens vel para voc seus colaboradores e outros desenvol vedores que venham a substitu lo Se seu programa n o merece ser documentado provavelmente n o merece ser executado NAG95 Evite enfeites ou seja n o use coment rios como faixas Voc deve escrever c di gos leg veis e n o c digos enfeitados Al m disso como muitas fontes usadas para e xibir e imprimir o c digo s o proporcionais e outras n o n o poss vel alinhar as cai xas corretamente Mantenha a simplicidade dos coment rios Os melhores coment rios s o anota es simples e diretas Voc n o tem de escrever um livro precisa apenas fornecer infor ma es suficientes para que os usu rios possam entender o c digo Crie a documenta o antes de escrever o c digo A melhor maneira de criar a do cumenta
82. e por sua vez pode estar s na internet ou ser uma combina o entre o que fica no computador e na rede A tend ncia virar algo cada vez mais 100 online Fortes 2006 p 48 Nos tempos atuais a tend ncia o crescimento da utiliza o de sistemas web tanto pela mobilidade e independ ncia de sistema operacional quanto pelo baixo custo 2 3 Comparativo de sistemas de gerenciamento de projetos A maioria dos sistemas de gerenciamento de projetos tem as mesmas caracter sticas e funcionalidades Algumas diferen as podem ser encontradas no que se refere a relat rios que fornecem uma an lise mais detalhado do projeto que est sendo controlado Abaixo segue uma tabela de compara o dos sistemas de gerenciamento de projetos ci tados no item anterior SGP Forma de Intera o Principais Caracter sticas Plataformas dotProject Interface Web Classifica o de projetos ge Unix renciamento de documenta o Linux emiss o de alertas sobre alte Windows ra es nos documentos ProjectOpen Interface Web Administra o dos custos de Linux um projeto e a colabora o en Windows tre membros da equipe Gforce Interface Web Atende s necessidades de to Linux do o ciclo de vida do projeto Windows controle de registro de bugs e de reposit rio de distribui o 26 GERENCIAMENTO DE PROJETOS Gantt Project Instala o Desktop Elabora o de cronogramas Unix
83. e conclu da a execu o de um m todo MEY88 As precondi es e p s condi es descrevem de v rias formas as suposi es feitas durante a cria o de um m todo e AMB98 definem com precis o os limites de uso desses Todas as quest es de simultaneidade Simultaneidade um conceito novo e comple xo para muitos desenvolvedores e na melhor das hip teses um t pico antigo e com plexo para programadores com experi ncia em simultaneidade Em suma se voc usar as caracter sticas de simultaneidade da programa o Java dever document las inte gralmente LEA97 Sugere que quando uma classe inclui m todos sincronizados e n o sincronizados voc deve documentar o contexto de execu o em que se baseia o REFER NCIAS ANEXOS 133 m todo principalmente se ele requer acesso irrestrito para que os outros desenvolve dores possam utiliz la com seguran a Se um setter um m todo que atualiza um campo de uma classe que implementa a interface Runnable n o estiver sincronizado voc dever documentar os motivos pelos quais n o est Por fim caso voc sobrepo nha ou sobrecarregue um m todo e altere sua sincroniza o tamb m deve documentar o motivo Voc s deve documentar aquilo que contribua para a clareza do c digo N o preciso documentar todos os fatores descritos acima para toda e qualquer m todo por que nem todos os fatores s o aplic veis a todas os m todos Entretanto v rios deles devem
84. e dados sistemas operacionais e outros detalhes t cnicos O sistema dividido em subsistemas que se comunicam atrav s de interfaces bem defi nidas O modelo de classes composto inicialmente pelas classes de an lise expandido incluin do as classes necess rias para a implementa o do sistema como um todo Os atributos de todas as classes s o detalhados considerando se a linguagem que ser utilizada e os tipos de dados s o identificados O acesso aos m todos e propriedades s o indicados assim como a forma de en capsulamento dos subsistemas Neste processo os profissionais segundo Kruchten 2004 p 145 v o desempenhar os seguintes pap is Arquiteto lidera e coordena as atividades t cnicas do projeto Projetista define as responsabilidades atributos e rela es entre as classes Projetista de Banco de Dados especifica os modelos l gicos e f sicos do banco de da dos Revisor da arquitetura e do design revisa os artefatos produzidos durante o processo RUP RATIONAL UNIFIED PROCESS 45 Os artefatos trabalhados pelo Arquiteto Modelo de An lise Modelo de Design Interfaces Descri o da arquitetura de software Artefatos de tempo real Artefatos trabalhados pelo Projetista Realiza o de Casos de Uso Classes Pacote de design Especifica es de subsistemas Artefato trabalhado pelo Projetista de Banco de Dados Modelos de dados l gico e f sico
85. e prioridade para cada risco e sua an lise An lise quantitativa de riscos que a an lise num rica dos efeitos dos riscos que fo ram identificados Planejamento de respostas a riscos onde desenvolvem se op es e a es para que possam aumentar oportunidades e reduzir amea as aos objetivos do projeto Monitoramento e controle de riscos que o acompanhamento dos riscos durante todo o ciclo de vida do projeto A ltima das reas de conhecimento o Gerenciamento de Aquisi es de Projetos Este gerenciamento segundo o PMBOK 2004 define os processos que s o necess rios para com prar ou adquirir os produtos servi os ou resultados necess rios de fora da equipe do projeto para a realiza o do trabalho Tamb m engloba os processos de gerenciamento de contratos Os principais processos que correspondem ao Gerenciamento de Aquisi es do Projeto s o PMBOK 2004 Planejar compras e aquisi es onde determina se o que comprar ou adquirir e como e quando fazer isso Planejar contrata es onde faz se a documenta o dos requisitos de produtos servi os e resultados e identifica o de poss veis fornecedores Solicitar respostas de fornecedores onde obt m se informa es cota es pre os quando necess rio Selecionar fornecedores onde analisa se as ofertas e escolhe se poss veis fornecedo res negociando um contrato por escrito Administra o de contrato que a parte de
86. e todos que posteriormente ser o respons veis pela manuten o e melhoria do c digo Com a documenta o do c digo no in cio do processo de desenvolvimento sua produtividade ser maior porque voc ser for ado a pensar sobre a l gica empregada antes de aplic la ao c digo Al m disso quando voc retorna ao c digo que escreveu dias ou semanas antes pode determinar facilmente o que tinha em mente ao escrev lo pois os procedimentos j est o documentados Nunca se esque a de que o c digo escrito hoje poder ser usado por muitos anos e prova velmente ser mantido e melhorado por outra pessoa Voc deve procurar criar um c digo leg vel e compreens vel porque esses fatores facilitam a manuten o e a implementa o de melhori as REFER NCIAS ANEXOS 129 B4 1 3 Padr es para M todos Nunca se esque a de que o c digo escrito hoje poder ser usado por muitos anos e provavelmen te ser mantido e melhorado por outra pessoa Voc deve procurar criar um c digo leg vel e compreens vel porque esses fatores facilitam a manuten o e a implementa o de melhorias Nomea o de m todos As fun es de membro devem ser nomeadas atrav s de uma descri o completa que combine letras mai sculas e min sculas sendo que a primeira letra de toda palavra n o inicial deve ser mai scula Tamb m comum usar um verbo forte e ativo para a primeira palavra de uma fun o de membro Exemplos verifi
87. ecesesese 28 3 3 1 Diagramas de Classes de sette cut dasth cusses ri duke s de sita vesht ee ENEE do Sulina Ca sn ose sinis 29 3 3 2 Diagrama de componentes er ene e ene e ente vr re eneve re eee emer e teen ecen eee rren rene 30 3 3 3 Diagrama de estrutura composta ir en eene entente mere neve neo n eee trennen 30 3 3 4 Diagrama de objetos vash inicio di seris dose k Su esit sh dhat d shi s hehe Ee 30 3 3 5 Diagrama de implanta o eee sone sone sone e eneve ne ee re ee nono non eee rre en nc en nera enn naar narco rren neon neon reve enen 31 3 3 6 Diagrama de artefatos er ee neo rre ente vere vr ee enne tene merre err ee tren rrene enen 31 3 3 7 Diagrama de caso de USO eee core ene cen re ente en rennen tentent tenet entren rren rene 33 3 3 8 Diagrama de seq ncia en us re enes e ne eee ecen ece ne eee rene eee re ente vr ee eneve busua huuu rene 35 3 3 9 Diagrama de Comumteac o eee ene e en re ente vere br eee re ene enes e nene rrenen rrenen 35 3 3 10 Diagrama de gr fico de estados i certet hesht n dendi ii r 36 33 11 Diagrama de atividades nisi eode oe pe e be iter At eU eue NUI iere idee asas sussa 37 CAP IV RUP RATIONAL UNIFIED PROCESS 38 4 1 Desenvolvimento Iterativo eee e esee esee aaa sassa mesmen se tn se tasse secs nas ta ss ends atoa ta sene see ecemeesecesesese
88. entemente de um diagrama de gr fico de estados o diagrama de atividades mostra tamb m a concorr ncia de atividades existentes e as ramifica es de controle Tais caracter sticas podem ser visualizadas na figura 3 12 Select site a es 7 Commission architect l e Develop plan Bid plan not accepted CertificateOfOccupancy completed Figura 3 12 Exemplo de Diagrama de Atividades Fonte Jacobson Rumbaugh e Booch 2005 p 270 Jacobson Rumbaugh e Booch 2005 p 270 definem que um diagrama de atividades essencialmente um fluxograma que enfatiza a atividade que ocorre ao longo do tempo 38 RUP RATIONAL UNIFIED PROCESS CAP IV RUP Rational Unified Process Segundo Kruchten 2004 p 15 o Rational Unified Processo RUP um processo de engenharia de software que fornece um modo disciplinado para assumir tarefas e responsabilidades dentro de uma empresa de desenvolvimento Este processo desenvolvido e mantido pela Rational Software e esta dispon vel atrav s da empresa IBM Este processo tenta resolver um grande problema a dificuldade em fazer com que proje tos de sistemas complexos sejam entregues nos prazos determinados Conforme os anos v o pas sando os sistemas v o ficando cada vez mais complexos e precisando ser entregues em prazos mais curtos Combinado a isso h novas tecnologias que surgem a cada dia e a especifica o do sistema se altera n
89. er ser recalculada a porcentagem de conclus o da tarefa e posteriormente do projeto que o andamento foi cadastrado REFER NCIAS ANEXOS 83 A2 4 12 UC12 Visualizar Tarefas Breve Descri o Este caso de uso tem como finalidade mostrar todas as tarefas vinculadas para um deter minado funcion rio Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o usu rio acessa o sistema O usu rio pode atrav s deste caso de uso visualizar todas as suas tarefas O sistema ir capturar todas as tarefas que est o vinculadas ao usu rio e apresentar uma lista contendo os seguintes dados projeto tarefa data de in cio e data de t rmino da tarefa Ao apresen tar na tela a lista o usu rio poder clicar em qualquer tarefa para verificar seus andamen tos executando assim o caso de uso UC13 Visualizar Andamento de Tarefas Fluxos alternativos Nenhum Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema Condi es Posteriores Nenhuma 84 REFER NCIAS ANEXOS A2 4 13 UC13 Visualizar Andamento de Tarefas Breve Descri o Este caso de uso tem como finalidade mostrar todos os andamentos das tarefas vinculadas para um determinado funcion rio Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o usu rio quer ver os andamentos de suas tarefas O sistema ir capturar os andamentos da tarefa e apresentar uma lista contendo o nome do usu rio
90. escricao Breve descri o do projeto suas caracter sticas etc pro prioridade Prioridade do projeto 3 Alta 2 M dia 1 Baixa pro status Status do projeto A Ativo I Inativo pro progresso Porcentagem de progresso de t rmino do projeto pro nome Nome do projeto pro orcamento Valor or ado do projeto fun cpf CPF do Gerente de Projetos REFER NCIAS ANEXOS 121 B3 2 3 Tabela TAREFA Campo Descri o tar codigo C digo da tarefa pro codigo C digo do projeto que a tarefa pertence tar prioridade Prioridade da tarefa 3 Alta 2 M dia 1 Baixa tar descricao Breve descri o da tarefa caracter sticas etc tar prog andamento Porcentagem de progresso de t rmino da tarefa tar dt inicio Data de in cio da tarefa tar dt final Data de t rmino da tarefa tar hs estimadas Quantidade de horas estimadas para executar a tarefa tar hs trabalhadas Quantidade de horas trabalhadas na tarefa tar status atual Status da tarefa A Ativo I Inativo tar precedente Tarefa que antecede esta tar nome Nome da tarefa B3 2 4 Tabela ANDAMENTO TAREFA Campo Descri o and tar codigo C digo do andamento da tarefa tar codigo C digo da tarefa que pertence o andamento da tarefa and tar hs trabalhadas Quantidade de horas trabalhadas no andamento da tarefa
91. gerenciamento do contrato entre o com prador e o fornecedor Encerramento do contrato onde cada contrato terminado ou liquidado GERENCIAMENTO DE PROJETOS 23 Pode se ter uma vis o geral das reas de conhecimento em gerenciamento de projetos e processos atrav s da figura abaixo 4 Gerenciamento de integra o do projeto 4 1 Desenvolver o termo de abertura do projeto 4 2 Desenvolver a declara o do escopo preliminar do projeto 4 3 Desenvolver o plano de gerenciamento do projeto 4 4 Orientar e gerenciar a execu o do projeto 4 5 Monitorar e controlar o trabalho do projeto 4 6 Controle integrado de mudan as 4 7 Encerrar o projeto 7 Gerenciamento de custos do projeto 7 1 Estimativa de custos 7 2 Or amenta o 7 3 Controle de custos 10 Gerenciamento das comunica es do projeto 10 1 Planejamento das comunica es 10 2 Distribui o das informa es 10 3 Relat rio de desempenho 10 4 Gerenciar as partes interessadas GERENCIAMENTO DE PROJETOS 5 Gerenciamento do escopo do projeto 5 1 Planejamento do escopo 5 2 Defini o do escopo 5 3 Criar EAP 5 4 Verifica o do escopo 5 5 Controle do escopo 8 Gerenciamento da qualidade do projeto 8 1 Planejamento da qualidade 8 2 Realizar a garantia da qualidade 8 3 Realizar o controle da qualidade 11 Gerenciamento de riscos do projeto 11 1 Planejamento do gerenciamento de riscos 11 2 I
92. gia devido sua complexidade pode dificultar seu andamento Cada projeto possui caracter sticas pr prias e a aplica o de uma mesma metodologia nem sempre resultar em efici ncia Cabe empresa optar e adequar cada metodologia a seus diferentes projetos O objetivo deste trabalho viabilizar a implementa o de um gerenciador de projetos baseando se em uma das mais utilizadas metodologias de desenvolvimento de sistemas a Rational Unified Process RUP A arquitetura de desenvolvimento escolhida foi o Java Enterprise Edition JEE pois atende as necessidades do projeto trabalhar com orienta o a objetos e faz interface com a plataforma web Palavras chave RUP Gerenciamento de projetos UML JEE Metodologia de desenvolvimento Orienta o a objetos ABSTRACT Project management became a critical success factor about competitiveness between companies In system deployment area methodologies are adopted do reduce failures along the project life time But some times the choice of a particular methodology due to its complexity can disturb its progress Each project has its own properties and the use of the same methodology not always will work with the same efficiency The company has to choose and adapt each methodology to its different projects This papers goal is the implementation of a project manager system using one of the most used system development methodologies the Rational Unified Process RUP The chosen developmen
93. ilidade ao mercado orientado a objetos E o terceiro o aprimoramento dos tr s m todos anteriores de modo que poderiam lidar com proble mas que antes n o se poderia manipular de maneira adequada A UML por se tratar de uma linguagem prov vocabul rio e regras para representar seus elementos que descrevem um sistema Esta linguagem define uma gram tica que auxilia os de senvolvedores a criar e ler seus documentos Sommerville 2005 De acordo com Chonoles e Schardt 2003 p 12 uma analogia pr xima pode ser a de plantas de engenharia com detalhes suficientes para descrever como um pr dio deve ser Seus modelos podem ser usados para gerar c digo escrito em diferentes linguagens de programa o tais como Java Cft e C al m de tabelas de bancos de dados Ferramentas Case como o System Architect Jude e Together al m de outros prov em este recurso A documenta o gerada pela UML aborda tanto a arquitetura como todos os detalhes do sistema 3 1 Caracter sticas As partes que comp em a UML s o Sommerville 2005 Caso de uso apresenta uma vis o do ponto de vista externo do sistema descrevendo seu comportamento sob a perspectiva dos usu rios finais e projetistas do sistema L gica descreve a arquitetura do sistema ou seja suas classes interfaces componen tes e colabora es e identifica os tipos de servi os fornecidos pelo sistema Processo mostra o processamento concorrente do sistema atrav s de
94. inis trador pode escolher ou n o vincular as permiss es de acesso ao sistema do funcion rio cadastrado executando o caso de uso UC02 Vincular Permiss es REFER NCIAS ANEXOS 67 OBS As permiss es de acesso encontram se cadastradas na tabela PERMISS O Os tipos de funcion rio s o 1 Administrador 2 Gerente de Projetos 3 Analista programador projetista etc Alterar Dados dos Funcion rios O administrador dever selecionar o usu rio que deseja alterar Automaticamente os da dos daquele funcion rio ser o carregados na tela O administrador alterar os dados ne cess rios e clicar no bot o Alterar O nico dado que n o poder ser alterado o CPF Ap s a altera o dos dados do funcion rio o administrador pode escolher ou n o alterar as permiss es de acesso ao sistema daquele funcion rio alterado executando o caso de uso UC02 Vincular Permiss es OBS As permiss es de acesso encontram se cadastradas na tabela PERMISS O Desativar Funcion rio O administrador dever selecionar o usu rio que deseja excluir e clicar no bot o Excluir para que os dados daquele funcion rio possam ser desativados no sistema Al m de desa tivar o funcion rio as permiss es de acesso ao sistema do mesmo devem ser exclu das da tabela PERMISS O Fluxos alternativos Funcion rio j cadastrado Este fluxo ocorre quando o administrador tenta inserir um funcion rio com o CPF igual ao
95. ios ciclos que ocorrem durante o projeto eliminando assim grande parte dos riscos que geralmente est o associados fase de integra o permitindo desta forma aumentar significativamente as chances de sucesso Segundo Kroll e Kruchten 2003 p 38 um artefato uma parte de informa o que produzida modificada ou usada por um processo Artefatos s o elementos tang veis de projetos que s o usados como entrada de regras para executar uma atividade e s o tamb m o resultado de outras atividades 4 2 Organiza o dos Modelos Um modelo criado tendo como base observa es do mundo real ou uma aproxima o baseada nos objetivos do sistema O modelo deve ser simples o bastante para permitir uma r pida implementa o da solu o dos problemas levantados De acordo com Kroll e Kruchten 2003 p 34 o RUP trabalha com os modelos providos pela UML Modelo de an lise tem foco no neg cio organizando os elementos do Modelo em pacotes que dar o origem aos subsistemas Modelo de design refinamento do Modelo de an lise com foco na implementa o fi sica do sistema Modelo de banco de dados consiste nos modelos l gico e f sico do banco de dados 40 RUP RATIONAL UNIFIED PROCESS Modelo de casos de uso casos de uso organizados em pacotes fornecendo uma vis o externa do sistema Modelo de implanta o descreve a distribui o f sica do sistema indicando como os subsistemas ser
96. iro Elsevier 2005 474 p KROLL Per KRUCHTEN Philippe The Rational Unified Process Made Easy A Practitioner s Guide to the RUP 1 ed Boston Addison Wesley 2003 KRUCHTEN Philippe Introdu o ao RUP Rational Unified Process 2 ed Rio de Janeiro Editora Ci ncia Moderna Ltda 2003 MICROSOFT Project Homepage Dispon vel em lt http office microsoft com pt br project default aspx gt Acesso em 27 fev 2007 PMBOK Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos Guia PMBOKG 3 ed Eua Four Campus Boulevard 2004 PRADO Darci Gerenciamento de Projetos nas Organiza es Belo Horizonte Dg 2003 199 p PROJECT OPEN project open Dispon vel em lt http www project open com gt Acesso em 27 fev 2007 PRESSMAN Roger S Engenharia de Software S o Paulo Pearson Makron Books 1995 RATIONAL SOFTWARE CORPORATION Rational Unified Process Dispon vel em lt http www wthreex com rup gt Acesso em 20 mar 2007 SILVEIRA NETO Fernando Henrique da DISNMORE Paul Campbell Como gerenciar equipes de projetos e consquistar resultados atrav s de pessoas Mundo PM Project Program Portfolio Management Rio de Janeiro n 10 p 58 60 ago set 2006 Bimestral SOMMERVILLE lan Engenharia de Software 6 ed S o Paulo Pearson Education 2005 VARGAS Ricardo Viana Identificando e Recuperando Projetos Problem ticos Como Resgatar seu Projeto do Fracasso Mundo PM Project Progr
97. is es de escopo Coordenador Administra o do plano e programa de traba lho Execu o do cronograma Levantamento de requisitos segundo RUP An lise e desenho da solu o segundo RUP Analista de Garantir a documenta o e andamento do Marcos Alves Sistemas projeto segundo a metodologia RUP Garantir que a auditoria valide os artefatos gerados em cada fase do projeto An lise e desenho da solu o segundo RUP e VA Garantir a documenta o e andamento do Rodrigo de Oliveira Analista de projeto segundo a metodologia RUP Neves Sistemas o Garantir que a auditoria valide os artefatos gerados em cada fase do projeto An sio Rodrigues Analista de An lise e desenho da solu o segundo RUP Neto Sistemas Garantir a documenta o e andamento do REFER NCIAS ANEXOS 61 projeto segundo a metodologia RUP Garantir que a auditoria valide os artefatos gerados em cada fase do projeto A1 2 2 Resumo dos Usu rios Nome Descri o Responsabilidades Diretor Diretor da Empresa Monitora o andamento dos projetos em que a empresa est envolvida UC14 Gerente de Projetos Gerente do projeto Monitora o andamento do seu projeto UC10 Estima as horas de cada tarefa relacionada ao seu projeto UCOS e UCO6 Assegura o cumprimento dos prazos e metas estipuladas nas tarefas UC12 Relaciona os recursos dispon veis pa
98. jeto s o PMBOK 2004 Desenvolver o termo de abertura do projeto ou seja uma autoriza o formal do proje to Desenvolver a declara o do escopo preliminar onde possibilita uma vis o de alto n vel do escopo do projeto Desenvolvimento do plano de gerenciamento do projeto onde faz se a constru o de um documento coerente e defini se como o projeto executado monitorado controla do e encerrado GERENCIAMENTO DE PROJETOS 19 Orientar e gerenciar a execu o do projeto que consiste em realizar v rias a es para a realiza o do trabalho que foi definido no escopo do projeto Monitorar e controlar o trabalho do projeto onde feita uma verifica o do andamen to desempenho e avalia es para efetuar melhorias no processo Um monitoramento cont nuo permite que a equipe identifique as reas que exigem uma aten o especial Controle integrado de mudan as que realizado desde o in cio do projeto at o seu t rmino Permite o controle das mudan as que ocorreram durante todo o projeto Encerrar o projeto onde v rios processos s o envolvidos tais como encerramento do processo administrativo de contrato e o de formaliza o da entrega do projeto Segundo o PMBOK 2004 Gerenciamento de Escopo do Projeto composto dos pro cessos necess rios para garantir que o projeto inclua todo o trabalho necess rio e somente ele para terminar o projeto com sucesso Os principais pro
99. joeRosseursngesexkucueque peoequorss ses xkuss MeN prebojegssouishgeso KUSHE ex E ELLE Stsexlue eng esexugunioxs df esaxdupjooesnoxa dsl Jopersiuwpy esada anpxa ps 108 REFER NCIAS ANEXOS B2 1 7 UCO7 Realizar Login ss mae bebe sa gt i i 607 oyeuopuny Boyelsb 1 1 1 i i ogsses EU oueuo puny op OB poo o ENEE LA 4 kk q pos ss gt gja oungpoo secss uedo yuen sn i Quv 1snie H 1 H 1 euues ouersn euu siSiesssoe ue ooq La euues ouensn etuap isresseoe ue looq 1 euues ouensn ewaBisiessace ue looq i i euues Ouensn ewes Sesa ueejooq i se o i i i i i I i i i l l i t T 1 i i 1 f i i T 1 i 1 1 i L H 1 i ouer pus qediouud 7 T T TES TS Vull TES dsl dsl 607 wezi reay ps S NDOT vosnA dos 1s REFER NCIAS ANEXOS 109 B2 1 8 UC08 Verificar Permiss es oun jpoo saoss Lua HO yuan Sun Ipoos cssiuu cueOSIJu A SS oun4poo jseossiuuegeouuoA SIS
100. la com todos os funcion rios cadas trados no sistema Se for vincular funcion rios para uma nova tarefa o sistema dever carregar todos os funcion rios com nenhum selecionado caso seja de uma tarefa que seus dados foram alterados dever carregar todos os funcion rios mas aquelas que j fora ati vados no primeiro cadastro devem estar selecionados Fluxos alternativos Nenhum Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como administrador ou gerente de projetos Condi es Posteriores Ap s a execu o do caso de uso gerar log da opera o executando caso de uso UCO9 Gerar Log de Acesso REFER NCIAS ANEXOS 71 A2 4 4 UCO4 Manter Tarefas Breve Descri ao Este caso de uso tem como finalidade cadastrar alterar ou excluir Tarefas dos projetos do sistema proposto Fluxo de Eventos Fluxo Basico Este caso de uso se inicia quando o administrador ou o Gerente do Projeto vai cadastrar alterar ou excluir uma tarefa de um determinado projeto Cadastrar Tarefas O administrador ou gerente de projetos dever informar os seguintes dados em um formu l rio 1 Projeto 7 Data de in cio 2 Nome da tarefa 8 Data final 3 Status atual Ativo Inativo 4 Prioridade 5 Horas estimadas 6 Descri o Campos obrigat rios Depois disso dever clicar no bot o Incluir Ap s a inclus o da tarefa o administrador ou gerente do projeto pode e
101. lidades que foram vinculadas em seu cadastro As funcionalidades s o m dulos de acesso ao sistema A1 6 Vis o Geral do Sistema Proposto A1 6 1 Caracter sticas do Sistema Proposto Este sistema ter como finalidade gerenciar todos os projetos cadastrados assim como as suas ta refas relacionadas O objetivo do sistema controlar de forma detalhada o andamento de cada projeto al m do cumprimento de suas tarefas O sistema dever calcular automaticamente as porcentagens de conclus o de cada projeto a partir dos logs das tarefas gerados pelos usu rios que podem ser os analistas desenvolvedores e ou projetistas Dever possuir consultas e relat rios que auxiliem os Diretores acompanharem o andamento dos projetos da sua empresa assim como os Gerentes de Projetos terem acesso s informa es referentes ao seu projeto O sistema dever ter controle de acesso onde cada usu rio ter permiss o espec fica s funcionalidades a l m disso proporcionar o controle de logs das a es de cada usu rio conectado no sistema A1 6 2 Ambiente Alvo Tecnologia Padr o Vers o OBS Servidor de Banco de Dados MySql 5 0 Linguagem de Programa o JAVA JavaScript XML Ajax 64 REFER NCIAS ANEXOS A2 Casos de uso A2 1 Atores Administrador do Sistema Este ator possui acesso total todas funcionalidades do sistema Gerente de Projetos Respons vel no acompanhamento do
102. luxo B sico Este caso de uso se inicia quando qualquer usu rio em geral quer acessar o sistema O usu rio acessa a p gina de inicial do sistema Fornece seus dados de login e senha e clica em Logar O sistema verificar se o usu rio cadastrado e se o mesmo possui per miss o para acessar o sistema executando o caso de uso UCO8 Verificar Permiss es Ap s isto o usu rio ter acesso p gina principal do sistema Ap s verificar as permis s es e montar o menu de op es na tela o sistema buscar todas as tarefas do usu rio em quest o executando o UC12 Visualizar Tarefas Campos obrigat rios Fluxos alternativos Login ou senha inv lidos Este fluxo ocorre quando o usu rio digita a senha ou o login incorretamente Emitir mensagem Login ou senha inv lido Dados Incompletos Este fluxo ocorre quando algum campo obrigat rio n o foi preenchido no formul rio Emitir mensagem dos dados que est o faltando e colocar o foco no primeiro campo incor reto Sem permiss o Este fluxo ocorre quando o usu rio n o tem permiss o para acessar o sistema Emitir mensagem Voc n o possui permiss o para acessar o sistema Condi es Pr vias Nenhuma Condi es Posteriores Ap s a execu o do caso de uso gerar log da opera o executando caso de uso UCO9 Gerar Log de Acesso 78 REFER NCIAS ANEXOS A2 4 8 UCO8 Verificar Permiss es Breve Descri o Este c
103. m essa conven o de nomea o fica bvio que um m todo definir o valor de um campo de um objeto DES97 Nomea o de Construtores Os construtores s o m todos que executam a inicializa o necess ria quando um objeto criado pela primeira vez Os construtores sempre recebem o mesmo nome da classe a que per tencem Por exemplo um construtor da classe Tarefa ser Tarefa O uso de letras mai sculas e min sculas o mesmo Essa conven o de nomea o definida pela Sun Microsystems e deve ser seguida rigo rosamente Visibilidade de m todos Para garantir um bom design no qual voc diminua o acoplamento entre classes adote como regra pr tica geral ser o mais restritivo poss vel ao definir a visibilidade de um m todo Se um m todo n o precisa ser p blico defina a como protegido Se n o precisar ser protegido defi na a como privado Visibilidade Descri o Uso adequado p blica Um m todo p blico pode Quando o m todo tem de ser acessado por ser disparado por outro objetos e classes fora da hierarquia de m todo em outro objeto ou classes na qual o m todo est definido classe REFER NCIAS ANEXOS 131 protegida Um m todo protegido pode Quando p m todo fornece comportamento ser disparado por qualquer que necess rio internamente hierarquia m todo da classe na qual de classes mas n o externamente ela est definida ou por qualquer subclasse dessa classe
104. m sistemas de grande porte o tratamento de um volume grande de exce es em cada n vel dificulta a leitura e a manuten o do c digo As vezes o processamento de exce es inibe o processamento normal N o use exce es para eventos freqiientes e previs veis N o use exce es para implementar estruturas de controle Certifique se de que os c digos de status tenham valores apropriados Ao usar c digo de status retornado por subprogramas como um par metro externo ve rifique se h um valor atribu do a esse par metro fazendo com que essa seja a primeira instru o execut vel no corpo do subprograma Sistematicamente coloque todos os status como sucesso ou como fracasso por padr o Pense em todas as poss veis sa das do subprograma inclusive os controladores de exce o Realize verifica es de seguran a localmente N o espere que o cliente o fa a Se houver a possibilidade de um subprograma produzir resultados errados caso n o seja informada determinada entrada instale o c digo no subprograma para detectar e relatar entradas inv lidas de maneira controlada N o se baseie em coment rios que solicitam que o cliente in forme os valores apropriados praticamente garantido que mais cedo ou mais tarde o coment rio ser ignorado resultando em erros de dif cil depura o caso os par metros inv lidos n o se jam detectados REFER NCIAS ANEXOS 143 B4 1 8 Diversos Padr es em quest o Reutiliza o
105. n ner en rene enen 139 B4 1 6 Padr es para classes Interface e Pacotes erre enen 140 B4 1 7 Tratamento de Erros e Excec eg eee eee eee enteve 142 B4 1 8 Diversos Padr es em quest o rr nenen ecen rren re ente ere eren 143 BARR die 145 LISTA DE ILUSTRA ES Figura 2 1 Mapa mental dos indicadores de um projeto problem tico sse 17 Figura 2 2 Vis o geral das reas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de proJetos dte rdi erepta ree I EG y e E Dee tbe kd E 23 Figura 3 1 Exemplo de Diagrama de Classes 29 Figura 3 2 Exemplo de Diagrama de ObjJetos nn enne 30 Figura 3 3 Exemplo de Diagrama de Implanta o sese 31 Figura 3 4 Exemplo de Diagrama de Artefatos modelagem de c digo fonte 32 Figura 3 5 Exemplo de Diagrama de Artefatos modelagem de vers es execut vels 32 Figura 3 6 Exemplo de Diagrama de Artefatos modelagem de banco de dados f sicos 33 Figura 3 7 Exemplo de Diagrama de Artefatos modelagem de sistemas adapt veis 33 Figura 3 8 Exemplo de Diagrama de Casos de Uso en eeonee neo oreve ee enen e ene eene 34 Figura 3 9 Exemplo de Diagrama de Seat nca sene e veze never rene rene en rene eren 35 Figura 3 10 Exemplo de Diagrama de
106. ndidatos T tulo do Trabalho Gerenciador de Projetos Web JEE Desenvolvimento Orientado a Objetos usando Metodologia RUP Um Estudo de Caso ALUNOS Matr cula Banca Orientador M dia por atraso Final 1 An sio Rodrigues Neto 403 2684 5 2 Marcos Alves Pereira 403 4974 8 3 Rodrigo de Oliveira Neves 403 2569 5 COMISS O JULGADORA NOTA Orientador Titular 1 Titular 2 Suplente M dia Obtida pelo Grupo de Trabalho Para constar lavrado o presente termo que vai assinado pela Comiss o Julgadora e pelo Coordenador de TGI S o Paulo Comiss o Julgadora Prof Prof Prof Coordenador de TGI Prof As nossas fam lias amigos e professores AGRADECIMENTOS Deus que esteve sempre presente em todos os momentos dando nos coragem e determina o s nossas fam lias pelo incentivo e apoio nos momentos dif ceis Ao professor Vinicius Miana Bezerra por nos orientar e encorajar na realiza o deste trabalho todos os colegas do curso de Sistemas de Informa o a nossa gratid o pela ajuda e colabora o ao longo destes anos RESUMO O gerenciamento de projetos se tornou fator cr tico de sucesso com rela o competitividade entre as empresas Na rea de desenvolvimento de sistemas metodologias s o adotadas para minimizar falhas ao longo do ciclo de vida do projeto Em alguns casos a escolha de uma determinada metodolo
107. nizada em tr s se es PMBOK 2004 A primeira se o A estrutura do gerenciamento de projetos fornece uma estrutura b sica para que o leitor entenda sobre gerenciamento de projetos Nesta se o h o ca p tulo de Introdu o onde fornecido uma vis o geral do restante do guia e o cap tulo de Ciclo de Vida e Organiza o do Projeto que descreve o ambiente no qual o projeto opera Na segunda se o A norma de gerenciamento de projetos de um projeto aborda os cinco grupos de processos de gerenciamento de projetos necess rios para qualquer projeto e os processos de gerenciamento de projetos que os comp em A terceira se o aborda as reas de conhecimento em gerenciamento de projetos es tando elas divididas cada uma em um cap tulo PMBOK 2004 o Gerenciamento de integra o do projeto o Gerenciamento do escopo do projeto o Gerenciamento de tempo do projeto o Gerenciamento de custos do projeto o Gerenciamento da qualidade do projeto o Gerenciamento de recursos humanos do projeto o Gerenciamento das comunica es do projeto o Gerenciamento de riscos do projeto o Gerenciamento de aquisi es do projeto Conforme descrito no PMBOK 2004 Gerenciamento de Integra o de Projeto assegura que os processos e as atividades que integram os diversos elementos do projeto estejam adequa damente coordenados Os principais processos que correspondem ao Gerenciamento de Integra o de Pro
108. nte alcan ados e tamb m com mais facilidade Na rea de desen volvimento de software n o diferente Um software nada mais do que o resultado de um pro jeto portanto enfrenta os mesmos problemas podendo tamb m ter como seu futuro o fracasso Metodologias de gerenciamento de projetos est o sendo implantadas nas empresas hoje em dia com o objetivo de proporcionar uma melhor administra o e controle dos sistemas que est o sendo desenvolvidos desde sua documenta o at a fase de implementa o Cada projeto possui caracter sticas nicas e esse fato dificulta a ado o de uma metodologia nica para todos os projetos Para contornar esse tipo de problema em muitos casos s o elaboradas novas meto dologia com intuito de atender todos os diferentes tipos de projetos Essa elabora o na maioria das vezes feita com base em metodologias j existentes e consagradas Prado 2003 Muitas metodologias s o complexas e n o servem para projetos de pequeno porte E de contraponto existem metodologias mais simples que n o atendem projetos com grande porte Para o desenvolvimento de sistemas orientados a objetos a Rational Unified Process RUP possui caracter sticas que a colocam como uma das principais metodologias adotadas nas organiza es Por m em cada etapa do ciclo de vida do projeto muitos documentos s o gerados o que pode ocasionar atrasos na sua entrega se for de baixa complexidade Para evitar que ocor
109. nterior e as di reciona para a camada de persist ncia que por sua vez respons vel em atualizar as informa es no banco de dados ou em algum sistema legado Com base nesse pattern o sistema foi implementado conforme o diagrama a seguir sd Cadastrar Empresa 7 EE jp CadastrarEmpresaAction ManterEmpresaBusinessDelegatel ionFacadel Manter BusinessObject Mante saDAQI ST SGP EMPRESA xcadastroOKEmpresal Administrador cadastrar 1 gt i cadastrarEmpresa Empresa e cadastrarEmpresa Empresa H EE EE cadastrarEmpresa Empresa loton alt ERRO NO CADASTRO 7 true H Mensagem Esta empresa j est cadastrada Figura 5 3 Realiza es A figura 5 3 apresenta os seguintes componentes ST SGP EMPRESA I uma storage procedure ST que s o c digos SQLs Struc tured Query Language Manter EmpresaDAO respons vel pelas conex es aos banco de dados e executar as storage procedures Este objeto faz parte da camada de persist ncia Manter EmpresaBusinessObject o objeto respons vel pela regra de neg cio Toda regra de neg cio codificada neste objeto ManterEmpresaSessionFacade o objeto respons vel em controlar a transa o Manter EmpresaBusinessDelegate o objeto respons vel em localizar o objeto Man terEmpresaSessionFacade que pode estar no mesmo ou em outr
110. nto do projeto Segundo Pressman 1995 p 789 testes s o realizados e todos os resultados s o avalia dos ou seja s o comparados com os resultados esperados Quando dados err neos s o encontra dos infere se a presen a de erros e inicia se a depura o Pode se testar a funcionalidade dos prot tipos sua estabilidade e desempenho ainda com a possibilidade de corrigir eventuais erros em tempo de desenvolvimento isso al m de assegurar a qualidade do produto entregue ao cliente A id ia de testar tudo apenas quando o sistema estiver pronto desconsidera o principal benef cio do teste detectar problemas enquanto ainda h tempo para se fazer algo a respeito Os seguintes artefatos s o trabalhados neste processo Plano de Testes Modelo de Testes composto por o Casos de Teste o Procedimentos de Teste o Scripts de Teste o Notas Resultados Modelo de Carga 4 4 6 Distribui o O objetivo deste processo disponibilizar o sistema para os usu rios O maior n vel de ativida des deste processo ocorre na fase de transi o entre o novo sistema e o anterior caso exista Pa ra facilitar os trabalhos o usu rio deve ser envolvido o mais cedo poss vel iniciando com a ava lia o de vers es beta e apontando procedimentos que pode vir a facilitar esta transi o RUP RATIONAL UNIFIED PROCESS 47 Distribui o consiste em Teste do sistema no ambiente de produ o Empacotamento do software p
111. o Por exemplo uma empresa de consultoria usaria uma configura o diferente de uma empresa de publicidade De todos os SGP o ProjectOpen possui melhor seguran a e integra o dividindo de forma muito eficiente o acesso dos stakeholders com fun es distintas Duas grandes desvan tagens para o mercado brasileiro se destacam o software n o possui vers o em portugu s e a lin guagem utilizada a TCL linguagem pouco utilizada nos tempos atuais PROJECT OPEN 2007 O Gforge atende a todas as necessidades do ciclo de vida de um projeto Atua tamb m como um sistema de registro de bugs e de reposit rio de distribui o c digos fontes execut veis Possui um plugin comercial que capaz de interagir com o MSProject da Microsoft Foi desenvolvido em PHP Linux Apache e banco de dados PostgreSQL e outros componentes op cionais Hoje em dia existe uma vers o comercial dispon vel pelo Gforce Group chamada En terprise CDE GFORCE 2007 O Gantt Project focado na elabora o de cronogramas para necessidades simples Foi desenvolvido em Java podendo ser utilizado em v rios sistemas operacionais Na vers o 2 seus GERENCIAMENTO DE PROJETOS 25 dados podem ser importados e exportados no formato do MSProject Bastante indicado em pro jetos onde o cronograma de extrema import ncia GANTTPROJECT 2007 O Planner nada mais que a continua o do Mr Project software que j foi bastante po pular entre usu rios de
112. o A 5 1 1 Documento de Vis o A elabora o deste documento deu se por ser o marco inicial do projeto Neste artefato foram descritos os stakeholders envolvidos assim como suas responsabilidades e a defini o dos usu rios que utilizar o o sistema Al m disso foram definidos os requisitos funcionais e n o funcio nais tais como seguran a e disponibilidade Este artefato define a vis o que as partes envolvidas tem do sistema suas necessidades e caracter sticas importantes Este documento foi atualizado e mantido durante todo o tempo de vida do projeto e me dida que novos requisitos foram apontados detalhados e inseridos no escopo do projeto o Do cumento de Vis o refletiu estas mudan as Um ponto importante neste artefato a descri o da vis o geral do sistema proposto Neste item s o abordados os objetivos do sistema que serve como base para pr ximo o artefato o Casos de uso A finalidade deste artefato foi coletar analisar e definir os requisitos do sistema O foco est nos recursos necess rios dos envolvidos no desenvolvimento os usu rios do sistema e as ra z es que levam a estas necessidades 5 1 2 Casos de uso Os casos de usos s o documentos importantes no processo de desenvolvimento de um sistema Este artefato uma segii ncia das a es realizadas por um sistema que produz um resultado de valor observ vel para determinado ator Estes documentos s o geralmente escritos pelos analis tas
113. o decorrer do desenvolvimento A utiliza o de uma metodologia tenta evitar que mudan as atrapalhem o andamento e conclus o do projeto no tempo determinado Segundo a Rational 2001 o RUP se divide em quatro fases diferentes que ser o expli cadas posteriormente Concep o Elabora o Constru o Transi o O RUP composto de uma ou mais itera es geralmente de per odo curto uma a duas semanas o que reduz o impacto de mudan as Al m das fases e itera es existem tamb m os workflows que Kroll e Kruchten 2003 p 38 nada mais s o do que uma seq ncia de tarefas relacionadas a um importante aspecto do projeto em quest o Cada tarefa descrita em detalhes onde definido o respons vel a qual o workflow pertence e quais as entradas e sa das que s o descri es essenciais Segundo Kruchten 2004 p 5 o RUP segue as melhores pr ticas de desenvolvimento de software entre elas Desenvolvimento iterativo Gerenciamento de requisitos Arquitetura e uso baseados em componentes Organiza o da especifica o em modelos e UML Verifica o constante da qualidade Controle de mudan as e configura es 4 1 Desenvolvimento Iterativo Segundo Kruchten 2004 p 6 o desenvolvimento iterativo proposto pelo RUP tem por objetivo conduzir o projeto em ciclos isto itera es Cada um destes ciclos tratado de forma tradicio RUP RATIONAL UNIFIED PROCESS 39 n
114. o servidor 54 PROJETO CadastrarEmpresaA ction o objeto respons vel em receber dos dados do browser cadastrarOKEmpresa jsp a p gina que o cliente interage seja para criar uma soli cita o ou para receber alguma informa o Todas as realiza es foram feitas com base nesse padr o O restante dos diagramas do sistema pode ser visualizado nos anexos B 5 2 4 Modelo de Dados O modelo de dados representa como as informa es do sistema que ser o armazenadas no banco de dados Para isso criou se o MER Modelo Entidade Relacionamento a partir do diagrama de classe do artefato anterior que identifica as tabelas colunas e seus tipos de dados e os relacio namentos e suas associa es Neste documento o importante criar um modelo consistente e organizado para que os dados sejam armazenados Para n o ter nenhuma d vida dos campos inseridos nas respectivas tabelas foram dicionarizadas todas as colunas explicando se o que estas representam nas tabelas e foram definidas as chaves PK Primary Key e FK Foreign Key das tabelas para que o siste ma n o tenha dados duplicados Para criar o modelo utilizou se uma ferramenta Case pr pria de banco de dados que au xiliou e muito na gera o autom tica dos scripts SQLs para a cria o das tabelas no sistema 5 2 5 Guia de Programa o Java O guia de programa o java um manual de boas pr ticas de programa o na linguagem Este documento auxiliou os de
115. ojeto n o est fugindo do seu escopo Segundo Prado 2003 um SGP deve refletir a metodologia da organiza o e na maioria das vezes a compra de um SGP completo nem sempre poss vel Ou seja a maioria das empre sas adota metodologias diferentes para o gerenciamento de seus projetos logo para fazer um bom gerenciamento em algumas ocasi es torna se necess rio o desenvolvimento de um sistema espec fico que atenda s necessidades da empresa No mercado atualmente existem diversos SGP Dentre eles encontra se desde solu es de Softwares Livres onde muitas vezes n o existe custo at solu es propriet rias com alto custo de licen a Existem sistemas tanto com interface web quanto para instala o desktop Como exemplo de SGP com interface web pode se citar dotProject ProjectOpen e Gforce E para instala o desktop Gantt Project MSProject Planner e Real Time Project O dotProject um sistema totalmente baseado em web Foi desenvolvido em PHP e seus criadores indicam a utiliza o da combina o cl ssica LAMP Linux Apache MySQL e PHP Possui instala o simples para usu rios que est o familiarizados com a configura o de servido res e por seu banco de dados ser MySQL permite f cil manipula o dos dados DOTPROJECT 2007 O ProjectOpen tem como objetivo principal a administra o dos custos de um projeto e a colabora o dos stakeholders Possui configura es pr prias para diferentes ambientes de us
116. oloigpoopsejase 1eosnq en i i i i i non Ovdejsie SEE SEET oja fo ypoo seyare recsnq 8n ojos foxdpoosejsre jeosnq en oja loaigpoopsejare eosnq sn E ESSE ESP seie 1eosng ps REFER NCIAS ANEXOS 97 Alterar Tarefa Tepe eue ee eres pee ejere 1 poojejare SOPR enq ejere A ejale 1 poo ejare sopequecsng ejan el Mg I eae Deje mile ND ea Ejere poojejare jsopegjezenq ee jae Jee moe Bae eNe a exuepeoaid en e euo pros opeuopajas ofod op sejai se easnq Ta b E ois lado euopeps N yama dos 1s S vash aos IS Ovagerpiauegr Peigosseursngeemuimuew peana P esepasseursnas muiauew eje posjejar jscpecueasnq ojlaid Gieres astaoeceme lt gt lt gt E bast ap steet eem ay ps 98 REFER NCIAS ANEXOS Cadastrar Tarefa T Teo Depe Lensepeo ejere Dejere epepeo e A ejare ejoue rensepeo E epeursepeo vise pl ejar epg ef e H OHLSVIVO ON OHS He enn epe ejare jyergepeo VWI dos 1S Ovdegiersuen i E i i i i PE
117. onceito de interfaces novo na linguagem Java as pessoas ainda Pacotes REFER NCIAS ANEXOS 141 n o t m experi ncia com o seu uso adequado e est o propensas a utilizarem as interfa ces em excesso Como as interfaces devem e n o devem ser usadas Os desenvolvedores precisam saber como uma interface deve ser usada e como ela n o deve ser usada H v rias regras associadas nomea o de pacotes Por ordem as regras s o Identificadores s o separados por pontos Para garantir a legibilidade dos nomes de pacote a Sun sugere que os identificadores dos nomes de pacote sejam separados por pontos Por exemplo o nome de pacote java awt formado por dois identificadores java e awt Os pacotes padr o de distribui o Java da Sun come am com o identificador java A Sun reservou se esse direito para que os pacotes padr o Java sejam nomea dos com consist ncia seja qual for o fornecedor do ambiente de desenvolvimento Ja va Os nomes de pacotes locais come am com um identificador cujas letras n o s o todas mai sculas Os pacotes locais s o usados internamente na organiza o e n o se r o distribu dos para outras organiza es Alguns exemplos desses nomes de pacote s o persistence mapping relational e interface screens Os nomes de pacotes globais come am com o nome de dom nio da Internet para sua organiza o invertido Um pacote que ser distribu do para v rias organiza es deve incluir o nome de
118. ontal representa o tempo e mostra os aspec tos do ciclo de vida do processo medida que se desenvolve e o vertical representa as discipli nas que agrupam as atividades de maneira l gica por natureza As atividades representam pacotes de trabalho que produzem resultados relevantes para o projeto geralmente associadas cria o ou atualiza o de artefatos que por sua vez s o os ele mentos a serem entregues ao cliente tais como classes componentes subsistemas interfaces documentos programas execut veis etc Segundo a Rational Software Corporation 2001 a seq ncia de atividades resulta em ar tefatos a serem criados pelos respons veis de modo que agreguem valor para o projeto Um ar tefato pode ser traduzido como um diagrama de atividades UML ou parte dele e deve ser adap tado s v rias fases do projeto em detrimento dos seus objetivos O RUP define nove fluxos de atividades Figura 4 1 Workflows Modelagem de neg cio Requisitos An lise e Projeto Implementa o Distribui o Configura o e Gerenciamento de Mudanga Gerenciamento t H de Projeto H H Ambiente 1 ed ode tirTran ran Inicial ECO lab 42 ij nicia a Ela qo an cadens Figura 4 1 Nove fiuc centrados no processo fonte Philippe Kruchten 2004 p 36 42 RUP RATIONAL UNIFIED PROCESS Modelagem de neg cio Requisitos An lise e design
119. or ou Gerente do Projeto dever selecionar o projeto que deseja alterar Au tomaticamente os dados daquele projeto ser o carregados na tela O administrador ou ge rente do projeto alterar os dados necess rios e clicar no bot o Alterar Excluir Projetos O administrador dever selecionar o projeto que deseja excluir e clicar no bot o Excluir para que os dados daquele projeto selecionado possam ser exclu dos do sistema Para que a exclus o seja efetuada necess rio que n o tenha nenhuma tarefa cadastrada no proje to selecionado 74 REFER NCIAS ANEXOS Fluxos alternativos Projeto j cadastrado Este fluxo ocorre quando existe no banco de dados um projeto j cadastrado com o mes mo nome do projeto que se deseja cadastrar Emitir mensagem Este projeto j est cadastrado Dados Incompletos Este fluxo ocorre quando algum campo obrigat rio n o foi preenchido no formul rio Emitir mensagem dos dados que est o faltando e colocar o foco no primeiro campo incor reto Projeto N o Selecionado Este fluxo ocorre quando n o foi selecionado nenhum projeto para as op es de alterar ou excluir Emitir mensagem Selecione um projeto para alterar ou excluir Projeto com tarefas cadastradas Este fluxo ocorre quando existe um ou mais registros de tarefas para o projeto que se de seja excluir Emitir mensagem N o poss vel excluir o projeto selecionado pois existem tarefas ca dast
120. ossam ser exclu dos do sistema Para que a exclus o seja efetuada necess rio que n o tenha nenhum projeto cadastrado com a empresa selecionada Fluxos alternativos Empresa j cadastrada Este fluxo ocorre quando existe no banco de dados uma empresa j cadastrada com o mesmo CNPJ da empresa que se deseja cadastrar Emitir mensagem Esta empresa j est cadastrada Dados Incompletos Este fluxo ocorre quando algum campo obrigat rio n o foi preenchido no formul rio Emitir mensagem dos dados que est o faltando e colocar o foco no primeiro campo incor reto Empresa N o Selecionada Este fluxo ocorre quando n o foi selecionada nenhuma empresa para as op es de alterar ou excluir Emitir mensagem Selecione uma empresa para alterar ou excluir Empresa com projetos cadastrados Este fluxo ocorre quando existe um ou mais registros de projetos para a empresa que se deseja excluir Emitir mensagem N o poss vel excluir a empresa selecionada pois existem projetos vinculados Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como administrador Condi es Posteriores Ap s a execu o do caso de uso gerar log da opera o executando caso de uso UCO9 Gerar Log de Acesso REFER NCIAS ANEXOS 77 A2 4 7 UCO7 Realizar Login Breve Descri o Este caso de uso tem como finalidade dar acesso ao sistema Fluxo de Eventos F
121. piebepasseuisngejereLeueyE gov ejerosseaboigarogeosng di dsl emm ep ouawepuy sensepeo ps 114 REFER NCIAS ANEXOS Buscar Andamento da Tarefa jeja ISolu tuepuyosnq BT a Vejare sojueurepuyreosnq Er1 S SHvL ONG dos 1s rasa pene L RiOss ursngejJ 1eLssuelN r Deep soueuepuyeosna SM PPESEIUOISSSSUS EL ISHIN GESOT jue ejare jsojusLuepuyeosna ST ws Staue ap soJuauepuy Jeosng ps REFER NCIAS ANEXOS 115 B2 1 12 UC12 Visualizar Tarefas jdo oueuorun sejere jessnq eJaJe dojoueuopunsejare 2 Leosnq SM 1 oueuorunasejare ecenq ejare T i 607 oueuopun j 6o eis6 i Jo no gt EH aaepe EE lI SC ISSSUISPISIPJSIPLT INEIN i Idojoueuopunss jare peosnq Sr i E I oueuopunj op sejare eosng i i l ouenn lorrensnsejoJer 19A noy 2unejoer je sngr df SeJOJeL aezilensiA ZION PS 116 REFER NCIAS ANEXOS B2 1 13 UC13 Visualizar Andamento de Tarefas ere 1poojejere Legsousurepuyieosna F r f amp j re Ipoojejere Isqsolueurepuveosnq E Bg
122. projeto que coordena as sim como vincular as tarefas para a equipe do seu projeto Usu rio Ator que alimenta a maior parte do sistema Ser ele que controlar sua tare fa assim como o status log desta Diretor Diretor da empresa que ter a vis o macro dos andamentos dos projetos em que a sua empresa esta executando A2 2 Lista de Casos de Usos UC01 Manter Funcion rio UC02 Vincular Permiss es UC03 Vincular Funcion rios UC04 Manter Tarefas UCOS Manter Projetos UC06 Manter Empresa UC07 Realizar Login UCOS Verificar Permiss es UC09 Gerar Log de Acesso UC10 Consultar Andamento do Projeto UC11 Manter Andamento da Tarefa UC12 Visualizar Tarefas UCI3 Visualizar Andamento de Tarefas UC14 Exibir dados dos projetos em andamento A2 3 Casos de Usos ud Use Case Model J dados dos andamento Diretor Login UC14 Exibir projetos em UC07 Realizar lt include gt UC08 Verificar Permiss es REFER NCIAS ANEXOS 65 ud Use Case Model Administra extends UC02 Vincular Permiss es UCO9 Gerar Log UC04 Manter E a de Acesso Tarefas include 5 extend 7 UCO5 Manter Projetos PUT indude 7777 2 UCOS Gerar Log de Acesso UC06 Manter Empresa include UC09 Gerar Log de Acesso include _ ___ aiaiai gt UC1
123. que j se encontra cadastrado no banco de dados Emitir mensagem Funcion rio j cadastrado Dados Incompletos Este fluxo ocorre quando algum campo obrigat rio n o foi preenchido no formul rio Emitir mensagem dos campos que est o faltando e colocar o foco no primeiro campo in correto Funcion rio N o Selecionado Este fluxo ocorre quando n o foi selecionado nenhum funcion rio para as op es de alte rar ou excluir 68 REFER NCIAS ANEXOS Emitir mensagem Selecione um funcion rio para alterar ou desativar Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como administrador Condi es Posteriores Ap s a execu o do caso de uso gerar log da opera o executando caso de uso UCO9 Gerar Log de Acesso REFER NCIAS ANEXOS 69 A2 4 2 UCO2 Vincular Permiss es Breve Descri o Este caso de uso tem como finalidade vincular as permiss es de acesso ao sistema para os funcion rios cadastrados Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o administrador ao cadastrar ou alterar um funcion rio ter que vincular suas permiss es de acesso ao sistema O administrador selecionar ou alterar as permiss es para o funcion rio e depois clicar em Gravar Permiss es Este caso de uso carregar uma tela com todas as permiss es de acesso ao sistema Se for vincular as permiss es de um funcion rio novo dever car
124. r Projeto ejnoexe oie foxgpos ors foxuinpxo 038 o1gpoo oje lo mpxa Li 4 oreloxapoo are farai pxe epersepeosejare P ixesiod opeuopejes ol loid o 1Impxo janssod 9 OEN usbesuay Gsseons LUCO vpez peau ogsniox3 uueBesuo I I i olebudpoo ol loucunpxe Ke OVSNTOXA WN ouda HE T olod anpxe gt L sojaloxd jecenq a i E PpeoesuorssesoreuqiatueWr prebereasseursngore lox ieu lese cLuziooesnjoxe dsp ojeloidimpoxe sl soreloid op el Ne ota anioxa ps 104 REFER NCIAS ANEXOS B2 1 6 UCO6 Manter Empresa Buscar Empresas Osesaidiugjiessnq En seseidurgreceng BI seseidureceng 817 lt sesexdueosnq N 1 1 i 1 i i t 1 1 1 IS kosseursngeseJddurjieiuepr BIB JUOISSSSES SHU SHEN ep jass ungeso LUIS e ses khuq Jeosng ps REFER NCIAS ANEXOS 105 Alterar Empresa edad eje A ads ssaidlupoo esairdurgopscuenq een sad aduana IEEE 3 E 0s F schreier es dua Sd sadia eae La ER E vsaidua dos 1s aos sa
125. r sua vers o de produ o Nomeie todos os m todos de teste forma consistente O teste de m todo consiste em verificar se um nico m todo executado como definido Todos os m todos do teste devem ser nomeadas de acordo com o formato testMemberFunctionNameForTestName Por exemplo os m todos do equipamento de teste para experimentar withdrawFunds devem incluir testWith drawFundsForInsufficientFunds e testWithdrawFundsForSmallWithdrawal Se voc tem uma s rie de testes para withdrawFunds pode preferir criar um m todo denominado testWithdraw Funds que dispare todos eles Crie um nico ponto para disparar os testes de uma classe Desenvolva um m todo est tico denominado testSelf que dispare todas os m todos da classe Documente os m todos do equipamento de teste Documente os m todos do equipa mento de teste A documenta o deve incluir uma descri o do teste assim como os resultados que se espera obter com ele REFER NCIAS ANEXOS 145 B4 1 9 Refer ncias AMB98 Ambler S W 1998 Building Object Applications That Work Your Step By Step Handbook for Developing Robust Systems with Object Technology Nova York SIGS Books Cambridge University Press DES97 DeSoto A 1997 Using the Beans Development Kit 1 0 February 1997 A Tutorial Sun Microsystems GOS96 Gosling J Joy B Steele G 1996 The Java Language Specifica tion Reading MA Addison Wesley Longman Inc KAN97 Kanerva
126. ra as tarefas UCO3 Usuario Usuario do projeto Verifica junto ao cliente as suas necessidades UC11 UCI2 e UC13 Identifica o dos requisitos do projeto UC11 UC12 e UCI3 Prop em solu es aos requisitos levantados UCII UC12 e UC19 62 REFER NCIAS ANEXOS A1 3 Lista de Casos de Uso identificados UC UC01 Manter Funcion rio UC02 Vincular Permiss es UC03 Vincular Funcion rios UC04 Manter Tarefas UC05 Manter Projetos UC06 Manter Empresa UC07 Realizar Login UC08 Verificar Permiss es UC09 Gerar Log de Acesso UC10 Consultar Andamento do Projeto UC11 Manter Andamento da Tarefa UC12 Visualizar Tarefas UCI3 Visualizar Andamento de Tarefas UC14 Exibir dados dos projetos em andamento A1 4 Requisitos Funcionais RF RFI Controlar Projetos RF2 Controlar Tarefas RF3 Calcular porcentagens de andamento dos projetos RF4 Registrar Logs de Tarefas RF5 Registrar Logs de Acesso RF6 Controlar Acessos RF7 Calcular porcentagens de andamento das tarefas RES Controlar Funcion rios RF9 Controlar Clientes A1 5 Requisitos N o Funcionais RNF Disponibilidade REFER NCIAS ANEXOS 63 As funcionalidades n o devem afetar as opera es do servidor de aplica es e deve estar dispon vel por 24 horas durante os 7 dias da semana Seguran a Os usu rios do sistema devem acessar apenas as funciona
127. radas Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como administrador ou gerente de projetos Condi es Posteriores Ap s a execu o do caso de uso gerar log da opera o executando caso de uso UCO9 Gerar Log de Acesso REFER NCIAS ANEXOS 75 A2 4 6 UC06 Manter Empresa Breve Descri o Este caso de uso tem como finalidade cadastrar alterar ou excluir empresas no sistema proposto Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o administrador vai cadastrar alterar ou excluir uma empresa do sistema Cadastrar Empresa O administrador dever informar os seguintes dados em um formul rio 1 Nome da empresa 9 Complemento do endere o 2 E mail 10 Bairro 3 Descri o 11 Cidade 4 Site 12 Estado 5 Respons vel 13 Pais 6 CNPJ 14 CEP 7 Rua 15 DDD telefone 8 N mero da empresa 16 N mero do telefone Campos obrigat rios Depois disso dever clicar no bot o Incluir Alterar Empresa O administrador dever selecionar a empresa que deseja alterar Automaticamente os da dos daquela empresa ser o carregados na tela O administrador alterar os dados necess rios e clicar no bot o Alterar 76 REFER NCIAS ANEXOS Excluir Empresa O administrador dever selecionar a empresa que deseja excluir e clicar no bot o Excluir para que os dados daquela empresa selecionada p
128. regar todas as permiss es com nenhu ma selecionada caso seja de um funcion rio que seus dados foram alterados dever car regar todas as permiss es mas aquelas que j fora ativadas no primeiro cadastro devem estar selecionadas OBS As permiss es de acesso encontram se cadastradas na tabela PERMISS O As permiss es s o listadas a seguir incluir alterar excluir projetos incluir alterar excluir empresas incluir alterar excluir tarefas incluir alterar desativar funcion rios consultar andamento dos projetos acessar o sistema visualizar tarefas incluir alterar excluir andamento de tarefas Fluxos alternativos Nenhum Condic es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como administrador Condi es Posteriores Ap s a execuc o do caso de uso gerar log da operag o executando caso de uso UCO9 Gerar Log de Acesso 70 REFER NCIAS ANEXOS A2 4 3 UCO3 Vincular Funcion rios Breve Descri o Este caso de uso tem como finalidade vincular os funcion rios s tarefas cadastradas Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o administrador ou gerente de projetos ao cadastrar ou alterar uma tarefa ter que vincular os funcion rios que participar o da mesma O admi nistrador ou gerente de projetos selecionar ou alterar os funcion rios e depois clicar em Gravar Altera es Este caso de uso carregar uma te
129. res entendam os pontos fracos e as difi culdades relacionados a essa classe Al m disso o motivo para n o corrigir o erro tamb m precisa ser documentado O hist rico de desenvolvimento ou manuten o da classe bastante comum a in clus o de uma tabela de hist rico com datas autores e sum rios das mudan as efetua das em uma classe Dessa forma os programadores de manuten o t m id ia das mo difica es sofridas por uma classe al m de saber quem fez o qu na classe Interface A conven o Java nomear as interfaces com letras mai sculas e min sculas combina das sendo que a primeira letra de cada palavra deve ser mai scula A conven o Java mais a conselh vel para o nome de uma interface usar um adjetivo descritivo como Runnable ou Cloneable embora substantivos descritivos como Singleton ou DataInput tamb m sejam comuns As seguintes informa es devem ser exibidas nos coment rios de documenta o imedia tamente antes da defini o de uma interface Informar o objetivo Antes de outros desenvolvedores usarem uma interface eles precisam saber qual o conceito que ela encapsula Em outras palavras eles precisam saber qual o seu objetivo Um teste muito bom para saber se preciso definir uma in terface identificar o grau de facilidade ou dificuldade com que voc descreve sua fi nalidade Se voc tiver dificuldades para descrev la provavelmente nem precisa da interface Como o c
130. rio fornecer uma tradu o clara dos re quisitos equipe de desenvolvimento e tamb m do sistema assim como prover informa es para o planejamento do projeto tais como conte do t cnico para os ciclos de desenvolvimento al m de subs dios para estimativas de prazo e custo Segundo Pressman 1995 p 266 a fun o e o desempenho atribu dos ao software s o re finados quando se estabelece uma descri o completa da informa o indica o dos requisitos de desempenho e restri es de projeto Os requisitos podem ser funcionais aqueles capturados atrav s dos casos de uso que do cumentam as entradas as sa das e os processos assim como n o funcionais que s o compostos por caracter sticas n o associadas ao comportamento esperado do sistema como usabilidade confiabilidade desempenho e suporte Neste processo as pessoas envolvidas v o desempenhar os seguintes pap is Analista de sistemas o profissional que comanda o processo Especificador de Casos de Uso o profissional que detalha as funcionalidades do sis tema atrav s dos casos de uso Projetista de Interface de Usu rio o profissional que vai desenvolver os prot tipos das interfaces com o usu rio Os artefatos desenvolvidos e atualizados neste processo s o os que definem os requisitos e o escopo do sistema Artefatos trabalhados pelo Analista de Sistemas Plano de gerenciamento de requisitos Gloss rio de termos do neg cio e do
131. s as necessidades de informa es e comunica es dos stakeholders Distribui o das informa es onde as informa es necess rias s o colocadas dispo si o dos stakeholders Relat rio de desempenho que consiste na coleta e distribui o das informa es sobre o desempenho incluindo o relat rio de andamento e medi o do progresso e previs o Gerenciar as partes interessadas onde gerenciam se as comunica es para satisfazer os stakeholders e resolver seus problemas J o Gerenciamento de Riscos do Projeto segundo o PMBOK 2004 determina os pro cessos que tratam da realiza o de identifica o an lise repostas monitoramento controle e planejamento do gerenciamento de riscos em um projeto e na maioria das vezes esses processos sofrem atualiza es durante todo seu ciclo de vida 22 GERENCIAMENTO DE PROJETOS Como principal objetivo o gerenciamento de riscos do projeto procura aumentar a proba bilidade de eventos positivos e diminuir os negativos Os principais processos que correspondem ao Gerenciamento de Risco do Projeto s o PMBOK 2004 Planejamento do gerenciamento de risco onde existe a decis o de como dever ser abordada planejada e executada as atividades de gerenciamento de riscos de um proje to Identifica o de riscos onde tenta se identificar os riscos que podem afetar o projeto e documentar suas caracter sticas An lise qualitativa de riscos onde coloca s
132. s desenvolvedores ou at mesmo voc n o le r o o c digo corretamente enquanto ele estiver sendo modificado tornando mais dif cil a detec o de erros Uso de m todos de acesso Al m das conven es de nomea o a manutenibilidade dos campos obtida pelo uso a dequado de m todos de acesso ou seja m todos que oferecem a funcionalidade necess ria para atualizar um campo ou acessar seu valor Os m todos de acesso podem ser de dois tipos setters tamb m conhecidos como mutantes e getters O setter modifica o valor de uma vari vel en quanto o getter a obt m Nomea o de m todos de acesso Os nomes dos m todos getter devem incluir get nome do campo Se o campo repre sentar um valor boolean verdadeiro ou falso o nome do getter poder ser is nome do cam po Os nomes dos m todos setter devem ser set nome do campo seja qual for o tipo de cam po O nome de campo sempre uma combina o de letras mai sculas e min sculas com letra mai scula no in cio de todas as palavras Exemplo Campo Tipo Nome do getter Nome do setter nomeProjeto String getNomeProjeto setNomeProjeto 138 REFER NCIAS ANEXOS tarPrecedente Integer getTarPrecedente setTarPrecedente cpf Integer getCpf setCpf endereco Objeto getEndeteco setEndeteco permissoes Collection getPermissoes setPermissoes Visibilidade de m todos de
133. s outras Ter bom senso obrigat rio 124 REFER NCIAS ANEXOS B4 1 2 Padr es de Codifica o Os padr es de codifica o para Java s o importantes porque garantem maior consist ncia de seu c digo e do c digo de seus companheiros de equipe Maior consist ncia gera c digos mais f ceis de serem entendidos desenvolvidos e mantidos Dessa forma voc reduz o custo total dos apli cativos criados Lembre se de que seu c digo Java continuar a existir por muito tempo ainda mesmo depois de voc estar envolvido em outros projetos Uma meta importante durante o desenvolvi mento garantir que voc possa passar seu trabalho para outro desenvolvedor ou outra equipe de desenvolvedores a fim de que eles possam continuar a manter e melhorar seu trabalho sem pre cisarem investir um esfor o desnecess rio para entender o c digo que voc criou C digos de di f cil compreens o correm o risco de serem descartados e reescritos Conven es de nomea o As conven es de nomea o ser o abordadas junto com os padr es Portanto vamos de finir alguns fundamentos Use descritores completos que descrevam com exatid o o atributo e a classe Por exemplo use nomes como primeiroName totalProjetos ou qtdeClientes Embora nomes como x1 yl ou fn sejam f ceis de digitar por serem pequenos eles n o forne cem qualquer indica o do que representam dificultando a compreens o a manuten o e a melhoria do c digo
134. s outros programadores devem conseguir entender o que a fun o de membro executa bem como o motivo e a maneira dessa execu o em menos de 30 segundos Se isso n o for poss vel sinal de que o c digo muito di f cil de manter e deve ser melhorado Trinta segundos nada mais A pr tica demonstra que se uma fun o de membro ocupa mais de uma tela provavelmente ela muito grande Criar linhas de comandos simples e curtas O c digo deve ter uma execu o por li nha Na poca das placas de inser o fazia sentido tentar o m ximo de funcionalidade em uma nica linha de c digo Sempre que voc tentar mais de uma execu o em uma nica linha de c digo estar dificultando o entendimento Por que fazer isso Quere mos facilitar a compreens o do c digo para tamb m facilitar sua manuten o e melho ria Assim como uma fun o de membro deve desempenhar apenas uma a o voc tamb m deve incluir apenas uma a o em uma nica linha de c digo Al m disso vo c deve escrever c digos que possam ser visualizados na tela VIS96 Voc n o deve precisar rolar a janela de edi o para a direita a fim de ler toda a linha de c digo in clusive do c digo que usa coment rios in line Especificar a ordem das opera es Uma maneira realmente f cil de aumentar a le gibilidade do c digo usar par nteses para especificar a ordem exata das opera es no c digo Java NAG95 e AMB98 Se voc precisa saber a ordem
135. sObject SessonFacade Action Bean BusnessDelegate BusnessObject DAO Form SessonFacade mem ug Action Action LI constantes Bean Bean BusinessDelegate BusinessDelegate BusnessObject BusinessObject DAO DAO Fom Fom SessonFacade SessonFacade 90 REFER NCIAS ANEXOS B2 Modelo de design B2 1 Diagrama de seq ncia B2 1 1 UCO1 Manter Funcion rio Buscar Funcion rios LI i lro x soueuopun yessng EN OsoueuopunJreoenq srq soueuobungessng ET soueuomunJreosng Br1 IS SOHVNOIONnH dos 1S ERE doelaosseursngoueuorunJiepepr epeoeuorssesoueuorund9uelw EPonsvsoueuorounaesng seueuotouna aeosng ps REFER NCIAS ANEXOS 91 ionario Alterar Func Qsoxdaqiessng SEIT ATORWNODNN dos 1s S GE dos is OVA PRA doi Weupurdsopaqiesna uo pung CA 92 REFER NCIAS ANEXOS ionario Cadastrar Func Gsoidegjessnq BIT 1 Gueuoiungjoueuopunguersepes T usuoonaousuopunamisepas Toko SEN
136. scolher ou n o vincular um ou mais funcion rios tarefa ca dastrada executando o caso de uso UCO3 Vincular Funcion rios Alterar Tarefas O administrador ou gerente de projetos dever selecionar a tarefa que deseja alterar Au tomaticamente os dados daquela tarefa ser o carregados na tela O administrador alterar os dados necess rios e clicar no bot o Alterar Depois que os dados da tarefa forem alte rados o administrador ou gerente do projeto poder alterar tamb m os funcion rios vin culados esta tarefa executando o caso de uso UC03 Vincular Funcion rios 72 REFER NCIAS ANEXOS Excluir Tarefas O administrador ou gerente de projetos dever selecionar a tarefa que deseja excluir e cli car no bot o Excluir para que os dados daquela tarefa selecionada possam ser exclu dos do sistema Para que a exclus o seja efetuada necess rio que n o tenha nenhum log de andamento de tarefa cadastrado da tarefa selecionada ou nenhum funcion rio vinculado tarefa Fluxos alternativos Tarefa j cadastrada Este fluxo ocorre quando existe no banco de dados uma tarefa j cadastrada com o mes mo nome da tarefa que se deseja cadastrar Emitir mensagem Esta tarefa j est cadastrada Dados Incompletos Este fluxo ocorre quando algum campo obrigat rio n o foi preenchido no formul rio Emitir mensagem dos dados que est o faltando e colocar o foco no primeiro campo incor reto Tarefa N o
137. se 38 4 2 Organiza o dos Modelos eerie eee sezone essen Sans Sas senten ses sosta aqa asa sesso a nes esine 39 A eS DE E A ER 40 4 4 Fluxos de Atividades eerie tete ne sene kaa as se teme E aE Na ua q eee mee ecoa vese ESSES 41 441 Modelagem do N SOCIOr ane ana annuum rre 42 4 4 2 REGUISILOS sortir 43 4 4 3 An lise e Destinada 44 44 4 Implementa o Shtun n de gege 45 AMI TESE est e q awa og 46 4 4 6 NN 46 4 4 7 Gerenciamento de Configura o de Mudan a seen eene eene 47 4 4 8 Gerenciamento de Projeto eee en re ente vere vr ever aeee area area aaa ee tren rrenen rene 48 4 49 Ambiente u s u ud ve e e dre oe und e 48 GAP V PROJETO H 49 LANERO Aic m R 49 BL Documento de V1830 2 a uu huu tete etri aa eo bp dehet este ee veo eter d r 49 EISE GETRETEN 49 5 2 Fase Elabora o M 50 2 1 NN 50 5 2 2 Arquitetura de Software ooren ieo sves enin r ESE teen nono rene enne eren e tren 52 5 2 3 Modelo de Design ei ette ere lances en osea HT 92 9 2 4 Modelo d DAdoS iii cil lis 54 5 2 5 Guia de Programac o JAVA socesonnsires n event NEEN sens doz ras obere edet te erepto r selo r r grev ver n re d si 54 EE ISI idilcimMe C 54 mWMIIMUCHUCIUIMC
138. senvolvedores para se criar um padr o de codifica o para que qual quer desenvolvedor possa continuar um trabalho outrem sem problemas de adapta o Este guia um manual de boas pr ticas baseados em padr es e experi ncias de desenvol vimento de profissionais da rea O documento auxilia qualquer desenvolvedor a padronizar no mes de atributos m todos m todos de acesso passagem de par metros dos m todos constantes classes interfaces vari veis locais Auxilia tamb m em como estruturar o c digo fonte do siste ma para o tratamento de exce es e de importa o na utiliza o de pacotes pr prios da lingua gem ou dos pacotes criados no sistema um manual de orienta o b sica que foi seguido a fundo na fase de constru o com ob jetivo de ganhar produtividade no desenvolvimento do sistema 5 3 Fase Constru o O objetivo desta fase codificar os requisitos para que estes se tornem um programa A fase de constru o concentrou se em gerar o sistema que at ent o estava sendo analisado e projetado Inicialmente esta fase constitui se basicamente da montagem do ambiente e codifica o dos Casos de usos Para que nesta fase n o fosse encontrados muitos problemas optou se em cri ar um plano de desenvolvimento de software no qual a partir das fases anteriores foi determi nada a seq ncia cronol gica das atividades Neste plano de desenvolvimento a constru o do sistema seguiu a seguinte ordem PROJ
139. sistema Vis o do software Especifica es suplementares Modelo de Casos de Uso Artefatos trabalhados pelo Especificador de Casos de Uso Casos de Uso Pacote de Casos de Uso Especifica es dos requisitos do software 44 RUP RATIONAL UNIFIED PROCESS Artefatos trabalhados pelo Projetista de Interface com o Usu rio Ator Classes de fronteira Roteiro dos Casos de Uso Prot tipo da Interface com o Usu rio 4 4 3 An lise e Design O objetivo deste processo traduzir os requisitos numa especifica o que explica como o siste ma deve ser desenvolvido por exemplo caracter sticas como a arquitetura o ambiente operacio nal e a escalabilidade Este processo aborda tanto a an lise quanto o design do sistema Segundo Kruchten 2004 p 146 o modelo de an lise omite a maioria dos detalhes do sistema e fornece uma avalia o de suas funcionalidades An lise esta especifica o faz abstra es evitando resolver problemas que ser o re solvidos no processo de design e visualiza apenas as entidades associadas ao neg cio Esta separa o permite uma melhor elabora o de especifica es j que n o considera as limita es t cnicas associadas tecnologia Design esta especifica o foca na produ o de uma vis o detalhada do sistema con siderando a tecnologia a ser usada no desenvolvimento isto significa a linguagem de programa o o sistema gerenciador de banco d
140. t architecture was the Java Enterprise Edition JEE because it suits the project needs work with object orientation and build an web interface Keywords RUP Project management UML JEE Development methodology Object orientation SUM RIO CAP I INTRODUCAO U U u Pa Po IN aS Ea poU 14 IBMAD COOLER OM UDUoP 14 1 2 OUI E C U IQ 14 1 3 Procedimentos metodol gicos 15 1 4 Organiza o do Trabalho 4 a a sasa saa ense tnn ta sns sans ee tastes tosta sse ta sons seas eeemestecesesecesese 15 CAP Il GERENCIAMENTO DE PROJETOS 16 KN PR PMBOK qot EE 17 2 2 Ferramentas de gerenciamento de projetos 24 2 3 Comparativo de sistemas de gerenciamento de projetos 25 CAP III UML UNIFIED MODELING LANGUAGE 27 3 1 Caracter sticas P dose 27 A HRS 28 3 3 Principais Diagramas nana eee ece ce neo u eese eese nese eese eese sene te nete eme emen enes eme sene sado nese sesoses adsense sete ve mee mese s
141. ta SE mamm Espen Geen dodo adi M EH psaiducpiooeoesage ES jopeislutupy seua say ps 106 REFER NCIAS ANEXOS Cadastrar Empresa Gss ons LOD epensepeo esaidur uueDesuey E enn OHLSVAVO ON OtiH3 He gt M ZS EEE gege gt OD asi El ajnoaxa eseidur3 esaidurgeusepeo D H esaidwa esaiduguersepeo Ta esaidugjeseidugjesisepeo r t I es xduig es iduigieusepeo i i i 1 i Jeipepeo I i I i i 1 i i 1opeiglulupy eseadurpooAsepeo Y VvSa3HdW3 dos 1S esalduu la Jue DS EES CB juoissaseseudureluejy jeqsseursngeseudurgejuepyr CES Hensepes esf E eseudus Jensepeo ps REFER NCIAS ANEXOS 107 Excluir Empresa 1 Esaduspoo sadusinpre eseudurgpoo eseiduisuin pxe O T esaduapo ssidusinpro mens LUCO epezileei QESH WBU Teme a as A Sope noun sop aid uie ess od epeuo po es esexiuie E 1Inpxe PASOd 9 CEN 2uefeauea eseidurgpoojesaxiuguinpxe i ja vssudwa dos 1S Dvaesexiuzueuepy
142. tar Andamento do Projeto Breve Descri o Este caso de uso tem como finalidade fornecer informa es referente aos projetos cadas trados no sistema Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o gerente do projeto quer obter informa es dos seus projetos O sistema mostrar uma lista contendo o nome descri o e progresso de andamento dos projetos do gerente respons vel Ap s isso o gerente ter a possibilidade de visualizar mais informa es como data de in cio data de termino prioridade cliente e status atual do projeto clicando em Detalhes Fluxos alternativos Projeto N o Selecionado Este fluxo ocorre quando n o foi selecionado nenhum projeto para as op es de detalhes Emitir mensagem Selecione um projeto Condi es Pr vias Estar logado no sistema O usu rio dever estar logado no sistema como gerente de projetos Condi es Posteriores Nenhuma REFER NCIAS ANEXOS 81 A2 4 11 UC11 Manter Andamento da Tarefa Breve Descri o Este caso de uso tem como finalidade cadastrar alterar ou excluir andamentos das tarefas Fluxo de Eventos Fluxo B sico Este caso de uso se inicia quando o usu rio vai cadastrar alterar ou excluir um andamento de uma determinada tarefa Cadastrar Andamento da Tarefa O usu rio dever selecionar a tarefa que est participando e informar os seguintes dados no formul rio 1 Horas trabalhadas 3 Descri
143. tar o c digo n o valer a pena mant lo NAG95 Se voc aplicar corretamente os padr es e as di retrizes de documenta o propostos neste documento obter c digos de melhor quali dade Criar par grafos ou recuos no c digo Uma maneira de melhorar a legibilidade de uma fun o de membro criar par grafos ou recuos no c digo dentro do escopo de um bloco de c digo Qualquer c digo contido entre chaves os caracteres e com p e um bloco A id ia b sica que o c digo contido em um bloco seja uma unidade uniformemente recuada A conven o Java sugere que a chave de abertura seja colo cada na linha seguinte ao propriet rio do bloco e que a chave de fechamento seja recu ada em um n vel O importante segundo LAF97 que a sua organiza o escolha um estilo de recuo e se atenha a ele Use o mesmo estilo de recuo que o ambiente de desenvolvimento Java usa para o c digo que ele gera Usar espa o em branco Algumas linhas vazias denominadas espa o em branco a dicionadas ao c digo Java podem aumentar a sua legibilidade dividindo o em peque nas se es de f cil assimila o VIS96 Sugere o uso de uma nica linha vazia para separar grupos l gicos do c digo como estruturas de controle com duas linhas vazi REFER NCIAS ANEXOS 135 as para separar as defini es de fun o de membro Sem o espa o em branco a leitura e a compreens o ficam mais dif ceis Seguir a regra dos 30 segundos O
144. tema possui interface com usu rio Desta forma teremos uma camada de apresenta o camadas de negocio transa o e persist ncia A hierarquia de pacotes segue a defini o abaixo B1 4 2 REFER NCIAS ANEXOS 87 Projeto dos Pacotes Nome net sgp empresa Descri o Pacote respons vel pelo cadastro de clientes empresas Nome net sgp colaborador Descri o Pacote respons vel pela cadastro do colaborador funcion rio Nome net sgp util Descri o Pacote para v rias utilidade como constantes Nome net sgp tarefa Descri o Pacote respons vel pelo cadastro de tarefas e andamento das tarefas Nome net sgp projeto Descri o Pacote respons vel pelo cadastro de projetos Nome net sgp permissao Descri o Pacote respons vel pelas permiss es dos usu rios Nome net sgp log Descri o Pacote respons vel pela gera o de logs 88 REFER NCIAS ANEXOS B1 5 Vis o de Implanta o dd Deployment Model y Servidor de Aplicac o Weblogic 8 x ou JBoss 4 x x Banco de Dados MySQL REFER NCIAS ANEXOS 89 B1 6 Vis o de Implementa o id Component Model E Action Bean BusnessDelegate BusinessObject DAO Form SessonFacade Action Bean BusnessDelegate BusnessObject DAO Form SessonFacade Action Bean DAO Form BusnessDelegate Busnes
145. tos colaterais inesperados de valores anteriores de uma vari vel local no in cio do c digo Com certeza a reutiliza o de vari veis locais mais eficiente pois necess rio alocar menos mem ria No entanto a reutiliza o de vari veis locais diminui a manutenibilidade do c digo e o fragiliza Geralmente n o vale a pena arriscar apenas por n o precisar alocar mais mem ria 140 REFER NCIAS ANEXOS B4 1 6 Padr es para classes Interface e Pacotes Uma classe um template a partir do qual objetos s o instanciados criados As classes cont m a declara o de campos atributos e m todos As interfaces s o a defini o de uma assinatura comum incluindo m todos e campos que uma classe que implementa uma interface deve supor tar Um pacote um conjunto de classes relacionadas Classes A conven o Java padr o usa um descritor ling stico completo com a primeira letra em mai scula e uma combina o de mai sculas e min sculas no resto do nome Os nomes tamb m precisam estar no singular As seguintes informa es devem ser exibidas nos coment rios de documenta o imedia tamente antes da defini o de uma classe A finalidade da classe Os desenvolvedores precisam saber qual o objetivo geral de uma classe para que possam determinar se ela atende s suas necessidades Erros conhecidos Se houver problemas pendentes com uma classe eles devem ser documentados para que outros desenvolvedo
146. tos de baixa complexidade Para e vitar que ocorram esses atrasos faz se necess rio a escolha de apenas alguns dos in meros do cumentos que podem ser gerados ao longo do ciclo de vida do projeto A implanta o do RUP de forma customizada pode ser feita atrav s dos estudos a seguir Concep o fase que tem como objetivo identificar o que ser constru do quais as funcionalidades que o sistema ter entre outras Nesta fase indica se a elabora o do documento de vis o e casos de usos Elabora o fase onde o projeto come a a sair da an lise Nesta fase indica se a elabo ra o do documento de arquitetura de software modelo de design modelo de dados guia de padr es de programa o da linguagem adotada e a cria o de um prot tipo na veg vel do sistema Constru o esta fase se encarrega da codifica o do sistema Pode n o ser gerado ne nhum documento mas importante definir um plano de desenvolvimento das funcio nalidades a serem implementadas ou seja tra ar um roteiro dos casos de uso que se r o codificados Transi o nesta fase o sistema proposto implantado Esta fase n o foi aplicada no trabalho em quest o mas como o sistema j est testado e pronto a gera o de docu mentos n o se faz necess rio O que pode ser interessante a cria o de um plano de treinamento dos usu rios mas isso fica a crit rio do cliente Como se pode ver o RUP uma metodologia muito forte na q
147. tru es no c digo que precisem ser execu tadas em uma ordem definida garanta que sejam documentadas AMB98 N o h na da pior do que efetuar uma simples modifica o em um trecho do c digo para depois perceber que ele n o funciona mais As horas investidas na procura do problema signi ficam que voc s conseguiu desordenar tudo Documente as chaves de fechamento Com frequ ncia voc ver que h estruturas de controle contidas em outras estruturas de controle que por sua vez tamb m est o contidas em estruturas de controle Embora voc deva evitar escrever c digos desse ti po pode haver situa es em que seja preciso faz lo O problema que fica confuso determinar a qual chave de finaliza o o caractere pertence a qual estrutura de con trole A boa not cia que alguns editores de c digo suportam um recurso que quando voc seleciona uma chave de abertura a chave de fechamento automaticamente des tacada A m not cia que nem todos os editores suportam esse recurso De acordo com a nossa experi ncia marcar as chaves de finaliza o com um coment rio in line como end if end for end switch facilita bastante a compreens o do c digo T cnicas para escrever c digos leg veis Esta se o aborda v rias t cnicas que ajudam a separar os desenvolvedores profissionais de outros tipos de codificadores As t cnicas s o Documentar o c digo Lembre se de que se n o valer a pena documen
148. uest o de controle sua a do o influencia muito do desenvolvimento de softwares A customiza o da metodologia entra CONCLUS O 57 como alternativa para qualquer tipo de projeto evitando que estes tenham problemas com prazos e custos 58 CONCLUS O Cap VII Refer ncias Anexos 7 1 Refer ncias Bibliogr ficas AMS Project Management Software Resource Management Software Time Recording Software from AMS Dispon vel em lt http www amsusa com gt Acesso em 27 fev 2007 CHONOLES Michael Jesse SCHARDT James A UML 2 for Dummies 1 ed Indianapolis Ed Wiley Publishing Inc 2003 DOTPROJECT Dotproject Open Source Software Open Source Project and Task Management Software Open Source Project and Task Management Software Dispon vel em lt http www dotproiect netz Acesso em 27 fev 2007 FORTES D bora Web 2 0 A nova cara do software Info Exame S o Paulo n 243 p 44 63 jun 2006 Mensal GANTTPROJECT GanttProject Dispon vel em lt http ganttproject sourceforge net gt Acesso em 27 fev 2007 GFORGE GForge CDE Dispon vel em lt http www gforge org gt Acesso em 27 fev 2007 HOUAISS Antonio Dicion rio Houaiss da L ngua Portuguesa 1 ed S o Paulo Objetiva IMENDIO Imendio Developer Pages Dispon vel em lt http developer imendio com gt Acesso em 27 fev 2007 JACOBSON Ivar BOOCH Grady RUMBAUGH James UML Guia do Usu rio 2 ed Rio de Jane
149. uso Segundo Jacobson Rumbaugh e Booch 2005 nenhum sistema existe isoladamente Todo sis tema interage com atores humanos ou aut matos que usam o sistema com algum objetivo Um diagrama de caso de uso identifica quais s o os comportamentos pretendidos no desenvolvimen to de um sistema Os casos de uso s o um dos diagramas da UML que possibilitam a modelagem dos aspec tos din micos de um sistema Atrav s deles os desenvolvedores podem compreender facilmente como o usu rio final interage diretamente com o sistema Em geral os diagramas de casos de uso costumam conter Assunto Casos de Uso Atores e Relacionamentos que podem ser de depend ncia generaliza o e associa o Comumente es se tipo de diagrama utilizado para a modelagem do contexto de um assunto e para a modela gem dos requisitos de um sistema 34 UML UNIFIED MODELING LANGUAGE Sistema de valida o de cart o de cr dito O Realizar transa o de cart o Cliente Sg Institui o Processar fatura de venda do cliente a varejo O O Reconciliar EN q transa es Cliente Cliente l individual jur dico Institui o Gerenciar financeira conta do cliente patrocinadora Figura 3 8 Exemplo de Diagrama de Casos de Uso Fonte Jacobson Rumbaugh e Booch 2005 p 246 Jacobson Rumbaugh e Booch 2005 p 250 sugerem que para um diagrama de caso de uso bem estruturado um diagrama que Tem como foco comunicar um
150. vidade onde se faz estimativa dos recursos que ser o ne cess rios para executar cada atividade do cronograma 20 GERENCIAMENTO DE PROJETOS Estimativa de dura o da atividade onde se estima o per odo necess rio para a conclu s o de cada atividade do cronograma Desenvolvimento do cronograma onde criado o cronograma do projeto Controle do cronograma onde feito um controle das altera es efetuadas no crono grama Conforme o PMBOK 2004 Gerenciamento de Custo do Projeto define os processos ne cess rios para certificar que o projeto ser conclu do dentro do or amento previsto que j foi a provado Os principais processos que correspondem ao Gerenciamento de Custo de Projeto s o PMBOK 2004 Estimativa de custos onde se desenvolve uma estimativa dos custos dos recursos que ser o necess rios para terminar cada atividade do projeto Or amenta o onde h uma agrega o dos custos que foram estimados para estabele cer uma linha de base de custos Controle de custos onde faz se o controle das mudan as no or amento do projeto e dos fatores que criam as varia es de custos O Gerenciamento de Tempo do Projeto e o Gerenciamento de Custo do Projeto s o as reas de conhecimento de maior import ncia dentro do contexto do gerenciamento de um projeto pois s o as mais vis veis durante a sua gest o O Gerenciamento de Qualidade de Projetos definido pelo PMBOK 2004 como sendo
151. visualiza o dos as pectos est ticos do sistema mais especificamente de blocos de constru o e seus relacionamen tos e a especifica o dos detalhes de constru o Jacobson Rumbaugh e Booch 2005 Empresa Escrit rio endere o Sequ ncia de caracteres telefone N mero MM Escrit rioCentral e gerente membro 1 1 membro dos sub Pessoa nome Nome c digoDoFuncion rio Inteiro t tulo Sequ ncia de caracteres _ opera es obterFoto Foto obterTelefone N mero obterinforma esDeConiato r obterRegistrosPessoais endere o Seq ncia de caracteres c digoDelmposto hist ricoDeEmprego sal rio linforma aoSegura Figura 3 1 Exemplo de Diagrama de Classes Fonte Jacobson Rumbaugh e Booch 2005 p 108 Segundo Jacobson Rumbaugh e Booch 2005 p 109 a utiliza o do diagrama de clas ses est classificada em tr s formas 30 UML UNIFIED MODELING LANGUAGE Para fazer a modelagem do vocabul rio de um sistema Para fazer a modelagem de colabora es simples Para fazer a modelagem do esquema l gico de um banco de dados 3 3 2 Diagrama de componentes Jacobson Rumbaugh e Booch 2005 p 97 definem um diagrama de componentes o diagrama que mostra as partes internas os conectores e as portas que implementam um componente Um componente um programa ou objeto reutiliz vel que

UNIVERSIDADE PRESBITERIANA MACKENZIE

Contents

Download Pdf Manuals

Related Search

Related Contents