Métodos Ageis

A metodologia ágil é combinação de valores e princípios. Ela se desenvolveu em um esforço de sanar fraquezas dos métodos convencionais  de engenharia de software. A insatisfação com abordagens pesadas em projetos pequenos e médios motivou um numero de programadores a iniciar a metodologia.

No mercado moderno atual é quase impossível prever como um sistema computacional irá evoluir. As condições mudam rapidamente, as necessidades de usuários se alteram e novas ameaças competitivas emergem sem aviso. Dessa forma, os métodos ágeis contam com uma abordagem iterativa para especificação, desenvolvimento e entrega de software. A metologia procura uma aproximação maior com o cliente, onde é feito pequenas entregas do sistema para que o cliente possa o quanto antes ter posse do seu sistema. Uma estrategia atrelada a um feedback que propicia um alinhamento maior entre o que o cliente pediu e o que foi entregue.

As metodologias ágeis possuem princípios que seguem a maioria de suas especificações, Sommerville (2007) descreve alguns.

• Envolvimento do Cliente

Os clientes devem estar envolvidos com o desenvolvimento do sistema. Provendo informações para construção dos requisitos e dando feedback sobre o que já foi criado.

• Entrega Incremental

O software é desenvolvido em incrementos e o cliente especifica os requisitos a serem incluídos.

• Pessoas, não processos

As habilidades da equipe devem ser exploradas.

• Aceite Mudanças

Aceitar as mudanças de requisitos que irão ocorrer.

• Simplicidade

Trabalhe ativamente para eliminar a complexidade do sistema.

Referências:

PRESSMAN, R.S. Engenharia de Software. 7ª Edição. Rio de Janeiro: McGraw-Hill, 2011

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Métodos Ágeis - XP

A Extreme Programming, ou simplesmente XP, é uma metodologia de software ágil, foi criada nos Estados Unidos por Kent Beck em 1997. Sua abordagem abusa do desenvolvimento iterativo e conta com uma aproximação do cliente com o projeto. Nele todos os requisitos são descritos em histórias, que são implementados como tarefas. O desenvolvimento das tarefas é realizadas em pares e antes da codificação das mesmas é criado testes.

O XP é formado fundamentalmente por princípios e valores, são características que moldam o desenvolvimento de software sobre o escopo dessa metodologia. São ao todo cinco valores e quatorze princípios. Vejamos cada um a seguir.

Valores do XP

• Comunicação

O XP prima pela comunicação ativa entre os clientes e a equipe de desenvolvimento, com o intuito de reduzir requisitos equivocados e assim construir um software mais próximo do que o cliente espera. Além disso o XP prioriza uma comunicação presencial com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreender da melhor maneira possível.

• Coragem

No XP acredita-se que o erro vai acontecer, o diferencial seria como tratar a ocorrência do mesmo. Assim, impedir mudanças e frear a criatividade do cliente não são consideradas no XP. Nessa metodologia a equipe deve se adaptar as modificações e está confiantes nos mecanismos do XP.

• Feedback

Os desenvolvedores procuram entregar as tarefas o mais rápido possível, para que assim o cliente possa usufruir das funcionalidades e prover informações a respeito delas.

• Respeito

Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.

• Simplicidade

Nesse aspecto a equipe XP se concentra, primeiramente, em desenvolver as tarefas essências para o funcionamento do sistema, evitando desenvolver funcionalidades que talvez nunca cheguem a ser utilizadas.

Princípios

1. Auto-semelhança: Soluções que funcionem em diferentes contextos
2. Benefício Mútuo: Estrutura que proporciona benefícios para as diferentes partes do projeto
3. Diversidade: Equipes com profissionais de varias áreas, arquiteto, designer, programadores etc. 
4. Economia: Priorizar módulos que gerem receita mais rápido e controle de gastos no desenvolvimento
5. Falha: Testar soluções sem medo de falhas.
6. Fluidez: O objetivo é fazer com que o sistema seja desenvolvido de forma evolutiva e vá crescendo em funcionalidades a cada nova iteração.
7. Humanismo: Compreender a natureza humana para que possamos potencializar o que ela tem de melhor e suprimir o que tem de pior
8. Melhoria: Aprimoramento continuo do software.
9. Oportunidade: Enxergar problemas como oportunidades.
10. Passos de Bebê: Realizar pequenas modificações por vez.
11. Qualidade: Desenvolver visando a melhor qualidade possível
12. Redundância: Os problemas críticos devem ser resolvidos com varias soluções
13. Reflexão: A equipe analisa seu processo durante a construção do software, discutindo falhas e acertos.
14. Responsabilidade Aceita: A responsabilidade não deve ser atribuída, ela deve ser aceita.

