ANÁLISE E PROJETO DE SISTEMAS PARA WEB II Processos

Transcrição

1 ANÁLISE E PROJETO DE SISTEMAS PARA WEB II Processos

2 PROCESSO DE SOFTWARE Ao falar de processo, no contexto da Engenharia de Software, estamos nos referindo ao processo de desenvolvimento de software. O processo está presente nas etapas iniciais da construção de um software, até o treinamento do usuário final na nova ferramenta. Se refere à metodologia adotada.

3 QUAL O PROCESSO ADEQUADO Existem vários processos que tem a pretenção de serem adequados à construção de software. Mesmo antes da UML, existia um processo não formal, de construção de software, que se resumia ao levantamento de requisitos (necessidades), definição de um modelo (MER) e, finalmente, iniciava-se a codificação.

4 QUAL O PROCESSO ADEQUADO (CONTINUAÇÃO) Todos os processos de construção de software que apareceram foram apresentando problemas no resultado final. Ainda hoje, mesmo os mais decantados processos, apresentam falhas ainda não superadas.

5 QUAL O PROCESSO ADEQUADO (CONTINUAÇÃO) Ernani Medeiros, cita em seu livro, o exemplo de um amigo que aplicou integralmente os conceitos de Gerenciamento de Projetos que haviam sido utilizados anteriormente para a construção de uma usina hidrelétrica e teve diversas decepções. A construção de uma casa pode ser mais simples que a construção de um software.

6 Somos capazes de apontar os motivos, mas não somos tão felizes em apontar as soluções para esta problemática Ernani Medeiros A fórmula secreta da boa construção de software ainda não foi desenvolvida, e isso ocorre em conseqüência da grande quantidade de tecnologia existente.

7 POR QUE A ENGENHARIA DE SOFTWARE NÃO APRESENTA A MESMA CONSTÂNCIA QUE EM OUTRAS ÁREAS? O Grupo Hyunday, na Coréia consegue recordes nos prazos de entrega de grandes navios, não importando onde a encomenda tenha sido feita ou qual o seu tamanho. Nosso primeiro equívoco ocorre no formato da construção: Nada se inicia em termos de construção, antes que a concepção do projeto seja terminada.

8 POR QUE A ENGENHARIA DE SOFTWARE NÃO APRESENTA A MESMA CONSTÂNCIA QUE EM OUTRAS ÁREAS? Na construção civil, tudo é pensado, antes mesmo de um tijolo ser assentado. Tudo é pensado, medido, checado, corrigido, até que os números sejam extremamente precisos. Durante anos tentamos construir software tendo como termo de comparação a construção civil. O problema é que os requisitos de software sofrem mudanças.

9 SEIS ESTÁGIOS DE MUDANÇA DE REQUISITOS DE SOFTWARE NO DECORRER DO DESENVOLVIMENTO, INDEPENDENTE DO TAMANHO DO SOFTWARE.

10 PRIMEIRO ESTÁGIO CONCEPÇÃO A idéia inicial existe em formato nebuloso dentro da mente do interessado. O que ele tem como certo é a sua necessidade A forma de resolver ou atender a essa necessidade não tem um formato definido. Isso ocorre por diversas razões como falta de conhecimento tecnológico ou mesmo aversão inicial à tecnologia.

11 PRIMEIRO ESTÁGIO CONCEPÇÃO Na construção civil, se o engenheiro civil informar que o que pode ser construído é um sobrado de dois andares, com a metragem de área útil de x metros, dificilmente se discutirá sua sentença.

12 SEGUNDO ESTÁGIO APROVAÇÃO DA CONCEPÇÃO É a aprovação de uma idéia abstrata por parte do interessado. A visão que o interessado tem é de alto nível, porém nada palpável existe para a tomada segura de decisão nesse estágio. Além disso, a idéia inicial do interessado muda em relação ao primeiro estágio. Isso é inevitável, pois a idéia nebulosa do primeiro estágio foi, agora, melhorada, com a ajuda de outras pessoas.

13 SEGUNDO ESTÁGIO APROVAÇÃO DA CONCEPÇÃO Na construção civil, quando a planta é mostrada ao interessado, este fala mais à vontade de sua aprovação ou recusa, pelo fato de tratar de assuntos mais concretos. Ele sabe o que é uma parede e um dormitório, então consegue abstrair, com maior fluidez, o resultado final. Muitos resultados indesejáveis, no fututro, são resolvidos nesse estágio (junção de dois dormitórios, por exemplo).

