Processos e ambientes Conceitos básicos

Transcrição

1 Processos e ambientes Conceitos básicos Arndt von Staa Departamento de Informática PUC-Rio Fevereiro 2014 Especificação Objetivo apresentar os conceitos básicos envolvendo processos e ambientes de engenharia de software Justificativa a terminologia de engenharia de software é muito fluida. Um mesmo termo tem várias acepções dependendo do autor. torna-se necessário estabelecer uma terminologia padrão para este curso 2 1

2 Software O que é Software? não é produto é uma das formas de armazenar conhecimento, em ordem cronológica: 1. DNA 2. Cérebro memes um DNA cultural 3. Ferramentas / artefatos 4. Escrita / livros 5. Software Armour, P.G.; The Laws of Software Process: A New Model for the Production and Management of Software; New York: Taylor & Francis; 2003; Chapter 1: The Nature of Software and the Laws of Software Process 3 Software O que é software? segunda visão é muito mais do que somente código especificação de requisitos para que, o que, como (qualidade) arquitetura design de alto nível de abstração design código scripts de teste scripts de recompilação, integração, controle de versão,... subsistema de manutenção documentação para a equipe de manutenção documentação, auxílio, tutoriais, para o usuário documentação para fins de auditorias material de propaganda... precisa continuamente formar um todo coerente 4 2

3 Sistema intensivo em software Software não é fim em si, é meio para alcançar algo é sempre parte de um sistema maior sempre depende de outros elementos plataforma: hardware, sistema operacional papéis desempenhados por pessoas... possui interfaces através das quais se comunica com outros sistemas elementos com que interfaceia podem ser pessoas sensores atuadores outros sistemas... Foco de interesse Processo da organização 1 Processo da organização 2 Usuário Resultados Controles e dados Outros artefatos Artefato Consequência Interação com outros artefatos Dados persistentes Outras organizações Bases de dados 5 Artefato (work product) Artefato é um resultado de uma atividade Um artefato é tangível e aceito segundo algum critério de qualidade, exemplos: documento revisto e aceito módulo implementado, testado e aceito construto (build) integrado, testado e aceito código fonte, script de teste, script de make (ou ant, maven, hudson), documentado, possui ambiente de manutenção e teste framework documentado, implementado, testado e aceito Artefatos correspondem a algum arquivo possivelmente contido em algum sistema de controle de versão Quando entregue ao usuário (cliente) o artefato é um produto mas se software é conhecimento, pode ser produto? 6 3

4 Artefato Possui qualidade assegurada precisa satisfazer a sua especificação requisitos funcionais requisitos de interface com usuário usualmente esses eram parte de requisitos não funcionais mas usuário e software fazem parte do sistema maior sistemas podem falhar se o usuário falha» o usuário pode falhar por deficiência da interface do usuário» o usuário pode falhar por não saber usar o sistema requisitos não funcionais requisitos inversos outros: contratos, restrições legais, restrições da empresa,... 7 Artefato Possui qualidade assegurada, exemplos critérios de aceitação como será controlada a qualidade para poder aceitar o artefato expectativas do usuário (desejos, anseios) software é desenvolvido para ser usado por alguém ou alguma coisa exemplos de possíveis usuários (interessados stakeholders) usuário pessoa» usuário propriamente dito pessoal de suporte outro sistema ou artefato sistemas controlados por software» ex. grid elétrica, telefonia, máquinas, robôs desenvolvedores mantenedores controladores da qualidade adquiridores (clientes) 8 4

5 Artefato É um conceito recursivo um artefato pode ser composto por outros artefatos próprios do projeto em questão (work product) de outros projetos (insumos) Sistema X Material de divulgação Documentação para usuário Documentação técnica Ambiente de desenvolvimento Código Instalação Requisitos Fontes Executável Manual de uso Arquitetura 9 Perguntas Quantos sistemas, componentes, bibliotecas, módulos, etc. satisfazem essa definição de artefato? Por que sim? Por que não? Existe software infalível? Por que sim? Por que não? 10 5