Referencia:

EXTREME PROGRAMMING Disponível em:<http://www.desenvolvimentoagil.com.br/xp/> Acessado em 30 de Outubro de 2016.

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Information Technology Infrastructure Library (ITIL)

É uma biblioteca de gerenciamento de TI criada pelo governo britânico. Na sua criação foi levado em consideração a experiência de organizações públicas e privadas, atualmente está disponibilizado na versão 3.0.

O ITIL é dividido em torno de ciclo de vida do serviço e possui cinco volumes:

• Estratégia do Serviço: Definição dos requisitos e necessidades do negócio
• Projeto de Serviço: Definição da solução a ser adotada
• Transição de Serviço: Relacionado ao gerenciamento de mudanças
• Operação do Serviço: Assegura que os serviços estão sendo atendidos baseado nos SLAs
• Melhoria Contínua do Serviço: Manter a constante melhoria dos serviços baseando-se no ciclo PDCA.

Dentre os principais benefícios do uso do modelo ITIL V3 podemos mencionar:

• Alinhamento de TI, seus serviços e riscos com as necessidades do negócio
• Níveis de Serviço (SLA) negociáveis
• Processos consistentes e previsíveis
• Eficiência na entrega de serviço
• Serviços e Processos mensuráveis e passíveis de melhorias
• Otimização da experiência do cliente
• Uma linguagem comum

Catálogo

O Catálogo de Serviço traz uma visão clara de quais serviços a TI oferece e como a TI agrega valor para os recursos financeiros alocados. Ele oferece um método para requisitar ou pedir os serviços publicados. O Catálogo de Serviço viabiliza a boa governança em que os principais termos, condições e controles definidos nele estejam integrados aos processos de prestação de serviço da organização. Ele permite que a organização melhore o planejamento, a entrega e o suporte aos serviços, enquanto avalia de forma correta os custos e preços do serviço.

O “Catálogo de Serviços”, como definido na diretriz Service Delivery da ITIL, é uma lista de serviços que uma organização oferece, em geral, para os funcionários e clientes. Normalmente, cada serviço dentro do catálogo inclui:

• Uma descrição do serviço;
• Cronogramas ou acordo de nível de serviço para a finalização do serviço;
• Quem tem direito de solicitar/ver o serviço;
• Custos (se houver);
• Como realizar o serviço.

Referências:

O QUE É ITIL Disponível em:<http://www.mundoitil.com.br/> Acessado em 30 de Outubro de 2016.

Catálogo de Serviço Disponível em:<http://www.apmg-international.com/br/qualificação/catálogo-serviço/catálogo-serviço.aspx/> Acessado em 30 de Outubro de 2016.

Rational Unified Process (RUP)

O RUP é um processo proprietário criado pela Rational Software Corporation, e posteriormente adquirido pela IBM, para gerenciar de maneira eficiente as diversas ações no processo de software, para isso o RUP adota três premissas básicas:

• Uso de iterações para evitar o impacto no projeto
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

A estrutura do RUP é dividido em 4 fases e 8 disciplinas, como mostrado na figura abaixo.

Fig. 1: Esquema de Iterações

Sua distribuição apresenta duas dimensões bem definidas:

• Eixo X -Tempo: divisão do ciclo de vida em fases e iterações, mostra os aspectos do ciclo de vida do processo à medida que se desenvolve.

• Eixo Y - Componentes de processo: produção de um conjunto específico de artefatos (produtos) com atividades bem definidas.

Cada fase tem um conjunto bem definido de objetivos e pode conter uma ou mais iterações, são elas:

• Iniciação - entendimento da necessidade e visão do projeto,
• Elaboração - especificação e abordagem dos pontos de maior risco,
• Construção - desenvolvimento principal do sistema,
• Transição - ajustes, implantação e transferência de propriedade do sistema.

Agrupamento lógico dos elementos do processo (atividades, artefatos e papéis). Corresponde às disciplinas essenciais do processo.

