sauloarruda.eti.br

…revirando até chegar do outro lado…

Proposta para o Agile Brazil 2010

February 28th, 2010

Nos dias 22 a 25 de Junho de 2010 acontecerá em Porto Alegre um grande evento dedicado ao tema Agile, o Agil Brazil 2010. As submissões de palestra tiveram seu prazo aumentado para dia 07/03 pelo site http://submissoes.agilebrazil.com/. Submeti a palestra abaixo e estou na torcida pela aprovação! Aproveite e deixe seus comentários, será de grande valia!

Em 6 meses de imersão ágil o que mudou?

Público alvo
Desenvolvedores e testadores, gerentes de projeto, executivos, entusiastas e iniciantes em métodos ágeis, quem mais tiver interesse!

Resumo
Começamos o ano de 2010 com um desafio: reverter o cenário de baixa produtividade e desmotivação da equipe que estava pairando no ar. Após várias discussões entre as pessoas chave da equipe bolamos um plano e entramos de cabeça em um projeto de agile adoption. Este trabalho mostra os principais resultados e dificuldades deste processo.

Descrição completa
No final de 2009, iniciamos uma reforma na unidade de Campo Grande da Agence. Literalmente o teto caiu e passamos grandes dificuldades com a chuva diária no chão do escritório. A reforma está construindo um segundo andar na nossa sede, mas como todos sabemos, não é nada agradável “morar” em uma casa em reforma.

Além disso, nossa equipe estava pecando no quesito qualidade e prazo em alguns projetos, o que gerou um descrédito por parte da diretoria da empresa. No final do ano, tivemos o desligamento de 3 profissionais, além da insatisfação com as dificuldades no ambiente de trabalho e projetos.

Nesse contexto, reunimos as pessoas chave da equipe e após várias discussões bolamos um plano para adotar desenvolvimento ágil como uma forma de motivação da equipe e melhoria no produto desenvolvido.

O plano abrange 6 meses a começar a partir de janeiro de 2010 e têm metas bastante agressivas que envolve várias mudanças na forma de trabalho, além de sessões semanais de treinamento (tech thursday) e vários finais de semana dedicados à estudos.

A proposta deste trabalho é mostrar nossa experiência na adoção de métodos ágeis em uma equipe de 20 pessoas que trabalha com vários tipos diferentes de projetos: novos sistemas, manutenção e pesquisa & desenvolvimento.

O plano prevê adoção da técnica pomodoro, SCRUM, Behavior Driven Development (BDD), Domain Driven Design (DDD) e Programação em Pares. Ufa! Continuamos com a mão na massa e já estamos colhendo resultados desse trabalho e gostaríamos muito de compartilhar essas experiências com a comunidade.

Mecânica/Processo
Apresentação de slides seguindo a Agenda abaixo:
- Como estávamos no final de 2009?
- Qual nosso plano?
- 1º mês: Pomodoro
- 2º mês: Scrum
- 3º mês: Behavior Driven Development
- 4º mês: Domain Driven Design
- 5º mês: Pair Programming
- 6º mês: E agora?
- Conclusões e resultados

Benefícios
Durante esses 6 meses de projeto, estamos publicando vários artigos, no blog da empresa e individuais, com o objetivo de trocar idéias e mostrar como estamos buscando melhorar nossa forma de trabalho. Acredito na importância da apresentação dessas experiências em um evento dedicado ao assunto, que permitirá excelente troca de idéias com pessoas que também tem os mesmos interesses

Experiência com o assunto
Venho estudando métodos ágeis há pelo menos 3 anos e já aplicando algumas práticas na Agence, que tem um processo mais próximo do “OpenUP”. Já ministrei treinamentos em diversas áreas sempre divulgando métodos ágeis e pregando boas práticas de engenharia e já dei consultoria em algumas empresas para MPS nas áreas de gerenciamento de projetos e requisitos, baseado nos modelos MPS.br e CMMi.

