Tipos e Níveis de Processo PDF

Tipos e níveis de processo DISCIPLINA: PROCESSOS DE SOFTWARE Objetivos Apresentar uma metodologia do processo de software Apresentar os tipos e níveis de abstração de processo essenciais para a definição de processos...

Tipos e níveis de processo DISCIPLINA: PROCESSOS DE SOFTWARE Objetivos Apresentar uma metodologia do processo de software Apresentar os tipos e níveis de abstração de processo essenciais para a definição de processos 2  Representação esquemá1ca de um processo de so4ware (PRESSMAN, 2011) Processo de Software Processo de Software Um conjunto de atividades de trabalho, ações e tarefas realizadas quando algum artefato de software deve ser criado Fonte: Pressman 3 Processo de Software Metodologia do processo Metodologia de processo Identifica um conjunto de atividades estruturais aplicáveis a todos os projetos de software, independentemente de tamanho ou complexidade Cada uma das atividades, ações e tarefas alocam-se dentro de uma metodologia ou modelo que determina seu relacionamento com o processo e seu relacionamento uma com as outras Fonte: Pressman 4 Processo de Software Metodologia do processo Atividades de apoio Atividade A"vidademetodológica de Apoio 1 nº1 ação de Engenharia de Software nº1.1 tarefas de trabalho Atividades de apoio Conjunto artefatos de software de tarefas Fatores de garantia da qualidade Ponto de controle do projeto Aplicadas ao longo do progresso, E.g., atividades como o ação de Engenharia de Software nº1.k acompanhamento e controle do tarefas de trabalho projeto, a administração de riscos, Conjunto artefatos de software de tarefas Fatores de garantia da qualidade a garantida qualidade, o Ponto de controle do projeto gerenciamento de configurações, as revisões técnicas, etc. Atividade metodológica nºn A"vidade de Apoio 2 Fonte: Pressman 11 Processo de Software Metodologia do processo Atividades de apoio Atividade metodológica nº 1 ação de Engenharia de Software nº1.1 tarefas de trabalho Atividades metodológicas Conjunto artefatos de software de tarefas Fatores de garantia da qualidade Ponto de controle do projeto São compostas de um conjunto de ações de ES ação de Engenharia de Software nº1.k Cada ação é definida por um Conjunto tarefas de trabalho artefatos de software conjunto de tarefas, o qual de tarefas Fatores de garantia da qualidade identifica tarefas, artefatos, Ponto de controle do projeto fatores de garantia de qualidade exigidos e os marcos utilizados para indicar o Atividade metodológica nº n progresso Fonte: Pressman 5 Processo de Software Metodologia do processo Atividades de apoio Atividade metodológica nº1 Uma metodologia ação de Engenharia de Software nº1.1 do processo de tarefas de trabalho Conjunto de tarefas artefatos de software Fatores de garantia da qualidade software Ponto de controle do projeto ação de Engenharia de Software nº1.k tarefas de trabalho Conjunto artefatos de software de tarefas Fatores de garantia da qualidade Ponto de controle do projeto Atividade metodológica nº n Fonte: Pressman 12 Uma metodologia de processo genérica estabelece 5 atividades metodológicas de software Comunicação Planejamento Modelagem Construção Entrega 6  Importante Essas cinco a)vidades metodológicas genéricas podem ser u)lizadas para: – o desenvolvimento de programas pequenos e simples; – para a criação de grandes aplicações para a Internet; e – para a engenharia de grandes e complexos sistemas baseados em computador. Os detalhes do processo de so:ware serão bem diferentes em cada um dos casos, mas as a)vidades metodológicas permanecerão as mesmas. Atividades metodológicas básicas Comunicação Comunicar-se e colaborar com o cliente (e outros interessados) para o levantamento das necessidades que ajudarão a definir as funções e características do software Planejamento Ajuda a guiar a equipe É conduzida através do plano de projeto de software que define o trabalho de ES, descrevendo as tarefas técnicas a ser conduzidas, os riscos, os recursos e os produtos resultantes a ser produzidos e um cronograma 7 Atividades metodológicas básicas Modelagem Criação de modelos para melhor entender as necessidades do software e o projeto que irá atender a essas necessidades Construção Combina geração de código e testes necessários para revelar erros na codificação Entrega O software (ou incremento) é entregue ao cliente, que avalia o produto entregue e fornece feedback baseado na avaliação 8  Importante Além disso, um conjunto de a2vidades de apoio (umbrela ac2vi2es) são aplicadas ao longo do processo; – Ajudando a equipe a gerenciar, a controlar o progresso, a qualidade, as mudanças e o risco. Atividades de apoio típicas Controle e acompanhamento do projeto Permite que a equipe avalie o progresso do projeto e tome as medidas necessárias para cumprir o cronograma Administração de riscos Avalia os riscos que possam afetar o resultado ou a qualidade do produto/projeto Garantia da qualidade de software Define e conduz as atividades que garantem a qualidade do software Revisões técnicas Avaliam os artefatos da ES, com o objetivo de identificar erros antes que se propaguem para a atividade seguinte 9 Atividades de apoio típicas Medição Define e coleta medidas do processo, do projeto e do produto Gerenciamento da configuração de software Gerencia os efeitos das mudanças ao longo do processo Gerenciamento de reusabilidade Define critérios para o reúso de artefatos e estabelece mecanismos para a obtenção de componentes reutilizáveis 10 Fluxo de processo Descreve como são organizadas as atividades metodológicas, em como as ações e tarefas que ocorrem dentro de cada atividade em relação a sequência e ao tempo Pode ser Linear Iterativo Evolucionário Paralelo 13 Fluxo de processo Linear Comunicação Planejamento Modelagem Construção Entrega 14 Fluxo de processo Iterativo Comunicação Planejamento Modelagem Construção Entrega 15 Fluxo de processo Evolucionário Planejamento Comunicação Modelagem Construção Liberado por Entrega incremento Fluxo de processo Paralelo Comunicação Planejamento Tempo Modelagem Entrega Construção 17  Definindo a*vidades metodológicas Apesar de termos descrito 5 a2vidades metodológicas, um 2me de desenvolvimento necessita de muito mais informações antes de poder executar apropriadamente qualquer uma dessas a2vidades como parte do processo de soCware; Então, desenvolvedores chegam a uma questão: Quais ações são apropriadas para uma a0vidade metodológica, dado um problema do mundo real? Exemplo: Exemplo  Iden%ficação de um conjunto de tarefas: A iden)ficação de tarefas a serem executadas é uma tarefa par)cular para cada projeto; Cada a)vidade de Eng. So:ware (ex: elicitação) pode ser representada por um conjunto diferente de a)vidades; O Analista deve escolher um conjunto de tarefas que melhor acomode as necessidades do projeto de acordo com as caracterís)cas do seu )me de desenvolvedores; Isso implica dizer que ações de Eng. So:ware podem ser adaptadas para necessidades especiais do projeto de so:ware e do )me de desenvolvimento.  Padrões de Processo Toda equipe de desenvolvimento encontra problemas à medida que avança no processo de so6ware; Seria ú;l se soluções comprovadas es;vessem prontamente à disposição da equipe, de modo que os problemas pudessem ser localizados e resolvidos rapidamente; Um padrão de processo descreve um problema de processo encontrado durante o trabalho de engenharia de so6ware, iden;ficando o ambiente onde foi encontrado e sugerindo uma ou mais soluções comprovadas para o problema.  Padrões de Processo Um padrão de processo fornece um modelo (template), um método consistente para descrever soluções de problemas no contexto do processo de so4ware; Combinando padrões, uma equipe conseguirá solucionar problemas e elaborar um processo que melhor atenda às necessidades de um projeto. Padrões podem ser definidos em qualquer nível de abstração. Outra representação do mesmo Exemplo... (PRESSMAN, 2011)  Avaliação e melhora de processos: A existência do processo de so:ware não garante sua qualidade, pontualidade de entrega e que ele atende às necessidades do cliente por um longo tempo; Os processos, por eles mesmos, podem ser avaliados para garan)r que ele corresponde a um conjunto básico de critérios para a Engenharia de So:ware bem sucedida Níveis de abstração Processos padrão Refere-se a um processo genérico institucionalizado em uma organização, estabelecendo requisitos básicos para processos serem executados nessa organização Processos de projeto Referem-se a processos definidos para projetos específicos, considerando as particularidades desses projetos 18 Níveis de abstração Processos de software (padrão ou de projeto) podem ser definidos adaptando-se um processo padrão A partir do Processo Padrão, diferentes processos de software podem ser especializados de acordo com Características dos tipos de software produzidos na organização, e.g., sistemas especialistas, sistemas de informação e sistemas de controle de processos, e dos Paradigmas de desenvolvimento adotados , e.g., orientado a objetos e estruturado 19 Níveis de abstração (cont.) Processo padrão adaptado Todos os ativos de processo definidos para o processo padrão tornam-se parte do processo especializado Processo especializado Novos ativos podem ser incluídos para tratar um tipo de software, paradigma ou domínio de aplicação específico 20 Níveis de abstração (cont.) Processo especializado definido É composto de ativos do processo padrão e novos ativos podem ser incluídos Processo de projeto considerando características do projeto, como complexidade, tamanho, experiência da equipe, expectativa de vida útil, características de qualidade desejadas, etc. 21 Tipos de processo e níveis de abstração 23 Fonte: Bertollo  Importante O processo de so*ware deve ser adaptável ao problema, ao projeto, à equipe e à cultura organizacional. Pode ser muito diferente daquele adotado para outro. Diferenças: – fluxo geral de aDvidades, ações e tarefas e suas interdependências; – grau pelo qual ações e tarefas são definidas dentro de cada aDvidade da metodologia; – grau pelo qual artefatos de so*ware são idenDficados e exigidos; – modo de aplicar as aDvidades de garanDa de qualidade; – modo de aplicar as aDvidades de acompanhamento e controle do projeto; – grau geral de detalhamento e rigor da descrição do processo; – grau de envolvimento com o projeto (por parte do cliente e de outros interessados); – nível de autonomia dada à equipe de so*ware; – grau de prescrição da organização da equipe. A*vidade Ler o Capítulo 2: Modelos de Processo. Livro de Engenharia de So:ware: Uma abordagem gerencial – Roger S. Pressman. Referências bibliográficas PRESSMAN, Roger S. Engenharia de software - Uma abordagem profissional. 7. ed. São Paulo: Makron Books, 2011. ISBN: 9788563308337 BERTOLLO, G. 2006. Definição de Processo em um ambiente de desenvolvimento de software. Dissertação de mestrado. Departamento de Informática, Centro Tecnológico, Universidade Federal do Espírito Santo (UFES), Vitória - ES, Brasil. VILELLA, K.; SANTOS, G.; MONTONI, M.; et al. 2004. “Definição de Processos em Ambientes de Desenvolvimento de Software Orientados a Organização”. In III Simpósio Brasileiro de Qualidade de Software, pp 22-37, Brasília, Brasil. 24