{"id":28,"date":"2013-03-30T16:27:57","date_gmt":"2013-03-30T19:27:57","guid":{"rendered":"http:\/\/gois.inf.br\/wordp\/?p=28"},"modified":"2020-05-14T20:56:59","modified_gmt":"2020-05-14T23:56:59","slug":"analise-e-projeto-de-sistemas-orientados-a-objetos","status":"publish","type":"post","link":"http:\/\/gois.inf.br\/wordp\/?p=28","title":{"rendered":"An\u00e1lise e Projeto de Sistemas Orientados a Objetos"},"content":{"rendered":"<p>No ano de 2006 elaborei meu trabalho de conclus\u00e3o de curso sobre este t\u00f3pico de An\u00e1lise e Projeto de Sistemas Orientado a Objetos, pode ser acessado <a title=\"TCC Tadeu\" href=\"http:\/\/www.pergamum.udesc.br\/dados-bu\/000000\/000000000005\/00000531.pdf\" target=\"_blank\">aqui<\/a>\u00a0( a partir do cap\u00edtulo 5 \u00e9 que se inicia a parte de engenharia de software)\u00a0. \u00c9 um assunto pouco comentado, e at\u00e9 mesmo um pouco pol\u00eamico, pois \u00e9 muitas vezes confundido com uma parte de documenta\u00e7\u00e3o chata no desenvolvimento de software.<\/p>\n<p>Mas muito pelo contr\u00e1rio, \u00e9 uma fase fundamental para o sucesso na entrega do software. Pois \u00e9 neste momentos que como j\u00e1 diz no t\u00edtulo, analisamos e projetamos o futuro software, tentamos mapear o m\u00e1ximo poss\u00edvel das possibilidades nas regras \u00e9 onde o usu\u00e1rio j\u00e1 tem uma ideia da carinha do sistema e tamb\u00e9m tudo que ele vai abranger nesta primeira entrega do software, ou seja, a important\u00edssima defini\u00e7\u00e3o do escopo do projeto.<\/p>\n<p>Neste ano de 2006, pesquisei bastante, li v\u00e1rios livros para ter um bom embasamento te\u00f3rico na escrita do TCC e consequentemente aprendi v\u00e1rias t\u00e9cnicas para a an\u00e1lise e a elabora\u00e7\u00e3o de um bom projeto de software. \u00c9 muito melhor pensar antes de executar, dominar um pouco, n\u00e3o tudo da linguagem UML tamb\u00e9m \u00e9 fundamental para documentar esta fase de estudo, an\u00e1lise, reuni\u00f5es, prototipagem e entendimento do neg\u00f3cio e suas regras que o futuro software ir\u00e1 atender.<\/p>\n<p>A metodologia RUP (Rational Unified Process), tamb\u00e9m chamado de UP (Unified\u00a0Process), Processo Unificado, que est\u00e1 fortemente associado \u00e0 nota\u00e7\u00e3o UML, \u00e9 um processo de engenharia\u00a0de software que oferece uma abordagem baseada em disciplinas para atribuir\u00a0tarefas e responsabilidades dentro de uma organiza\u00e7\u00e3o de desenvolvimento.\u00a0Sua meta \u00e9 garantir a produ\u00e7\u00e3o de software de alta qualidade que\u00a0atenda \u00e0s necessidades dos usu\u00e1rios dentro de um cronograma e de um or\u00e7amento\u00a0previs\u00edvel. A figura 1 exibi uma vis\u00e3o geral dos processos envolvido\u00a0no RUP.<\/p>\n<div id=\"attachment_29\" style=\"width: 310px\" class=\"wp-caption aligncenter\"><a href=\"http:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/rup.jpg\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-29\" class=\"size-medium wp-image-29 \" alt=\"Figura 1 \u2013 RUP, vis\u00e3o geral (RUP, 2003)\" src=\"http:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/rup-300x195.jpg\" width=\"300\" height=\"195\" srcset=\"https:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/rup-300x195.jpg 300w, https:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/rup.jpg 538w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><p id=\"caption-attachment-29\" class=\"wp-caption-text\">Figura 1 \u2013 RUP, vis\u00e3o geral\u00a0(RUP, 2003).<\/p><\/div>\n<p>O RUP comporta, em suas recomenda\u00e7\u00f5es, as antigas fases de\u00a0estudo de viabilidade, an\u00e1lise de requisitos, an\u00e1lise de dom\u00ednio, e o projeto em\u00a0m\u00faltiplas camadas (WAZLAWICK, 2004).<\/p>\n<p>O ciclo de vida de software do RUP \u00e9 dividido em quatro fases\u00a0sequenciais (Figura 2), cada uma conclu\u00edda por um marco principal, ou seja,\u00a0cada fase \u00e9 basicamente um intervalo de tempo entre dois marcos principais.<\/p>\n<div id=\"attachment_30\" style=\"width: 310px\" class=\"wp-caption aligncenter\"><a href=\"http:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/RUP.png\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-30\" class=\"size-medium wp-image-30\" alt=\"Figura 2 \u2013 As fases e os marcos de um projeto RUP (RUP, 2003)\" src=\"http:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/RUP-300x115.png\" width=\"300\" height=\"115\" srcset=\"https:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/RUP-300x115.png 300w, https:\/\/gois.inf.br\/wordp\/wp-content\/uploads\/2013\/03\/RUP.png 406w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><p id=\"caption-attachment-30\" class=\"wp-caption-text\">Figura 2 \u2013 As fases e os marcos de um projeto RUP (RUP, 2003)<\/p><\/div>\n<p>&nbsp;<\/p>\n<p>WAZLAWICK, 2004 defini da seguinte forma as seguintes etapas.<\/p>\n<p>&#8211; A fase de<strong> inicia\u00e7\u00e3o ou concep\u00e7\u00e3o<\/strong> incorpora o estudo de viabili\u00addade e uma parte da an\u00e1lise de requisitos.<\/p>\n<p>&#8211; A fase de <strong>elabora\u00e7\u00e3o<\/strong> incorpora a maior parte da an\u00e1lise de requisitos, a an\u00e1lise de dom\u00ednio e projeto.<\/p>\n<p>&#8211; A fase de <strong>constru\u00e7\u00e3o<\/strong> corresponde \u00e0 programa\u00e7\u00e3o e testes,<\/p>\n<p>&#8211; e a fase de <strong>transi\u00e7\u00e3o<\/strong> consiste na instala\u00e7\u00e3o e manuten\u00e7\u00e3o do sistema<\/p>\n<p>A seguir defino melhor cada etapa do processo:<\/p>\n<p><strong>Fase de Inicia\u00e7\u00e3o ou Concep\u00e7\u00e3o<\/strong><\/p>\n<p>A fase de concep\u00e7\u00e3o, (<i>inception)<\/i>, deve ser a primeira do pro\u00adcesso de desenvolvimento de <i>software<\/i>, na qual se procura levantar os princi\u00adpais requisitos e compreender o sistema de forma abrangente (WAZLAWICK, 2004).<\/p>\n<p>Esta fase inicial indica o nascimento da id\u00e9ia sobre um novo <i>software<\/i>. Pode consistir da discuss\u00e3o sobre um problema que ocorre na em\u00adpresa ou nos clientes e que eventualmente poderia ser resolvido ou minimizado com o desenvolvimento de um sistema informatizado (QUADROS, 2002).<\/p>\n<p>Nesta etapa, n\u00e3o \u00e9 realizado nenhum tipo de estudo aprofun\u00addado sobre o sistema, no entanto, podem ser feitas algumas proje\u00e7\u00f5es grossei\u00adras que permitam inferir, ainda que com pouca precis\u00e3o QUADROS (2002): Quanto tempo o <i>software<\/i> levaria para ser desenvolvido? Quanto o <i>software<\/i> custaria para ser desenvolvido? Quais benef\u00edcios o projeto traria para a em\u00adpresa ou para o cliente?<\/p>\n<p>Segundo <a href=\"http:\/\/www.wthreex.com\/rup\/\">RUP (2003<\/a>) \u00a0os principais objetivos da fase de concep\u00e7\u00e3o incluem:<\/p>\n<p>a)\u00a0\u00a0\u00a0 <strong>Estabelecer o escopo do software do projeto e as condi\u00e7\u00f5es limite<\/strong>, incluindo uma vis\u00e3o operacional, crit\u00e9rios de aceita\u00e7\u00e3o e o que deve ou n\u00e3o estar no produto.<\/p>\n<p>b)\u00a0\u00a0\u00a0<strong> Discriminar os casos de uso cr\u00edticos do sistema, os principais cen\u00e1rios de opera\u00e7\u00e3o<\/strong> e o que direcionar\u00e1 as principais trocas de design.<\/p>\n<p>c)\u00a0\u00a0\u00a0 Exibir, e talvez demonstrar, pelo menos uma <strong>op\u00e7\u00e3o de arquitetura<\/strong> para alguns cen\u00e1rios b\u00e1sicos.<\/p>\n<p>d)\u00a0\u00a0\u00a0 <strong>Estimar o custo geral e a programa\u00e7\u00e3o para o projeto inteiro<\/strong> (e estimativas detalhadas para a fase de elabora\u00e7\u00e3o imediatamente a seguir).<\/p>\n<p>e)\u00a0\u00a0\u00a0 Estimar <strong>riscos em potencial<\/strong> (as origens de imprevistos).<\/p>\n<p>f) \u00a0Preparar o ambiente de suporte para o projeto.<\/p>\n<p>&nbsp;<\/p>\n<p>A fase de concep\u00e7\u00e3o \u00e9 onde se buscam as primeiras informa\u00e7\u00f5es sobre o sistema a ser desenvolvido e contem as seguintes atividades:<\/p>\n<ul>\n<li>Levantamento de requisitos<\/li>\n<li>Organiza\u00e7\u00e3o dos requisitos.<\/li>\n<\/ul>\n<p>A etapa de levantamento de requisitos corresponde a buscar junto ao usu\u00e1rio, seus sistemas e documentos, todas as informa\u00e7\u00f5es poss\u00edveis sobre as fun\u00e7\u00f5es que o sistema deve executar e as restri\u00e7\u00f5es sob as quais o sistema deve operar. O produto desta etapa ser\u00e1 o documento de requisitos, primeiro componente do anteprojeto de\u00a0<i>software\u00a0<\/i>(WAZLAWICK, 2004).<\/p>\n<p>A etapa de organiza\u00e7\u00e3o dos requisitos serve para estruturar os requisitos para que possam ser abordados nos ciclos de desenvolvimento. Grande parte dos requisitos ser\u00e1 acomodada em processos de neg\u00f3cio conhecidos como casos de uso. Outros requisitos poder\u00e3o ser associados a opera\u00e7\u00f5es simples (como cadastros), outros ainda ser\u00e3o meramente consultas. Os casos de uso, cadastros e consultas ser\u00e3o abordados nos diferentes ciclos, priorizando-se os elementos mais cr\u00edticos (normalmente casos de uso), e deixando-se para o final os mais elementares (cadastros e consultas) (WAZLAWICK, 2004).<\/p>\n<p>&nbsp;<\/p>\n<p>Esta etapa \u00e9 a de defini\u00e7\u00e3o do escopo do projeto. Ao final desta, tem-se o primeiro Marco (<i>milestone<\/i>), o <i>Lifecycle Objective Milestone<\/i>, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):<\/p>\n<ul>\n<li>Sum\u00e1rio Executivo ou Documento de<strong> Vis\u00e3o Geral do Sistema<\/strong>, incluindo requerimento, recursos principais e restri\u00e7\u00f5es.<\/li>\n<li>Gloss\u00e1rio do projeto, explicando os termos peculiares ao desenvolvimento do mesmo (opcional).<\/li>\n<li><strong>Caso de uso <\/strong>inicial (descrito utilizando a UML).<\/li>\n<li>Levantamento dos <strong>requisitos<\/strong>.<\/li>\n<li>Um ou mais <strong>prot\u00f3tipos<\/strong>.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Fase de Elabora\u00e7\u00e3o<\/strong><\/p>\n<p>No in\u00edcio da elabora\u00e7\u00e3o, o profissional tem uma vaga id\u00e9ia dos requisitos que o software dever\u00e1 atender. Nesta fase, o profissional dever\u00e1 investigar a fundo os obst\u00e1culos (riscos) que o projeto pode encontrar. Tais riscos como: Riscos de requisitos, riscos tecnol\u00f3gicos, riscos de habilidades, riscos pol\u00edticos (QUADROS, 2002).<\/p>\n<p>Al\u00e9m da an\u00e1lise dos riscos, a elabora\u00e7\u00e3o \u00e9 marcada pela defini\u00e7\u00e3o detalhada do escopo e dos requerimentos do software a ser desenvolvido. Esta defini\u00e7\u00e3o dos requerimentos deve ser formalizada por escrito atrav\u00e9s de um documento denominado Documento de Levantamento e Especifica\u00e7\u00e3o de Requerimentos de Usu\u00e1rio (DLERU). O DLERU deve ser submetido ao usu\u00e1rio\/cliente sempre que poss\u00edvel para que ele seja avaliado (QUADROS, 2002).<\/p>\n<p>A meta da fase de elabora\u00e7\u00e3o \u00e9 criar a <i>baseline <\/i>(a base de sustenta\u00e7\u00e3o) para a arquitetura do sistema a fim de fornecer uma base est\u00e1vel para o esfor\u00e7o da fase de constru\u00e7\u00e3o. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que t\u00eam grande impacto na arquitetura do sistema) e de uma avalia\u00e7\u00e3o de risco. A estabilidade da arquitetura \u00e9 avaliada atrav\u00e9s de um ou mais prot\u00f3tipos de arquitetura (<a href=\"http:\/\/www.wthreex.com\/rup\/\">RUP, 2003<\/a>).<\/p>\n<p>&nbsp;<\/p>\n<p>A fase de elabora\u00e7\u00e3o se inicia com uma sub-fase an\u00e1lise e prossegue com uma sub-fase de projeto. A sub-fase de an\u00e1lise em si comporta tr\u00eas atividades distintas realizadas na seguinte ordem (WAZLAWICK, 2004):<\/p>\n<ul>\n<li>Expans\u00e3o dos casos de uso e determina\u00e7\u00e3o dos eventos de sistema.<\/li>\n<li>Constru\u00e7\u00e3o do modelo conceitual.<\/li>\n<li>Elabora\u00e7\u00e3o dos contratos de opera\u00e7\u00f5es de sistema.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>A expans\u00e3o dos casos de uso corresponde ao aprofundamento da an\u00e1lise de requisitos. J\u00e1 a modelagem conceitual corresponde \u00e0 an\u00e1lise de dom\u00ednio em seus aspectos est\u00e1ticos. Por fim, a elabora\u00e7\u00e3o dos contratos corresponde \u00e0 especifica\u00e7\u00e3o funcional dos aspectos din\u00e2micos da an\u00e1lise de dom\u00ednio (WAZLAWICK, 2004).<\/p>\n<p>A subfase de projeto pode se dividir em diversas tarefas com objetivos distintos WAZLAWICK (2004). As tarefas ser\u00e3o:<\/p>\n<ul>\n<li>Projeto da camada de dom\u00ednio.<\/li>\n<li>Projeto da camada de interface.<\/li>\n<li>Projeto da camada de persist\u00eancia.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>O projeto da camada de dom\u00ednio comp\u00f5e-se basicamente de duas atividades: definir os diagramas de colabora\u00e7\u00e3o e elaborar o diagrama de classes de projeto (WAZLAWICK, 2004).<\/p>\n<p>O projeto da camada de interface mostra como manter a independ\u00eancia entre a camada de dom\u00ednio e a interface do <i>software<\/i>. O projeto da camada de persist\u00eancia mostra como implementar um sistema de persist\u00eancia que automatiza o salvamento e a recupera\u00e7\u00e3o de dados em disco (WAZLAWICK, 2004).<\/p>\n<p>&nbsp;<\/p>\n<p>O objetivo dessa etapa \u00e9 analisar o dom\u00ednio do problema, estabelecer uma funda\u00e7\u00e3o, desenvolver o plano de projeto e eliminar os elementos de maior risco do projeto. Ao final dela, tem-se o segundo Marco (<i>milestone<\/i>), o <i>Lifecycle<\/i> <i>Architecture<\/i> <i>Milestone<\/i>, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):<\/p>\n<ul>\n<li>Um <strong>caso de uso praticamente pronto<\/strong> com uma descri\u00e7\u00e3o completa dos atores e cen\u00e1rios de uso.<\/li>\n<li>Descri\u00e7\u00e3o das <strong>opera\u00e7\u00f5es e consultas<\/strong> de sistema.<\/li>\n<li><strong>Modelagem Conceitual<\/strong><\/li>\n<li>Os<strong> Contratos de opera\u00e7\u00f5es e consultas<\/strong> de sistema.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Fase de Constru\u00e7\u00e3o<\/strong><\/p>\n<p>A constru\u00e7\u00e3o \u00e9 a fase do processo cujo final \u00e9 marcado pela disponibiliza\u00e7\u00e3o do produto de <i>software<\/i> (um arquivo execut\u00e1vel ou uma p\u00e1gina Web, por exemplo) para os clientes ou usu\u00e1rios (QUADROS, 2002).<\/p>\n<p>Durante essa etapa, os profissionais estar\u00e3o primeiramente modelando o software utilizando alguma nota\u00e7\u00e3o, tais como a definida pela UML. Ap\u00f3s a modelagem, a fase de constru\u00e7\u00e3o \u00e9 marcada pela codifica\u00e7\u00e3o do software, onde os desenvolvedores estar\u00e3o fazendo uso de alguma ferramenta de programa\u00e7\u00e3o, bem como criando as estruturas de apoio, tais como o banco de dados com suas tabelas e outros elementos (QUADROS, 2002).<\/p>\n<p>A fase de constru\u00e7\u00e3o \u00e9 tamb\u00e9m composta pela homologa\u00e7\u00e3o que consiste na realiza\u00e7\u00e3o de testes de garantia de qualidade como o produto antes do envio para o cliente. A documenta\u00e7\u00e3o do produto encerra essa fase do processo de desenvolvimento, juntamente com a disponibiliza\u00e7\u00e3o de todo o conjunto do produto para o cliente (<i>software<\/i>, manuais de treinamento e refer\u00eancia). A vantagem desta abordagem est\u00e1 em se permitir definir <i>deadlines<\/i> (limites) intermedi\u00e1rios pra os v\u00e1rios subprojetos, impedindo que os problemas e os atrasos se evidenciem apenas no final do projeto (QUADROS, 2002).<\/p>\n<p>A meta da etapa de constru\u00e7\u00e3o \u00e9 esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da <i>baseline<\/i>. A fase de constru\u00e7\u00e3o \u00e9 de certa forma um processo de manufatura, em que a \u00eanfase est\u00e1 no gerenciamento de recursos e controle de opera\u00e7\u00f5es para otimizar custos, programa\u00e7\u00f5es e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transi\u00e7\u00e3o do desenvolvimento da propriedade intelectual durante a inicia\u00e7\u00e3o e elabora\u00e7\u00e3o, para o desenvolvimento dos produtos que podem ser implantados durante a constru\u00e7\u00e3o e transi\u00e7\u00e3o (<a href=\"http:\/\/www.wthreex.com\/rup\/\">RUP, 2003<\/a>).<\/p>\n<p>Ao final desta etapa, temos o terceiro Marco (<i>milestone<\/i>), o <i>Initial Operational Capability Milestone<\/i>, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):<\/p>\n<ul>\n<li>O produto (<i>software<\/i>) completamente operacional.<\/li>\n<li>Os manuais do produto.<\/li>\n<\/ul>\n<p>O marco Capacidade Operacional Inicial determina se o produto est\u00e1 pronto para ser implantado em um ambiente de teste beta (<a href=\"http:\/\/www.wthreex.com\/rup\/\">RUP, 2003<\/a>).<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Fase de Transi\u00e7\u00e3o<\/strong><\/p>\n<p>Nesta fase, o produto j\u00e1 foi entregue e s\u00e3o feitas as manuten\u00e7\u00f5es corretivas e as otimiza\u00e7\u00f5es de pequeno porte (que n\u00e3o envolvam uma completa reconstru\u00e7\u00e3o do software) (QUADROS, 2002).<\/p>\n<p>O foco da Fase de Transi\u00e7\u00e3o \u00e9 assegurar que o software esteja dispon\u00edvel para seus usu\u00e1rios finais. A Fase de Transi\u00e7\u00e3o pode atravessar v\u00e1rias itera\u00e7\u00f5es e inclui testar o produto em prepara\u00e7\u00e3o para <i>release<\/i> e ajustes pequenos com base no <i>feedback<\/i> do usu\u00e1rio. Nesse momento do ciclo de vida, o <i>feedback<\/i> do usu\u00e1rio deve priorizar o ajuste fino do produto, a configura\u00e7\u00e3o, a instala\u00e7\u00e3o e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto (<a href=\"http:\/\/www.wthreex.com\/rup\/\">RUP, 2003<\/a>).<\/p>\n<p>No fim do ciclo de vida da Fase de Transi\u00e7\u00e3o, os objetivos devem ter sido atendidos e o projeto deve estar em uma posi\u00e7\u00e3o para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o in\u00edcio de outro ciclo de vida no mesmo produto, conduzindo \u00e0 nova gera\u00e7\u00e3o ou vers\u00e3o do produto. Para outros projetos, o fim da Transi\u00e7\u00e3o pode coincidir com uma libera\u00e7\u00e3o total dos artefatos a terceiros que poder\u00e3o ser respons\u00e1veis pela opera\u00e7\u00e3o, manuten\u00e7\u00e3o e melhorias no sistema liberado (<a href=\"http:\/\/www.wthreex.com\/rup\/\">RUP, 2003<\/a>).<\/p>\n<p>A Fase de Transi\u00e7\u00e3o entra quando uma <i>baseline<\/i> estiver desenvolvida o suficiente para ser implantada no dom\u00ednio do usu\u00e1rio final. Isso normalmente requer que algum subconjunto us\u00e1vel do sistema tenha sido conclu\u00eddo com n\u00edvel de qualidade aceit\u00e1vel e documenta\u00e7\u00e3o do usu\u00e1rio, de modo que a transi\u00e7\u00e3o para o usu\u00e1rio forne\u00e7a resultados positivos para todas as partes (<a href=\"http:\/\/www.wthreex.com\/rup\/\">RUP, 2003<\/a>).<\/p>\n<p>Com base na an\u00e1lise feita neste Marco, a empresa poder\u00e1 decidir finalmente pela disponibiliza\u00e7\u00e3o do produto para os clientes. Ao final do projeto, deve ser feita tamb\u00e9m uma revis\u00e3o do cronograma f\u00edsico-financeiro de forma a avaliar a adequa\u00e7\u00e3o final do projeto com rela\u00e7\u00e3o ao planejamento inicial. A fase de transi\u00e7\u00e3o poder\u00e1, dependendo do <i>feedback<\/i> dos usu\u00e1rios, coincidir com o in\u00edcio de um novo ciclo de desenvolvimento (QUADROS, 2002).<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Refer\u00eancias<\/strong><\/p>\n<p>QUADROS, Moacir. <b>Ger\u00eancia de Projetos de Software<\/b>. T\u00e9cnicas e Ferramentas. S\u00e3o Paulo: Visual Books, 2002.<\/p>\n<p>RUP. <b>Rational Unified Process. <\/b>\u00a02003. Dispon\u00edvel em &lt;http:\/\/www.wthreex.com\/rup&gt;.Acessado em: 24\/04\/2006.<\/p>\n<p>WAZLAWICK, Raul Sidnei. <b>An\u00e1lise e Projeto de Sistemas de Informa\u00e7\u00e3o Orientados a Objetos.<\/b> Rio de Janeiro: Ed Campus Ltda, 2004.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>No ano de 2006 elaborei meu trabalho de conclus\u00e3o de curso sobre este t\u00f3pico de An\u00e1lise e Projeto de Sistemas Orientado a Objetos, pode ser acessado aqui\u00a0( a partir do cap\u00edtulo 5 \u00e9 que se inicia a parte de engenharia de software)\u00a0. \u00c9 um assunto pouco comentado, e at\u00e9 mesmo um pouco pol\u00eamico, pois \u00e9 [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[9,11,10,12,7,8],"class_list":["post-28","post","type-post","status-publish","format-standard","hentry","category-analise-projetos-sistemas","tag-analise","tag-casos-de-uso","tag-projeto","tag-requisitos","tag-rup","tag-uml"],"_links":{"self":[{"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=\/wp\/v2\/posts\/28","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=28"}],"version-history":[{"count":8,"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=\/wp\/v2\/posts\/28\/revisions"}],"predecessor-version":[{"id":233,"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=\/wp\/v2\/posts\/28\/revisions\/233"}],"wp:attachment":[{"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=28"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=28"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/gois.inf.br\/wordp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=28"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}