Blog

ANALISE E DESENVOLVIMENTO DE SISTEMAS ENGENHARIA DE SOFTWARE ALEXANDRE FЙLIX NETO EDILSON BATISTA DE SANTANA LUIZ CARLOS FERREIRA ROCHA NIEDSON BARROS BRANDГO SEVERINO JOSЙ FERRARA DA SILVA Palmares/PE 2010 ALEXANDRE FЙLIX N EDILSON BATISTA DE LUIZ CARLOS FERREI NIEDSON BARROS B SEVERINO JOSЙ FERR OF9 Swipe nentp ROC ENGENHARIA DE SOFTVVARE Trabalho apresentado ao Professor Luis Clбudio Perini da disciplina Engenharia de Software do 20 semestre do curso Anбlise e Desenvolvimento de Sistemas.

SUMБRIO … 8 CONSIDERAЗХES FINAIS… INTRODUЗAO 3 1 METODOS AGEIS Entre as dйcadas de 1980 e comeзo da dйcada de 1 990, os esenvolvedores de software tinham um conceito de que, a melhor forma de se obter um software com qualidade, era atravйs de um cuidadoso projeto. Esses softwares eram praticamente desenvolvidos por equipes que trabalhavam para diversas empresas. Estas geralmente estavam separadas geograficamente e trabalhavam no software por longos perнodos de tempo.

Quando esse tipo de desenvolvimento pesado e baseado em planos foi aplicado a sistemas de pequenas e mйdias empresas, viu-se que o tempo gasto para determinar como o sistema deveria ser desenvolvido era maior do que o empregado no desenvolvimento do programa em testes. Na dйcada de 1990, alguns desenvolvedores estavam insatisfeitos com esse tipo de abordagem, e fez com que proporem- se mйtodos бgeis. Este mйtodo permitia que a equipe de desenvolvimento se preocupasse somente com o software em vez gastar tempo indeterminado com o projeto.

Os mйtodos бgeis tem uma abordagem iterativa para especificaзгo, desenvolvimento e entrega de software, e foram criados para apoiar o desenvolvimento de aplicaзхes de negуcios, nos quais os requisitos mudam durante o processo de desenvolvimento. Como o e diz, este й um mйtodo 2 EXTREME PROGRAMMING O nome Extreme Programming foi dado por Beck, pois a bordagem foi desenvolvida pelo avanзo de reconhecida boa prбtica, tal como o desenvolvimento iterativo e o envolvimento do cliente em nнveis extremos.

Na XP, todos os requisitos sгo expressos em cenбrios (histуrias do usuбrio), e sгo praticados diretamente por um conjunto de tarefas. Os programadores trabalham em pares, e fazem testes para cada tarefa antes da escrita do cуdigo. Enfim, todos os testes devem necessariamente ser executados com sucesso quando um novo cуdigo й implementado ao sistema. 4 A XP busca o mбximo de valor a cada dia de trabalho da equipe para o seu cliente.

Em curto espaзo de tempo o cliente terб um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido й realmente o desejado. 2. 1 PRATICAS UTILIZADAS PELA XP Essas prбticas sгo designaзхes que praticantes da XP devem seguir durante o processo de desenvolvimento de software: * Cliente disponнvel => o XP tem uma visгo totalmente diferente do modelo tradicional em relaзгo ao cliente.

Este sugere que o cliente esteja no dia-a-dia do projeto, acompanhando os passos dos desenvolvedores. Sua ausкncia representa sйrios riscos ao projeto. Assim, o produto final terб ais garantia de ser o que o cliente pediu; * Planejamento O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o mбximo de valor para o cliente.

Esse planejamento й feito vбrias vezes durante o projeto. Й o momento onde o cliente solicita as funcionalidades desejadas atravйs de estуrias, onde 3 o momento onde o cliente solicita as funcionalidades desejadas atravйs de estуrias, onde a equipe estima o custo de cada estуria e planeja as releases e as iteraзхes; * Stand up meeting => o dia de trabalho de uma equipe XP comeзa com um stand up meeting. ?? uma rбpida reuniгo pela manhг, com aproximadamente 20 minutos de duraзгo, que tem como objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiкncias das dificuldades enfrentadas; 5 Programaзгo em par=> O XP exige que todo e qualquer cуdigo implementado no projeto seja feito em dupla, chamada de programaзгo em par. Й uma tйcnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador.