• Modelagem do negócio - Descreve o negócio através de casos de uso de negócio.
• Requisitos - Narrativa da visão do sistema. Descrição das funções do sistema.
• Análise e Projeto - Descrição de como o sistema será realizado na etapa de implementação.
• Implementação - Produção do código que resultará em um sistema executável.
• Testes - Verificar a integração entre todos os componentes de software, identificar e corrigir erros de implementação.
• Gestão de projetos - Especifica um conjunto de princípios a aplicar na gestão de projetos a nível de alocação de recursos, planejamento, identificação e gestão de riscos, etc.
• Gestão de configuração e mudança - Controla as mudanças e mantém a integridade dos artefatos do projeto.
• Definição do ambiente - Cobre a infra-estrutura necessária para desenvolver um sistema (seleção de ferramentas, definição das regras de negócio, interface, testes, etc.).

Referência:

Conheça o Rational Unified Process (RUP) Disponível em:<http://www.linhadecodigo.com.br/artigo/79/conheca-o-rational-unified-process-rup.aspx> Acessado em 30 de Outubro de 2016.

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figura 1

Risk reduction with the RUP phase plan Disponível em:<http://www.ibm.com/developerworks/rational/library/1826.html> Acessado em 30 de Outubro de 2016.

Processo de Software - Interação

No processo iterativo várias fases do sistema é desenvolvido de forma conjunta. Com o intuito de se adequar mais rapidamente a mudanças, o sistema é desenvolvido com a presença ativa do usuário. Alguns modelos fazem uso de iteração mais efetivamente, dos quais temos:

• Incremental

É identificado os serviços mais importantes e os menos importantes. Com a quantidade de incrementos definida, o sistema é desenvolvido com os serviços de maior prioridade sendo entregues primeiro. Portanto, o cliente tem acesso a funcionalidades do sistema antes mesmo deste ser finalizado.

Fig. 1: Modelo Incremental

• Desenvolvimento em Espiral

No modelo em espiral cada fase do processo é descrita como um loop. Cada loop está dividido em quatro setores: Definição de objetivos, Avaliação e redução de risco, Desenvolvimento e validação e Planejamento.

Fig. 2: Modelo espiral

Referências

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figura 1

Modelos Incremental, Espiral e de Prototipação. Disponível em: <http://engenhariadesoftwareuesb.blogspot.com.br/2012/12/blog-post.html> Acessado em 30 de Outubro de 2016.

Figura 2

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Processo de Software - Modelos

Os modelos de software são descrições do processo de software, no qual possuem uma estrutura genérica. Embora não sejam respostas definitivas de processo são uteis para exemplificar abstrações diferentes no desenvolvimento de software. Sommerville (2007), discuti quatro destes modelos:

Modelo em cascata

Consiste do princípio que as etapas avançam  conforme sua aprovação. Portanto, a fase seguinte não deve ser iniciado antes que atual esteja terminada.

Fig. 1: Esquema de processo em cascata

Modelo Evolucionário

O desenvolvimento evolucionário baseia-se na proposta de mudança constante do projeto, expondo o resultado ao cliente e refinando as versões até que seja desenvolvido um sistema adequado.

Fig. 2: Esquema de Processo Evolucionário

Desenvolvimento Formal de Sistema

Nessa modelo é utilizado uma especificação formal matemática, onde a verificação dos componentes seguem uma argumentação matemática para demonstrar que os componentes atendem sua especificação.

Fig. 3: Desenvolvimento Formal

Desenvolvimento Orientado a Reuso

Nessa abordagem os componentes possuem uma característica de reutilização. O processo de software se concentra na integração desses componentes, ao contrario de desenvolver um sistema do zero.

Referências:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figuras 1,2 e 3:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Processo de Software - Introdução

O processo de software é um conjunto de atividade que leva a produção de um produto de software. Não existe um processo ideal de desenvolvimento, mas sim várias abordagens diferentes que atendem necessidades especificas. Suas atividades principais se mantêm semelhantes:

• Especificação de Software.

A especificação de software é a fase do processo na qual é identificado os requisitos do sistema. Esta atividade é realizada juntamente com os stakeholders do sistema, problemas nessa fazem possuem um custo elevado de manutenção pois afetam todas as fases seguintes do processo.

• Projeto e Implementação.

Processo no qual é desenvolvido a aplicação propriamente dita. O projeto de software é uma descrição dos componentes do sistema, sendo eles: interface, algoritmo e arquitetura.

