Perfil Profissional - X

Criação de diagrama de Casos de Uso

Criamos os diagramas de Casos de Uso que servirão de base para análise do desenvolvimento do sistema.

Atualização do Glossário do Projeto

Atualizar o glossário do projeto.

Grande Abraço,

Gilberto Ribeiro.

Requisitos - XI

Softwares

“Quando um projeto de software falha, raramente a causa é técnica”.
Jim Johnson, do The Standish Group.

Tal afirmação reforça o conceito de que o problema não está na tecnologia que usamos para implementação de um sistemas, mas sim na QUALIDADE dos REQUISITOS, ou seja, o entendimento do domínio do negócio.

A raiz da maioria das falhas está na (ausência de) utilização de metodologias de desenvolvimento adequadas e como elas interagem com os stakeholders em um projeto de software, e principalmente pela dificuldade do entendimento dos conceitos básicos dos processos de negocio.

Por “metodologia de desenvolvimento” entende-se o conjunto das:

• Atividades
• Responsabilidades
• Artefatos (documentos, diagramas, código-fonte etc.)
• Orientação e boas práticas usadas para planejar, construir e implementar software.

Um METODOLOGIA estabelece um caminho único no desenvolvimento de sistemas novos ou na evolução de sistemas já existentes. Ela introduz consistência ao longo do desenvolvimento de vários projetos de sistemas, provendo uma lista de todas as atividades a serem realizadas, estabelecendo pontos de verificação para auditoria e controle do projeto.

Então vejamos algumas situações que temos de enfrentar:

“Estou precisando de um website...

Ótimo, podemos fazê-lo. Gostaria de marcar uma reunião para fazermos um briefing do que precisa, conhecer alguns detalhes de design, tipo de hospedagem...

Não, não, você não está entendendo, é pra ontem!”

IMPORTANTE:

• Nem se estresse tentando definir requisitos de sistemas em prazos absurdos que não permitam o seu correto entendimento e especificação.
• Sistemas não são feitos da noite para o dia, eles englobam muito mais que linhas de programação, horas de testes, manuais, documentação e treinamento fazem parte do que chamamos de software.
• Se o cliente exige um prazo absurdamente curto, rediscuta ou não o faça, pois o resultado da pressa é proporcional à qualidade do resultado de sistema.
• Se o cliente do projeto de sistema quer que você converse, faça levantamento de requisitos em curto espaço de tempo, com agendas apertadas, lembre-se de que você não tem como estar levantando informações e necessidades de um grupo de usuários ao mesmo tempo em que de outro, de áreas distintas, ou operações distintas.
• Conhecer e dominar uma linguagem de programação é bom, mas não é tudo, assim como conhecer processos como CMMI ou MPS-BR. É preciso mais que um bom processo ou boa linguagem e bons analistas e programadores.

A necessidade de estabelecer os requisitos de maneira e de forma precisas é crítica à medida que o tamanho e a complexidade do software aumentam.

Os requisitos exercem influências uns sobre os outros, logo não podemos realizar análise de necessidades sem buscar sempre o entendimento do todo. Isso é o que chamamos de ter Visão Sistêmica de Processo, enxergar e abstrair de cada necessidade a sua implicação com as outras dentro do contexto operacional do negócio. Então, vemos que a análise de requisitos e análise de processos estão intimamente ligadas.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - X

Fundamentando o Conhecimento

Como estabelecer uma operação de software mais efetiva em termos de custo, agregação de valor ao negócio, qualidade, previsibilidade do atendimento aos serviços de desenvolvimentos e manutenção? Por onde começar o processo de implantação de gestão e de operação na área de TI? (Em especial na área de desenvolvimento de sistemas)

Gestão de Operações

Garante que os processos ocorram de acordo com padrões estabelecido, garantindo aos clientes os produtos e serviços previstos na contratação. Isso envolve planejamento prevendo estratégias para o entendimento dos diferentes domínios de negócio, sua transformação em sistema e aplicação produzindo os resultados esperados.

