Engenharia de Software - XVI

Métricas Externas 

Utilizam medidas de um produto de software derivadas de medidas do comportamento do sistema do qual o software é uma parte, através de teste, operação e observação do software executável ou do sistema. Antes de adquirir ou utilizar um produto de software, convém que ele seja avaliado utilizando-se métricas baseadas nos objetivos de negócio e relacionadas ao uso, exploração e gestão do produto num ambiente técnico e organizacional especificado.

As métricas citadas são, primordialmente, métricas externas; exemplos são encontrados na ISO/IEC 9126-2. Métricas externas oferecem a usuários, avaliadores, executores de teste e desenvolvedores os benefícios de poderem avaliar a qualidade do produto de software durante seu teste ou operação.

Grande Abraço,
Gilberto Ribeiro.

SCRUM - Implantação XV

Os Papeis do Scrum

Podemos identificar no Scrum três papeis bem definidos, o Dono do Produto ou PO – Product Owner, o Scrum Master e o Time de Desenvolvimento.

O Dono do Produto tem como função principal garantir o ROI - Return on Investment do produto, conhecendo as reais necessidades dos usuários e stakeholders. Dentre as suas habilidades podemos destacar a necessidade da visão estratégica e entendimento do que é valor para o cliente por ele representado, a capacidade de comunicação para conseguir trabalhar em conjunto com os stakeholders capturando as necessidades do cliente e usuários, a facilidade para estabelecer e comunicar a visão do produto para todos os envolvidos, autoridade para exercer suas responsabilidades, o comprometimento com o projeto, as habilidades de negociação, o bom relacionamento interpessoal e o conhecimento sobre o Scrum.

O Scrum Master deve ser um profundo conhecedor da metodologia, tendo domínio sobre suas regras, papéis, eventos e artefatos. Ele atua como mentor, auxiliando o Time de Desenvolvimento e o Dono do Produto a trabalhar melhor com o Scrum. É um facilitador, e deve também, possuir habilidades de comunicação e negociação, além de ter algum conhecimento técnico, saber blindar a equipe contra interferências externas e dar suporte para que o Time de Desenvolvimento seja funcional e produtivo.

O Time de Desenvolvimento, da mesma forma que o Scrum Master, precisa conhecer o framework Scrum, como as suas regras, papéis, cerimônias e artefatos, trabalhar sempre de forma colaborativa, atuando com transparência e sempre buscando entregar o máximo de valor ao negócio. Suas atividades devem estar pautadas pelo conceito de melhoria continua, trabalhando com qualidade e produtividade e principalmente, dado ao número reduzido de papeis, o time deve ser auto organizável.

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - XV

Entidades Associativas

As entidades que relacionam duas ou mais outras entidades entre si são chamadas de Entidades Associativas.

Grande Abraço,
Gilberto Ribeiro.

Fábrica de Software - XV

Definição das Atividades e Precedências

Com base no WBS definimos as atividades requeridas para a geração de cada fase ou produto. Por exemplo, as atividades básicas para elaboração do produto Plano de Capacitação deve ser elaborado e supervisionado pelos recursos seniores da empresa:

• Preparação do programa de treinamento
• Validação do programa
• Desenvolvimento do material de treinamento
• Validação do material de treinamento
• Programação do treinamento e sua logística
• Execução do treinamento
• Avaliação do treinamento

É necessário o estabelecimento de pontos de controle para a avaliação do progresso do projeto. Geralmente, são atividades de verificação e validação de produtos críticos para o sucesso do projeto. São produtos que estão no caminho crítico do projeto.

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - XV

Métricas internas

Métricas internas podem ser aplicadas a um produto de software não executável, tais como uma especificação ou código fonte, respectivamente, durante o projeto e a codificação. Convém que, no desenvolvimento de um produto de software, os produtos intermediários sejam avaliados utilizando-se métricas internas, as quais medem propriedades intrínsecas, incluindo aquelas que podem ser derivadas de um comportamento simulado. O propósito básico destas métricas internas é assegurar que a qualidade externa e a qualidade em uso requerida sejam alcançadas; exemplos são encontrados na ISO/IEC 9126-3. Métricas internas oferecem a usuários, avaliadores, executores de teste e desenvolvedores os benefícios de poderem avaliar a qualidade do produto de software e considerar questões relativas à qualidade bem antes do produto de software se tornar executável.

