Processo de Desenvolvimento de Software. ETE Timbaúba

Transcrição

1 Processo de Desenvolvimento de Software ETE Timbaúba

2 Saindo do caos Não é raro em ambientes de desenvolvimento que muitos desenvolvedores sejam envolvidos em multiplos projetos simultaneamente. Assim sendo ao mesmo tempo em que um desenvolvedor desenvolve dois softwares, está também corrigindo bugs de outros dois, dificultando desta forma o trabalho do desenvolvedor. As tarefas de desenvolvimento, quer sejam elas de criação de novos softwares ou de manutenção dos softwares existentes, devem ser divididas em projetos e cada projeto deve seguir uma seqüência de execução que garanta a qualidade do software que está sendo gerado.

3 Equipes Envolvidas As seguintes equipes devem ser delineadas e envolvidas no processo de desenvolvimento: Desenvolvimento; Testes; Homologação; Banco de Dados; Suporte; Produção.

4 Divisões do Processo de Desenvolvimento Análise Codificação Testes Implantação Produção

5 Análise A etapa de análise é a etapa na qual se faz o levantamento da necessidade existente e define-se de que forma o software a ser criado deverá solucionar esta necessidade. Em alguns ambientes os desenvolvedores tem o mal costume de pular a etapa de análise passando diretamente a etapa de desenvolvimento. Isso causa frequentemente falhas na definição do software, ou seja, descobre-se após o desenvolvimento que o que foi feito não atende a necessidade existente

6 Divisões da etapa de análise Levantamento de informações Desenho de processo (Use Cases) Modelagem de Dados (MER) Modelagem do sistema (DFD/CLASS/SEQUENCE) Prototipação Definições finais

7 Levantamento de Informações Nesta etapa o analista realiza o levantamento de informações com o usuário. O analista faz uso de muitas entrevistas com o usuário para descobrir as necessidades existentes. O analista deve estar atento as informações fornecidas pelo usuário, cada detalhe mencionado por usuário as vezes pode resultar em mudanças no planejamento que o analista já estava realizando. O analista não deve se confundir quando o usuário tentar indicar como algo deve ser feito fisicamente (estrutura de tabela, tela, programas, etc). O usuário não tem conhecimento técnico para fazer essa indicação, o analista deve extrair do usuário apenas as especificações ligadas ao negócio da empresa. Nem sempre o usuário tem todas as informações que o analista precisa. Muitas vezes o usuário tem uma informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim sendo o analista deve consultar outras pessoas além dos usuários da aplicação.

8 Desenho de Processo O desenho de processo é realizado com os dados colhidos no levantamento de informações. É uma demonstração gráfica da forma de funcionamento do negócio descrito pelo usuário. O desenho de processo é utilizado para apresentar o resultado do levantamento ao usuário. Na verdade as duas etapas são recorrentes, caso o usuário identifique erros no desenho de processo volta-se ao levantamento para acerta-los e assim consecutivamente até que o usuário aprove o desenho de processo.

9 Modelagem de Dados Tendo o desenho de processo sido realizado parte-se para o modelo de dados. A criação do modelo de dados irá novamente se utilizar das informações obtidas durante o levantamento, mas poderá também ter necessidade de novas informações e obrigar o analista a retornar para a etapa de levantamento. O modelo de dados não é tão compreensível para um usuário leigo como o desenho de processo, portanto apresenta-lo ou não ao usuário pode ser uma decisão do analista. O modelo de dados deve ser dividido em lógico e físico, um estando mais próximo das características do negócio enquanto o outro demonstrando características físicas do banco de dados. O analista de sistemas nem sempre é um DBA, portanto o modelo de dados deve ser aprovado pela equipe de administradores de dados. Tendo o modelo de dados sido aprovado gera-se um script 0 do banco de dados, o script inicial deste banco Toda futura alteração do modelo de dados deve ter a aprovação do DBA, que aproveita seu conhecimento das alterações para se preparar para a fase de implantação. As alteração são realizadas na forma de scripts evolutivos do banco de dados de forma a complementarem o script 0. Assim sendo ganha-se uma sequencia histórica de mudanças realizadas no banco de dados.

