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.