Engenharia de Requisitos, Manutenção Corretiva e Acordo de Nível de Serviço.



Documentos relacionados
CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos

Universidade Paulista

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

Projeto de Sistemas I

ATO Nº 233/2013. A PRESIDENTE DO TRIBUNAL REGIONAL DO TRABALHO DA 7ª REGIÃO, no uso de suas atribuições legais e regimentais,

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião

Gerenciamento de Níveis de Serviço

PROFESSOR: CRISTIANO MARIOTTI

Desenvolvimento de um software de gerenciamento de projetos para utilização na Web

Governança de T.I. Professor: Ernesto Junior Aula IV Unidade II

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Governança de TI. ITIL v.2&3. parte 1

SLA - Service Level Agreement (Acordo de Nível de Serviço) Gerenciamento de Estoque

Exame de Fundamentos da ITIL

SETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014.

SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE INCIDENTE

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

Gledson Pompeu 1. Cenário de TI nas organizações. ITIL IT Infrastructure Library. A solução, segundo o ITIL

Modernização e Evolução do Acervo de Software. Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br

CAPITAL DE GIRO: ESSÊNCIA DA VIDA EMPRESARIAL

ITIL - Information Technology Infraestructure Library

Conhecimento em Tecnologia da Informação. CobiT 5. Apresentação do novo framework da ISACA Bridge Consulting All rights reserved

Projeto Você pede, eu registro.

Engenharia de Software

ITIL v3 - Operação de Serviço - Parte 1

Disciplina: Administração de Departamento de TI. Professor: Aldo Rocha. Aula IX - 28/04/2011

PÁGINA 4 ITIL V.2 & ITIL V.3

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Gerenciamento de Problemas

15/09/2015. Gestão e Governança de TI. Modelo de Governança em TI. A entrega de valor. A entrega de valor. A entrega de valor. A entrega de valor

Profa. Gislaine Stachissini. Unidade III GOVERNANÇA DE TI

GARANTIA DA QUALIDADE DE SOFTWARE

Requisitos de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

Sistemas de Gerenciamento de Banco de Dados

Engenharia de Software

MASTER IN PROJECT MANAGEMENT

Garantia de Processo Leis de Lehman Manutenção de Softwares

DIRETORIA DE GESTÃO DE TECNOLOGIA DA INFORMAÇÃO COORDENAÇÃO DE SISTEMAS DE INFORMAÇÃO

Metodologia de Desenvolvimento de Sistemas

Fundamentos em Teste de Software. Vinicius V. Pessoni

Processo de Desenvolvimento de Software

Engenharia de Software

Processos Técnicos - Aulas 4 e 5

Disciplina: Administração de Departamento de TI. Professor: Aldo Rocha. Aula I - 11/08/2011

Gestão da Qualidade em Projetos

Roteiro SENAC. Análise de Riscos. Monitoramento e Controle de Riscos. Monitoramento e Controle de Riscos. Monitoramento e Controle de Riscos

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO

CAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes

A PRESIDENTE DO TRIBUNAL REGIONAL DO TRABALHO DA 11ª. REGIÃO, no uso de suas atribuições legais e regimentais,

Introdução à Computação

Gerenciamento de Incidentes

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

RELATÓRIO SOBRE A GESTÃO DE RISCO OPERACIONAL NO BANCO BMG

Ciência da Computação ENGENHARIA DE SOFTWARE. Recursos e Cronograma

Estrutura de Gerenciamento do Risco Operacional

P4-MPS.BR - Prova de Conhecimento do Processo de Aquisição do MPS.BR

Superioridade do Linux sobre Windows no quesito segurança

TRIBUNAL SUPERIOR DO TRABALHO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO ORDEM DE SERVIÇO Nº 1/SETIN, DE 30 DE SETEMBRO DE 2010

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Processos de Desenvolvimento de Software

Gerenciamento de Projetos Modulo IX Qualidade

Curso Fundamentos de Gerenciamento de Serviços de TI baseado no ITIL V3

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

FATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios

Engenharia de Software II: Desenvolvendo o Orçamento do Projeto. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

ITIL. Conteúdo. 1. Introdução. 2. Suporte de Serviços. 3. Entrega de Serviços. 4. CobIT X ITIL. 5. Considerações Finais

18/08/2015. Governança Corporativa e Regulamentações de Compliance. Gestão e Governança de TI. Governança Corporativa. Governança Corporativa

A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11

Service Level Management SLM. Gerenciamento de Níveis de Serviço

ENGENHARIA DE SOFTWARE I

Fundamentos de Teste de Software

Gerenciamento de Projetos no Marketing Desenvolvimento de Novos Produtos

CLOUD. tendências CLOUD. entendendo e contratando assertivamente. Agosto/2012 INFORMATIVO TECNOLÓGICO DA PRODESP EDIÇÃO 02