• Validação de Software.

A validação destina-se a verificar se o sistema estar em conformidade com o que foi prometido. A verificação ocorre em todo processo de software, desde a definição de requisitos até o desenvolvimento do sistema. Os testes são feitos em três etapas, sendo elas:

1. Teste de Componente – Os componentes são testados individualmente, eles podem ser entidades simples como classes ou grupos de entidades.
2. Teste de Sistema – Os componentes são testados quando integrados. É feito uma varredura para detectar erros de interação não prevista ou erros de interface.
3. Teste de Aceitação – O sistema é testado com os dados fornecidos pelo cliente. O teste exercita o sistema de maneira diferente e pode expor erros não identificados anteriormente.

• Evolução de Software.

A evolução de software trata do potencial de escalabilidade do sistema. Em um processo no qual o desenvolvimento e a manutenção se tornam cada vez mais irrelevante.

Processo de software deve ser aprimorado e padronizado conforme a cultura da empresa, não existe um processo ideal. A padronização e aprimoramento desses processos produzem uma serie de melhorias para a empresa, entre elas, o aprimoramento da comunicação e a redução do tempo de treinamento. Além disso o processo é um passo inicial para introdução de novos métodos de engenharia de software.

Referência:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Os 47 Processos do Guia do PMBok 5ª Edição

Após ter sido apresentados às mudanças ocorridas no do Guia PMBOK 5a edição, iremos agora analisar sucintamente o que acontece em cada processo. 

INTEGRAÇÃO

4.1 Desenvolver Termo de Abertura

      • Processo de desenvolver o documento que formalmente autoriza o projeto ou fase.

4.2 Desenvolver Plano de Gerenciamento do Projeto

     •Processo de documentar as ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares.

4.3 Dirigir e Gerenciar a Execução

     • Processo de executar o trabalho definido no Plano de Gerenciamento do Projeto.

4.4 Monitorar e Controlar o Trabalho

     • Processo de monitorar e controlar o progresso do projeto de acordo com o Plano.

4.5 Realizar Controle Integrado de Mudanças

     • Processo de revisar, aprovar e controlar solicitações de mudança, bem como manter atualizados os documentos do projeto.

4.6 Encerrar Projeto ou Fase

     • Processo de finalizar todas as atividades e encerrar formalmente o projeto ou fase.

ESCOPO

5.1 Planejar Gerenciamento do Escopo

     •Processo de planejar como o escopo será definido, validado e controlado.

5.2 Coletar Requisitos

  • Processo de definir e documentar os requisitos necessários para atender necessidades e expectativas de interessados.

5.3 Definir Escopo

     • Processo de desenvolver uma descrição detalhada do projeto e do produto.

5.4 Criar EAP – Estrutura Analítica do Projeto

     • Estrutura Analítica do Projeto é uma subdivisão hierárquica orientada a entregas. Criar a EAP envolve definir as entregas principais e seus componentes, bem como todo o trabalho do projeto.

5.5 Validar Escopo

     • Processo de formalizar a aceitação das entregas do projeto.

5.6 Controlar Escopo

     • Processo de monitorar e controlar o escopo do projeto.

TEMPO

6.1 Planejar Gerenciamento do Tempo

     • Processo planejar como será definido, gerenciado e controlado o cronograma do projeto.

6.2 Definir Atividades

     • Processo de identificar atividades específicas que precisam ser realizadas para produzir as entregas do projeto.

6.3 Definir Sequência de Atividades

     • Processo de identificar e documentar dependências entre as atividades do cronograma.

6.4 Estimar Recursos das Atividades

     • Processo de estimar tipo e das quantidades de recursos necessários para realizar cada atividade do cronograma.

6.5 Estimar Durações das Atividades

     • Processo de estimar o número de períodos de trabalho necessários para realização das tarefas.

6.6 Desenvolver Cronograma

     • Processo de analisar os recursos necessários, restrições do cronograma, durações e sequências de atividades para criar o cronograma do projeto

6.7 Controlar Cronograma

     • Processo de monitorar e controlar o progresso do projeto e a performance de execução do cronograma, tomando medidas corretivas quando necessário.

CUSTO

7.1 Planejar Gerenciamento dos Custos

     • Processo planejar como será definido, gerenciado e controlado o orçamento do projeto.

7.2 Estimar Custos

     • Processo de estimar os custos dos recursos necessários para a execução das atividades.