Operação de Software

Toda operação de software envolve custo, é preciso agregar valor ao negócio do cliente, os requisitos deve atender as necessidade do cliente e adequá-lo ao negócio, envolve também previsibilidade no atendimento aos serviços de desenvolvimentos e manutenção, garantido a continuidade da prestação de serviço.

Uma série de atividades como as listadas abaixo compõe a operação de software:

• Análise da OS (Ordem de Serviço)
• Especificação dos Requisitos
• Desenvolvimento do Projeto
• Construção do Sistema
• Planejamento de Testes
• Teste Unitário
• Teste de Integração
• Teste de Sistema
• Instalação
• Teste de Aceitação
• Implantação
• Ajustes

No modelo fabril as operações acima pertencem a disciplina Construção de Produto de Software, que fazem parte do Sistema de Gestão, podemos citar:

• Gestão Estratégica
• Gestão da Operação
• Gestão do Projeto
• Construção de Produto de Software

Aprendemos que o maior desafio neste novo cenário é manter a Fábrica de Software de forma regular e consistente ao longo do tempo, gerindo operações de software em larga escala e todas as suas variáveis e elementos que as  fundamentam, e isso só será possível com um processo bem definido.

Uma empresa que pretende trabalhar com o conceito de Fábrica de Software, precisa ter fundamentado as fases clássicas do processo de engenharia de software, como:

• Planejamento
• Especificação de Requisitos
• Projeto de especificação
• Especificação física
• Construção (que abrange a programação)
• Implantação
• Transição (passagem para produção)

Pontos de atenção na evolução contínua do modelo Fabril:

• Estabelecer objetivos da manufatura de software.
• Focar no produto e nos processos - Software de Prateleira e Software Customizados.
• Coletar os dados sobre o processo existente - Mapeamento dos processos existentes.
• Estabelecer Sistemas de controle - Modelos de gestão PMI, SCRUM e etc.
• Ferramentas para apoiar o controle dos projetos. 
• Estabelecer controle de qualidade e círculos da qualidade.
• Revisar dos padrões.  

• Padronizar os métodos para o desenvolvimento - Conceito de "Pronto".
• Desenvolver em ambiente on-line - ex. GSD - Global Software Development.
• Implantação de Plano de Capacitação para os recursos, padronizando suas habilidades.
• Criação de Base do conhecimento - Bibliotecas de código-fonte.
• Metodologias integradas e ferramentas de desenvolvimento.
• Ferramentas para geração de código, teste e documentação.
• Intregrar ferramentas com banco de dados e plataformas de desenvolvimento.
• Introduzir ferramentas de apoio à reutilização.
• Introduzir ferramentas de automação e design.
• Introduzir ferramentas de apoio à análise de requisitos.
• Integrar ferramentas em plataforma de desenvolvimento.
• Aumento da capacidade das ferramentas existentes.
• Transferências de métodos e ferramentas para as subsidiárias.
• Evolução dos métodos e ferramentas.

Quality Assurance

Importantes recomendações visando a qualidade na codificação, focar na qualidade dos processos de desenvolvimento e programação, ao invés de remover defeito em software através de teste, ou seja, antes de enviar o resultado do desenvolvimento para a equipe de Q.A., certificar se a equipe de desenvolvimento seguiu o prescrito nos processos delineado para a área.

Alguns princípios

• Eliminar qualquer especificação ou porção de código que não adiciona valores efetivos às funções do software.
• Eliminar, simplificar e automatizar os processos que possam causar problemas na fase de teste.
• Testar e aperfeiçoar o processo, em vez do produto.
• Enfatizar o treinamento e a aplicação disciplinada e consistente de padrões.
• Promover autonomia às equipes para construir e implantar a arquitetura da Fábrica de Software.
• Fazer grande uso de componentes reutilizáveis.

Referências

• CMMI – Capability Maturity Model Integration - principal referência em gestão de processos de software em nível mundial. 
• RUP – Rational Unified Process
• Série ISO 
• PMI – Project Management Institute.
• SCRUM
• XP - Extreme Programming