Tags: , , , , , , , , , , , , , , ,
Posted in Agence, Agile, Drops, Eventos | 4 Comments »

Conclusão da Especialização em MPS na UFLA

November 4th, 2009

Neste final de semana finalmente participei do segundo encontro presencial na UFLA (Universidade Federal de Lavras) para conclusão do curso de Especialização em MPS (Melhoria do Processo de Software) que iniciei em 2006. O encontro foi extremamente produtivo visto que havia poucos alunos e com isso temos a oportunidade única de ter consultorias ao invés de aulas com professores de altíssimo nível. Fora que com pouca gente a interação entre os alunos foi infinitamente maior o que com certeza vai promover amizades produtivas.

No sábado eu tive a oportunidade de apresentar meu Trabalho de Conclusão de Curso que trata-se de um artigo entitulado: Gerenciando Projetos de Escopo Aberto – Uma Visão Ágil. Ainda tenho alguns ajustes para fazer, mas já disponibilizei uma prévia do trabalho em PDF e depois atualizo esse post com a versão final (para fazer o download clique no link do nome do trabalho).

É uma pena esse curso ter acabado. Mas já deixo a recomendação de outro curso, na verdade um MBA, que tem como coordenador um dos professores. Trata-se do MBA Gestão da Qualidade em Software com ênfase em CMMI® e MPS.BR da FIAP, e o coordenador é o sensacional Nilson Salvetti.

Como voltei bastante animado do encontro, em breve devo publicar, em parceria com alguns colegas, artigos que estamos preparando sobre teste de integração e gerenciamento de projeto “agile”. Pode me cobrar se eu não enviar! Estou até animado a embarcar em um mestrado na área de Engenharia de Software, e aceito recomendações!

Tags: , , , , , ,
Posted in Agence, Agile, Artigos, Engenharia de Software, MPS | No Comments »

Javaneiros 2008

November 12th, 2008

No último sábado o JUG-MS realizou em Campo Grande o Javaneiros 2008. O Evento contou com 2 tracks de palestras sobre Java e também sobre Engenharia de Software.

Eu apresentei a palestra “Como sobreviver com Java 2?” falando sobre as dificuldades que ainda hoje temos que enfrentar com ambientes (as vezes precários) dos clientes onde temos que instalar nossos sistemas.

Como estava trabalhando na organização, não pude assistir muitas palestras, mas vou dar os comentários sobre aquelas que vi:

Implantando MPS.br com Wilson Pinto e Antonio Felicio: Meus ex-colegas da DígithoBrasil apresentaram como foi o processo de implantação do MPS.br na empresa. Mostraram uma visão geral sobre o projeto e os resultados obtidos no curto prazo. Bastante interessante a apresentação apesar de não ter dado muita gente.

Integração Contínua  – cuidando de softwares “doentes” com Jefferson Moreira (JEFFMOR): Excelente apresentação do Jefferson sobre implementação de integração contínua, inclusive com alguns exemplos de testes funcionais usando o Selenium.

Tecnologias para implementação de NF-e em Java com Edilmar Alves: Apresentação bastante detalhada sobre implementação de Notas Fiscais Eletrônicas em Java. Foi ótimo da parte do Edilmar mostrar os problemas que eles tiveram com a implementação e disponibilizar componentes Open Source que resolve.

No site do JUG-MS tem fotos e os slides de todas as palestras.

Agora é só aguardar o Javaneiros 2009!

Tags: , , , , , , , , , , , , , ,
Posted in Drops | 1 Comment »

Como medir produtividade em projetos de software?

May 28th, 2008

Planejar e controlar projetos de software são atividades que boa parte das empresas tem conseguido desempenhar em seu processo de desenvolvimento. Porém, medir qual desenvolvedor é mais produtivo, re-alimentar o processo de estimativa e coletar informações para tomada de decisão quando o projeto “sai dos trilhos” é uma tarefa bastante complicada.