GERÊNCIA DE INTEGRAÇÃO DO PROJETO

CENTRAL DE SERVIÇOS APOIADA EM SOFTWARE LIVRE

Estratégia de TI. Posicionamento Estratégico da TI: como atingir o alinhamento com o negócio. Conhecimento em Tecnologia da Informação

PLANO DE GERANCIAMENTO DO RELEASE Release:

PLANOS DE CONTINGÊNCIAS

MRP II. Planejamento e Controle da Produção 3 professor Muris Lage Junior

MÉTRICAS DE SOFTWARE

Plano de Continuidade de Negócios

UNIVASF - Universidade Federal do Vale do São Francisco Manutenção de Software

CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação

APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2

Aplicações da FPA em Insourcing e Fábrica de Software

Fábrica de Software 29/04/2015

Transcrição:

Engenharia de Requisitos, Manutenção Corretiva e Acordo de Nível de Serviço. Nilton Ferreira Caetano, Francinaldo de Paula Santos, Thiago Lopes de Godoi Barbosa Centro Universitário de Brasília (UNICEUB) SEPN 707/907 70.790-075 Brasília DF Brasil necrossomus@gmail.com, francinaldof@hotmail.com, tlgodoi@gmail.com Resumo: O presente artigo trata de uma relação entre Engenharia de Requisitos, Manutenção Corretiva e o Acordo de Nível de Serviço. A Engenharia de Requisitos é um ramo da Engenharia de Software que engloba todas as atividades que contribuem para a produção de um documento de requisitos de software. O documento de requisitos de software é útil durante o tempo em que o software é utilizado, pois serve de apoio as Manutenções Corretivas que ele sofrerá. A Manutenção Corretiva que variavelmente pode ocorrer, visa corrigir as falhas nas funcionalidades do software e dos requisitos mal especificados. O Acordo de Nível de Serviço (ANS ou SLA, do inglês Service Level Agreement) é um contrato assinado entre a área de Tecnologia da Informação e seu cliente, visando definir prioridades, etapas, responsáveis, regras, penalidades, multas, fornecedores, etc. Inclui o que é necessário para suporte às Manutenções Corretivas do software. Como resultado, demonstrase que estes três assuntos podem ajudar nas Manutenções Corretivas dos softwares. Palavras-Chave: Engenharia de Requisitos (ER), Acordos de Nível de Serviço (ANS), Manutenção Corretiva e Tecnologia da Informação (TI). 1. Introdução

2 Atualmente é uma grande preocupação a qualidade dos softwares das empresas que o foco não é a área de Tecnologia da Informação (TI). A preocupação está ligada em manter a confiabilidade, atrair mais clientes a fim de expandir seus negócios, atender questões de legislação e corrigir problemas. Nesse contexto, é importante uma estratégia que mantenha o software disponível a seus usuários, mas também um software com qualidade e de acordo com a necessidade do momento. Entender os requisitos das necessidades das empresas, entretanto é uma das tarefas mais difíceis enfrentadas por um Engenheiro de Software na manutenção. Em muitos casos, os usuários responsáveis pelo software já saíram das empresas, ou não existe nenhum documento que contenha as regras do software ou ainda pode ocorrer à má qualidade do software. (Lientz e Swanson, 1980), (Dekleva, 1992), (Dart et al., 2001). A Engenharia de Requisitos como todas as outras atividades da Engenharia de Software, precisa ser adaptada às necessidades do processo, do projeto, do produto e do pessoal que está fazendo o trabalho de manutenção do software. A Engenharia de Requisitos fornece subsídios para manutenção do software, permitindo à equipe responsável pela manutenção examinar: o contexto do trabalho necessário a ser executado; as necessidades específicas que a manutenção precisa satisfazer; as prioridades do trabalho que devem ser completadas em primeiro, as funções e os comportamentos que terão um impacto profundo com a manutenção do software (PRESSMAN, 2006). Há mais de três décadas, a manutenção de software foi caracterizada como um iceberg. No início dos anos 1970, o iceberg de manutenção era suficientemente grande para afundar um porta-aviões. Hoje, poderia facilmente afundar toda a Marinha (PRESSMAN, 2006). A manutenção de software existente pode ser responsável por mais de 60% de todo o esforço despendido por uma organização de desenvolvimento, e a porcentagem continua a crescer à medida que mais softwares são produzidos. Utilizando o princípio de Pareto (VALE, 2010) onde apenas 20% de todo o trabalho de manutenção é gasto consertando erros. Os restantes 80% são gastos adaptando sistemas existentes a modificações no seu ambiente

