Este trabalho trata

128 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
128
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Este trabalho trata

  1. 1. Este trabalho trata-se da engenharia de software onde mais especificamente requisitos desoftware ,e também descreve algumas dificuldades existentes e apresenta praticas para oauxilio de elaboração dos requisitos necessários para o sistema solicitado ao usuário final.Software é toda a parte logica que o usuário pode ver e usar em um computador , a analisede sistemas identifica problemas existentes no mesmo, e apresenta meios para soluções.Após ser feita a analise do computador , é realizado o escorpo onde os requisitos desoftware são definidos.Os requisitos de um sistemaOs requisitos de um sistema refletem as necessidades dos clientes de um sistema queajuda a resolver algum problema, por exemplo, controlar um dispositivo, enviar umpedido ou encontrar informações. O processo de descobrir, analisar, documentar everificar esses serviços e restrições é chamado de engenharia de requisitos( R E –RequirementsEngineering).” (Ian Sommerville/2007)Requisitos funcionaisSão declarações de serviços que o sistema fornece, como o mesmo deve reagir as estradasespecificas e como ele deve se comportar em uma determinada situação. Em alguns casoso mesmo pode funcionar também estabelecer o que o sitema não deve fazer.Requisitos não funcionaisOs requisitos não funcionais são aqueles diretamente relacionados as funções especificasfornecidas pelo sistema. Esses requisitos podem especificar desempenho, proteção ,disponibilidade entre outras propriedades emergentes de sistema.Requisitos não funcionais determinam o processo que deve ser usado para desenvolver osistema. Exemplo: as especificações no padrão de qualidade, o tópico de ferramentas CASEe uma descrição do processo que deve ser seguido. Os requisitos não funcionais surgem pela as necessidades do usuário final, àsrestrições de orçamento, as políticas organizacionais* Requisitos de produto: especificam o comportamento do produto. Entre eles estãorequisitos de desempenho, confiabilidade, portabilidade e usabilidade. * Requisitos organizacionais: este requisito é derivado de políticas da organização docliente e do desenvolvedor, exemplo requisito de implementação como a linguagem deprogramação ou o método de projeto usado e requisitos de entrega que especificamquando o produto e a sua documentação devem ser entregues. * Requisitos externos: são requisitos derivados de fatores externos ao sistema e seuprocesso de desenvolvimento. Podem incluir requisitos de interoperabilidade, requisitoslegais e requisitos éticos.
  2. 2. Os tipos de requisitos não funcionais são: * Requisitos de produto: neste requisito ele montra o comportamento do produto. Entreeles estão requisitos de desempenho, confiabilidade e usabilidade. * Requisitos organizacionais: neste requisito é derivado de políticas da organização docliente e do desenvolvedor, exemplo: requisito de implementação como a linguagem deprogramação ou o método de projeto usado e requisitos de entrega que especificamquando o produto e a sua documentação devem ser entregues. * Requisitos externos: são requisitos derivados de fatores externos ao sistema e seuprocesso de desenvolvimento. Podem incluir requisitos de interoperabilidade, requisitoslegais e requisitos éticos.Requisitos de UsuárioOs requisitos de usuário de um sistema se define pela descrição do que o sistema devefazer (requisitos funcionais e não funcionais) que seja compreendido pelo usuário nãofinal . Deve ser escrito em uma linguagem simples. Entretanto, alguns problemas podem surgir com essa especificação em linguagemnatural. São eles: falta de clareza; confusão de requisitos e fusão de requisitos. O requisito de usuário deve simplesmente enfocar apenas característicasessenciais ao sistema. Requisitos muito detalhado geralmente limitam as soluções para osproblemas e são difíceis de serem compreendidos.Requisitos de sistemaOs requisitos de sistemas são versões expandidas dos requisitos de usuários usados pelosengenheiros de software como ponto de partida para o projeto de sistema.” (Sommerville– 2007).São descrições detalhados pelos usuários sobre o sistema que servem como base para aimplementação com a especificação completa e consistente de todo o sistema. Uso da linguagem estruturada, que é padronizada, a torna com a liberdade maislimitada e com isso mantém a facilidade de expressão e compreensão .Podemos também usar tabelas ou modelos gráficos para facilitar o entendimento dosistema de como é processada a informação, como a informação é armazenada e assequencias de ações que serão tomadas de maneira bem detalhada e assim reduzir asdúvidas do usuário sobre o funcionamento do sistema.
  3. 3. Documentos de RequisitosComo resultado do processo de levantamento de requisitos é feito o documento de requisitosdo sistema. Este documento contém todas as especificações de todos os requisitos funcionaise não funcionais do software, incluindo as capacidades do produto, os recursos disponíveis, osbenefícios e os critérios de aceitação ou não.
  4. 4. Características do documento de requisitosO documento de requisitos do sistema deve ser composto por sentenças em linguagemnatural, seguindo determinados padrões:1) Iniciar com “O sistema deve”.2) Deve-se usar frases curtas• Exemplo: “O sistema deve rodar em microcomputadores com memorias ram acima de 2 gb”
  5. 5. SCRUMO SCRUM é um modelo de desenvolvimento ágil de software para fornece métodos para sedefinir o planejamento, os principais papéis de pessoas e a forma de trabalho. A ideia doSCRUM é justamente definir papéis bem específicos para as pessoas envolvidas no projeto ,ouseja, o que cada uma vai ter que fazer para o desenvolvimento do software .Em geral e de forma reduzida, esta metodologia funciona da seguinte forma: 1. O produto é definido: quais são realmente seus requisitos? O que realmente o clientedeseja ? 2. O Proprietário do Produto define quais são as funcionalidades do programa que maisimportam. 3. Com as prioridades definidas, uma pessoa é definida para ser o ScrumMaster, umaespécie de coordenador do projeto. O ScrumMaster, junto com o Proprietário do Produto e oTime de desenvolvimento definem o que chamamos de Sprints.RUPO Processo Unificado da Rational conhecido como RUP , é um processo de engenharia desoftware criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma formasistemática para se obter vantagens no uso da UML. Foi criado pela Rational SoftwareCorporation e adquirido em fevereiro de 2003 pela IBM. O principal objetivo do RUP é atenderas necessidades dos usuários garantindo uma produção de software de alta qualidade quecumpra um cronograma e um orçamento exato. Assim, o RUP mostra como o sistema seráconstruído na fase de implementação, gerando o modelo do projeto . O RUP defineperfeitamente quem é responsável pelo que, como as coisas deverão ser feitas e quandodevem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente paraque sejam alcançadas.O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas questõessobre planejamento, levantamento de requisitos, análise, implementação, teste e implantaçãodo software. Cada fase tem um papel fundamental para que o objetivo seja cumprido,distribuídos entre vários profissionais como o Analista de sistema, Projetista, Projetista detestes, entre outros.
  6. 6. Fases do RUP1-Fase de Concepção / Iniciação: Nesta fase do RUP abrange as tarefas de comunicação como cliente e planejamento. É feito um plano de projeto avaliando todos os riscos possíveis , asestimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos dosistema e preliminarmente analisá-lo.2-Fase de Elaboração: O objetivo desta fase é analisar de forma mais detalhada a análise dodomínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projetocomeça a ter sua forma básica. Por exemplo as duvidas mais apontadas são “O plano doprojeto é confiável?”, “Os custos são admissíveis?” todas e mais duvidas são esclarecidasnesta etapa.3-Fase de Construção: O principal objetivo desta fase é a construção do sistema de software,com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase deConstrução que a maior parte de codificação ocorre.4-Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivodesta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final.XpO método XP, do inglês eXtremingProgramming, é uma proposta de desenvolvimento ágil e serepete diversas vezes para se chegar a um resultado. O método XP propõe um processo leve,e com a entrega constante de pequenas partes da funcionalidade do software. As partesdevem ser incrementadas e requerem a melhoria constante do código . A possibilidade de entrega rápida do código é um dos fatores de sucesso do XP. Istono entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna umparticipante da equipe de desenvolvimento. Esta é uma das características importantes para ométodo funcionar bem. No entanto, nem sempre o cliente está disponível para a participaçãoativa. Uma das características importantes do XP é que não existe um processo de designtradicional com a elaboração de modelos da arquitetura do software.
  7. 7. O retrabalho ou pré-fabricação é uma atividade fundamental e necessária para o XP funcionar.Mesmo que o código esteja 100% testado, para viabilizar reuso, ele precisa ser revisto pararemover redundâncias, retirar funcionalidades desnecessárias e modificar arquitetura . Oretrabalho do código ao longo de todo o ciclo de vida reduz o tempo total de entrega do códigoe aumenta a qualidade do software produzido.Regras e PráticasPlanejando * Planejando liberações e pequenas liberações * Dividir projetos em diversas partes* Medindo velocidade do projeto * Reuniões diáriasProjetando * Simplicidade * Metáfora * Re-fabricarCodificando * O cliente deve estar sempre disponível. * Programação em pares. * Codificar de acordo com padrões acordados. * Codificar testes de unidade primeiro. * Integrar com frequência. * O código é propriedade coletiva.
  8. 8. .Testando * Todo código deve ter os testes de unidade. * Cada unidade deve ser testada antes de liberada. * Quando um erro é encontrado, testes devem ser realizados. * Testes de aceitação devem ser freqüentes. A programação extrema tem sido bem sucedida em projetos pequenos com timespequenos. Relatos mostram que para projetos grandes o método XP não é recomendado.
  9. 9. Conclusão
  10. 10. BibliografiaSOMMERVILLE, Ian – Engenharia de Software. 8ª Ed. Pearson Education, 2007.CARDOZO, Eleri – Requisitos de Software 2ª parte. FEEC/Unicamp, 2007.KOTONYA, Gerald - http://www.scc.lancs.ac.uk/IEEE Std 830-1998,IEEE RecommendedPractice for Software RequirementsSpecifications -http://www.ieee.org.br/* http://www.agilealliance.org/article/articles_by_category/17 * http://www.codeproject.com/KB/architecture/scrum.aspx

×