Neste artigo, vou apresentar a experiência que implantamos na área de Produção de Software da Agence para medição da produtividade.

Primeiro Passo: Estimativa

Qualquer planejamento de projeto de software é elaborado com base em uma estimativa, especialmente em “Fábricas de Software” que muitas vezes trabalham com projetos de escopo fechado e orçamento pré-definido.

Na Agence, usamos basicamente três métodos para estimar o tamanho de um projeto:

Para pequenos projetos, inferiores a 300 horas, usamos uma Planilha de Estimativa onde são estimadas horas de trabalho para cada uma das disciplinas da Engenharia de Software (análise e projeto, requisitos, codificação, testes, implantação, etc.). Este método é bastante simples, mas exige experiência do profissional que faz a estimativa, é bastante suscetível a falhas e é calçado em um histórico de experiências anteriores do mesmo tipo.

Para projetos maiores, usamos contagem de Pontos por Função e/ou de Pontos por Caso de Uso. Esses métodos têm o embasamento científico de várias pesquisas com projetos de empresas diferentes e devem ser calibrados pela complexidade e natureza do projeto e também pela qualidade da equipe.

Segundo Passo: Planejamento

Com a estimativa em mãos, é hora de planejar o projeto. Na Agence trabalhamos com o modelo Iterativo e Incremental de ciclo de vida. Logo, a primeira fase do planejamento é definir as iterações do projeto e quais artefatos serão entregues em cada uma.

Seguindo o princípio do Unified Process (UP), temos quatro fases no ciclo de vida do projeto: Iniciação, Elaboração, Construção e Transição.

A fase de Iniciação na maioria dos casos refere-se à prospecção do projeto junto ao cliente e não possui um planejamento formal. Nesta fase o Consultor de Negócio (figura do Analista de Requisitos) entrevista o cliente, documenta os requisitos e prototipa a solução. Nesta fase o projeto é estimado e uma proposta apresentada ao cliente. Se o cliente aprovar, o projeto continua.

Na fase de Elaboração, o planejamento do projeto como um todo é elaborado. Além disso, o Modelo de Casos de Uso é detalhado e a Arquitetura da Solução é desenvolvida. Nesta fase, existe uma maior participação do Gerente de Projeto, Analista de Requisitos e Arquiteto.

A partir da fase de Construção que o trabalho pesado começa. Nesta fase, há sempre uma versão utilizável do sistema (ou incremento) produzida por mês, independente do tamanho do projeto ou da equipe. Essa entrega da versão formaliza o término de uma iteração e início de outra.

Na fase de Transição, o software é instalado em ambiente de homologação/produção e avaliado pelo cliente e usuários final. Muitas vezes são executados testes de carga e stress, projetos pilotos da operação do sistema e treinamentos.

Terceiro passo: Controle

Diariamente, os profissionais fazem seu trabalho e registram as horas gastas em uma ferramenta de controle de projetos. No final de cada iteração o Gerente de Projeto mede os registros de trabalho dos profissionais e compara com os valores inicialmente estimados.

Naturalmente, o cliente fará uma avaliação da versão entregue no término da iteração e novas pendências podem aparecer. O tempo para os ajustes geralmente está contabilizado na estimativa para o desenvolvimento da funcionalidade.

Mas o ponto é, para medir a produtividade, é necessário dividir a quantidade de horas de trabalho pelo tamanho em pontos (de função ou casos de uso) da funcionalidade. Por exemplo, se o desenvolvedor codificou uma funcionalidade que totaliza 5 pontos de função (PF) em 40 horas (h), sua produtividade é de 40 h / 5 PF = 8 h/PF (lê-se quatro horas por ponto de função). Desta forma é possível obter uma produtividade média da equipe e avaliar os desenvolvedores que têm um desempenho menor ou maior.

