Engenharia de Software Processo de Desenvolvimento António Rito Silva Rito.Silva@inesc-id.pt Sumário Caracterização Objectivos Problemas Qualidades Técnicas Avaliação e Validação Exemplo Conclusões Processo de Desenvolvimento 2 Objectivos Definir o processo de desenvolvimento como uma série de etapas envolvendo actividades, restrições e recursos, que produzem um produto. Pretende-se impor coerência e estrutura às actividades de desenvolvimento de software O ciclo de vida do produto de software é o seu processo de construção usando um processo de desenvolvimento Problemas O desenvolvimento de software é difícil de gerir dado que é necessário controlar muitas variáveis: Estrutura organizacional da empresa Necessidades dos clientes Competências da equipa Tecnologia a usar... Pelo que não existe um processo de desenvolvimento universalmente aplicável Processo de Desenvolvimento 3 Processo de Desenvolvimento 4
Qualidades Compreensível a definição do processo é explícita e facilmente comunicável Aceitação o processo é aceite e usável pela equipa de desenvolvimento Visibilidade as actividades do processo têm resultados visíveis Retroalimentação o processo promove a retroalimentação com os clientes e utilizadores Qualidades Rastreabilidade é possível relacionar os produtos intermédios de acordo com a sua geração Fiabilidade o processo promove a detecção precoce de erros Evolução o processo pode ser alterado como consequência de variações das variáveis Suporte as actividades do processo são suportadas por ferramentas Processo de Desenvolvimento 5 Processo de Desenvolvimento 6 Técnicas Caracterização do Processo Etapas Actividades Produtos Modelos de Processo Cascata Prototipagem Especificação Operacional Faseado Espiral Etapas do Processo As etapas do processo estabelecem os pontos onde devem ser tomadas decisões importantes de gestão de projecto Uma etapa do projecto agrega diversas actividades do processo no âmbito dum objectivo O fim de cada etapa é denominado de marco (milestone) do projecto Processo de Desenvolvimento 7 Processo de Desenvolvimento 8
Actividades do Processo Corresponde ao menor pequeno grão trabalho da equipa de desenvolvimento, e.g., implementar uma funcionalidade Usa recursos e produz produtos intermédios e finais Cada actividade tem critérios de entrada e saída bem definidos As actividades são organizadas do ponto de vista temporal Produtos do Processo São o resultado das actividades do processo Constituem uma representação do software que está a ser desenvolvido Alguns dos produtos mais comuns são: Modelos de requisitos Arquitectura de software Desenho do programa Implementação Modelo de testes Processo de Desenvolvimento 9 Processo de Desenvolvimento 10 Produtos do Processo Modelos de requisitos Descrevem o problema para cuja solução se deve construir um programa Explícita as necessidades dos utilizadores e clientes Arquitectura de Software Define a estrutura geral da solução relacionandoa com o problema A arquitectura de software explícita o compromisso que a solução estabelece entre os requisitos, frequentemente contraditórios, do problema Produtos do Processo Desenho do programa Define a estrutura detalhada da solução Explícita as entidades da implementação: interfaces, estruturas de dados, algoritmos,... Implementação Constitui o produto final Modelo de Testes Define os testes que devem ser feitos para validar a solução em função dos requisitos Explícita como se valida que o programa cumpre as especificações Processo de Desenvolvimento 11 Processo de Desenvolvimento 12
Modelo de Processo Define os objectivos do desenvolvimento, como seja detectar faltas cedo, obter programas de alta qualidade, ou respeitar o orçamento Cada equipa de desenvolvimento deve escolher o modelo que mais se enquadra com os seus objectivos A equipa deve adaptar o modelo às suas necessidades criando assim o seu próprio processo de desenvolvimento Tipos de Modelo de Processo Cascata Prototipagem Especificação Operacional Desenvolvimento Faseado Espiral Processo de Desenvolvimento 13 Processo de Desenvolvimento 14 ANÁLISE DE REQUISITOS DESENHO DE SISTEMA Cascata DESENHO DO PROGRAMA PROGRAMAÇÃO TESTES OPERAÇÃO E MANUTENÇÃO Positivo: Cascata O modelo é simples, associando as etapas à construção de produtos Esta associação facilita as tarefas de gestão Negativo: Mas, não reflecte a forma como se constróem os programas pois ignora a iteração necessária quando há alterações de requisitos ou numa etapa se identificam problemas nos produtos construídos nas fases anteriores Processo de Desenvolvimento 15 Processo de Desenvolvimento 16
REQUISITOS DO SISTEMA (informais e incompletos) ENTREGA DO SISTEMA Prototipagem PROTÓTIPO DOS REQUISITOS PROTÓTIPO DO DESENHO PROTÓTIPO DO SISTEMA TESTES alterar protótipo revisão utilizador/ cliente LISTA DE ALTERAÇÕES LISTA DE ALTERAÇÕES LISTA DE ALTERAÇÕES Prototipagem As etapas estão associadas a produtos executáveis (protótipos) Dá ênfase à qualidade de retroalimentação do processo com vista a um desenvolvimento rápido com os utilizadores e clientes, através do desenvolvimento de protótipos para avaliar da sua satisfação com as soluções de desenho, através de protótipos que avaliam as diferentes alternativas de desenho Processo de Desenvolvimento 17 Processo de Desenvolvimento 18 Positivo: Prototipagem Retroalimentação rápida Negativo: Fraca visibilidade que dificulta a gestão Fraca estruturação dos sistemas Requer recursos humanos de grande competência Especificação Operacional REQUISITOS DO SISTEMA (informais e incompletos) ESPECIFICAÇÃO OPERACIONAL (baseada-problema) ESPECIFICAÇÃO TRANSFORMADA (implementação) EXECUTAR E REVER TESTES ENTREGA DO SISTEMA Processo de Desenvolvimento 19 Processo de Desenvolvimento 20
Especificação Operacional Positivo: A retroalimentação centra-se numa única etapa próxima do nível de abstracção do espaço do problema O impacto das alterações de requisitos é analisado rapidamente Negativo: Aplicável apenas se é possível inferir do modelo de requisitos qual vai ser o comportamento do sistema pois o modelo de requisitos já possui a semântica que vai existir no produto final Desenvolvimento Faseado Reduz o ciclo de desenvolvimento através da entrega em partes Existem dois sistemas em simultâneo sistema operacional sistema em desenvolvimento Construção Distribuição 1 Sistemas operacionais Construção Distribuição 2 Utilização Distribuição 1 Sistemas em desenvolvimento Utilização Distribuição 2 Tempo Processo de Desenvolvimento 21 Processo de Desenvolvimento 22 Desenvolvimento Faseado A construção das distribuições pode seguir duas estratégias: Desenvolvimento incremental em que os produtos associados a cada distribuição são construídos por incrementos de funcionalidade Desenvolvimento iterativo em que as distribuições possuem toda a funcionalidade sendo feitas iterações sobre funcionalidades existentes Normalmente a construção das distribuições utiliza uma combinação de desenvolvimento incremental e iterativo Desenvolvimento Faseado Positivo: O treino e familiarização dos utilizadores pode ocorrer logo na primeira distribuição A experimentação com cada distribuição pode motivar os clientes e utilizadores para a definição de novas funcionalidades A equipa de desenvolvimento pode focar em diferentes tipos de saber conforme as distribuições Negativo: Pode tornar-se caótico O desenho da solução pode degradar-se Processo de Desenvolvimento 23 Processo de Desenvolvimento 24
DETERMINAR OBJECTIVOS, ALTERNATIVAS, RESTRIÇÕES PLANIFICAÇÃO Plano de requisitos Plano de ciclo de vida Plano de desenvolvimento Plano de integração e teste Espiral Análise de Risco 4 Análise de Risco 3 Análise de Risco 2 Análise de Risco 1 Protótipo 1 Conceito de operação Validação de requisitos Teste de aceitação AVALIAR ALTERNATIVAS E RISCOS Protótipo 2 Validação de desenho Teste de sistema Requisitos de software Protótipo 3 Desenho de software Teste de módulo Protótipo 4 Desenho detalhado Programação DESENVOLVIMENTO E TESTE Espiral O modelo espiral combina as actividades do processo com a gestão do risco para maximizar o sucesso Cada etapa do processo tem 4 fases: Determinar Objectivos objectivos, restrições e alternativas da etapa Avaliar Riscos análise de riscos e controlo dos riscos Desenvolvimento e Teste de acordo com o modelo de desenvolvimento que mais se ajuste Planificação decisão sobre se continuar e plano da próxima etapa Processo de Desenvolvimento 25 Processo de Desenvolvimento 26 Positivo: Espiral Adaptável em função da análise de riscos A manutenção pode ser considerada como mais um ciclo do processo Negativo: Não pode ser aplicado a projectos que têm de terminar devido a um contrato com o cliente Não se pode aplicar a projectos de pequena dimensão sob pena da análise de riscos ser demasiado dispendiosa Avaliação e Validação Análise póstuma Para avaliar o nosso processo deve ser recolhida informação durante o desenvolvimento e depois do projecto terminar A análise póstuma é uma avaliação de todos os aspectos do projecto, incluindo os produtos, processos e recursos, para identificar as áreas que podem ser melhoradas Processo de Desenvolvimento 27 Processo de Desenvolvimento 28
Avaliação Póstuma 1. Desenhar e promover um levantamento retrospectivo para recolher dados sem comprometer a confidencialidade 2. Recolher informação objectiva sobre o projecto que foque nos custos, calendarização e qualidade 3. Organizar uma reunião para recolher informação que o levantamento retrospectivo ignorou 4. Organizar um dia de história do projecto para rever os acontecimentos e dados do projecto e identificar a causa dos problemas ocorridos durante o projecto 5. Publicar os resultados focando nas lições aprendidas CMM O Modelo de Maturidade de Capacidades (CMM) define 5 níveis de maturidade Os níveis de maturidade são atribuídos de acordo com as respostas dadas a um conjunto 110 de perguntas O modelo é usado de duas formas: Os clientes potenciais avaliam a qualidade dos seus fornecedores A equipa de desenvolvimento avalia as suas capacidades e definem como estas podem ser melhoradas Processo de Desenvolvimento 29 Processo de Desenvolvimento 30 Nível 1: Iniciação Nível 2: Repetição Níveis CMM Nível 3: Definição Nível 4: Gestão Nível 5: Optimização Nível Iniciação Descreve um processo de desenvolvimento que é ad hoc ou mesmo caótico As entradas do processo não estão definidas Os resultados esperados não estão definidos A produtividade e qualidade de projectos semelhantes é muito variável Processo de Desenvolvimento 31 Processo de Desenvolvimento 32
Nível Repetição Entradas, saídas, recursos e controlo do processo estão identificados Apenas as entidades abaixo podem ser medidas para fins de gestão Entradas Controlo Construir o Sistema Recursos Saídas Nível Definição As actividades de gestão e de engenharia encontram-se documentadas, normalizadas e integradas definindo um procedimento normalizado a toda a organização A organização adapta o processo normalizado aos casos concretos Dado que o processo se encontra definido é possível medir os produtos internos e avaliar da sua qualidade e das relações de qualidade entre os diferentes produtos, e.g., a qualidade dos requisitos pode ser usada para predizer acerca da qualidade do código Processo de Desenvolvimento 33 Processo de Desenvolvimento 34 Nível Gestão A retroalimentação determina como os recursos são afectados As medidas deste nível reflectem as características do processo como um todo A gestão usa uma base de dados de métricas fornece informação acerca das características de produtividade, faltas, etc Nível Optimização Retroalimentação quantitativa é incorporada no processo para melhorar continuamente o processo Difere do nível Gestão pois possibilita a alteração dinâmica da estrutura do processo e desta forma da própria organização Processo de Desenvolvimento 35 Processo de Desenvolvimento 36
Disciplina de processo Definição de processo Nível 1: Iniciação Controlo de processo Nível 2: Repetição Níveis CMM Aperfeiçoamento contínuo de processo Nível 3: Definição Gestão de projecto Nível 4: Gestão Gestão de engenharia Nível 5: Optimização Gestão quantitativa Gestão da alteração Exemplo Sistema de Suporte e Gestão às Páginas de uma Disciplina da LEIC Funcionalidades do Discente Ver página Inscrição de aluno Inscrição de grupo... Funcionalidades do Docente Criar e modificar página Inscrição de alunos Definição das características dos grupos... Processo de Desenvolvimento 37 Processo de Desenvolvimento 38 Fluxos de Engenharia Modelação do Negócio Requisitos Análise e Desenho Implementação Teste Instalação Fluxos de Suporte Gestão de Configurações Gestão de Projecto Modelo Unificado Definição Iterações preliminares Elaboração 1 Etapas 2 Construção n Iterações n+1 n+2 Transição m Tempo m+1 Etapas Caracterização Determinam num marco que disponibiliza um conjunto de artefactos Pontos de decisão de gestão Fluxos de Trabalho Engenharia actividades de construção de modelos Suporte actividades de gestão Iterações Mini-projectos que aumentam as funcionalidades do produto Processo de Desenvolvimento 39 Processo de Desenvolvimento 40
Etapas Definição estabelece a visão do produto final e do seu caso de negócio Elaboração estabelece uma arquitectura base da solução Construção o produto é efectivamente construído por enchimento da arquitectura Transição o produto é entregue aos clientes e utilizadores Fluxos de Trabalho Os fluxos de trabalho de engenharia constróem os seguintes produtos: Modelo de casos de uso Modelo de análise Modelo de desenho Modelo de implementação (código) Modelo de testes Processo de Desenvolvimento 41 Processo de Desenvolvimento 42 Iterações Reduzem o risco pois se a iteração falha apenas essa iteração tem de ser repetida Reduzem o risco pois os problemas são identificados mais cedo Aumentam a produtividade pois os resultados são rapidamente visíveis Aumentam a retroalimentação com os clientes pois os resultados são visíveis rapidamente Conclusões P14 Construir sistemas incrementalmente Diminui o risco associado a cada versão Ver uma versão ajuda os utilizadores a perceberem que outras funcionalidades necessitam Contudo, se for escolhida a arquitectura errada pode ser necessário um redesenho completo. Para reduzir este risco deve-se construir inicialmente alguns protótipos descartáveis Processo de Desenvolvimento 43 Processo de Desenvolvimento 44
Conclusões P16 Alterações durante o desenvolvimento são inevitáveis Todos os artefactos devem possuir referências cruzadas para permitir a rastreabilidade Procedimentos de gestão devem considerar a possibilidade de alterações inesperadas Orçamentos e planeamento devem ser suficientemente flexíveis de modo a não se ignorar as alterações para cumprir orçamentos e prazos Conclusões P21 Linguagens diferentes para diferentes etapas Uma abordagem unificadora, e redutora, para complexidade do processo de desenvolvimento, que use a mesma notação ao longo de todo o processo ainda não é viável Para cada uma etapas do processo de desenvolvimento escolher as técnicas e linguagens que mais se adaptam Processo de Desenvolvimento 45 Processo de Desenvolvimento 46 Conclusões P22 Técnicas antes das ferramentas Antes de se usar uma ferramenta deve-se possuir uma disciplina sobre o seu uso Inicialmente deve-se seguir uma técnica sem o apoio de ferramentas de modo a verificar que é útil e antes de investir em ferramentas que automatizem a técnica Se uma técnica não funciona sem automatização de certeza que não funciona com automatização Conclusões P26 Saber quando é tão importante como saber como Saber como usar uma técnica bem não a torna numa boa técnica nem nos torna em bons engenheiros O bom engenheiro sabe como usar diversas técnicas e, mais importante, sabe quando usar cada uma delas Processo de Desenvolvimento 47 Processo de Desenvolvimento 48
Conclusões P27 Parar assim que se atinge o objectivo Evitar ficar de tal forma envolvido pelo método que se está a utilizar que se esquece o objectivo Se, por exemplo, se entende qual o problema a resolver após metade dos passo do método a isso destinados, então não é necessário continuar com os restantes passos Conclusões P28 Conhecer métodos formais Os métodos formais podem ajudar a descobrir problemas escondidos Os métodos formais não devem ser usados para especificar um sistema completamente mas sim para ajudar nas partes mais complicadas onde a utilização de uma linguagem natural dificulta a clarificação Utilizar diferentes métodos formais consoante as necessidades Processo de Desenvolvimento 49 Processo de Desenvolvimento 50 Conclusões P172 Fazer a análise póstuma do projecto No fim do projecto os intervenientes devem ter 3 a 4 dias de análise sobre os problemas que ocorreram Usar a metodologia definida atrás Referências Pfleeger98, Capítulo 2. 1,2,7,8,9 Pfleeger98, Capítulo 11. 5 Jacobson99, Capítulo 1 David95 Processo de Desenvolvimento 51 Processo de Desenvolvimento 52