Resumo Código de Ética dos Engenheiros de Software

Os engenheiros de software devem estar convictos a fazer do conjunto da análise, da especificação, do projeto, do desenvolvimento, do teste e da manutenção de software, uma profissão benéfica e respeitada. De acordo com o seu comprometimento com a saúde, segurança, e bem-estar do público, os engenheiros de software devem adotar os oito princípios.

• Público. Engenheiros de Software devem atuar consistentemente com os interesses públicos.
• Clientes e empregados. Engenheiros de Software devem atuar de modo a atender os melhores interesses dos seus clientes e empregados, consistentemente com os interesses públicos.
• Produto. Engenheiros de Software devem assegurar que seus produtos e modificações relacionadas atendam os melhores padrões profissionais possíveis.
• Julgamento. Engenheiros de Software devem manter a integridade e independência nos seus julgamentos profissionais.
• Administração. Administradores e líderes de Engenharia de Software devem aderir e promover uma abordagem ética ao gerenciamento do desenvolvimento e manutenção de software.
• Profissão. Engenheiros de Software devem desenvolver a integridade e reputação da profissão consistentemente com os interesses do público.
• Companherismo. Engenheiros de Software devem ser justos e dispostos a auxiliar seus colegas.
• Identidade. Engenheiros de Software devem participar do aprendizado de suas vidas valorizando a prática da sua profissão e devem promover uma abordagem ética à prática da profissão.”

Grande Abraço,

Gilberto Ribeiro.

Gestão de Projetos - X

Gerenciamento de programas

Um programa é definido como um grupo de projetos relacionados gerenciados de modo coordenado para a obtenção de benefícios e controle que não estariam disponíveis se eles fossem gerenciados individualmente. Os programas podem incluir elementos de trabalho relacionado fora do escopo de projetos distintos no programa. Um projeto pode ou não fazer parte de um programa, mas um programa sempre terá projetos.

O gerenciamento de programas é definido como o gerenciamento centralizado e coordenado de um programa para atingir os objetivos e benefícios estratégicos do mesmo. Os projetos dentro de um programa são relacionados através do resultado comum ou da capacidade coletiva. Se a relação entre projetos for somente a de um cliente, vendedor, tecnologia ou recurso compartilhado, o esforço deve ser gerenciado como um portfólio de projetos e não como um programa.

O gerenciamento de programas se concentra nas interdependências do projeto e ajuda a determinar a melhor abordagem para gerenciá-los. As ações relacionadas a essas interdependências podem incluir:

• Solução de restrições e/ou conflitos de recursos que possam afetar múltiplos projetos no sistema;
• Alinhamento da orientação estratégica/organizacional que afeta as metas e objetivos do projeto e do programa e
• Solução de problemas e gerenciamento de mudanças em uma estrutura de governança compartilhada.

Um exemplo de programa seria um novo sistema de satélite de comunicação com projetos para o design do satélite e das estações terrestres, construção de cada uma delas, integração do sistema e lançamento do satélite.

Grande Abraço,
Gilberto Ribeiro

Métrica de Software - X

Dados de Código (Metadados)

Os requisitos de armazenamento, funcionais e não funcionais, de uma aplicação são classificados em:

• Dados de Negócio
• Dados de Referência
• Dados de Código

Aqueles enquadrados como Dados de Código, apesar de poderem representar até metade das entidades em um modelo de dados em terceira forma normal, não devem ser considerados Arquivos Lógicos. Eles são uma implementação de requisitos técnicos e não devem influenciar no tamanho funcional da aplicação, ou seja, os pontos de função não ajustados. As transações que existem exclusivamente para a manutenção de dados de código não devem ser consideradas processos elementares, assim como os dados de código não devem ser contados como arquivos referenciados nos processos elementares que os leiam e/ou atualizem.

Exemplos: data de início e término de vigência, sigla e nome das unidades federativas e etc... Não são especificados pelo usuário, mas identificado pelo desenvolvedor em resposta a um ou mais requisitos técnicos (fase de normalização) e ainda:

