Gestão de Configuração de Softwares

"Independente da fase do ciclo de vida de um Software, o desejo de modificá-lo vai persistir durante todo o cilco de vida do mesmo."

Mudanças durante o desenvolvimento de um software, são inevitáveis. As necessidades dos usuários mudam, o ambiente no qual o sistema vai rodar muda e etc. Com tantas mudanças assim, é necessária alguma forma para que o desenvolvimento não entre no chamado "incêndio". Para isso, é criada uma Gerência de Configuração de Softwares que se utiliza da Gestão de Configuração de Softwares(GC).

CONCEITO E FUNÇÃO

A Gestão de Configuração de Software é um conjunto de atividades de apoio ao desenvolvimento de softwares que ajuda a lidar e controlar as modificações que ocorrem durante todo o ciclo de vida.
Quem faz parte dessa Gestão são os chamados Skateholder(entidades que particpam do processo de produção): Gerente de Projetos, Analistas, Desenvolvedores, Usuário e a Organização.

PRINCÍPIOS BÁSICOS

A GC é responsável por responder a 3 questões básicas:

1. Quais mudanças aconteceram no sistema?
2. Por que essas mudanças aconteceram?
3. O sistema continua íntegro mesmo depois das mudanças?


Para que seja recebido resultados positivos a essas perguntas a GC é formada pelas seguintes atividades:

PASSOS DA GESTÃO

1. Controle de Versão
* Identificação, armazenamento e gerenciamento dos itens de configuração e de suas versões durante todo o ciclo de vida do software;
* Histórico de todas as alterações efetuadas nos itens de configuração;
* Recuperação de uma configuração em um determinado momento desejado do tempo.
2. Auditoria
* Envocar auditores, ou um grupo, para fiscalizar o desenvolvimento do software. Esses auditores devem identificar, rastrear, analisar e controlar as mudanças nos itens.
3. Documentação
* Documentar através de relatórios as pricipais modificações desenvolvidas.

PRODUTOS OBTIDOS

Os Produtos do Trabalho da gerência de configuração é um Plano de estrategia, contendo:

* As modificações do software
* Relatorios
* Ordens de modificações

Origem das Modificações

* Novas condições de negocios(Modificações internas)
* Novas necessidade do cliente(Acrescentar funções ao sistema)
* Reorganização ou crescimento e diminuição dos negocios
* Restrições no orçamento ou no tempo que foi determinado(dependendo do dinheiro e do tempo disponível, o processo de desenvolvimento será modificado)

BASELINES

As mudanças feitas no softwares são analisadas através das Linhas de Base ou Baselines. As Baselines são configurações formalmente aprovadas para servir de referência para o desenvolvimento posterior do sistema. (Ver nosso artigo sobre Baselines Aqui)

Vídeo aulas de Engenharia de Software

Se você assimila mais o conteúdo ouvindo ou assistindo, assista direto no Youtube as aulas abaixo. São aulas ministradas por professores que abordam vários aspectos da Engenharia de Software com uma boa apresentação de slides. Cada aula dura em média 10 a 11 minutos.

Aula 1 - Parte 1 - Entender as principais características de um Software e sua qualidade.
Link Youtube

Aula 1 - Parte 2 - História e Princípios da Engenharia de Software
Link Youtube

Aula 2 - Parte 1 - Processos e Modelos de Softwares.
Link Youtube

Aula 2 - Parte 2 - Desenvolvimento Evolucionário de um Software(Controle de Versões)
Link Youtube

Aula 3 - Parte 1 - Requisitos de ambas as partes, Tarefa da Engenharia de Requisitos.
Link Youtube

Aula 3 - Parte 2 - Especificação, Validação, Gestão(Partes do processo de construção)
Link Youtube

Aula 4 - Parte 1 - Metodologias de testes na engenharia, Técnicas de manutenção do software.
Link Youtube

Aula 4 - Parte 2 - Caixa preta, Casos de Teste, Confiabilidade
Link Youtube

Aula 5 - Parte 1 - Qualidade e Métricas de Software, Qualidade e Custos de Softwares.
Link Youtube

Aula 5 - Parte 2 - Métricas de Software(Tamanhos, Funções, Re-Trabalho), Problemas de métricas.
Link Youtube

Aula 6 - Parte 1 - Teoria da Análise orientada a Objetos
Link Youtube

Aula 6 - Parte 2 - Continuação da Análise orientada a Objetos
Link Youtube

Ferramenta Case

A Ferramenta Case (do inglês Computer Aided Software Engeneering), é uma ferramenta que oferece um conjunto de serviços, fortemente relacionados, para apoiar uma ou mais atividades do processo de desenvolvimento de software, em outras palavras, é uma ferramenta cujo objetivo prinicpal é auxiliar a construção de um software de forma mais prática e eficaz.

As ferramentas CASE operam em dois níveis:

* Alto Nível: Ferramentas que auxiliam nas atividades iniciais de requisitos e projetos;

* Baixo Nível: Ferramentas que auxiliam nas atividades de desenvolvimento.