6 Tarefa Tarefa é uma ação desempenhada por alguma pessoa visando algum desenvolvimento, monitoramento, ação complementar, ou ação pessoal corresponde a trabalho a ser realizado Pode ser: única ex: redigir o código de um determinado módulo ex: produzir diagrama de classes de um componente recorrente ex: preencher folhas de tempo ex: realizar backup complementar ou pessoal vinculada ou não ao projeto ex: estudar, ir ao banco, participar de reunião 11 Tarefa Tarefas não necessariamente produzem resultados controlados, logo: ter concluído uma tarefa não representa uma evidência de progresso no desenvolvimento ter trabalhado 20 horas não implica ter produzido um artefato aceitável, mesmo que se tenha estimado serem necessárias menos de 20 horas para o seu desenvolvimento Tarefas sempre consomem tempo e podem ser recorrentes quebradas em vários períodos 12 6

7 Tarefa Tarefas consomem recursos consumo real, não o que foi planejado considerando todos os recursos esforço tempo de pessoa, homem hora equipamento financeiro ambiente e outros recursos de infra-estrutura energia 13 Atividade Atividade é um conjunto de tarefas que levam a um ou mais artefatos (de qualidade controlada pleonasmo...) a conclusão de uma atividade representa uma evidência de progresso no desenvolvimento os artefatos resultantes existem, possuem a qualidade requerida e podem ser usados o controle da qualidade do resultado num extremo pode ser a mera constatação de que o resultado existe no outro extremo pode envolver técnicas muito avançadas de controle da qualidade, ex. prova da corretude o esforço e o consumo de recursos é medido através das tarefas constituintes 14 7

8 Atividades Atividades são mini-projetos produzem artefatos segundo uma especificação formalmente definida, embora indesejável, algumas vezes informal ou intuitiva (tácita) necessitam de insumos outros artefatos do desenvolvimento ou externos devem seguir métodos, práticas definidas, padrões,... têm início e fim definidos não são recorrentes consomem um volume finito de recursos os artefatos são aceitos segundo critérios de aceitação estabelecidos o controle da qualidade (aceitação) dos artefatos produzidos indica se a atividade foi ou não concluída a contento 15 Composição de atividades Atividades podem conter diversas tarefas: ex: Atividade desenvolver um módulo: faz mesmo parte do desenvolvimento de um módulo? redigir a especificação da interface do módulo (módulo de definição) revisar a especificação da interface redigir os casos de teste (test driven development) revisar os casos de teste redigir o código do módulo de teste redigir o código do módulo de instrumentação redigir os módulos dublê (imitação, enchimento, simulação, fictício) redigir o código do módulo revisar o código do módulo realizar os testes diagnosticar as falhas realizar as ações corretivas integrar o módulo testado com os demais módulos aceitos testar o construto diagnosticar as falhas realizar as ações corretivas registrar o módulo aceito no repositório de artefatos concluídos 16 8

9 Atividades Atividade é um conceito recursivo atividades são realizadas possivelmente por outras atividades e/ou tarefas nós estruturais da árvore WBS (work breakdown structure) desenvolver um sistema inteiro é, em última análise, uma atividade atividades atômicas são realizadas somente por tarefas nós folha da árvore WBS 17 Atividades O conjunto de atividades forma uma estrutura acíclica WBS - work break-down structure (diagrama de Gantt) PERT (program evaluation and review technique) - grafo acíclico estabelecendo as precedências, durações e recursos alocados às atividades Processo Workflow O fragmento de modelo em BPMN (Business Process Modeling Notation) abaixo descreve uma atividade? Wikepedia:

10 Exemplo de work breakdown structure parcial Desenvolver o componente servidor de objetos persistidos estabelecer o contexto de integração especificar componentes do servidor de objetos persistidos especificar servidor de páginas especificar processador de listas persistentes especificar acesso indexado a elementos de listas desenvolver elementos do servidor de registros desenvolver servidor de páginas desenvolver módulo de acesso a arquivos locais desenvolver módulo de acesso a arquivos remotos desenvolver módulo de acesso a páginas desenvolver processador de listas persistentes desenvolver acesso indexado a elementos de listas aprovar a implementação do servidor de registros Ou seria uma atividade? Arquitetar componente servidor de objetos persistidos 19 Diagrama PERT neste diagrama falta a indicação de tempo necessário estimado e recursos por atividade a Especificar módulo grafo Especificar ambiente b Arquitetar Estabelecer ambiente d Desenvolver vértices Desenvolver precedências Produzir documentação e f Testar vértices Testar precedências Verificar documentação h Controle final i c g 20 10