3 externo, fazendo melhorias solicitadas por usuário se submetendo uma aplicação a reengenharia (PRESSMAN, 2006). Em destaque esta atividade de Manutenção Corretiva de software que é caracterizada pela modificação de um produto de software já entregue ao cliente. Isso serve para a correção de eventuais erros, melhora em seu desempenho, ou qualquer outro atributo, ou ainda adaptações desse produto a um ambiente modificado (PADUELLI, 2011). A partir das necessidades de manutenção, são adotados os Acordos de Nível de Serviço (ANS). Eles têm por finalidade formalizar os termos para manter um software em funcionamento, definindo os tópicos mínimos aceitáveis para que um determinado um software possa atender de modo eficiente a seus usuários e as formas e procedimentos a se adotar em casos de adversidades, visando à continuidade da funcionalidade do software com qualidade. 2. Metodologia A metodologia adotada no artigo baseia-se na pesquisa bibliográfica. A pesquisa pode ser considerada um procedimento formal com método de pensamento reflexivo que requer um tratamento científico e se constitui no caminho para conhecer a realidade ou para descobrir verdades parciais. Significa muito mais do que apenas procurar a verdade: é encontrar respostas para questões propostas, utilizando métodos científicos (LAKATOS, 1992). 3. Engenharia de Requisitos A Engenharia de Requisitos é um ramo essencial da Engenharia de Software. Hoje, em amplo crescimento no mercado, nasceu da necessidade de se criar métodos e técnicas com o intuito de otimizar e racionalizar a forma do estudo de viabilidade, elicitação, análise, validação, gerenciamento dos requisitos na construção e manutenção de software. O Objetivo do processo de Engenharia de Requisitos é criar e manter um documento de requisitos do software (SOMMERVILLE, 2010).

4 4. Manutenção Corretiva A manutenção de um software é um processo geralmente de mudanças depois que o software é entregue para utilização dos seus usuários. Existem três tipos diferentes de manutenções de software (SOMMERVILLE, 2010).: Manutenção Corretiva: Aquela que se presta a reparar defeitos de software. Manutenção Adaptativa: Aquela que se presta a adaptar o software a um ambiente operacional diferente. Manutenção Evolutiva: Aquela que se presta a adicionar funcionalidade ao software ou modificá-lo para atender a evolução do negócio ou mudanças organizacionais. Por se tratar de uma porcentagem de apenas 20% do universo das manutenções existentes a corretiva não deixa de ser importante no ciclo de vida de um software, pois como se sabe há necessidade constante de reparos por falhas ocasiodas por fatores diversos muitas vezes ligados a Murphologia. Murphologia é a ciência que estuda a Lei de Murphy, inclui seus corolários e engloba todas as frases derivadas da primeira Lei. Exemplo (VALE, 2010): Qualquer programa quando começa a funcionar já está obsoleto. Só quando um programa já está sendo usado a seis meses é que se descobre um erro fundamental. A complexidade do programa cresce até exceder a competência do programador. A manutenção começa quase sempre imediatamente. O software é liberado para os usuários finais e em alguns dias, os relatos de bugs começa, a chegar a organização de Engenharia de Software. (PRESSMAN, 2006). 5. Acordo de Nível de Serviço O Acordo de Nível de Serviço (ANS ou SLA, do inglês Service Level Agreement) que é parte integrante do Gerenciamento de Nível de Serviço, que é uma das disciplinas do Framework ITIL, pode ser classificado em três modalidades (FREITAS, 2010):

5 Acordos baseados no Serviço: abrange um nível de serviço único para todos os clientes que utilizam esse serviço. Acordos baseados no Cliente: abrange todos os serviços entregues a um único cliente. Acordos Multinível: acordos realizados sob uma das três estruturas possíveis (FREITAS, 2010): Nível Corporativo: cobre todos os aspectos do nível de serviço para cada cliente de uma única empresa. Nível de Cliente: cobre todos os aspectos relevantes a um grupo particular de clientes ou unidades de negócio que compartilham um serviço em comum. Nível de Serviço: cobre todos os aspectos relevantes de um serviço específico entregue a um grupo específico de clientes com o mesmo nível de serviço exigido. 6. Relação entre os Assuntos O desafio da manutenção de software começa a partir do momento que surge uma fila de correções de problemas, solicitações de adaptações e melhorias que devem ser planejadas, programadas e por fim, executadas. Com o passar do tempo, descobre-se que se está gastando mais com a manutenção de programas do que criando novas aplicações. Não é raro uma organização de software depender de 60% a 70% de todo o seu recurso com manutenção de software (PRESSMAN, 2011). No caso específico da Manutenção Corretiva é essencial que haja uma suportabilidade do software. Define-se, estatisticamente, que uma média de 75% do total de recurso alocados a manutenção geral, cerca de 19% dos gastos são alocados para a Manutenção Corretivas nas organizações. Para suportar efetivamente software de classe industrial, a organização deve ser capaz de fazer correções inerentes à atividade de manutenção. Além disso, a organização deve executar outras atividades importantes que incluem suporte operacional continuando muitas vezes celebrados por Acordos de Nível