10 Modelagem do Sistema Feita a modelagem de dados, modela-se o sistema que irá manipular esses dados. Pode-se utilizar DFDs, típicos da análise estruturada, ou diagramas de classe e Sequence, típicos da análise orientada a objetos. Obtem-se como resultado desta etapa descrições gráficas dos módulos que serão gerados no sistema, quer sejam formulários/funções em aplicações estruturadas quer sejam classes/componentes em aplicações orientadas a objeto. Todas as etapas de análise são interligadas. A modelagem do sistema pode afetar todas as etapas anteriores, eventualmente exigindo que o analista retorne ao levantamento. É papel do analista, durante este processo, realizar suposições sobre diversas situações de negócio que porventura o usuário não tenha imaginado, garantindo assim que o sistema funcione de forma flexivel mesmo frente a situações inesperadas.

11 Prototipação Feita a modelagem do sistema parte-se então para a construção do protótipo. O protótipo é um modelo das telas do sistema que tem por inteção obter do usuário a aprovação da navegabilidade do sistema e da forma como suas funcionalidades serão visualmente implementadas.

12 Definições finais Tendo obtido a aprovação do usuário para o desenho de processo e o protótipo a fase de análise encontra-se concluida em sua etapa mais formal. Da fase de análise obtem-se definições sobre como serão as fases seguintes : A partir das definições de análise é possível desenvolver um cronograma de execução A partir do cronograma e das necessidades do usuário é possível prever o pessoal que deverá ser envolvido nas fases seguintes do projeto (qtd. Desenvolvedores) A partir das informações acima é possível fazer uma previsão de custo do projeto e a partir desta informação a diretoria identifica sua real viabilidade.

13 Curiosidades sobre a etapa de análise A etapa de análise na verdade não termina. Mesmo durante as etapas seguintes a análise continua a ocorrer, se aprofundando mais tecnicamente no sistema. Eventualmente descobre-se na etapa de codificação novas características do negócio que alteram definições feitas em análise O analista é, em geral, um gerente de projetos. Após a etapa de análise ele estará gerenciando os desenvolvedores na execução da especificação do sistema. O analista é em geral um ex-desenvolvedor, mas que adquiriu um linguajar de negócios que permite que ele se comunique com os usuário na mesma lingua destes, podendo desta forma extrair informações durante o levantamento. Como ex-desenvolvedor é comum que o analista não esteja 100% atualizado com as tecnologias atuais. Desta forma nem sempre o analista consegue realizar as melhores opções em termos de tecnologia para o projeto e, nos piores casos, o analista chega a ter dificuldade de falar com os desenvolvedores. Neste caso é necessária a presença de um outro personagem, o arquiteto do sistema, que tem por finalidade definir as tecnologias a serem aplicadas para execução do projeto, definir as metodologias de desenvolvimento a serem usadas pelos desenvolvedores e fazer a tradução entre o analista e os desenvolvedores quando necessário. A equipe de suporte deve trabalhar em conjunto do analista ou do arquiteto do projeto na definição física do projeto, iniciando uma especificação de equipamentos que serão necessários ao projeto

14 Divisões do Processo de Desenvolvimento Análise Codificação Testes Implantação Produção

15 Codificação A etapa de codificação envolve o desenvolvimento em si do projeto

16 Ambiente de codificação Os desenvolvedores devem possuir um ambiente apartado no qual tenham total controle de forma a poderem rapidamente resolver problemas nas máquinas. A equipe de suporte deve dar total apoio aos desenvolvedores, tal como em termos de instalação das máquinas, backup e solução rápida de problemas que sejam exclusivamente de infraestrutura. Deve também procurar, junto com o analista, as melhores técnicas de otimização do ambiente de codificação. Deve estar em uso um sistema de controle de versões no ambiente de desenvolvimento, tal como o Microsoft Visual Source Safe

17 Ocorrências comuns no ambiente de codificação Alterações no modelo de dados Devem ser aprovadas pela equipe de banco de dados e deve ser gerado um script evolutivo que será armazenado juntamente com script 0 do banco de dados Alterações no protótipo Devem ser aprovadas pelo usuário Alterações na modelagem do sistema Alterações no desenho do processo Essas duas últimas podem ter impacto médio a grande no desenvolvimento do sistema. É importante verificar se é realmente absolutamente necessário que essas modificações sejam feitas ou se seria possível que essas modificações fossem implementadas apenas em uma versão 2 do sistema. Caso seja absolutamente necessária a realização destas modificações o cronograma do sistema deve ser corrigido com base no impacto destas mudanças. Normalmente mudanças deste porte causam as outras 2, alteração de protótipo e de modelo de dados