É importante salientar que quando a estimativa é feita, é normal que se tenha 12 h para cada PF. Esse tempo, porém, é dividido entre todas as atividades do processo de desenvolvimento: codificação, testes, análise e projeto, requisitos, gerenciamento, implantação, etc. Logo, se for considerado apenas o tempo de codificação, consideramos de 40 a 50% do tempo estimado para cada PF. Assim, uma funcionalidade que tenha 2 PF, com a relação de 12 h por PF na estimativa, não pode gastar mais que 12 horas com codificação, incluindo os ajustes solicitados pelo cliente. Logo, um desenvolvedor com a produtividade de 8 h/PF não é uma boa média, que será, no máximo, 6 h/PF.

De posse dessas informações, é possível, já inicio do projeto, tomar atitudes para evitar atrasos no cronograma ou prejuízos financeiros. No término no projeto, essas informações servem de base para próximas estimativas, definido um fator de horas por ponto de função ou de caso de uso aplicável para a empresa em determinados tipos de projetos.

E na prática?

Em um próximo artigo, vou apresentar uma forma de medir produtividade na prática usando a ferramenta Jira. Para quem não conhece, o Jira é uma ferramenta paga, porém com preço bastante acessível, para controle de pendências e gerenciamento de projetos. Até lá!

Tags: , , , , , ,
Posted in Agile, Artigos, Engenharia de Software, MPS | 2 Comments »

Ótimo artigo sobre Desenvolvimento Ágil

May 2nd, 2007

Um cidadão chamado Mateus Velloso resolver falar mal de CMMI. Ele é louco? (Deixo a resposta para vocês…). Leia o artigo na íntegra.

Tags: , , ,
Posted in Agile, Artigos, Drops, Engenharia de Software, MPS | 1 Comment »

ISO/IEC 9001:2000 e Desenvolvimento de Software

January 30th, 2007

Hoje, li um depoimento sobre o processo de implantação de um sistema de gestão da qualidade conforme os requisitos da Norma ISO/IEC 9001:2000 em uma empresa que desenvolve software. O autor é Cláudio Testoni Cardozo, responsável pelo setor de desenvolvimento da empresa Constat.

Minha opinião sobre o assunto: Eu acho que a implantação de um sistema de gestão da qualidade é o primeiro passo para uma empresa que deseja melhorar seus processos. Explico: em geral, as empresas que desenvolvem software não têm a cultura de definir seus processos, isto é, nós sabemos fazer software, mas constantemente mudamos nossa forma de trabalho com boas intenções. Logo, quando os desenvolvedores são questionados sobre como as coisas são feitas, geralmente as respostas são contraditórias. Até aí, nada grave, os céticos dizem. O software é “produzido“, o cliente é “atendido“, os desenvolvedores estão “satisfeitos“…

Pouco tempo depois, o gerente de projeto é questionado a respeito da baixa produtividade da equipe. Ok, todos sabemos que a produtividade em software é realmente muito baixa. Mas, alguém sabe dizer o quão baixa? Ou quem sabe estabelecer metas para aumento da produtividade? Que seja, medir a produtividade?

Neste ponto, o sistema de gestão da qualidade apresenta resultados, diferentemente do que várias pessoas pensam – que a certificação ISO 9001 (e isso se aplica a outros modelos como CMMI ou mps.BR) servirá para burocratizar o processo de desenvolvimento de software – quando na verdade a principal função é medir. Medir para Analisar. Analisar para Melhorar. A melhoria de processos se dá com base em números e não com base em fatos.

Logo, a necessidade de padronizar o processo se dá pela necessidade de medir. Não é possível comparar dois produtos produzidos por processos diferentes. OK, temos nosso processo definido. Agora, o que foi definido deve ser aplicado e aí entra o setor de Garantia da Qualidade que nada mais faz do que garantir que as coisas estão sendo feitas como está escrito que elas deveriam ser feitas.