11 Exemplo de atividade genérica Atividade: Elaborar casos de teste para casos de uso Condição de entrada formulário caso de uso verificado, validado e aprovado Condição de saída cenários, suítes (casos de teste) visando o caso de uso verificados, validados e aprovados Descrição Elaborar cenários e as correspondentes suítes de teste visando o escopo e a iteração ou release (liberação) corrente do caso de uso. Os casos de teste devem ser derivados dos formulários casos de uso e valorados segundo o critério condições de contorno. Papéis envolvidos Gerente de Testes; Testador; Especificador Artefatos de Entrada: Plano de teste, Especificações, Arquitetura, Formulários caso de uso Artefatos de Saída: Cenários, Suítes de teste Tarefas: Faz parte da especificação da atividade, ou faz parte do plano de teste de módulos específicos? Entender a especificação. Entender a arquitetura e as especificações dos casos de uso. Especificar a instrumentação a ser incorporada ao código. Valorar os casos de teste. Gerar os scripts de teste visando a ferramenta de teste automatizado a ser utilizada. Descrever e documentar cenários e suítes de teste. Verificar, validar e aprovar esses artefatos. 21 Exemplo de unidade de processo 22 11

12 Objetivo de processos Processos de software visam organizar o trabalho de modo que o desenvolvimento de software se dê: com prazos e necessidade de recursos definidos e realistas com elevada produtividade, ou melhor, de forma econômica com qualidade assegurada produzindo resultados de valor para clientes e usuários 23 Processos Processos estabelecem sequencias de atividades atividades são especificadas por meio de práticas os insumos necessários para poder iniciar cada atividade os artefatos resultantes de cada atividade as pré e pós-condições de cada atividade critérios de partida qualidade requerida dos insumos os critérios de controle da qualidade dos artefatos resultantes critérios de aceitação 24 12

13 Processo de desenvolvimento de software Software é conhecimento processos adquirem o correspondente conhecimento conhecimento sobre o serviço do software conhecimento sobre a engenharia do software É pouco provável que se consiga adquirir perfeitamente todo o conhecimento necessário antes de prosseguir que não existam conflitos de interesse ou restrições de implementação Logo, o processo de desenvolvimento usualmente requer negociação para mitigar os conflitos conflitos podem ser observados durante o desenvolvimento precisa refazer artefatos em virtude de alterações solicitadas ou impostas em virtude de problemas encontrados retrabalho inútil? útil? ou nenhum dos dois? 25 Processos Processos estabelecem sequências de atividades os instrumentos a serem utilizados para realizar a atividade linguagens de representação diretrizes, padrões, normas ferramentas os papéis a serem desempenhados pelas pessoas que realizarão cada atividade a proficiência necessária para desempenhar cada papel 26 13

14 Estrutura de especificação de processos modelo de processo Meta-processo padrão Tecnologia a ser utilizada Natureza da aplicação adição da tecnologia e das características do ambiente a utilizar Estabelecer ambiente Processo definido Especificação de requisitos Recursos disponíveis adição das características do artefato e dos recursos a utilizar Ambiente de desenvolvimento Plano de desenvolvimento execução segundo o plano Insumos Desenvolvimento disciplinado Artefatos 27 Estrutura de especificação de processos Meta-processos (modelos de processos) são instanciados para classes de projetos gerando o processo definido domínio do problema necessidades específicas dos sistemas (aplicações) a desenvolver domínio da solução seleção da tecnologia de suporte a ser utilizada ambiente (ferramentas, procedimentos) de suporte Processos definidos são instanciados visando o projeto específico esta instanciação é o plano de desenvolvimento pode complementar ou adaptar a tecnologia 28 14