Controle de Processo de Software

O controle da qualidade é definido como um processo e métodos usados para monitorar o trabalho e observar se os requisitos estão sendo satisfeitos. O foco é justamente em revisões e remoção de defeitos antes mesmo do envio dos produtos. O controle da qualidade deve ser de responsabilidade da unidade organizacional que produz o produto. No entanto, é possível ter o mesmo grupo que constrói o produto, que realize também o controle da qualidade, ou estabelecer um grupo de controle da qualidade separado ou departamento dentro da mesma unidade organizacional que desenvolve o produto.

O controle da qualidade consistem de checklists bem definidos em um produto que é especificado no plano de garantia da qualidade. Um exemplos clássico de controle da qualidade são as inspeções de software. A inspeção é o grau mais maduro e formal dentro das revisões, sendo necessária uma preparação prévia, participantes definidos adequadamente e critérios de entrado e saída bem definidos.

O controle da qualidade é projetado para detectar defeitos e corrigir esses defeitos encontrados, enquanto que a garantida da qualidade é orientada através da prevenção de defeitos.

Para o controle do processo podemos definir requisitos, que implicam em:

* Competência para gerir:
* O custo do software;
* O tempo;
* A qualidade.

Já um processo de software sem controle implica em:

* Improvisação;
* Falta de rigor;
* Qualidade ruim;
* Riscos.

Desta forma a empresa acaba em "incêndio", ou seja, ela resolve o problema de forma inadequada.

Modelo McCall

Em 1977, McCall propôs um modelo para a avaliação da qualidade de software. Esse modelo envolve um conjunto de três fatores que avalia o software com relação a três pontos de vista distintos. A seguir o

I - Com relação ao uso do produto (Características Operacionais).

* Corretudide → Medida na qual o software satisfaz as especificações e objetivos visados pelo cliente.

* Confiabilidade → À medida que se pode esperar que um programa execute sua função pretendida com a precisão exigida.

* Eficiência → É a quantidade de recursos computacionais e de código exigida para que um programa execute sua função, com total precisão, visando realizar a operação de forma 100% segura.

* Integridade → Medida na qual, contrala-se o acesso ao software e aos dados, bloqueando assim o acesso de pessoas não autorizadas, para que não ocorra perda de dados ou de código.

* Usuabilidade → Mede a facilidade para a utilização do software.

II - Com relação a alteração do produto (Habilidade para ser alterado).

* Manutenção → O esforço exigido para localizar e reparar erros em um programa.

* Flexibilidade → O esforço utilizado para realizar uma alteração no software, isto é, qual o grau de facilidade que o sw oferece para a sua alteração, de forma rápida e eficaz?

* Testabilidade → São todos os recursos utilizados, no teste do software, isto é, o esforço exigido para testar um programa a fim de garantir que ele execute a função pretendida.

III - Transição do produto (Adaptabilidade a novos ambientes).

* Portabilidade → Mede a facilidade com que um produto pode ser movido para outra plataforma, ou software.

* Reusabilidade → Medida na qual o software, ou parte dele, poder ser reusado em outros softwares, em outras palavras, o código do sw deve ser reaproveitável.

* Interoperabilidade → O software é capaz de ser acoplado ao outro?

Visões de Qualidade de Software

A visão de qualidade de software pode ser enxergda de três modos, que são os seguintes:

Usuário → este, avalia o software sem conhcecer seus aspectos internos, isto é, o usuário esta apenas concentrado na facilidade de uso do software, no seu desempenho, na confiabilidade dos resultados; de uma forma geral, o usuário, vê o software como algo que venha a solucionar o seu problema de forma prática, eficaz e segura.

Desenvolvedor → este, avalia aspectos de conformidade em relação aos requisitos dos clientes e também aspectos internos do software, isto é, um software, cujo tenha facilidade de manutenção e que seja bem codificado, podendo assim ser bem endentido, e reaproveitável.

Organização → esta, avalia aspectos de conformidade em relação aos requisitos dos clientes e desenvolvedores e também aspectos de custo e cronograma, ou seja, deve haver por parte da empres cumprimento de prazo, boa previsão de custo, boa produtividade e portabilidade.

Qualidade de Software

Resumo - Gerenciando a Qualidade de Software com Base em Requistos

Obter qualidade nos processos e produtos de engenharia de software não é uma tarefa tão fácil. São vários os fatores que dificultam atingir os objetivos de qualidade. Mas, o principal objetivo é o software atender a necessidade do usuário, E em muitos casos, muitos recursos são gastos, mas ainda assim ocorre uma grande frustração por parte dos clientes com o produto final. Muitos desses problemas são derivados da falta de atenção na divisão das tarefas durante a produção do software.

Para diminuição desse problema, e o melhoramento da qualidade do software, é necessário usar o chamado baseline de requisitos. Baseline é uma definição que toma por base as necessidades dos clientes, serve de referência para o desenvolvimento de software e está em constante evolução.

CLIQUE AQUI PARA SABER APROFUNDADAMENTE SOBRE BASELINE.