Não estendendo mais o assunto, a empresa que tem interesse em melhorar processos têm na norma ISO/IEC 9001:2000 um grande aliado quanto a requisitos para a implementação de um sistema de gestão da qualidade. A pergunta final é: Porque ISO/IEC 9001:2000? Não poderia usar CMMI ou mps.BR? A resposta é SIM, poderia. Porém a implementação da ISO 9001 é muito mais simples, basta que a empresa documente como ela trabalha (não sendo necessário na maioria das vezes mudar a forma de trabalho) e criar indicadores para medir o desempenho da produção. Enquanto em modelos como o CMMI e mps.BR, várias práticas devem ser implementadas com metas e resultados que devem ser respeitados, o que, na maioria dos casos irá interferir na forma que a empresa trabalha.

A vantagem de implantação de ISO/IEC 9001:2000 ANTES de outros modelos é a criação de uma cultura voltada à qualidade, que é uma das tarefas mais difíceis da implementação de CMMI ou mps.BR.

Tags: , , , ,
Posted in Artigos, Engenharia de Software, MPS | 2 Comments »

livro: Nosso iceberg está derretendo

January 29th, 2007

Mais uma recomendação de livro: “Nosso iceberg está derretendo” de John Kotter e Holder Rathgeber. Este livro fala sobre mudança através de uma fábula sobre pingüins que vivem em um iceberg que está prestes a despedaçar-se em pedaços menores. O livro apresenta um método de Kotter que ele chama de “O processo da mudança bem-sucedida”. Este processo consiste em 8 passos para a mudança, vou transcrever na íntegra aqui, é bastante interessante:

Crie a estrutura

1. Demonstre a urgência. Ajude os outros a ver a necessidade de mudança e a importância de uma ação imediata.
2. Reúna a equipe orientadora. Certifique-se de que um grupo seguro orientará a mudança – um grupo com habilidades de análise e liderança, credibilidade, capacidade de comunicação e consistência da urgência.

Decida o que fazer

3. Desenvolva a visão da mudança e a estratégia. Esclareça como o futuro será diferente do passado e como é possível torná-lo realidade.

Faça acontecer

4. Comunique-se para ser entendido e apoiado. Faça com que o maior número possível de pessoas entenda e aceite a estratégia.
5. Divida as responsabilidades. Remova o máximo possível de obstáculos, facilitando a ajuda de todos que querem tornar realidade a mudança.
6. Demonstre vitórias em curto prazo. Divulgue os sucessos sempre que eles aconteçam, sejam grandes ou pequenos.
7. Não relaxe. Pressione cada vez mais após os primeiros sucessos. Inicie a mudança após mudança até que o objetivo se torne realidade

Solidifique a mudança

8. Crie uma nova cultura. Reforce os novos comportamentos e certifique-se de que serão bem-sucedidos até se tornarem suficientemente fortes para substituir as antigas tradições.

Lendo este livro percebi que a proposta de Kotter é bem parecida com abordagens para Melhoria de Processo que tenho estudado, por exemplo:

  • PDCA [1]: Plan (Planejar), Do (Implementar), Check (Verificar), Act (Agir corretivamente);
  • IDEAL [2]: Início, Diagnóstico, Estabelecimento, Ação, Aprendizado;

Logo, abordagens para Melhoria de Processos exigem muitas mudanças, desde culturais, organizacionais e até mesmo de infra-estrutura sendo que o método de Kotter também pode trazer bons ensinamentos nesta área.

Recomendo a leitura do livro, tem fontes bem grandes e várias figuras. Eu li o livro todo em menos de uma hora. É bom para quem não gosta de ler.

Referências:

  • KOTTER, John; RATHGEBER, Holger. Nosso iceberg está derretendo. 1ª Edição, Best Seller: 2005, ISBN 857684172X
  • [1] DEMING, W. Edward. Out of the Crisis. Cambridge, MIT
    Center for Advanced Engineering Study: 1986, ISBN 0911379010.
  • [2] McFEELEY, Bob. IDEAL – A User’s Guide for Software process
    Improvement. Handbook CMU/SEI-96-HB-001: 1996, Disponível em http://www.sei.cmu.edu/publications/documents/96.reports/96.hb.001.html.
  • Resenhas no Submarino.com.br
  • Comentário sobre o livro no blog Anklan.Net