15 Meta-processos (modelos de processos) Meta-processos definem a composição a ser satisfeita pelos processos definidos reduzem o risco de processos definidos estarem incompletos ou inconsistentes conduzem à criação de ativos de processos ativos de processos são elementos de processos que podem ser reutilizados em diversos projetos aumentam a chance de reúso de planos e artefatos 29 Meta-processos (modelos de processos) Existem vários padrões de meta-processos (modelos de processo) dirigidos por planos: CMMI, SW-CMM, MPS.BR SecureSE-CMM, ITService-CMM, Trillium ITIL ISO/IEC (SPICE) TSP - Team Software Process PSP - Personal Software Process Existem vários padrões de meta-processos ágeis: XP - Extreme Programming Existem vários padrões de meta-processos de gestão ágil: Scrum Kanban Lean (enxuto)

16 Meta-processos Meta-processos são particionados em várias áreas de processo (áreas chave de processo). Exemplos gerência de requisitos gerência de configuração verificação e validação... Cada área de processo pode ser entendia como um subprocesso que agrega um conjunto de práticas afins com as metas que caracterizam a área de processo. 31 Processo definido Processo definido estabelece uma organização padrão para planos de projetos em um determinado domínio de problema e de solução papéis responsabilidades ferramentas sub-processos... reduzem o risco do estabelecimento de planos irrealistas ou incompletos reduzem o esforço para produzir planos realistas e completos estabelecem diretrizes e padrões a serem seguidos estabelecem critérios para a medição visando acompanhar a execução de um plano de forma objetiva avaliar a eficácia e eficiência do processo definido 32 16

17 Plano Plano é o resultado da instanciação de um processo definido visando um produto (sistema, componente) específico estabelece como será realizado este desenvolvimento identifica atividades insumos e resultados específicos associa recursos reais às atividades pessoas equipamentos ferramentas tempo, início e fim de cada atividade, dimensão do trabalho financeiros estabelece um cronograma de realização do projeto permite a estimativa do esforço e custo do restante do projeto permite o acompanhamento da execução do projeto 33 Risco básico dos processos Risco: Cargo cult software engineering copiar (macaquear?) sem saber se traz ou não benefícios ou mesmo se faz ou não sentido qual é mesmo o benefício de se utilizar determinado modelo de processo? O que importa em última análise é a competência (proficiência) da equipe e a adequação (harmonia) do ambiente e não a adoção cega de um processo, independentemente de se este foi bem organizado ou não. Organizações incompetentes praticam cargo cult software engineering Cargo cult é a crença de que seguir um determinado ritual asseguradamente trará benefícios materiais é uma forma de imitação sem entender o que está por trás do que está sendo imitado e/ou sem uma devida avaliação crítica McConnell, S.; Cargo Cult Software Engineering ; from the Editor; IEEE Software 17(2); Los Alamitos, CA: IEEE Computer Society; 2000; pags

18 AMBIENTES 35 Objetivo dos ambientes de ES Ambientes de engenharia de software visam aumentar significativamente a produtividade a qualidade assegurada baratear o desenvolvimento acelerar o tempo de desenvolvimento (time to market) Destinam-se ao desenvolvimento sistemático de software de qualidade assegurada Processos definidos têm o mesmo objetivo

19 Processos e ambientes Processos definidos e ambientes são fortemente interdependentes os ambientes estabelecem o domínio de solução utilizado pelo processo quando for introduzida, alterada ou removida uma ferramenta o processo definido precisa ser ajustado ambientes precisam ser estabelecidos para adequadamente apoiar processos definidos estar em conformidade com meta-processos processos definidos são institucionalizados com vistas a domínios de aplicação específicos Institucionalizar: disponibilizar, implantar e tornar de uso corriqueiro por toda a organização Uso corriqueiro: usado sempre, continuando em uso, mesmo em momentos de stress, ex. prazo curto demais 37 EXEMPLOS 38 19