• Arquivos que sempre armazenam apenas uma ocorrência e cujo conteúdo de seus atributos raramente mude.
• Exceção: arquivos com apenas um registro, armazenar informação de controle do negócio (parâmetro).
• Em que tanto a quantidade de ocorrências quanto seu respectivo conteúdo raramente mudam.
• Templates que armazenam valores padrão para alguns atributos de uma nova ocorrência de um objeto de negócio.
• Com apenas um atributo. Cada ocorrência representa somente um valor válido.
• Com dados que raramente mudem e que representem uma faixa de valores válidos. Tabelas com valores da mão de obra.

Dados de Código

Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - X

Manutenibilidade segundo a Norma ISO 9126

“Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais”. (NBR ISO/IEC 9126)

Os três valores do framework Scrum, transparência, inspeção e adaptabilidade garantem este item da Norma ISO.

Analisabilidade

“Capacidade do produto de software de permitir o diagnóstico de deficiências ou causas de falhas no software, ou a identificação de partes a serem modificadas”. (NBR ISO/IEC 9126)

Os três valores do framework Scrum, transparência, inspeção e adaptabilidade garantem este item da Norma ISO.

Modificabilidade

“Capacidade do produto de software de permitir que uma modificação especificada seja implementada”. (NBR ISO/IEC 9126)

Os três valores do framework Scrum, transparência, inspeção e adaptabilidade garantem este item da Norma ISO.

Estabilidade

“Capacidade do produto de software de evitar efeitos inesperados decorrentes de modificações no software”. (NBR ISO/IEC 9126)

Os três valores do framework Scrum, transparência, inspeção e adaptabilidade garantem este item da Norma ISO.

Testabilidade

“Capacidade do produto de software de permitir que o software, quando modificado, seja validado”. (NBR ISO/IEC 9126)

Os três valores do framework Scrum, transparência, inspeção e adaptabilidade garantem este item da Norma ISO.

Conformidade relacionada à Manutenibilidade

Capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à manutenibilidade.

Grande Abraço,

Gilberto Ribeiro.

SCRUM - Implantação X

Colaboração com o cliente, mais que negociação de contrato.

Existia aqui uma grande queda de braço entre o time de desenvolvimento e o cliente. Com o objetivo de delinear o escopo na elaboração da proposta o time defendia a ideia de enxugar ao máximo a quantidade de funcionalidades, pois não conhecia os meandros do projeto, os seus riscos e a quantidade de mudanças que poderiam encontrar no tempo de projeto. Do outro lado o cliente forçava para colocar o máximo de funcionalidades, pois uma vez fechado o contrato não haveria mais alteração no escopo, sem a geração de custos para o projeto.

Os softwares inteligentes variam de acordo com o negócio do cliente, e são únicos. Um projeto com domínio de negócio complexo não podem seguir um cronograma rígido e cuja participação do cliente só aconteça no final.

A framework ágil tem como fundamento o envolvimento do cliente em todas as fases do projeto, para nós denominado “coautor do sistema”. Nada mais inteligente, pois é ele quem conhece o domínio do negócio e é o feedback regular e frequente do cliente que nos garantirá o sucesso do projeto.

Em um contrato não conseguimos especificar todas as complexidades dos requisitos, e refletir em um cronograma fixo os meandros, as particularidades que o domínio do negócio nos imputará ao logo do ciclo de vida do sistema, pois não somos os especialistas no negócio. Os contratos devem regular as relações entre cliente e fornecedores, norteando o modo como a equipe de desenvolvimento e o cliente trabalharão juntos, e esse foi o nosso diferencial.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - IX

A Fábrica de Software de Evans

Outro conceito que enriquece nosso estudo é o da Fábrica de Software de Evans, que por sua vez a denomina, Ambiente de Engenharia de Software de 4ª Geração.