18 O trabalho do analista O analista aproveita o período de desenvolvimento, no qual seu trabalho fica mais direcionado à gerencia de projeto, para realizar as seguintes tarefas : Criar um plano de testes para a aplicação Realizar o teste de bancada, teste inicial ainda em ambiente de desenvolvimento, conforme os desenvolvedores terminam cada trecho da aplicação Planejar o teste de stress em conjunto com a equipe de suporte Planejar o processo de implantação da aplicação em conjunto com a equipe de suporte e banco de dados

19 Cronograma e desempenho Uma técnica muito útil para a análise de tempo gasto em desenvolvimento é a análise de pontos de função. Esta análise intenciona quantificar o software que está sendo desenvolvido em pontos de função e identificar a produtividade dos desenvolvedores também em pontos de função/dia. Com isso consegue-se : Identificar os desenvolvedores muito e pouco produtivos Montar cronogramas mais precisos com base na produtividade real dos desenvolvedores Identificar a necessidade de mais desenvolvedores para cumprir um determinado prazo Identificar mais precisamente os custos do projeto A análise de ponto de função é muito detalhista e normalmente demanda tempo na etapa de análise, por isso é muito comum as empresas criarem pequenas adaptações desta análise conforme a arquitetura utilizada.

20 Divisões do Processo de Desenvolvimento Análise Codificação Testes Implantação Produção

21 Testes Os testes se dividem em 5 tipos : Teste de bancada Teste de qualidade Teste de Stress Teste de Segurança Homologação Destes 5 tipos apenas o teste de bancada é realizado em ambiente de desenvolvimento, em geral pelo próprio analista conforme comentado anteriormente. Os demais testes são realizados em um ambiente denominado ambiente de qualidade.

22 Ambiente de Qualidade O ambiente de qualidade é um ambiente o mais similar possível ao ambiente de produção da empresa. Este ambiente é utilizado para a realização de testes de qualidade na aplicação Raramente, porém, é possível ter um ambiente de qualidade realmente identico ao de produção. Cabe à equipe de suporte juntamente com o analista/arquiteto do sistema realizar um relatório de riscos relativo a passagem da aplicação para produção, ou seja, o risco de mesmo depois dos testes em qualidade a passagem para produção não funcionar devido a diferença entre qualidade e produção

23 Montagem do ambiente de qualidade A montagem do ambiente de qualidade é, de fato, um teste : Testa-se o passo-a-passo de instalação do sistema, garantindo que o processo de instalação funcionará quando for executado em ambiente de produção

24 Teste de Qualidade O teste de qualidade é, de todos, o teste mais detalhado do sistema. É realizado por testers, profissionais especializados na realização de testes da aplicação. Os testers podem fazer uso do plano de testes criado pelo analista, mas não se prendem a ele. O objetivo principal dos testers é fazer o que é chamado de monkey test : Fazer exatamente o contrário do que a aplicação pede em cada tela e verificar como a aplicação reage. Desta forma obtem-se a garantia de que a aplicação funcionará mesmo perante os piores tipos de usuário existentes. Os testers em geral são desenvolvedores, mas não precisam ser tão especializados como os próprios desenvolvedores do projeto. Em alguns casos podem ser outra equipe de desenvolvimento da própria empresa, mas não devem ser os mesmos desenvolvedores do projeto, pois por mais que tentem os desenvolvedores do projeto sempre fazem testes para fazer a aplicação funcionar, ao contrário de testers que devem fazer a aplicação dar erro Há um trabalho circular entre os testers e o processo de codificação. Os testers devem gerar um relatório de volta para o processo de codificação, gerando uma re-implantação da aplicação em qualidade e novo teste até o momento em que os testers não identifiquem nenhum erro

25 Teste de Stress O teste de stress tem por objetivo testar a aplicação em condições de uso muito maciço, verificando como o hardware e o software respondem em ambiente simulado. O teste envolve tanto o analista/arquiteto, responsável por especificar a simulação de teste, como a equipe de banco, responsável pela análise da resposta do servidor de banco ao teste como a equipe de suporte, responsável pela análise da resposta do hardware e do sistema operacional.