7.3 Determinar Orçamento

     • Processo de agregar custos estimados de atividades individuais ou pacotes de trabalho para determinar o orçamento do projeto.

7.4 Controlar Custos

     • Processo de monitorar e controlar o progresso do projeto e a performance de execução do orçamento, tomando medidas corretivas quando necessário.

QUALIDADE

8.1 Planejar Gerenciamento da Qualidade

     • Processo de identificar padrões, normas ou requisitos de qualidade do projeto e produto, e documentar como o projeto demonstrará concordância.

8.2 Realizar Garantia de Qualidade

     • Processo de auditar requisitos de qualidade e os resultados das medições de controle de qualidade para assegurar que os padrões apropriados de qualidade estão sendo observados.

8.3 Controlar Qualidade

     • Processo de monitorar e controlar os resultados e as atividades do Plano de Gerenciamento da Qualidade.

RECURSOS HUMANOS

9.1 Planejar Gerenciamento de Recursos Humanos do Projeto

     • Processo de identificar e documentar funções, responsabilidades e habilidades requeridas para a criação do Plano de Gerenciamento de Recursos Humanos

9.2 Mobilizar Equipe do Projeto

     • Processo para confirmar a disponibilidade dos recursos humanos e obter a equipe necessária para terminar o projeto.

9.3 Desenvolver Equipe do Projeto

     • Processo de integração e construção da equipe do projeto, bem como melhoria de competências individuais e coletivas da equipe.

9.4 Gerir Equipe do Projeto

     • Processo de acompanhar desempenho de membros da equipe, fornecendo feedback e solucionando conflitos.

COMUNICAÇÃO

10.1 Planejar Comunicação

     • Processo de determinar as necessidades de informações das partes interessadas no projeto para definir abordagens adequadas de comunicação.

10.2 Distribuir Informação

     • Processo de tornar disponíveis as informações necessárias aos interessados.

10.2 Relatar Desempenho

     • Processo de coleta e distribuição das informações sobre o desempenho e performance do projeto.

RISCOS

11.1 Planejar Gerenciamento dos Riscos

     • Processo de definir como serão identificados, analisados e gerenciados os riscos do projeto, incluindo procedimentos e padrão para gestão de riscos.

11.2 Identificar Riscos

     • Processo de determinar quais riscos podem afetar o projeto e documentar suas características.

11.3 Realizar Análise Qualitativa

     • Processo de priorização dos riscos por meio da avaliação subjetiva das suas probabilidades de ocorrência e impactos no projeto.

11.4 Realizar Análise Quantitativa

     • Processo de análise numérica do efeito dos riscos identificados sobre os objetivos gerais do projeto.

11.5 Planejar Respostas aos Riscos

     • Processo de desenvolver estratégias e ações para ampliar oportunidades e reduzir ameaças aos objetivos do projeto.

11.6 Monitorar e Controlar Respostas aos Riscos

   • Processo de monitorar os riscos, implementando as ações do plano de resposta quando necessário.

AQUISIÇÕES

12.1 Planejar Gerenciamento das Aquisições

     • Processo de documentar as decisões de aquisição do projeto, definir tipos de contratos e identificar potenciais fornecedores.

12.2 Conduzir Aquisições

     • Processo de obter propostas de fornecedores, selecionar fornecedor e formalizar contrato.

12.3 Administrar Aquisições

     • Processo de gerenciar as relações contratuais, fiscalizar e monitorar o desempenho dos contratos.

12.4 Encerrar Aquisições

     • Processo de finalizar formalmente todas as aquisições e contratos do projeto.

STAKEHOLDERS

13.1 Identificar Stakeholders

     • Processo de identificar pessoas, grupos ou organizações que poderiam afetar ou serem afetadas pelo projeto.

13.2 Planejar Gerenciamento dos Stakeholders

     • Processo de desenvolver estratégias para engajar efetivamente os stakeholders ao longo do projeto.

13.3 Gerenciar Engajamento dos Stakeholders

     • Processo de gerenciar expectativas e promover o engajamento dos stakeholders em favor do projeto.

     13.4 Controlar Engajamento dos Stakeholders

• Processo de monitorar os relacionamentos com stakeholders do projeto.

Fonte: NÃO TENHA PRESSA – 47 PROCESSOS DO GUIA PMBOK 5 EDIÇÃO