14 TERCEIRO ESTÁGIO DETALHAMENTO COMPLETO DAS NECESSIDADES DO SOFTWARE O detalhamento completo do software desejado é escrito novamente buscando a aprovação do interessado. Nada é construído, apenas as funcionalidades desejadas são escritas. A idéia inicial do interessado se altera. Isso ocorre pelo fato de que o seu nível de abstração melhorou. Normalmente, a própria equipe de construção descobre inconsistências significativas.

15 TERCEIRO ESTÁGIO DETALHAMENTO COMPLETO DAS NECESSIDADES DO SOFTWARE Na construção civil, como o segundo estágio foi baseado em fundamentos bem concretos, esse estágio quase não sofre alterações significativas.

16 QUARTO ESTÁGIO INÍCIO DA CONSTRUÇÃO O início da construção do software se dá com base na aprovação das idéias surgidas no segundo e terceiro estágios. Nesse estágio o interessado vê algo mais concreto na construção de seu software.

17 QUARTO ESTÁGIO INÍCIO DA CONSTRUÇÃO Na construção civil, a idéia inicial do interessado foi concebida e visualizada na planta em que a construção se baseia. Paredes levantadas, desejo alcançado. Alterações no projeto geralmente não são feitas nesse estágio.

18 QUINTO ESTÁGIO CONSTRUÇÃO E TESTES O interessado, nesse momento fica afastado do contato com o software de seu interesse. Tudo o que se necessitava foi conversado e assinado. Ele deverá fazer visita periódica, apenas para avaliar o andamento do projeto x cronograma. O banco de dados escolhido passa por testes com as interfaces gráficas construídas, e muitos códigos de linguagens e funções do banco de dados são escritos.

19 QUINTO ESTÁGIO CONSTRUÇÃO E TESTES No caso de demissão de um programador ou Web designer, ou administrador de dados, os problemas começam a aparecer. Programadores com o mesmo nível de conhecimento e experiência tem visões completamente diferentes sobre como se deve fazer um código.

20 QUINTO ESTÁGIO CONSTRUÇÃO E TESTES Na construção civil, a visita do interessado para avaliar o andamento x cronograma é feita com regularidade. No caso da demissão de um empregado, busca-se outro que tenha a mesma experiência.

21 SEXTO ESTÁGIO ENTREGA A entrega de um software ao seu interessado ocorre com raros estouros de champanha. Devido aos problemas de adaptação de pessoal, tecnologia e política, as datas de entrega foram negociadas com várias protelações. Não é muito raro se ouvir, do principal investidor, na cerimônia de entrega, a seguinte frase: Mas não é nada disso que eu queria! ou Olha, está bom, mas eu gostaria de fazer algumas mudanças!.

22 SEXTO ESTÁGIO ENTREGA Na construção civil, quando uma edificação é terminada, niguém ouve coisa semelhante ao que foi citado no slide anterior. Isso indicaria uma completa imcompetência por parte do engenheiro responsável. Se a planta foi obedecida e existe a intenção de se fazer alterações, é necessário que essa alteração esteja presente na planta, e que tenha novas aprovações no órgão responsável.

23 QUAL O FORMATO CERTO? NÃO existe uma forma de construção de software certa. Ao existir, provavelmente ocupará as primeira página dos principais jornais do mundo!

24 A FORMA DE CONSTRUÇÃO DO SOFTWARE DEPENDE: Do conhecimento do negócio a ser modelado; Do conhecimento da tecnologia a ser utilizada; Da capacidade de abstração do principal interessado no software; Da capacidade de abstração de quem construirá o software; Do volume de dinheiro dedicado à aquisição de banco de dados, ferramentas de desenvolvimento, hardware e terceiros, como provedores de acesso.

25 CONSIDERAÇÕES Alterando-se apenas uma das variáveis citadas no slide anterior, obtém-se um ganho enorme em termos de produtividade. Não podemos comparar a Engenharia de Software com as outras engenharias. Os trabalhos das engenharias naval, elétrica, civil e música existem há séculos, enquanto a Tecnologia da Informação, em especial a Engenharia de Software, existe há poucas dezenas de anos.

26 CONSIDERAÇÕES (CONTINUAÇÃO) A ciência naval tem séculos de tentativas, erros, acertos, e hoje se constroem verdadeiras cidades flutuantes. Existe um padrão e um censo comum de como fazer um barco!

