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