Analise e desenvolvimento
- 1. Análise e Desenvolvimento de Software Aula 01 CURSO: TÉCNICO EM INFORMÁTICA DOCENTE: TALIANE LIMA
- 2. Início • A partir de 1961 o mundo presenciou o surgimento de novos computadores, mais modernos e com mais poder computacional. • A partir dessa data o software ganhou notoriedade e, por conta disso, uma série de problemas relacionados ao “amadorismo” utilizado para sua construção ficou evidente.
- 3. • Em 1968 aconteceu a NATO(Software Engineering Conference), um evento criado com o objetivo de discutir alternativas para contornar a Crise do Software.
- 5. “O Pobre Programador” “A maior causa da crise do software é que as máquinas tornaram-se várias ordens de magnitude mais poderosas! Para esclarecer melhor: quando não havia máquinas, a programação não era um problema; quando tínhamos poucos computadores, a programação tornou-se um problema razoável, e agora, que nós temos computadores gigantes, a programação tornou-se um problema igualmente grande.” Edsger Dijkstra.
- 6. Podemos resumir a crise à imaturidade no desenvolvimento de software, causando diversos problemas, como por exemplo: • Projetos estourando o orçamento. • Projetos estourando o prazo. • Software de baixa qualidade. • Software muitas vezes não atendendo os requisitos. • Projetos não gerenciáveis e código difícil de manter.
- 9. Será que a crise acabou?
- 11. • Embora problemas durante o desenvolvimento de software aconteçam, e com certa frequência, os processos, métodos e ferramentas existentes auxiliam muito o desenvolvimento. Uma vez aplicados por pessoas com os conhecimentos adequados, podemos ter certeza do sucesso em um projeto.
- 14. • Com a identificação dos requisitos é possível iniciar a montagem de um protótipo, para se avaliar diversos pontos que necessitam de esclarecimento antes da construção efetiva do carro. • Essa prototipação pode ser feita via ferramentas de simulação partes que irão compor o automóvel. Essas partes são chamadas de unidades , como por exemplo, a barra de direção, a porta, o motor, as rodas,etc
- 15. • O modelo criado, seja qual for, normalmente é utilizado para responder diversas questões, para em seguida dar-se início ao desenvolvimento das partes que irão compor o automóvel.
- 16. • Se o item não passar nessa verificação, não podemos continuar com a construção do produto. • Caso os componentes sejam aprovados na verificação, podemos iniciar a combinação desses componentes, integrando-os (Integração)
- 17. Engenharia de Software poderia ser resumida à utilização de princípios de engenharia para o desenvolvimento de software: •levantar os requisitos associados, •construir modelos para representar a solução a ser desenvolvida •implementar as diversas unidades que irão compor o produto •verificando se tais unidades atendem aos requisitos identificados •realizar a integração entre as unidades, também verificando seu funcionamento, até que tenhamos o produto por completo
- 18. • De modo mais objetivo, pode-se dizer que a Engenharia de Software busca prover a tecnologia necessária para produzir software de alta qualidade a um baixo custo. Os dois fatores motivadores são essencialmente a qualidade e o custo.
- 19. Problemas no desenvolvimento de software • Embora a Engenharia de Software seja uma área consolidada e existam várias empresas que a utilizam com muito sucesso em projetos de desenvolvimento de software, isso não é verdade na maioria dos casos. • A crise continua em muitos locais, não mais por ausência de métodos, técnicas e ferramentas, mas pela falta do seu uso!
- 20. Tripé da Engenharia de Software.
- 21. Componentes de um sistema
- 22. • Um sistema é bem mais que o software. Embora o software seja uma parte importante de um sistema, ele não é a única. Se não existir o hardware para execução do software, de nada servirá. Da mesma forma, é necessário existir bases de dados, uma vez que praticamente todos os sistemas com algum tipo de utilidade devem armazenar dados.
- 23. • Atualmente, com o advento da Internet, dificilmente um sistema seja útil se não tiver certos mecanismos de comunicação associados. Tudo isso junto, forma o sistema. Por diversas vezes tendemos a utilizar software e sistema como algo similar, mas é importante ressaltarmos suas diferenças, de forma a deixar claro o que representa cada um desses termos.
- 24. • Um produto de software, por outro lado, é sistematicamente destinado ao uso por pessoas diferentes dos seus programadores. • Os eventuais usuários podem ter formações e experiências diferentes, o que significa que uma grande preocupação no que diz respeito ao desenvolvimento do produto deve ser a sua interface,
- 25. • Um programa desenvolvido para resolver um dado problema e um produto de software destinado à resolução do mesmo problema são duas coisas totalmente diferentes.
- 26. • Os produtos de software desenvolvidos utilizando a Engenharia de Software sempre estão envolvidos em algum processo de negócio, seja ele simples ou complexo. Assim, é fundamental entender esse processo de negócio para que seja possível informatizá-lo. • Exemplo : casa
- 27. Processos de Software • Engenharia de Software nada mais é que o tratamento do software como um produto, empregando dentro do processo de desenvolvimento todos os princípios da engenharia.
- 28. • Como todo produto, o software também possui um ciclo de vida, que pode ser definido como o conjunto de todas as etapas relacionadas à sua existência, desde a sua concepção, até o seu desaparecimento.
- 29. ETAPAS DO PROCESSO DE SOFTWARE: concepção desenvolvimento operação retirada
- 30. Qual a relação do processo de software com o ciclo de vida?
- 31. CONCEITO: • Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, utilizados para se atingir uma meta.
- 32. • Importante: enquanto o processo é um guia para se construir um produto, um projeto é o uso de um processo para desenvolvimento de um produto específico.
- 33. • Um processo deve ter uma documentação que o descreve, apresentando detalhes sobre o que é feito (produto), quando (passos), por quem (agentes), o que usa como entrada (insumo) e o que é produzido (resultado).
- 34. • PROCESSOS X SUBPROCESSOS
- 35. Para detalhamento dos modelos de ciclo de vida, necessitaremos entender melhor cada um dos subprocessos (fluxos ou disciplinas) : oRequisitos oAnálise oDesenho oImplementação oTeste
- 36. Codifica-Remenda • O modelo de ciclo de vida mais utilizado é o modelo codifica-remenda. • Apartir de uma especificação incompleta, ou mesmo ausente, inicia-se a codificação do software, que por sua vez tende a gerar “algo”.
- 38. • A grande utilização desse modelo se dá em virtude de boa parte dos “profissionais” responsáveis pelo desenvolvimento de software não terem qualquer conhecimento sobre a Engenharia de Software.
- 39. ASPECTO POSITIVO ASPECTO NEGATIVO • Não exige nenhum conhecimento técnico ou gerencial. Basta iniciar, sem muito preparo sobre o tema a ser abordado, e trabalhar para gerar algo como resultado. • É um modelo de alto risco, praticamente impossível de se gerenciar, tornando-se impossível estabelecer qualquer estimativa de custo e prazo.
- 40. Cascata
- 41. • Esse modelo de ciclo de vida (ou paradigma) foi muito utilizado no passado. No entanto, devido a falhas durante sua execução, ele vem sendo preterido por outros modelos.
- 42. FALHAS ENCONTRADAS: • Surgimento de grandes problemas quando temos mudanças em um projeto em andamento; • é difícil para os clientes identificarem todos os requisitos explicitamente; • O cliente precisa ter paciência; • Erros grosseiros desastrosos.
- 43. Espiral • A ideia básica é desenvolver um produto a partir de pequenas versões incrementais, que podem iniciar com um modelo em papel e evoluir até versões do sistema completamente funcionais.
- 45. • A ideia básica por trás do modelo em espiral é: dividir para conquistar! • Ao invés de querer resolver todos os problemas de uma vez, é interessante resolver parte dele e então partir para o restante.
- 46. VANTAGENS DESVANTAGENS • É utilizada apenas para a redução dos riscos e para o enfoque maior naquilo que é mais importante/ complexo/ crítico no sistema. • A não entrega das partes para ao cliente. • Tomada de decisões é feita apenas com o conhecimento do produto que existe até o momento.
- 47. • O fato de dividir um sistema para tratá-lo por partes favorece o entendimento e facilita a própria vida dos clientes, que podem emitir opiniões e identificar requisitos com mais propriedade. Isso facilita o uso desse tipo de modelo de ciclo de vida.
- 48. Incremental • O modelo incremental, também denominado de prototipagem evolutiva, é baseado no modelo em espiral. • O modelo incremental não é utilizado apenas para construir o produto por completo, mas uma série de versões provisórias, denominadas protótipos.
- 50. • Esses processos são conhecidos como Processos (ou Métodos ou Metodologias) Ágeis, em virtude de darem mais importância ao software funcionando do que qualquer outro artefato gerado durante o desenvolvimento.
- 53. • O termo “metodologias ágeis” tornou-se popular em 2001 quando diversos especialistas em processos de desenvolvimento de software representando as metodologias Extreme Programming (XP), SCRUM, DSDM (Dynamic Systems Development Methodology), Crystal e outros, estabeleceram princípios comuns compartilhados por todos esses métodos. O resultado foi a criação da Aliança Ágil, e o estabelecimento do “Manifesto Ágil” (Agile Manifesto).
- 54. Os conceitos chaves do Manifesto Ágil são: Indivíduos e interações ao invés de processos e ferramentas; Software executável ao invés de documentação; Colaboração do cliente ao invés de negociação de contratos; Respostas rápidas a mudanças ao invés de seguir planos.
- 55. Entrega Evolutiva • O levantamento de requisitos é feito como um todo, para que seja possível entender todo as questões que envolvem o produto a ser construído • E em pontos bem definidos os usuários podem avaliar as partes do produto já desenvolvidas, fornecendo realimentação
- 57. • De forma geral o bom senso é o melhor termômetro para definição do que é mais apropriado em uma situação, mas um conselho a todos que possam se deparar com essa situação é: nunca acredite em pessoas que defendem cegamente esse ou aquele processo; como tudo na vida, o contexto da situação pode determinar o que é o mais apropriado.