27 CONSIDERAÇÕES (CONTINUAÇÃO) O software se refere à coisas intangíveis, às vezes, inimagináveis. O mesmo não ocorre com as outras ciências citadas. Esse fato alia-se ao desconhecimento dos requerentes de um software, sobre as tecnologias à sua disposição. Assim, conforme o software vai se concretizando, a idéia do interessado se aprimora, ou seja, muda.

28 MODELOS DE PROCESSOS DE SOFTWARE

29 MODELOS DE PROCESSOS DE SOFTWARE É uma representação simplificada e abstrata de um processo de software, apresentada a partir de uma perspectiva específica.

30 EXEMPLOS: Modelo Em Cascata Separa as fases de especificação e desenvolvimento e estas são executadas em sequência. Modelo Espiral Cada loop na espiral pprocesso de software. representa uma fase do Desenvolvimento Baseado em Reuso O sistema é construído com base em componentes existentes

31 MODELO EM CASCATA - ESTÁGIOS Definição e análise dos requisitos Projeto Implementação e teste de unidades Integração e Testes de Sistema Operação e Manutenção

32 MODELO CASCATA ESTÁGIOS: 1. Definição e análise dos requisitos: As funções, as restrições e os objetivos do sistema são estabelecidos por meio da consulta aos usuários do sistema. Em seguida, são definidos em detalhes e servem como a especificação do sistema.

33 MODELO CASCATA ESTÁGIOS: 2. Projeto O projeto de sistemas agrupa os requisitos de sistemas de hardware e software. Estabelece uma arquitetura do sistema geral.

34 MODELO CASCATA ESTÁGIOS: 3. Implementação e teste de unidades Esse estágio compreende um conjunto de programas ou unidades de programa. O teste de unidades envolve verificar que cada unidade atenda a sua especificação.

35 MODELO CASCATA ESTÁGIOS: 4.Integração e teste de sistemas. As unidades de programa ou programas individuais são integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos. Após os testes, os sistema é entregue ao cliente.

36 MODELO CASCATA ESTÁGIOS: 5.Operação e manutenção Esta é a fase mais longa do ciclo de vida A manutenção envolve corrrigir erros que não foram descobertos em estágios anteriores do ciclo de vida, melhorando a implementação das unidades de sistema e aumentando as funções desse sistema.

37 PROBLEMAS DO MODELO EM CASCATA: Divisão inflexível das fases do projeto Dificuldade em reagir às mudanças ao longo do processo Isto dificulta a resposta às alterações de requisitos É apropriado somente quando os requisitos estão bem entendidos.

38 MODELO ESPIRAL Proposto, originalmente por Boehm, em O processo é representado como uma espiral ao invés de uma seqüência de atividades com retrocesso. Cada loop da espiral, representa uma fase do processo Não há fases fixas como especificação ou projeto, os loops são escolhidos dependendo da necessidade

39 MODELO ESPIRAL Os riscos são explicitamente avaliados e resolvidos durante o processo Em vez de representar o processo de software como uma sequência de atividades com retorno de alguma atividade para outra, o processo é representado como um espiral. Cada loop na espiral representa uma fase do processo de software. Cada espiral é dividido em quatro setores:

40 DEFINIÇÃO DOS SETORES 2. Definição de objetivos, alternativas e restrições; 4. Avaliação e redução dos riscos; 6. Desenvolvimento e validação; 8. Planejamento

41 DEFINIÇÃO DOS SETORES 1.Definição de objetivos, alternativas e restrições: São definidos os objetivos específicos, identificadas as restrições para o processo e o produto e é preparado um plano de gerenciamento detalhado.

42 DEFINIÇÃO DOS SETORES (CONTINUAÇÃO) 2.Avaliação e redução dos riscos: Para cada um dos riscos de projeto identificados, é realizada uma análise detalhada e são tomadas providências para reduzir os riscos.

43 DEFINIÇÃO DOS SETORES (CONTINUAÇÃO) 3.Desenvolvimento e validação Depois da avaliação dos riscos, é escolhido um modelo de desenvolvimento para o sistema. Por exemplo, se forem dominantes os riscos relacionados à interface com o usuário, um modelo apropriado seria o modelo por prototipação evolucionária. O modelo cascata poderá ser o modelo de desenvolvimento mais apropriado se o risco principal identificado for a integração de sistemas.

44 DEFINIÇÃO DOS SETORES (CONTINUAÇÃO) 4.Planejamento O projeto é revisto e é tomada uma decisão sobre continuar com o próximo loop da espiral. Se a decisão for continuar, serão traçados os planos para a próxima fase do projeto.