Tags: , , ,
Posted in Liderança, Livros, MPS, Reviews | No Comments »

ISO/IEC 12207 Processos Fundamentais

November 27th, 2006

Introdução

Atualmente, cada vez mais sistemas são controlados por software, desde o aparelho celular até armamentos de guerra. O desenvolvimento de software representa o maior custo para a maioria dos produtos, superando os custos de produção do hardware e até mesmo do transporte.

Com isso, a indústria do software vem tentando superar a grande demanda por produtos de qualidade, visto que o processo de software nas empresas em geral ainda se apresenta bastante imaturo e de baixa capacidade. Organizações globais como ISO (Institute of Organization for Standardization), IEEE (Institute of Electrical and Electronics Engineers), PMI (Project Management Institute), SEI (Software Engineering Institute), entre outros vêm propondo uma série de modelos e padrões visando a melhoria do processo de produção de software.

Norma ISO/IEC 12207

A Norma ISO/IEC NBR 12207 foi criada pela ISO (Institute of Organization for Standardization) e o IEC (International Electrotechnical Commission) dentro de um esforço conjunto dessas organizações. A ISO/IEC 12207 teve seu desenvolvimento proposto em 1988 e a primeira versão foi publicada em agosto de 1995 e em 1998 foi publicada a versão brasileira. Em 2002 e 2004 foram feitas atualizações na norma gerando as ementas 1 e 2 respectivamente [Machado, 2006].

O objetivo da ISO/IEC 12207 é estabelecer uma estrutura comum para os processos de ciclo de vida de software, com uma terminologia bem definida, que pode ser referenciada pela indústria de software. A estrutura contém processos, atividades e tarefas que servem para ser aplicadas durante a aquisição de um sistema que contém software, de um produto de software independente ou de um serviço de software, e durante o fornecimento, desenvolvimento, operação e manutenção de produtos de software [NBR ISO/IEC 12207, 1998].

O escopo da ISO/IEC 12207 abrange todo o ciclo de vida de software, desde sua concepção até a descontinuidade do projeto de software, e por todos os envolvidos com produção, manutenção e operação do software. A norma pode ser aplicada para toda a organização, mas existem casos de aplicação em projetos específicos por imposição contratual ou nas fases iniciais de implantação [NBR ISO/IEC 12207, 1998].

Os processos da ISO/IEC 12207 são agrupados de acordo com sua natureza, ou seja, o seu objetivo principal no ciclo de vida de software. Este agrupamento resultou nas 3 classes de processos a seguir: Processos Fundamentais, Processos de Apoio e Processos Organizacionais. A figura 1 apresenta os processos de cada classe. Este artigo aborda apenas os Processos Fundamentais.

Figura 1. Processos da ISO/IEC 12207 [Machado, 2006]

Processos Fundamentais

Os Processos Fundamentais são basicamente todas as atividades que a empresa executa nos serviços de desenvolvimento, manutenção ou operação de software. Esses processos comandam a execução de todos os outros processos. Os cinco processos fundamentais de ciclo de vida são:

  • Aquisição;
  • Fornecimento;
  • Desenvolvimento;
  • Operação; e
  • Manutenção.

Na prática, o processo de Aquisição inicia o ciclo de vida de software. O processo de Fornecimento responde sobre a execução dos processos de Desenvolvimento, Operação e/ou Manutenção [Machado, 2006].

Aquisição

O Processo de Aquisição define as atividades a serem executadas pela organização de adquire ou sub-contrata um produto ou serviço de software. O propósito do Processo de Aquisição é obter um produto e/ou serviço que satisfaça a necessidade expressa pelo cliente. O processo inicia com a identificação de uma necessidade do cliente e termina com a aceitação do produto e/ou serviço [NBR ISO/IEC 12207, 1998].