26 Teste de Segurança Em geral é realizado por uma equipe externa de hackers contratados especialmente para testar a segurança do sistema, este teste tem se tornado comum nas atuais arquiteturas de desenvolvimento para web.

27 Homologação É o teste realizado pelos usuários finais, que podem ou não seguir o plano de testes preparado pelo analista O processo de homologação pode gerar um trabalho circular com a etapa de codificação, assim como ocorreu com o teste de qualidade, mas é mais improvável que o processo de homologação encontre muitas falhas no sistema O usuário vai, como sempre, pedir modificações no sistema. Porém o analista deve ser cuidadoso de direcionar as modificações solicitadas pelo usuário para a próxima versão do sistema. Ao final da homologação o usuário dá sua aprovação final para o sistema

28 Divisões do Processo de Desenvolvimento Análise Codificação Testes Implantação Produção

29 Implantação Não existe uma regra específica para o processo de implantação, mas o analista, a equipe de suporte e a de banco de dados devem estar em conjunto solucionando os seguintes problemas : Treinamento para os usuários Trabalho em paralelo com aplicações existentes quando necessário Migração de dados de bancos de dados existentes quando necessário Observe que tanto o analista, como a equipe de suporte e a equipe de banco de dados devem ter trabalhado deste o término da etapa de análise no planejamento do processo de implantação. Desta forma o trabalho neste etapa torna-se bem planejado e organizado, menos sujeito a falhas

30 Divisões do Processo de Desenvolvimento Análise Codificação Testes Implantação Produção

31 Produção A partir da implantação da aplicação entra em cena a equipe de produção, que algumas vezes é um sub-conjunto da equipe de suporte. Eis algumas tarefas da equipe de produção : Fornecer suporte ao uso da aplicação Inspecionar logs de eventos gerados pela aplicação identificando possíveis problemas em produção Montar uma linha base de performance para a aplicação Conhecer as características da aplicação de forma a poder auxiliar a equipe de suporte no planejamento do remanejamento da aplicação em relação aos servidores da empresa. Apontar para a equipe de desenvolvimento problemas de performance na aplicação

32 Possíveis rupturas no processo Mesmo muito bem organizado da forma como aqui foi descrita, podem ocorrer rupturas nesse processo de desenvolvimento que causarão problemas de custo e cronograma : Excesso de alterações na especificação durante a etapa de codificação Excesso de erros em homologação ou produção Dificuldade na comunicação entre o analista e os desenvolvedores Cronogramas imprecisos

33 Excesso de alterações na especificação durante a codificação Isso pode ser causado por uma inicial inexperiência de um analista. Deve-se registrar este fato como um índice qualitativo do processo de desenvolvimento e o analista deve utilizar cada ocorrência para aperfeiçoar-se, reduzindo este valor a cada projeto realizado

34 Excesso de erros em homologação ou produção Isso ocorre por inexperiência dos testers, responsáveis por identificar os erros da aplicação. Da mesma forma que o item anterior, isso deve ser registrado como um fator qualitativo do processo e os testers devem utilizar cada ocorrência para aperfeiçoar-se e reduzir este valor

35 Dificuldade na comunicação entre o analista e os desenvolvedores Uma das rupturas mais críticas, quando o analista, por estar muito envolvido com o negócio, passa a ter dificuldade de se comunicar com o desenvolvedor e suas especificações se tornam mais distantes do ambiente físico da codificação. Neste caso torna-se necessária a utilização de um arquiteto de sistemas como intermediário entre o analista e o desenvolvedor. Deve-se tomar muito cuidado na escolha de quem irá realizar esse papel, pois a pessoa deve ser capaz de utilizar a linguagem de negócio e traduzi-la para os desenvolvedores, tendo liberdade de requisitar alterações nas especificações quando estas estiverem por demais distantes do ambiente físico. Essa pessoa deve estar altamente atualizada para definir as melhores tecnologias para cada projeto.

36 Cronogramas imprecisos Isso normalmente reflete uma inexperiência do analista na especificação do tempo para desenvolvimento. Neste ponto duas coisas devem ocorrer : O analista deve usar as falhas de cronograma para aperfeiçoar-se em termos de calculo de duração de um projeto Deve-se aperfeiçoar a aplicação da técnica de análise de pontos de função de forma a depender o mínimo possível do instinto do analista

37 Dúvidas? ETE - Timbaúba