INTRODUÇÃO

Quando se fala em qualidade de software é necessário termos claro que o processo de produção também deve ter qualidade e não apenas o produto software.
Durante muito tempo, a qualidade do software era entendida da seguinte forma:

• Qualidade do produto é função principalmente de teste do produto
final.

• O processo de produção era centrado em fases caracterizadas por produtos bem
definidos.

• Tinha-se uma ênfase na qualidade das representações, isto é nas linguagens artificiais.

De fato, esses aspectos são também essenciais para a qualidade do produto. Todo software precisa dos testes finais que é onde se encontram os erros e os requisitos que se faltam. A escolha de qual linguagem de programação adotar é também um fator importante no processo. Se tem a visão de sequencialidade, onde acredita-se ser a chave para produtos bem definidos.

Hoje tem-se uma visão muito mais abrangente. Primeiro, sabe-se que o processo de produção é fundamental para obtenção de produtos de qualidade. Segundo, tem-se uma visão mais equilibrada dos aspectos essenciais e acidentais da engenharia de software. Terceiro, a sociedade passa a entender melhor os custos relacionados com a evolução do software. Hoje o processo de produção de software é composto por diferentes subsistemas, como Gerência, Análises e outras.

QUALIDADE

O software passou cada vez mais a fazer parte de outros produtos, e assim como eles exige-se qualidade e preço. Esse é o papel da Engenharia: procurar sistemas de melhor qualidade dentro de um custo compatível com essa qualidade, otimizando a redução de custos.

Como foi dito, ela envolve métodos, técnicas e ferramentas para este fim (Clique aqui para ver). O principal objetivo é que o software seja confiável, isto é seja eficaz e siga os padrões exigidos pelo contexto onde irá atuar. Freeman faz uma distinção entre qualidade básica e qualidade extra. Em qualidade básica ele lista: funcionalidade, confiabilidade, facilidade de uso, economia e segurança de uso. Em qualidade extra ele lista: flexibilidade, facilidade de reparo, adaptabilidade, facilidade de entendimento, boa documentação e facilidade de adicionar melhorias. Este tipo de classificação nos fornece uma idéia do que estamos falando, mas é importante ressaltar que dar prioridade à essas qualidades depende de cada caso e do custo de cada uma dessas qualidades. A qualidade deve estar presente não só nos produtos produzidos, como também nos processos utilizados para gerar esses produtos. Assegurar a qualidade dos produtos e dos processos é responsabilidade do subsistema GERÊNCIA, e este dever toda uma equipe onde o auxiliará. Com isso, percebe-se que é também muito importante não esquecer que a produção de software é um processo que envolve, como parte fundamental, seres humanos, portanto o ambiente de trabalho precisa ser o máximo “humanizado”, com tarefas definidas a cada pessoa e ele não se sobrecarregará com todo processo de produção.

REQUISITOS

Engeharia de Requisitos, é uma sub-área da Engeharia de Software, que tem por obejtivo melhorar a modelagem de sistemas e a capacidade de analisá-los, possibilitando assim, maior entendimento de suas características antes da implementação. É seu papel realizar a interação entre requisitantes e desenvolvedores, entre “o que” deve ser feito e “como” deve ser feito. Para isso estabelece um processo no qual é necessário, analisar conflitos, validar, priorizar, modificar e reusar requisitos.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares, 2005):

1 - Indentifição.
2 - Análise e negociação.
3 - Especificação e documentação.
4 - Validação.

Os requisitos de softwares estão dividiso em dois:

1 - Requisitos Funcionais: está diretamente ligado a funcionalidade do software, isto é, uma operação, cujo qualquer usuário pode manter com o software, calcular um média de um aluno, por exemplo.

2 - Requisitos não Funcionais: reflete os requisitos que expressam restrições que o software deve atender ou qualidades específicas que o software deve ter, por exemplo, num sistema acadêmico um aluno não pode ter acesso à alteração de notas, porém pode visualizar as notas.

EVOLUÇÃO

O processo de construção de software será cada dia mais baseado no conceito de evolução, ou seja estaremos sempre modificando algum software já existente, isso quer dizer que o software nunca estará 100% completo, por mais que ele esteja atendendo as necessidades do usuário, é o que chamanos de impossibilidade da completeza.

Acreditamos que para lidar com evolução é fundamental utilizar o conceito de baseline oriundo da área de configuração de sistemas. Um baseline é uma espécie de referencial que utilizamos num processo de mudança, por exemplo, uma 'imagem' de versão de cada artefato no repositório do projeto.

É claro que a complexidade de controlar essa baseline é não trivial, no entanto é uma maneira integrada de tentarmos garantir que a alocação dos requisitos, tanto funcionais como não funcionais seja registrada e rastreável. Assim, é possível efetivamente gerenciar os requisitos, principalmente num contexto volátil.

Qualidade de Software: Teoria e Prática, Orgs. Rocha, Maldonado, Weber, Prentice-Hall, São Paulo, 2001. Capítulo 17.