A ISO/IEC 12207 define o propósito e os resultados para os sub-processos de Preparação para Aquisição, Seleção de Fornecedor, Monitoração do Fornecedor e Aceitação pelo Cliente.

Fornecimento

O Processo de Fornecimento é a sustentação para a execução dos processos de desenvolvimento, manutenção e/ou operação do produto ou serviço de software. O processo se inicia na preparação de uma proposta para atendimento de um pedido de proposta de um adquirente e encerra-se com a entrega do produto ou serviço de software. O propósito do Processo de Fornecimento é estabelecer um produto ou serviço para o cliente que atenda os requisitos acordados [NBR ISO/IEC 12207, 1998].

A ISO/IEC 12207 define o propósito e os resultados para os sub-processos de Proposta do Fornecedor, Acordo Contratual, Liberação do Produto e Suporte à Aceitação do Produto.

Desenvolvimento

O Processo de Desenvolvimento contém as atividades e tarefas para o desenvolvimento do software, dentre elas: Elicitação de requisitos, análise de requisitos, projeto, construção, integração, testes e instalação.

O propósito do Processo de Desenvolvimento é transformar um conjunto de requisitos em um produto de software ou um sistema baseado em software que atenda às necessidades explicitadas pelo cliente [NBR ISO/IEC 12207, 1998].

A ISO/IEC 12207 define o propósito e os resultados para os sub-processos de Elicitação de Requisitos, Análise dos Requisitos do Sistema, Projeto da Arquitetura do Sistema, Análise dos Requisitos do Software, Projeto do Software, Construção do Software, Integração do Software, Teste do Software, Integração do Sistema, Teste de Sistema e Instalação do Software

Operação

O Processo de Operação contém as atividades e tarefas para a operação do software e suporte operacional aos usuários. O propósito do Processo de Operação é operar o produto de software no seu ambiente e fornecer suporte aos clientes desse produto [NBR ISO/IEC 12207, 1998].

A ISO/IEC 12207 define o propósito e os resultados para os sub-processos de Uso Operacional e Suporte ao Cliente.

Manutenção

O Processo de Manutenção é ativado quando o produto de software é submetido a modificações no código e na documentação associada devido a um problema ou a uma necessidade de melhoria ou adaptação. Seu objetivo é modificar o produto de software garantindo sua integridade. Este processo ainda inclui as possibilidades de migração e descontinuidade do produto de software.

O propósito do Processo de Manutenção é modificar um produto de software ou sistema após a sua entrega apara corrigir falhas, melhorar o desempenho ou outros atributos, ou adaptá-lo a mudanças do ambiente [NBR ISO/IEC 12207, 1998].

Conclusão

A Norma ISO/IEC 12207 tem sido muito utilizada para apoiar as organizações a definirem seus processos de ciclo de vida de desenvolvimento, operação e manutenção de software. Um dos pontos fortes da norma é a alta granularidade dos processos permitindo a definição de vários processos pequenos que serão integrados na sua execução.

Além disso, a ISO/IEC 12207 foi utilizada como base para a elaboração da norma ISO/IEC 15504-5:2006 que define um modelo para a avaliação de processos de software baseado no framework da norma ISO/IEC 15504.

Referências

[NBR ISO/IEC 12207, 1998] ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ISO/IEC 12207 – Tecnologia da Informação – Processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1996.

[Machado, 2006] MACHADO, Cristina F. Definindo Processos do Ciclo de Vida de Software Usando a Norma NBR ISO/IEC 12207 e Suas Ementas 1 e 2. Lavras: UFLA/FAEPE, 2006.

Tags: , , , , , , , ,
Posted in Artigos, MPS | No Comments »

■  Designed by Danial Keshani | Cubex.nl | sauloarruda.eti.br | …revirando até chegar do outro lado…