Engenharia de Software: maio 2013

quarta-feira, 29 de maio de 2013

Gestão de Projetos - XI

Projetos e planejamento estratégico

Os projetos são frequentemente utilizados como meio de atingir o plano estratégico de uma organização. Os projetos são normalmente autorizados como resultado de uma ou mais das seguintes considerações estratégicas:

Demanda de mercado (por exemplo, uma companhia automobilística autorizando um projeto para fabricar carros mais econômicos em resposta à escassez de gasolina);
Oportunidade/necessidade estratégica de negócios (por exemplo, uma empresa de treinamento autorizando um projeto para criar um novo curso a fim de aumentar a sua receita);
Solicitação de cliente (por exemplo, uma companhia de energia elétrica autoriza um projeto de construção de uma nova subestação para atender a um novo parque industrial);
Avanço tecnológico (por exemplo, uma empresa de produtos eletrônicos autoriza um novo projeto para desenvolver um laptop mais rápido, mais barato e menor após avanços obtidos em tecnologia para memória e circuitos eletrônicos de computador) e
Requisito legal (por exemplo, um fabricante de produtos químicos autoriza um projeto para estabelecer diretrizes para o manuseio de um novo material tóxico).

Os projetos, em programas ou portfólios, são um meio de atingir metas e objetivos organizacionais, geralmente no contexto de um planejamento estratégico. Embora um grupo de projetos em um programa possa ter benefícios distintos, eles também podem contribuir para os benefícios do programa, para os objetivos do portfólio e para o plano estratégico da organização.

As organizações gerenciam portfólios com base em seu plano estratégico, o que pode ditar uma hierarquia para o portfólio, programa ou projetos envolvidos. Um objetivo do gerenciamento de portfólios é maximizar o valor do portfólio através do exame cuidadoso de seus componentes: os projetos e programas integrantes e outros trabalhos relacionados. Os componentes que contribuem menos para os objetivos estratégicos do portfólio podem ser excluídos. Dessa forma, o plano estratégico de uma organização torna-se o principal fator de orientação para investimentos em projetos. Ao mesmo tempo, os projetos fornecem feedback aos programas e portfólios através de relatórios de progresso e solicitações de mudanças que possam impactar outros projetos, programas ou portfólios. As necessidades dos projetos, incluindo as necessidades de recursos, são encaminhadas e comunicadas no nível do portfólio, o qual, por sua vez, determina a orientação para o planejamento organizacional.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - XI

Como modelar uma Fábrica de Software?

Planejamento - Fase 1

Identificação do Modelo Organizacional.
Definição do modelo de gestão e nível de maturidade. (CMMI - PMI/SCRUM)

Planejamento - Fase2

Levantamento da estrutura onde a Fábrica será implantada.
Levantamento da infraestrutura, instalações e equipamentos (estado da arte ou orçamento)

Planejamento - Fase3

Identificar os itens qualificados e ganhadores do pedido.
Determinar os objetivos de desempenho da operação.

Determinar a estrutura organizacional.
Determinar a infraestrutura operacional.
Especificação da Fábrica.

A estratégia define:

Como vamos estruturar a WBS dos produtos a serem entregues ao longo do projeto.
Qual vai ser o ciclo de vida adotado para o projeto.
Qual a melhor sequência das atividades em função das prioridades.
Quem devemos envolver desde o início do projeto.
Como os formadores de opinião vão ser envolvidos, e assim sucessivamente.

A estratégia depende também da complexidade do projeto, levando em consideração o seu porte e risco. O maior objetivo do planejamento estratégico é a redução da complexidade do projeto.

Grande Abraço,
Gilberto Ribeiro.

SCRUM - Implantação XI

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.

Engenharia de Software - XI

Portabilidade segundo a Norma ISO 9126

“Capacidade do produto de software de ser transferido de um ambiente para outro”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Adaptabilidade

“Capacidade do produto de software de ser adaptado para diferentes ambientes especificados, sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Capacidade para ser instalado

“Capacidade do produto de software para ser instalado em um ambiente especificado”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Coexistência

“Capacidade do produto de software de coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Capacidade para substituir

“Capacidade do produto de software de ser usado em substituição a outro produto de software especificado, com o mesmo propósito e no mesmo ambiente”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Conformidade relacionada à portabilidade

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

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - XI

Arquivos de Índice

Não possuem funcionalidade de armazenar dados ou informações de controle, portanto não podem ser ALI ou AIE.

Arquivos com Dados Consolidados

Cujo único objetivo fim é agilizar o processamento, não representam requisitos funcionais, mas sim de desempenho, requisito não funcional. Exceção se as informações não forem constituídas a partir dos dados de outras tabelas.

Requisitos não Funcionais – atributos do sistema ou ambiente do sistema.

Extensibilidade
Usabilidade
Confiabilidade
Desempenho
Escalabilidade
Reusabilidade
Capacidade de manutenção
Reutilização de código
Eficiência no desenvolvimento
Confiabilidade nos dados apresentados

Arquivos Temporários e de Passagem de Movimento

Quando sua principal intenção é transportar dados, são de fato mensagens. Neste caso o arquivo original não representa um requisito funcional de armazenamento.

Distribuição de Dados

A distribuição de dados de um mesmo grupo lógico de dados em vários arquivos físicos mantidos em localidades diferentes não é um requisito funcional, portanto não pode ser considerados um ALI ou AIE.

Visões

Não são considerados Arquivos Lógicos, pois não representam requisitos funcionais de armazenamento do USUÁRIO. (visão do negócio)

Entidade de Ligação

As entidades com apenas as chaves de duas ou mais outras entidades como atributos, definindo com isso a intersecção entre elas, representam a implementação de um relacionamento em um modelo de dados normalizado, do tipo “N:M”, não podemos classificar o resultado da intersecção como um ALI ou AIE.

Entidades não Mantidas por Processos Elementares

Não são contadas como ALI ou AIE.

Atenção: Processo Elementar é a menor unidade de atividade significativa para o usuário final.

Grande Abraço,
Gilberto Ribeiro.

segunda-feira, 27 de maio de 2013

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)