20 Desenvolvimento incremental Caracterização Desenvolve um pouco alguma coisa (construto) que dê para ser utilizada mesmo que somente para fins de avaliação adicionando o mínimo de funcionalidade segundo XP e SCRUM, adicionando a funcionalidade que é considerada mais relevante quando do início do incremento. Controla a qualidade do que existe, registrando todos os problemas identificados falhas erros de especificação riscos potenciais solicitações de novos desenvolvimentos solicitações de evolução Corrige os problemas relevantes do momento Parte para um novo incremento 39 Desenvolvimento incremental Codificação Teste de módulos Projeto (projeto detalhado) Teste de integração Concepção Arquitetura (projeto conceitual) Construto 1 Construto 2 Teste de aceitação Especificação e evolução de requisitos Construto 3 Construto 4 Refatoração, melhorias 40 20

21 Desenvolvimento incremental Benefícios esperados: a redução dos riscos técnico e financeiro uma significativa redução do retrabalho inútil problemas existentes nos artefatos desenvolvidos até o momento são resolvidos antes de se propagarem para artefatos ainda não desenvolvidos problemas podem decorrer de erros de especificação ou design um significativo aumento de produtividade decorrente da redução do retrabalho inútil a disponibilização frequente de versões úteis com funcionalidade crescente asseguram satisfação do usuário visibilidade do desenvolvimento redução do stress ao desenvolver 41 Desenvolvimento + manutenção Repositório de versões Manutenção Solicitações exógenas Desenvolvimento Disponibilização Registros de demandas Teste contínuo Falhas Avaliação ao usar Melhorias, Falhas Novas necessidades Scripts de integração e teste 42 21

22 Passo de desenvolvimento Histórico de alterações Critérios e padrões de controle da qualidade Histórico de alterações Artefatos antecedentes Especificação Criação Alteração Artefato conseqüente Artefato Laudo Controle da qualidade Laudo FAP Gerência da evolução FAP FAP : ficha de acompanhamento de problema Outro artefato FAP Avaliação externa 43 Acompanhamento de pendências (issues) Início aprovada Em solução emergencial não aprovada modelo parcial Aguardando análise protelada falha grave Aguardando solução emergencial dados insuficientes Aguardando informação Em análise autorizada Aguardando solução suspensa Sendo resolvida concluída Aguradando aprovação Aguardando informação dados insuficientes não aprovada recusada Sendo controlada cancelada já resolvida recusada não aceita aprovada Fim aceita Sendo implantada Aguradando implantação Staa, A.v.; Acompanhamento de Projetos; Monografias em Ciência da Computação MCC13/03; Rio de Janeiro; Departamento de Informática; PUC-Rio; 2003; 44 22

23 Acompanhamento de pendências Razões para pendências: erros ao especificar > remover falha observada erros ao desenvolver > remover falha observada mudanças de especificação mudanças de plataforma mudanças no contexto externo desenvolvimento por versões sucessivas desenvolvimento incremental... Pendência (issue) é a designação coletiva para relatórios de falhas, solicitações de melhoria, solicitações de evolução, solicitações de desenvolvimento original. 45 Controle de versão simples Criação Registro de artefatos Artefatos simples Artefato não controlado Item de configuração Repositório de versões Registrar artefato Armazenar artefato Check-in Trabalho concluído Aceito Tipo artefato Criar artefato Não aceito Controlar artefato Área trabalho Item de configuração Artefato não controlado Check-out Item de configuração Alterar artefato Editar artefato Alteração autorizada 46 23

24 Trabalho em equipe Repositório local GIT Repositório de integração Criar Manter Área trabalho OK Sincronizar Check-in Registros de demandas Repositório local mutuamente exclusivo Não OK OK Revisão final Criar Manter Área trabalho OK Integrar Área integração Repositório local OK Notificar Testar integração Criar Manter Área trabalho equipe ou ferramenta 47 Aceitação de liberação (release) Repositório de integração Sincronizar Repositório de homologação Gerar distribuição Sincronizar OK Registros de demandas Não OK Área homologação Cópia de distribuição ferramentas Testar aceitação Usuário / Product Owner 48 24

25 Perguntas? 49 25