Um deles й responsбvel pela digitaзгo (condutor) e outro acompanhando o trabalho do parceiro (navegador); * Refactoring O XP diz que todo desenvolvedor ao ncontrar um cуdigo duplicado, pouco legнvel, mal codificado, sem padronizaзгo, lento, com cуdigo legado ou uso incorreto de outras implementaзхes, tem por obrigaзгo alterar este cуdigo deixando-o mais legнvel e simples, porйm esta alteraзгo nгo pode mudar o comportamento do cуdigo em questгo; * Desenvolvimento guiado por testes=> Esta atividade й considerada extremamente chata e dispendiosa por muitos desenvolvedores na modelagem tradicional, porйm para os desenvolvedores de uma equipe XP esta atividade deve ser encarada com extrema naturalidade.

Todo cуdigo implementando deve coexistir com um teste automatizado, assim arantindo o pleno funcionamento da nova funcionalidade; * Cуdigo Coletivo Esta prбtica tem como consequкncia um cуdigo r 4DF9 da nova funcionalidade; um cуdigo revisado por diversas pessoas e caso algo nгo esteja claro, com certeza serб alterado por alguma pessoa (refactoring) para que o mesmo torne-se legнvel; * Padrхes de Desenvolvimento O XP recomenda a adoзгo de um padrгo desde o inнcio do projeto, preferencialmente padrхes utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificaзхes e adaptaзхes durante o projeto, que visam agilizar o esenvolvimento, as mesmas devem ser efetuadas; * Design Simples => essa prбtica foca que o maior valor possнvel seja gerado para o cliente.