Métricas internas medem atributos internos pela análise das propriedades estáticas dos produtos de software intermediários ou preparados para entrega. Da mesma forma, as métricas internas podem ser indicadoras de atributos externos.

As medições de métricas internas utilizam números ou frequências de elementos que compõem o software e que aparecem, por exemplo, em declarações de códigos-fonte, no gráfico de controle e nas representações de fluxo de dados e de transição de estados.

Grande Abraço,

Gilberto Ribeiro.

Gestão de Projetos - XV

Conjunto de conhecimentos em gerenciamento de projetos

O Guia PMBOK® é o padrão para gerenciar a maioria dos projetos na maior parte das vezes em vários tipos de setores da indústria. Descreve os processos, ferramentas e técnicas de gerenciamento de projetos usados até a obtenção de um resultado bem-sucedido.

Esse padrão é exclusivo ao campo de gerenciamento de projetos e tem relacionamento com outras disciplinas de gerenciamento de projetos, como gerenciamento de programas e gerenciamento de portfólios.

As normas de gerenciamento de projetos não abordam todos os detalhes de todos os tópicos.

Esse padrão limita-se a projetos individuais e aos processos de gerenciamento de projetos amplamente reconhecidos como boa prática. Outros padrões podem ser consultadas para a obtenção de informações adicionais sobre o contexto mais amplo no qual os projetos são realizados. O gerenciamento de programas é abordado em A Norma para Gerenciamento de Programas (The Standard for Program Management) e o gerenciamento de portfólios é abordado em A Norma para Gerenciamento de Portfólios (The Standard for Portfolio Management). O exame das capacidades do processo de gerenciamento de projetos de uma empresa é abordado em Modelo de Maturidade de Gerenciamento de Projetos Organizacionais (Organizational Project Management Maturity Model, OPM3®). 

Grande Abraço,

Gilberto Ribeiro.

O Propósito do Guia SCRUM - XII

A palavra SPRINT tem como tradução arrancada, corrida de velocidade, logo quando a escrevemos nos referindo ao termo, o correto é a SPRINT ou da SPRINT,  o mais importante é que ela é o principal evento do SCRUM.

46. Como podemos definir a Sprint?

• Como o coração do Scrum, um time-box de um mês ou menos, durante o qual uma versão “Pronta”, versão incremental potencialmente utilizável do produto, é criada.

Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.

47. Qual o processo que compõe uma Sprint?

• As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.

48. Durante a Sprint o que muda e o que não pode mudar?

• Não são feitas mudanças que podem afetar o objetivo da Sprint;
• A composição da Equipe de Desenvolvimento permanece constantes;
• As metas de qualidade não diminuem; e,
• O escopo pode ser elucidado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido.

49. Como podemos descrever uma Sprint?

• Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês.
• Como os projetos, as Sprints são utilizadas para realizar algo.
• Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

50. Qual a duração de uma Sprint?

• Sprints são limitadas a um mês corrido.

Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer.

Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção a meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido. 

Grande Abraço,

Gilberto Ribeiro.

Requisitos - XVI

Produção

A partir da implantação da aplicação entra em cena a equipe de produção, que algumas vezes é um subconjunto 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

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 

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.

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

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.

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

Grande Abraço,

Gilberto Ribeiro.

O Propósito do Guia SCRUM - XI

Eventos Scrum

• Reunião de Planejamento da Sprint.

• Reunião diária.

 

• Reunião de Revisão da Sprint.

 

• Retrospectiva da Sprint.

44. Qual a principal característica dos eventos Scrum?

• Eventos time-boxed, onde todo evento tem uma duração máxima.

45. Qual objetivo dos eventos time-boxed?

• Garantir que uma quantidade adequada de tempo seja gasta no planejamento sem permitir perdas no processo de planejamento.

Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e adaptar.

Estes eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa.

Atenção: A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar.

Grande Abraço,
Gilberto Ribeiro.

Requisitos - XV

Testes

Os testes se dividem em 5 tipos :

• Teste de bancada
• Teste de qualidade
• Teste de Stress
• Teste de Segurança
• Homologação