Evans propõe nesse modelo que o ambiente de software enxergue o processo de engenharia como uma linha de montagem. Essa linha e montagem tem como objetivo o ciclo de vida do desenvolvimento (o processo produtivos), que interage com processos de garantia da qualidade do produto, suporte automatizado para o desenvolvimento e gestão do ambiente e com os processos de gestão propriamente ditos.

As características básicas desta fábrica são:

• O processo é padronizado, ou seja:
• Documentado
• Praticado
• Medido
• E as pessoas são treinadas para operá-lo.

• A capacidade de atendimento é planejada juntamente com o cliente, considerando um período mínimo de um ano.

• A plataforma de desenvolvimento é totalmente automatizada.

• Há uma sistemática de Planejamento e Controle de Produção, com controle rigoroso da alocação dos recursos.

• Flexibilidade de ambiente.

• Recursos humanos são flexíveis, à medida que cada programador domina pelo menos 3 (três) linguagens de programação.

• Há controle de qualidade e de metas, inclusive controle estatístico de processos e gráficos de Pareto para identificar a maior incidência de defeitos por tipo.

• As versões de programas são controladas por suporte automatizado.

• Os tempos de ciclo de produção da fábrica e o tempo de codificação são padronizados, considerando o tipo de linguagem e a complexidade do programa a ser construído.

• As metas de desempenho em termos de atendimento dos tempos padrões, produtividade individual dos programadores e nível de defeitos são controladas.

• Há projetos de melhoria contínua do processo em função dos resultados das metas de desempenho.

• A Fábrica opera em várias localidades separadas geograficamente, utilizando o mesmo processo padrão.

• O recebimento de especificações do cliente e o envio do programa codificado são feitos por meio eletrônico, inclusive pela internet.

Grande Abraço,

Gilberto Ribeiro.

Gestão de Projetos - IX

Gerenciamento de Portfólios

Um portfólio refere-se a um conjunto de projetos ou programas e outros trabalhos, agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atingir os objetivos de negócios estratégicos. Os projetos ou programas do portfólio podem não ser necessariamente interdependentes ou diretamente relacionados. Por exemplo, uma empresa de infraestrutura que tenha o objetivo estratégico de “maximizar o retorno sobre os seus investimentos” pode compor um portfólio que inclua uma mescla de projetos em petróleo e gás, energia, água, estradas, ferrovias e aeroportos. A partir dessa mescla, a empresa pode escolher gerenciar projetos relacionados como um programa. Todos os projetos de energia podem ser agrupados como um programa de energia. Da mesma forma, todos os projetos de água podem ser agrupados como um programa de água.

O gerenciamento de portfólios se refere ao gerenciamento centralizado de um ou mais portfólios, que inclui:

• Identificação
• Priorização
• Autorização
• Gerenciamento
• e Controle de projetos
• Programas e outros trabalhos relacionados

Para atingir objetivos de negócios estratégicos específicos. O gerenciamento de portfólios se concentra em garantir que os projetos e programas sejam analisados a fim de priorizar a alocação de recursos, e que o gerenciamento do portfólio seja consistente e esteja alinhado às estratégias organizacionais.

Grande Abraço,

Gilberto Ribeiro.

SCRUM - Implantação IX

Software em funcionamento mais que documentação abrangente

O Scrum não aboliu a documentação do sistema, muito pelo contrário a tornou mais inteligente com base em seu processo interativo e incremental. Neste modelo a documentação é dividida em dois momentos:

No primeiro organizamos as informações para saber o que fazer e quais os objetivos do sistema orientarão o planejamento do Backlog da Sprint e a formação da Sprint. O segundo momento documenta o que de fato foi implementado, seguindo o processo interativo e incremental, é o que denomino como documentação consequente. A grande vantagem neste modelo é que documentamos o que de fato foi implementado, uma vez que sabemos que a única certeza que temos em um projeto é a mudança.

Temos como premissa não produzir qualquer documento, cuja necessidade não seja imediata e significativa para o projeto.

Grande Abraço,

Gilberto Ribeiro.