O XP prega um design do sistema da forma mais simples possнvel para que atenda a necessidade do cliente; * Ritmo Sustentбvel => Um grande problema nos projetos de software й a falta de tempo para encerrar o mesmo, e uma das tйcnicas mais adotadas para compensar a falta de tempo й submeter os desenvolvedores a trabalharem atй mais tarde e muitas vezes sacrificarem seus finais de semana. O XP proнbe que os desenvolvedores trabalhem atй mais tarde. O XP sugere um ritmo sustentбvel de 40 horas semanais, respeitando assim a individualidade e o fнsico de cada desenvolvedor. Desta forma a equipe estarб sempre concentrada e muito menos propensa a pequenas falhas na Implementaзгo; 6 ntegraзao Continua => O XP propхe uma integraзгo cont[nua, se possvel deve ser efetuada vбrias vezes durante o dia para que toda a equipe tenha conhecimento do cуdigo recйm- desenvolvido. Com esta prбtica o feedback sobre alteraзгo efetuada serб retornado em um menor espaзo de tempo S recйm-desenvolvido.

Com esta prбtica o feedback sobre alteraзгo fetuada serб retornado em um menor espaзo de tempo; * Releases Curtos Release й um conjunto de funcionalidades bem definidas e que representam algum valor para o cliente. O XP recomenda que pequenos investimentos sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possнvel. Com a prбtica de releases curtos, o XP pretende dar o mбximo de valor econфmico ao cliente em um curto espaзo de tempo. 3 MODELO EVOLUCIONБRIO O Modelo evolucionбrio tem como base a ideia de desenvolver uma implementaзгo inicial, e interagir ativamente com o cliente a fim de fazer seu aperfeiзoamento travйs de muitos testes atй que o sistema desejado tinha sido desenvolvido.

Durante este modelo, sгo realizados constantemente atividades de especificaзгo, desenvolvimento e validaзгo. Este tipo de modelo й recomendado para sistemas de pequeno e mйdio porte. Existem dois tipos de modelos evolucionarios: * Exploratуrio: o software й desenvolvido com a constante participaзгo do cliente. Neste processo o produto й dividido em partes para a melhor compreensгo do cliente. E assim fazendo com que a Implementaзгo de novas caracterнsticas seja feita, de modo que o produto final seja o que o cliente especificou. Protуtipos descartбveis: durante o processo de desenvolvimento й comum que partes dos requisitos sejam mal compreendidas.

Para isso, os protуtipos descartбveis servem, para que os requisitos sejam bem compreendidos e o sistema seja finalizado corretamente. 3. 1 VANTAGENS DESTE MODELO Com certeza, a grande vantagem deste modelo й uma eficбcia superior a outros modelos, no cumprimento das especificaзхes do cliente, e uma rapidez superior a outros modelos no processo de desenvolvimento. 3. 2 DESVANTAGENS DESTE MODELO Se o sistema й desenvolvido rapidamente, nгo й bom produzir ocumentos que reflitam cada versгo do sistema e, portanto se perde o controle sobre o gerenciamento do projeto. Tambйm devido a mudanзas contнnuas, a estrutura do software aspira a se desgastar.

Para o seu desenvolvimento, podem ser exigidas tйcnicas e ferramentas especiais incompatнveis com outras ferramentas e que exigem conhecimento que poucos clientes possuem. 4 PESQUISA SOBRE MODELOS DE PROCESSO Foi realizada uma entrevista por meio da internet com a Software House PIX Software, onde foi colocado o questionбrio com 15 (quinze) perguntas relevantes ao modelo de processo de criaзгo e software. 4. 1 QUESTIONARIO COMO Й FEITO A ANALISE DE RISCO PELA EMPRESA? Sгo utilizados AO CONSTRUIR UM SOFTWARE, QUAL O MELHOR SISTEMA OPERACIONAL PARA RODAR SEU SOFTWARE? Nгo fazemos opзгo por sistemas operacionais. No entanto, temos no levantamento de re uisitos, uma ideia de como o proprietбrio da organizaзг r o seu sistema.

Hoje CONSTRUIR UM SOFTWARE QUAL A MENOR QUANTIDADE DE PESSOAS QUE PRECISA? Muito relativo porque nгo hб um padrгo. Como trabalhamos com sistemas mais complexos que precisam interagir com outros, tem-se no mнnimo uma equipe de 03 engenheiros que cuida de oda a parte de levantamento de requisitos. Em regra nгo menos que 15 profissionais. NA CRIAЗAO DO SOFTWARE, NA METADE DO PROJETO, ACONTECE UM PROBLEMA COM UNS DOS FUNCIONБRIOS ELE NГO PODE CONTINUAR, vocк PARA OU CONTINUA COM O DESENVOLVIMENTO? QUE TIPO DE CICLO DE VIDA E USADO PELA EMPRESA? Deve continuar a todo custo; afinal contrato se cumpre. No modelo espiral, temos a analise de riscos como mais usual.

E nessa analise, й previsto algo como os fatores de risco tais como: doenзa, viagem, etc. Situaзхes que acontecem durante o processo de criaзгo do sistema. Temos como regra bбsica a istribuiзгo do cуdigo fonte a 2 ou 3 responsбveis pelo projeto, evitando assim riscos de prazo de entrega do sistema. Й USADO APENAS UM MODELO, OU DEPENDE DO PROJETO? Nгo, depende do projeto. O QUE E NECESSARIO PARA QUE CONSIDERE O PROJETO FINALIZADO? Apуs os testes de entrada, processamento e saнda forem finalizados; claro que depois de alguns dias elou meses de testes dependendo do projeto. QUAL INFORMAЗГO QUE O DESENVOLVEDOR NAO PODE DEIXAR DE SABER DO SEU CLIENTE? Qual a principal finalidade do software.

Com certeza na primeira entrevista deve ficar claro o que ele quer e qual o objetivo do seu sistema. 8 im. Й IMPORTANTE DOCUMENTAR? Sim porque a manutenзгo que deverб ocorrer posteriormente serб necessбrio manual com as instruзхes de cada trecho de cуdigo. 8 PELA NECESSIDADE DE SE FAZER UM SOFTWARE DE QUALIDADE E EM MENOR TEMPO USA-SE MAIS OS PROCESSOS БGEIS DO QUE OUTROS MODELOS? Nem sempre. Depende muito do que o cliente solicita. Na maioria das vezes seguimos regras determinadas pelo responsбvel do sistema, mais, no entanto acontecem ajustes internos de como agir durante uma determinada situaзгo, ou seja, imprevistos podem acontecem a qualquer instante.

COM QUE FREQUКNCIA, OU CUANDO, UM SOFTWARE DEVE SER ATUALIZADO PARA O CLIENTE? Sempre que surgirem novas necessidades no processo de operacionalizaзгo ou de gestгo da organizaзгo. Geralmente a cada 6 meses sгo feitas implementaзхes novas no sistema. No entanto, vai depender tambйm do contrato com a organizaзгo. Poderб ser feito por nуs ou outra software house. EXISTE UMA FORMA MAIS ADEQUADA PARA REDUZIR CUSTO E TEMPO? Sim. Um bom planejamento antes da assinatura do contrato. QUAIS TESTES SГO FEITOS AO FINALIZAR O PROGRAMA? Teste de acessibilidade de usuбrios; stress do sistema; energia; Data-base. Acho que esses sгo mais importantes. 9 CONSIDERACOES FINAIS g