Destes 3 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.

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 idêntico 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.

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.

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 obtém-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 reimplantação da aplicação em qualidade e novo teste até o momento em que os testers não identifiquem nenhum erro

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. 

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.

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 

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.

Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - XIV

Métricas de software

Atributos Externos e Internos

Constata-se que os níveis de certos atributos internos influenciam os níveis de alguns atributos externos, de modo que há tanto um aspecto externo quanto um aspecto interno na maioria das características. Por exemplo, a confiabilidade pode ser medida, externamente, observando-se o número de falhas, num dado período de tempo de execução, durante um experimento de uso do software e, internamente, inspecionando as especificações detalhadas e o código-fonte para avaliar o nível de tolerância a falhas. Os atributos internos são tidos como indicadores dos atributos externos.

Um atributo interno pode influenciar uma ou mais características e uma característica pode ser influenciada por mais de um atributo (ver figura A.1). Neste modelo, todos os atributos de qualidade do produto de software são classificados numa estrutura hierárquica, em árvore, de características e subcaracterísticas. O nível mais alto desta estrutura consiste em características de qualidade e o nível mais baixo consiste em atributos de qualidade de software. A hierarquia não é perfeita, pois alguns atributos podem contribuir para mais de uma subcaracterística.

Fonte: NBR ISO/IEC 9126.

Subcaracterísticas podem ser medidas por métricas internas ou por métricas externas.

A correlação entre atributos internos e medidas externas nunca é perfeita e o efeito que um dado atributo interno tem sobre uma medida externa associada será determinado pela experiência e dependerá do contexto específico no qual o software será usado.

Do mesmo modo, propriedades externas (tais como: adequação, acurácia, tolerância a falhas ou comportamento em relação ao tempo) influenciarão a qualidade observada. Uma falha na qualidade em uso (por exemplo, o usuário não consegue terminar uma tarefa) pode ser relacionada a atributos de qualidade externa (por exemplo, adequação ou operabilidade) e a atributos internos associados que precisam ser modificados.

Grande Abraço,
Gilberto Ribeiro.

Fábrica de Software - XIV

Planejamento da Implantação

O planejamento da implantação da Fábrica deve seguir alguns passos e gerar um Plano do Projeto. A entrada principal para o planejamento da implementação da Fábrica de Software é constituída por suas especificações técnicas e pela estratégia de desenvolvimento.

O planejamento do projeto deve considerar os seguintes passos:

1. Definição do WBS do projeto.
2. Definição das atividades para geração de cada produto previsto para ser entregue pelo projeto (exemplo: instalação dos servidores, procedimento documentado de controle de qualidade etc.).
3. Definição sobre precedência entre as atividades.
4. Estimativa de prazos e recursos.
5. Estimativas de custo.
6. Elaboração do plano da qualidade.
7. Elaboração do plano organizacional.
8. Elaboração do plano de aquisição de recursos.
9. Elaboração do plano de riscos.
10. Elaboração do plano de comunicação.
11. Elaboração do cronograma do projeto.
12. Elaboração do orçamento de custo do projeto.
13. Elaboração dos critérios de controle do cronograma, custo e escopo.
14. Consolidação do Plano do Projeto.

WBS do projeto da Fábrica de Software 

O WBS do projeto define os entregáveis do projeto.

Um projeto de Fábrica de Software geralmente tem os seguintes entregáveis:

• Instalações Físicas
• Imobiliário

• Projeto de Rede
• Servidores
• Softwares
• Cabeamento
• Dispositivo de Rede

• Ferramentas do Processo de Construção
• Processo de Gestão do Projeto
• Ferramentas do Processo de Gestão do Projeto
• Processo de Gestão da Operação
• Ferramentas do Processo de Gestão da Operação
• Processo de Suporte
• Ferramenta de Processo de Suporte
• Processo de Gestão Estratégica
• Ferramentas de Processo de Gestão estratégica

 

• Organização Funcional
• Organização Matricial
• Organização Projetizada
• Organização Composta

• Gestão de Demanda
• Gestão de Desempenho
• Gestão do Projeto
• Gestão Financeira 

 

• Processos e Ferramentas de Comunicação
• Processos e Ferramentas de Gestão de Projeto
• Processos e Ferramentas de Gestão de Operação
• Processos e Ferramentas de Suporte
• Processos e Ferramentas de Processos Estratégicos