6 de Serviço, suporte ao usuário final e atividades de reengenharia durante toda vida útil do software (PRESSMAN, 2011). Essencialmente a suportabilidade é um dos muitos fatores de qualidade que devem ser considerados durante a análise e projeto na gestão de qualidade. Ela deve ser tratada como parte do modelo de requisitos (ou especificações) é considerada conforme o projeto evolui e a construção se inicia. Os Acordos de Nível de Serviço possuem as regras de atendimento, as classificações, os prazos, os envolvidos, as multas e as penalidades. Em suma, as definições contratuais para o atendimento das Manutenções Corretivas. Os Acordos de Nível de Serviço voltados a software são, por natureza, ligados a suportabilidade, que é um tópico da qualidade, são válidos como contratos entre a empresa que a produz e mantém software e os seus clientes, os que irão se beneficiar de seus produtos. Os Acordos de Nível de Serviço possuem cláusulas referentes à área responsável pela disponibilidade do serviço, se portar ou agir em caso de descontinuidade do serviço ou falhas de software que possam comprometer o processo. São definidos planos de contingências como restauração de backups, versões emergenciais do software, equipes de reparo, banco de dados de incidentes e falhas, parcerias de resolução de problemas, além de equipes de validação e testes que simulam falhas e estimam o retorno do serviço ou sistema de modo a não afetar o processo de modo negativo. A finalidade dos Acordos de Nível de Serviço é manter a continuidade do serviço, em suma, a sua disponibilidade de uso do software. Nesse contexto, é importante que haja uma documentação clara e atualizada não só do processo, mas do software e seu plano de contingência, ao qual se poderá acionar em caso de indisponibilidade do serviço ou falhas de software a fim de não comprometer o processo. Nesse ponto, a Engenharia de Requisitos irá suprir a documentação necessária e será anexada aos Acordos de Nível de Serviço para, em caso de necessidade, ser utilizada no intuito de solucionar incidentes ou auxiliar na resolução de problemas.

7 7. Conclusa o Em vista disso surgem as seguintes perguntas: Como podemos prever um prazo de atendimento para uma Manutenção Corretiva?; O que será prejudicado com a Manutenção Corretiva?; Onde esta a regra de negócio necessária para a Manutenção Corretiva? Como responder estas perguntas sem um software documentado com base nos conceitos fornecidos pela Engenharia de Requisitos e um Acordo de Nível de Serviço, nesta situação fica muito complicado manter um software. A Engenharia de Requisitos tem papel essencial nesse contexto, pois é justamente por meio dos seus insumos, que são as informações necessárias não só para manter o software documentado e atualizado, mas também para poder efetuar ajustes e correções, a fim de melhorar o software da empresa. O Acordo de Nível de Serviço disponibiliza todas as informações necessárias para o atendimento das Manutenções Corretivas. Para ter regras, prioridades de atendimentos, multas, penalidades. Precisamos ter um horizonte, este horizonte é fornecido pela Engenharia de Requisitos na manutenção de software. A partir do documento de requisitos, podemos atender as demandas com qualidade e rastreabilidade do que pode ser prejudicado com a alteração, assim também podemos cumprir o Acordo de Nível de Serviço, conforme foi assinado. Buscando contribuir com a pesquisa na área de Engenharia de Requisitos, este estudo apresenta uma análise da relação entre Engenharia de Requisitos, Manutenção Corretiva e Acordo de Nível de Serviço no processo de manutenção de software nas empresas que o foco não é Tecnologia da Informação. BIBLIOGRAFIA FREITAS, M.A.S. Fundamentos do Gerenciamento de Serviços de TI. 1 Ed. São Paulo: Brasport, 2010.

8 LAKATOS E.M; MARCONI M.A. Metodologia do Trabalho Científico. 4 Ed. São Paulo Atlas, 1992. PRESSMAN, R.S. Engenharia de Software. 6 Ed. São Paulo: McGraw- Hill, 2006. PRESSMAN, R.S. Engenharia de Software: Uma Abordagem Profissional. 7 Ed. Porto Alegre: McGraw-Hill, 2011. SOMMERVILLE, I. Engenharia de Software 8 Ed. São Paulo: Pearson, 2010. VALE, J.A. 40 +4 Ferramentas e Técnicas de Gerenciamento. 3 Ed. Rio de Janeiro: Brasport, 2010. Lientz, B. P.; Swanson, E. B. Software Maintenance Management, Reading, MA, Addison-Wesley, 1980. Dekleva, S. M. Annual Software Maintenance Survey: Survey Results, Software Maintenance Association, Vallejo, California, USA, 1990. Dart, S.; Christie, A. M.; Brown, A. W. A Case Study in Software Maintenance, Technical Report, Carnegie Mellon University, 2001.