- DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho das pessoas implicações estratégicas que o SI poderá ter na organização Aproximações de soluções: Hard assume que o problema tem base lógica ou matemática Soft relacionada aos efeitos ambientais do SI aspectos econômicos, legais, psicológicos do ambiente
Diferença entre desenvolvimento de Sistema de Informação e desenvolvimento de software Histórico: Década de 50 e 60 não havia processo definido para DSI. A solução era buscada por meio de termos computacionais, sem dar atenção à compreensão e descrição do sistema em si. Década de 70 maior conscientização da importância das fases análise de requisitos e modelagem movimento de desenvolvimento estruturado, sistemático, top-down. Surgimento do conceito de ciclo de vida de desenvolvimento de sistema (SDLC Systems Development Life Cycle)
Conceito de ciclo de vida de desenvolvimento de sistema Desenvolvimento sequencial segue uma abordagem sistêmica e linear ao longo da vida do projeto. Desenvolvimento evolutivo o sistema é construído em diferentes etapas, sendo, em cada etapa, construída uma versão do sistema que vai evoluindo. Cada versão satisfaz os requisitos conhecidos Desenvolvimento incremental parte da ideia que pode-se construir um sistema a partir de varias versões, cada uma com um conjunto especifico de funções.
Modelo sequencial linear ou modelo em Cascata (Waterfall model ) apareceu no início do anos 70, foi o primeiro que veio com a intenção de disciplinar e sistematizar o DSI. Características: Cada fase tem objetivos bem definidos modelo mais antigo e o mais amplamente usado modelado em função do ciclo convencional requer uma abordagem desenvolvimento do sistema sistemática, sequencial ao o resultado de uma fase se constitui na entrada da outra Apropriado para sistemas transacionais onde as rotinas e procedimentos estruturados. a serem automatizados são altamente
Modelo Cascata
Problemas Encontrados no modelo Cascata: Projetos reais raramente seguem o fluxo sequencial que o modelo propõe Difícil para o cliente estabelecer todos os requisitos inicialmente. O cliente precisa ter paciência! Tempo necessário para disponibilizar o software. Uma versão do software somente estará pronta ao final do cronograma do projeto; Incremento dos custos de correção na medida em que se avancem as fases. Os erros mais comuns são encontrados no início do período de testes, enquanto os mais sérios são encontrados apenas no final. Ausência de envolvimento do utilizador no processo de desenvolvimento
O Modelo de processo em Cascata trouxe contribuições importantes para o processo de desenvolvimento de sistemas: Imposição de disciplina, planejamento e gerenciamento a implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos; Permite gerência do baseline, que identifica um conjunto fixo de documentos produzidos ao longo do processo de desenvolvimento;
Modelo prototipagem Processo que propicia ao desenvolvedor cria um modelo do sistema que será implementado. O protótipo serve como um mecanismo para a identificação dos requisitos do sistema. Os protótipos permitem: que o projetista avalie previamente algumas características particulares do projeto; que o modelo seja testado sem o risco de comprometer todo um projeto; que o usuário tenha condições de melhor entender o produto que esta sendo desenvolvido.
O modelo pode assumir uma das três formas: Um protótipo em papel ou visual que retrata a interação homem-máquina; Um protótipo de trabalho que implementa algum subconjunto da função exigida do software desejado; Um programa que executa parte ou toda a função desejada, porém que necessita ser aprimorado para tornar-se operacional.
Modelo Prototipagem
Problemas da prototipagem: Não entendimento pelo cliente de que o protótipo não é um produto acabado; O cliente vê o protótipo e tem pressa para colocá-lo em funcionamento, não levando em consideração a qualidade global do sistema. Muitas vezes o desenvolvedor quer colocar o protótipo em funcionamento rapidamente, com isso, um sistema operacional ou linguagem de programação imprópria pode ser usada, simplesmente porque está à disposição e é conhecida.
Comentários sobre o Modelo de Prototipagem ainda que possam ocorrer problemas, a prototipagem é um ciclo de vida eficiente. a chave é definir as regras do jogo logo no começo. o cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo para definir os requisitos
Modelo Espiral foi evoluindo ao longo do tempo (Barry Boehm, 1988) Abrange as melhores características tanto do ciclo de cascata como prototipagem. Combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo linear sequencial (cascata). Fornece potencial para o desenvolvimento rápido de versões incrementais do SI. Foi acrescido de uma nova fase, a análise de risco. O modelo espiral é dividido em uma série de atividades de trabalho ou regiões de tarefa. Engloba várias iterações através de sucessivos ciclos.
Modelo Espiral
Modelo Espiral Estabelecimento de objetivos são definidos objetivos específicos para a fase do projeto. São identificadas restrições sobre o processo e o produto. É projetado um plano de gerenciamento detalhado. São identificados riscos do Projeto e, dependendo dos riscos, estratégias alternativas podem ser planejadas Planejamento o projeto é revisto e é tomada uma decisão de continuidade se é decidido continuar, são projetados planos para a próxima fase do projeto Avaliação e redução de riscos para cada um dos riscos identificados, uma análise detalhada é executada. Passos são tomados para reduzir o risco Desenvolvimento e validação depois da avaliação do risco, um modelo de desenvolvimento é escolhido para o sistema
Características dos ciclos Cada ciclo na espiral representa uma fase do processo de software o ciclo mais interno está concentrado nas possibilidades do sistema o próximo ciclo está concentrado na definição dos requisitos do sistema o ciclo um pouco mais externo está concentrado no projeto do sistema um ciclo ainda mais externo está concentrado na construção do sistema Não existem fases fixas no modelo. As fases mostradas na figura são meramente exemplos. A gerência decide como estruturar o projeto em fases
Modelo Espiral é, atualmente, a abordagem mais realística para o desenvolvimento de sistemas de informação /software em grande escala. usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso o modelo é relativamente novo e não tem sido amplamente usado. Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta
Modelo RAD - ( Rapid Application Development), desenvolvimento rápido deaplicações (Martin, 1991) enquadra-se no tipo de desenvolvimento sequencial linear que enfatiza um ciclo de desenvolvimento extremamente curto. O desenvolvimento rápido é obtido usando uma abordagem de construção baseada em componentes, seguindo a regra dos 80/20. Surgiu como uma reação aos modelos tradicionais que eram demasiadamente longos.
Características do Modelo RAD Os requisitos devem ser bem entendidos e o alcance do projeto restrito O modelo RAD é usado principalmente para aplicações de sistema de informação Cada função principal pode ser direcionada para uma equipe RAD separada e então integrada para formar o todo.
Modelo RAD
Desvantagens: Exige recursos humanos suficientes para todas as equipes Exige que desenvolvedores e clientes estejam comprometidos com as atividades de fogo-rápido a fim de terminar o projeto num prazo curto Nem todos os tipos de aplicação são apropriadas para o RAD: Deve ser possível a modularização efetiva da aplicação se alto desempenho é uma característica e o desempenho é obtido sintonizando as interfaces dos componentes do sistema, a abordagem RAD pode não funcionar
Modelo V (V Model) (Jensen e Tonies, 1979) Esse modelo pode ser visto como uma evolução do modelo em cascata. Neste modelo o processo de DSI é basicamente dividido em duas partes, as duas pernas do V, a parte da especificação e a da verificação e validação. Esse modelo sugere que nenhuma fase pode ser considerada completa, e a seguinte começar, até que o documento produzido esteja completo. A conexão entre os lados direito e esquerdo do modelo em V implica que, caso sejam encontrados problemas em uma atividade de teste, a correspondente fase do lado esquerdo e suas fases subsequentes podem ter de ser executadas novamente para corrigir ou melhorar esses problemas.
Modelo em V
Características Modelo V Enfatiza a importância de considerar as atividades de testes durante o processo, ao invés de um teste posterior após o término do processo; A fase de teste começa no início do ciclo. A segunda fase de testes é extremamente reduzida. Pode-se obter a retroalimentação mais rapidamente; Ajuda a desenvolver novos requisitos; Melhora a qualidade do produto resultante.
Desvantagens Modelo V Dificuldade em seguir o fluxo sequencial do modelo; Não é suficientemente flexível; É necessário maior feedback entre todas as fases do ciclo. Dificuldade para o cliente poder especificar os requisitos explicitamente. Pressupõem que o sistema é entregue completo, após a realização de todas as atividades do desenvolvimento. Entretanto, nos dias de hoje, os clientes não estão mais dispostos a esperar o tempo necessário para tal, sobretudo, quando se trata de grandes sistemas
Desenvolvimento de sistema WEB Devido a grande necessidade de desenvolvimento de sistemas para ambientes web, levou-se a questionar a utilização de diferentes abordagens para o desenvolvimento desses SI (WIS Web Information Systems) Modelo W é uma adaptação do modelo V. Esta adaptação baseia-se na substituição da fase de codificação por uma fase designada por implementação incremental, que inclui uma etapa de validação com o cliente, devido a importância que a interface com o utilizador tem nesses sistemas. Todas as outras fases devem existir, independente de ser um sistema web ou não.
Exercício Faça uma avaliação dos modelos apresentados e monte uma tabela com as fases do processo de DSI nas diferentes abordagens. Referencia: PRESSMAN, Roger S. Engenharia de Software. Trad. José Carlos Barbosa dos Santos. São Paulo: Makron Books, 1995. YOURDON, Edward. Análise Estruturada Moderna. 3ª Ed. Trad. Dalton C. de Alencar. Rio de Janeiro: Campus, 1990. FALBO, Ricardo de Almeida, Engenharia de software: Notas de aula, disponível em: http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-2/notasdeaula.pdf