• Plano da Garantia da Qualidade
• Relatórios da Garantia da Qualidade

• Plano do Projeto
• Controle do Cronograma
• Controle do Custo
• Controle da Qualidade
• Controle do Escopo

Grande Abraço,
Gilberto Ribeiro.

Gestão de Projetos - XIV

Papel de um gerente de projetos

O gerente de projetos é a pessoa designada pela organização executora para atingir os objetivos do projeto. O papel de um gerente de projetos é diferente de um gerente funcional ou gerente de operações. 

Normalmente, o gerente funcional está concentrado em proporcionar a supervisão de gerenciamento de uma área administrativa e os gerentes de operações são responsáveis por um aspecto do negócio principal.

Dependendo da estrutura organizacional, um gerente de projetos pode se reportar a um gerente funcional. Em outros casos, um gerente de projetos pode ser um dos vários gerentes de projetos que se reporta a um gerente de portfólios ou de programas que é, em última instância, o responsável pelos projetos no âmbito da empresa. Nesse tipo de estrutura, o gerente de projetos trabalha estreitamente com o gerente de portfólios ou de programas para atingir os objetivos do projeto e garantir que o plano do mesmo esteja alinhado com o plano do programa central.

Muitas das ferramentas e técnicas de gerenciamento de projetos são específicas ao gerenciamento de projetos. No entanto, compreender e aplicar o conhecimento, as ferramentas e as técnicas reconhecidas como boas práticas não é suficiente para um gerenciamento eficaz.

Além de todas as habilidades da área específica e das proficiências ou competências de gerenciamento geral exigidas , o gerenciamento de projetos eficaz requer que o gerente tenha as seguintes três características :

.1 Conhecimento.

Refere-se ao que o gerente de projetos sabe sobre gerenciamento de projetos.

.2 Desempenho.

Refere-se ao que o gerente de projetos é capaz de realizar enquanto aplica seu conhecimento em gerenciamento de projetos.

.3 Pessoal.

Refere-se ao comportamento do gerente na execução do projeto ou de atividade relacionada. A efetividade pessoal abrange atitudes, principais características de personalidade e liderança; a capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge objetivos e equilibra as restrições do mesmo.

Grande Abraço,

Gilberto Ribeiro.

Métrica de Software - XIV

Generalização, Subtipos e Supertipos.

A relação entre um elemento mais geral – o pai – e um elemento mais específico que agrega informações adicionais e é totalmente consistente com o primeiro elemento – o filho – é chamado de Generalização. 

 

Grande Abraço,

Gilberto Ribeiro.

SCRUM - Implantação XIV

Os Valores do SCRUM

Os valores do Scrum têm como base a transparência, a inspeção e a adaptação.

 

O valor transparência exige que todos os envolvidos no projeto conheçam os aspectos significativos do processo e do projeto. A visibilidade é fundamental para comunicação da equipe, colocando todos na mesma página. A clareza nas informações possibilita que todos tenham o mesmo entendimento, pois todos envolvidos tem que falar a mesma linguagem independente de para quem a pergunta foi formulada, a resposta tem que ser a mesma.

O valor inspeção garante o bom andamento do projeto e viabiliza a adaptação, o terceiro valor do Scrum. Os processos, as práticas e atividades devem ser inspecionadas constantemente para mantermos o projeto dentro do planejado nas Sprints, detectando os desvios o mais cedo o possível. A inspeção também garante que o sistema atenderá os requisitos do negócio, garantindo assim a qualidade do sistema.

O valor adaptação garante as correções dos desvios ao longo do ciclo de vida do desenvolvimento da Sprint, e serve como lição aprendida nas reuniões de retrospectivas do Scrum, evitando que erros detectados nas Sprints anteriores ocorram novamente ao longo do ciclo de vida das demais Sprints. Fazem parte do valor Adaptação quatro eventos formais que são utilizados para inspeção e adaptação:

• Reunião de planejamento da Sprint.
• Reunião diária
• Revisão da Sprint
• Retrospectiva da Sprint

A Adaptação depende da Inspeção e a Inspeção depende da Transparência.

Grande Abraço,
Gilberto Ribeiro.