José André Dorigan
Gerenciamento Gerenciamento de Requisitos: Requisitos: Um Comparativo Comparativo entre Metodologias Tradicionais e Ágeis sob a ótica dos Modelos Mode los de Qualidade
Londrina 2010
José André Dorigan
Gerenciamento Gerenciamento de Requisitos: Requisitos: Um Comparativo Comparativo entre Metodologias Tradicionais e Ágeis sob a ótica dos Modelos Mode los de Qualidade Trabalho apresentado à Universidade Estadual de Londri Londrina na,, como como parte parte do requi requisi sito to para para obtenção do título de Bacharel em Ciência da Computação.
Orientador: Prof. Dr. Rodolfo Miranda de Barros
U NIVERSIDADE E STADUAL DE L ONDRINA
Londrina 2010
José André Dorigan
Gerenciamento Gerenciamento de Requisitos: Requisitos: Um Comparativo Comparativo entre Metodologias Tradicionais e Ágeis sob a ótica dos Modelos Mode los de Qualidade Trabalho apresentado à Universidade Estadual de Londri Londrina na,, como como parte parte do requi requisi sito to para para obtenção do título de Bacharel em Ciência da Computação.
Orientador: Prof. Dr. Rodolfo Miranda de Barros
U NIVERSIDADE E STADUAL DE L ONDRINA
Londrina 2010
José André Dorigan
Gerenciamento Gerenciamento de Requisitos: Requisitos: Um Comparativo Comparativo entre Metodologias Tradicionais e Ágeis sob a ótica dos Modelos Mode los de Qualidade
Prof. Dr. Rodolfo Miranda de Barros Universidade Estadual de Londrina
Prof. Dr. Mario Lemes Proença Jr. Universidade Estadual de Londrina
Prof. Ms. Elieser Botelho Manhas Jr. Universidade Estadual de Londrina
Londrina 30 de Novembro de 2010
Aos meus pais, minhas irmãs e meus amigos...
Agradecimentos Primeiramente, gostaria de agradecer aos meus pais, José Luis e Aparecida pelo incentivo, tanto na questão financeira como no carinho e a compreensão que tiveram comigo ao longo desses 4 anos de curso. Mesmo estando tão longe eu sempre soube que quando eu precisasse eles estariam lá por mim. À eles um muito obrigado seria pouco. As minhas irmãs Carina e Patrícia que me ajudaram em várias oportunidades e que eu pude ajudar também com a pouco, mas inestimável, experiência que eu pude ter morando longe de casa. A Deus, por me permitir ter tantas oportunidades acadêmicas, sociais e profissionais. Ao Professor Dr. Rodolfo Miranda de Barros, que além de orientador nesse trabalho é um amigo que tenho muito orgunho de ter conhecido, sempre que precisei de algo me ajudou e continua ajudando nesse final de caminhada. Espero ainda, que possamos trabalhar um bom tempo juntos no mestrado e quem sabe num possível doutorado. Ao Professor Dr. Mario Lemes Proença Jr. com quem tive a oportunidade de trabalhar desde a metade do ano de 2009, no projeto de pesquisa GAIA - Fábrica de Projetos de TIC, juntamente com o Prof. Rodolfo, incentivou a mim e aos outros componentes da equipe mostrando que deveríamos pensar à frente, buscando utilizar novas tecnologias e sempre manter o comprometimento ao trabalho desenvolvido. A todos os professores e funcionários do Departamento de Computação, que buscaram nos preparar ao máximo para que tivessemos uma ótima qualificação acadêmica. Mesmo nos momentos difíceis, sempre existiu alguém em quem pudemos confiar e que trabalhou para nos oferecer o melhor. Aos meus amigos de longa data (os que ficaram lá em Amparo e os de Londrina), aos meus amigos de hoje, e também à aqueles que estiveram presentes nesse tempo que passei em Londrina. Sempre me lembrarei das risadas, festas e cervejadas em que estivemos juntos. Todos são e foram importantes para mim, e fico muito feliz de tê-los conhecido. Por fim, a Universidade Estadual de Londrina, por oferecer a qualidade de ensino e o curso de Ciência da Computação.
"Ninguém nasce odiando outra pessoa pela cor de sua pele, por sua origem ou ainda por sua religião. Para odiar, as pessoas precisam aprender e, se podem aprender a odiar, podem ser ensinadas a amar." Nelson Mandela
Resumo Este trabalho têm por finalidade apresentar os conceitos e o gerencimento de requisitos na metodologia tradicional RUP ( Rational Unified Process) e na metodologia ágil Scrum, mostrar um comparativo entre Casos de Uso e User Story, suas semelhanças e diferenças no que diz respeito à como os requisitos são levantados, como são mantidos, e qual a participação do cliente nessa parte do desenvolvimento. Sob a ótica dos modelos de qualidade CMMI e MPSBr busca-se demonstrar que as duas metodologias tem possibilidade de certificação nos níveis que tratam dos requisitos.
Palavras-Chaves : gerenciamento de requisitos, Use Case, User Story, Metodologias Ágeis, Metodologias Tradicionais, CMMI, MPS-Br.
Abstract This paper aim at presenting the concepts and requirements management in the traditional methodology RUP (Rational Unified Process) and Agile Scrum, showing a comparison between Use Case and User Story, its similarities and differences with regard to how the requirements are raised, how they are kept, and what’s the client participation in this part of development. From the viewpoint of quality models CMMI and MPS-Br demonstrate that the two methodologies has the possibility for certification levels that deals with the requirements.
Keywords: requirements management, Use Case, User Story, Agile Methodologies, Tradicional Methodologies, CMMI, MPS-Br.
Sumário Lista de Figuras Lista de Tabelas Lista de Abreviaturas
p.12
Introdução
p.13
1 Engenharia de Requisitos: Conceitos
p.15
1.1 Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 1.1.1
Identificar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p.17
1.1.2
Analisar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p.18
1.1.3
Documentar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p.18
1.1.4
Validar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
1.2 Gerenciamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2 A Engenharia de Requisitos nos modelos de qualidade
p.21
2.1 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22 2.1.1
CMMI Nível 2: Gerenciamento de Requisitos . . . . . . . . . . . . . p.24
2.2 MPS-Br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26 2.2.1
Norma ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
2.2.2
Norma ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.2.3
Níveis de Maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.2.4
Nível G: Gerência de Requisitos . . . . . . . . . . . . . . . . . . . . p.29
3 Metodologias Tradicionais
p.31
3.1 RUP: Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . p. 33 3.1.1
Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.1.2
Disciplinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p.37
4 Metodologias Ágeis
p.40
4.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41 4.1.1
Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
4.1.2
Sprint Planning Meeting . . . . . . . . . . . . . . . . . . . . . . . . p. 43
4.1.3
Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
4.1.4
Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
4.1.5
Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
4.1.6
Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4.1.7
Sprint Review Meeting . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
4.1.8
Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
5 Análise sobre a Gerência de Requisitos e os Modelos de Qualidade
p.48
5.1 Problemas na obtenção de requisitos . . . . . . . . . . . . . . . . . . . . . . p.48 5.2 Obtenção e gerência de requisitos nas metodologias RUP e Scrum . . . . . . p. 50 5.2.1
Use Case x User Story . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
5.3 Análise sobre Metodologias e os Modelos de Qualidade . . . . . . . . . . . . p. 54 5.3.1
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
5.3.2
RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
Conclusão
p.56
Referências Bibliográficas
p.58
Lista de Figuras 1.1 Conjunto de atividades da Engenharia de Requisitos . . . . . . . . . . . . . . p. 17 2.1 Representações do CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23 2.2 Representação dos níveis de maturidade do MPS-Br [1] . . . . . . . . . . . . p. 29 3.1 Modelo Clássico de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . p.31 3.2 Modelo Iterativo ou Incremental [2] . . . . . . . . . . . . . . . . . . . . . . p.32 3.3 Arquitetura do Modelo RUP [2] . . . . . . . . . . . . . . . . . . . . . . . . p. 33 4.1 Ciclo da Metodologia Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42 4.2 Exemplo de Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45 4.3 Cartas usadas no Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . p. 45 5.1 Exemplo de diagrama de caso de uso [2] . . . . . . . . . . . . . . . . . . . . p.50 5.2 Exemplo de uma User Story [3] . . . . . . . . . . . . . . . . . . . . . . . . p. 51
Lista de Tabelas 5.1 Características dos Use Cases e User Stories . . . . . . . . . . . . . . . . . p. 52 5.2 Tabela Comparativa entre Use Case e User Story . . . . . . . . . . . . . . . p. 53
12
Lista de Abreviaturas CMMI Capability Maturity Model Integration MPS-Br Melhoria de Processos de Software Brasileiro ISO International Organization for Standardization RUP Rational Unified Process IEEE Institute of Electrical and Electronics Engineers UML Unified Modeling Language SEI Software Engineering Institute CMM Capability Maturity Model for Software MCT Ministério da Ciência e Tecnologia FINEP Financiadora de Estudos e Projetos BID Banco Interamericano de Desenvolvimento IEC International Electrotechnical Commission TI Tecnologia de Informação MR-MPS Modelo de referência para melhoria do processo de software MA-MPS Método de avaliação para melhoria do processo de software MN-MPS Modelo de negócio para melhoria do processo de software IBM International Business Machines XP Extreme Programing FDD Feature Driven Development ASD Adaptive Software Development
13
Introdução A Gerência de Requisitos, sendo uma área da Engenharia de Software, tem como preceito utilizar as diretrizes de modelos de referência de qualidade como o CMMI (Capability Maturity Model Integration)[4] e o MPS-Br (Melhoria de Processos de Software Brasileiro)[1]. O CMMI é um conjunto de práticas consideradas efetivas que estabelecem prioridades para o gerenciamento e a melhoria da qualidade. Essas prioridades são aplicadas criteriosamente no processo de desenvolvimento de software[5]. O MPS-Br nasceu com base nos moldes do CMMI, porém dentro de uma realidade mais específica da cultura e do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil. Embora com conceitos herdados, a proposta brasileira também se baseia em outras normas internacionais, como ISO - 12207 para desenvolvimento de software, e ISO 15504 para avaliação de processos de software. Uma das principais vantagens do modelo é seu custo reduzido de certificação em relação às normas estrangeiras. Nas suas especificações, os dois modelos apresentam “o que” deve ser feito para que as melhores práticas no desenvolvimento de software sejam obtidas, mas não apresentam “como” deve-se proceder para isso[6] [7]. A qualidade no desenvolvimento de software é obtida quando são adotadas metodologias onde o processo de desenvolvimento ocorre de maneira organizada e padronizada. Essas metodologias podem ser tradicionais, usando como exemplo o RUP ( Rational Unified Process) ou ágeis, como exemplo o Scrum. Existem diferenças entre metodologias tradicionais e ágeis quando as utilizamos em conjunto com os modelos de referência. O RUP é um produto de um processo da Engenharia de Software, ele fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento[2]. Tem por objetivo a produção de software com qualidade, que satisfaça às necessidades dos usuários finais dentro de prazos e orçamentos previsíveis. O RUP ainda pode ser adaptado para compor as necessidades da empresa que o utiliza[8]. O Scrum é uma metodologia ágil para gerência de projetos. Ela é baseada em ciclos de 30 dias chamados Sprints, onde trabalha-se para alcançar objetivos bem definidos. Estes
14
objetivos são representados no Product Backlog, uma lista de atividades à serem feitas sendo constantemente atualizada e repriorizada. Essa metodologia provoca uma mudança cultural dentro das equipes de desenvolvimento[9]. Têm-se uma parceria entre times de profissionais e o acúmulo de tarefas e atrasos na entrega dos projetos dá lugar a uma cultura de ciclos curtos de desenvolvimento que aperfeiçoam um produto sempre funcional[10]. O Processo de software, ou processo de engenharia de software, é uma seqüência coerente de práticas que objetiva o desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação de requisitos, análise, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos[11]. Na área de requisitos, as atividades de análise focam na identificação, especificação e descrição dos requisitos do sistema de software. Existem várias interpretações e classificações sobre requisitos, como: requisitos funcionais, não funcionais, de usuário ou de sistema[11]. É comum que o cliente não saiba o que ele realmente deseja, que haja problemas na comunicação e ainda que haja mudança constante de requisitos. Todos esses fatores são recrudescidos pela intangibilidade sobre características de sistemas de software, principalmente sobre o custo de cada requisito[12]. A metodologia RUP gerencia os requisitos de um projeto através de Casos de Uso, enquanto a metodologia Scrum não possui um gerenciamento de requisitos de maneira explícita como o RUP, mas armazena os requisitos através de histórias chamadas User Stories. Este trabalho busca analisar como são tratados os requisitos nessas duas metodologias de desenvolvimento, e quais são as diferenças e semelhanças dos dois artefatos ditos anteriormente. Busca-se ainda mostrar que os modelos de qualidade CMMI e MPS-Br auxiliam no gerenciamento de requisitos e seria possível a certificação de uma empresa que adote tanto o RUP como o Scrum, no nível que trata de requisitos, nos dois modelos de qualidade. Este trabalho está dividido da seguinte forma: no Capitulo 1 serão apresentados os conceitos utilizados na Engenharia de Requisitos e no Gerenciamento de Requisitos, no Capítulo 2, serão apresentados os modelos de qualidade CMMI e MPS-Br e como eles tratam a gerência de requisitos. O Capitulo 3, será destinado às Metodologias Tradicionais de desenvolvimento, tendo como ênfase a metodologia RUP. O Capitulo 4 será destinado às Metodologias Ágeis de desenvolvimento, tendo como ênfase a metodologia Scrum, no Capitulo 5, será apresentada uma análise sobre a Gerência de Requisitos, contendo os problemas na obtenção de requisitos, um comparativo entre a gerência de requisitos nas metodologias Scrum e RUP e como as metodologias podem buscar certificação nos modelos de qualidade. Por fim serão apresentadas as considerações finais e possíveis trabalhos futuros.
15
1
Engenharia de Requisitos: Conceitos
Antes de abordar o processo de engenharia de requisitos, é importante conceituar requisito, termo freqüentemente utilizado em reuniões e muitas vezes sem que as partes possuam uma compreensão única de seu significado. A Análise de Requisitos é a primeira atividade técnica no desenvolvimento do software, e pode ser entendida como responsável por definir os serviços que um sistema deve realizar, sua interface com os demais elementos e sob quais restrições o sistema deve operar. Os requisitos dos sistemas devem estabelecer o que o sistema deve e o que não deve fazer [7]. Levantar corretamente os requisitos é umas das tarefas mais importantes na construção de um sistema. Quando o requisito é expresso em termos do comportamento do sistema, esse comportamento deve ser percebido por um observador externo ao sistema[12] [11]. Os requisitos de um sistema podem ser organizados em diferentes níveis de abstração[11], como mostrado a seguir: • Requisitos de Negócio: correspondem aos objetivos do negócio ou do usuário, que
devem ser satisfeitos pelo sistema. Normalmente são descritos através de um documento denominado visão ou escopo do sistema; • Requisitos de Usuários: descrevem as atividades que os usuários deverão ser capazes de
executar com a utilização do sistema; • Requisitos Funcionais: são os que descrevem as funcionalidades que o sistema deve
possuir para que o usuário possa executar suas atividades; • Requisitos não funcionais: são compostos por padrões, regulamentos e contratos com os
quais o sistema deve ter conformidade, descrição de interfaces externas e requisitos de desempenho; • Restrições: são limitantes nas possibilidades de escolha do desenvolvedor no projeto e na
implementação do produto, muitas vezes utilizadas para que o projeto não tome caminhos
16
indesejáveis; • Atribu Atributos tos de qualidad qualidade: e: ampliam ampliam a descriç descrição ão das funciona funcionalida lidades des do sistem sistemaa através através
da descrição de características de qualidade do produto, sendo essas características importantes para o cliente e para o desenvolvedor. Os requisitos de um projeto podem ser demandados por humanos, como usuários, clientes, órgãos reguladores ou desenvolvedores e também podem ser demandados por não humanos, como sistema de rede, sistema legado, bases de dados e ambientes [7]. Aos Requisitos estão associados os principais problemas do desenvolvimento de software, na maio maioria ria dos dos caso casoss eles eles não refle reflete tem m as reais reais neces necessid sidad ades es dos dos usuári usuários os,, por serem serem incompletos ou inconsistentes. Uma Uma das das princ princip ipais ais difi dificul culda dades des são as mu mudan dança çass em requi requisit sitos os já acord acordado ados, s, pois pois acarr acarret etam am re-trabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes e usuários de software. Muitos desses erros poderiam ser evitados se as organizações dispusessem de um processo de engenharia de requisitos definido, controlado, medido e aprimorado. No entanto para muitos profissionais da área de informática esses conceitos não são muito claros, o que certamente dificulta a ação dos gerentes no sentido de aprimorar os seus processos de desenvolvimento[13]. Antes de iniciar uma especificação de requisitos é importante que a organização tenha definido um documento que deverá ser elaborado, visando um entendimento comum do que deve ser produzido. O IEEE Guide for Developing Systems Requeriments Specifications [14] é um exemplo de documento detalhado que pode ser utilizado com este propósito.
1.1 Engenh Engenhari ariaa de Requis Requisito itoss Para elaborar e manter uma especificação de requisitos é necessário que os desenvolvedores executem um conjunto estruturado de atividades destinadas a elicitar, documentar, analisar e valida validarr requisi requisitos. tos. Este conjunto conjunto de ativida atividades, des, iterativ iterativas as por natureza natureza,, recebe recebe o nome nome de Processo de Engenharia de Requisitos [12]. A figura 1.1 mostra como a Engenharia de Requisitos se relaciona com a Produção de Requisitos e a Gerência de Requisitos.
17
Figura 1.1: Conjunto de atividades da Engenharia de Requisitos
Segundo Segundo NUSEIBEH et al [13], quando a organização organização não dispõe deste processo definido formalmente e amplamente divulgado, os desenvolvedores elaboram as especificações de forma empírica, executando atividades não padronizadas e definidas individualmente. Se isto ocorre, a qualidade da especificação dependerá exclusivamente da experiência e formação das pessoas, com uma elevada probabilidade de ocorrerem conflitos. As ativid atividades ades relacio relacionada nadass ao processo processo de Engenhar Engenharia ia de Requisi Requisitos tos apontada apontadass por SOMMERVILLE [12] e podem ser consideradas um conjunto de boas práticas que apóiam a sua execução são apresentadas a seguir.
1.1. 1.1.11 Iden Identifi tifica carr Corresponde à atividade de obter e compreender os requisitos de um sistema, através de entrevistas com os interessados, da análise do domínio do problema ou de estudos de mercado. Na identificação de requisitos podemos considerar como boas práticas: • A redação de uma declaração de visão e escopo do sistema; • A definição dos procedimentos para desenvolvimento dos requisitos; • A identificação das classes de usuários e dos diferentes grupos de interesse no sistema; • A identificação dos casos de uso; • A análise dos fluxos de trabalho dos usuários;
18 • A definição dos atributos de qualidade do sistema; • O desenvolvimento de mecanismos que possibilitem o re-uso de requisitos.
1.1. 1.1.22 Anal Analisa isarr Na análise, os requisitos identificados são compreendidos e detalhadamente analisados por todos os interessados interessados no sistema. Nesta atividade atividade surgem surgem muitos conflitos, conflitos, sendo comum a necessidade necessidade de negociação para que os requisitos sejam aceitos aceitos por todos. As boas práticas de análise referem-se à: • Elaboração de um diagrama de contexto do sistema; • Criação de protótipos; • Análise de viabilidade; • Priorização dos requisitos.
1.1. 1.1.33 Docu Docume ment ntar ar Uma vez compreendidos, analisados e aceitos, os requisitos devem ser documentados com um nív nível el de detalham detalhamento ento adequado adequado,, produzin produzindo do a especifi especificaçã caçãoo de requisit requisitos os de softwa software. re. Pod Podee ser ser utili utiliza zada da a li lingu nguage agem m natur natural al ou diagr diagram amas, as, como como os propos proposto toss pela pela UML UML (Unified Unified Modeling Modeling Language Language) [8].
1.1. 1.1.44 Valid alidar ar Após terem sido documentados, é necessário que os requisitos sejam cuidadosamente validados, principalmente quanto à consistência e a completude. Esta atividade visa identificar problemas nos requisitos, antes do início da implementação. A importância dessa atividade é caracterizada pelo fato de que, a correção de um erro nesta fase possui possui um custo custo mui muito to inferior inferior à correção correção nas fases fases posterio posteriores res do processo processo de desen desenvol volvim vimento ento..
1.2 Gerenc Gerenciam iament entoo de Requis Requisito itoss O gerenciamento de requisitos corresponde corresponde ao conjunto de atividades atividades que auxilia a equipe do projeto a identificar, controlar e rastrear os requisitos, bem como as alterações nos requisitos
19
em muitos momentos do projeto. Em outras palavras, é o processo que gerencia mudanças nos requisitos de um sistema[15]. Mudanças ocorrem conforme os clientes desenvolvem um melhor entendimento de suas reais necessidades ou em decorrência de alterações em circunstâncias externas como novas leis ou regulamentações introduzidas no ambiente de negócio. Novos requisitos surgem e há alterações nos requisitos em todos os estágios do processo de desenvolvimento do sistema. São comuns os casos em que mais de 50% dos requisitos são alterados antes que o sistema seja posto em operação, o que causa sérios problemas para os desenvolvedores. Para minimizar dificuldades, os requisitos devem ser documentados e controlados. Quando não há controle de alterações, mudanças de baixa prioridade podem ser implementadas antes daquelas de alta prioridade, além de mudanças com alto custo não serem necessariamente aprovadas. Uma das principais áreas problemáticas do desenvolvimento e produção de software é o gerenciamento de requisitos dos clientes[16]. As principais preocupações de gerenciamento de requisitos são: • Gerenciar mudanças nos requisitos acordados; • Gerenciar os relacionamentos entre os requisitos; • Gerenciar as dependências entre o documento de requisitos e outros documentos do
sistema. As mudanças nos requisitos podem ser devidas a erros e confusão no processo de engenharia de requisitos, design ou problemas de implementação[15]. Os requisitos não podem ser gerenciados de forma efetiva sem rastreabilidade. Um requisito é rastreável se for possível: • Identificar quem solicitou o requisito; • Saber porque o requisito existe; • Identificar quais outros requisitos se relacionam com ele; • Saber como é o relacionamento com outras informações como: design do sistema,
implementações e documentos do usuário. Estas informações são utilizadas para identificar todos os requisitos afetados por mudanças propostas.
20
Boas práticas de gerenciamento de requisitos, como uma manutenção de dependências entre requisitos, têm benefícios à longo prazo, como: maior satisfação do cliente e custos de desenvolvimento mais baixos. Uma vez que os retornos não são imediatos, o gerenciamento de requisitos pode parecer uma despesa desnecessária. Entretanto, sem gerência, a economia de curto prazo será devastada pelos custos à longo prazo. Os problemas com gerenciamento de requisitos geralmente significam que os clientes não ficaram satisfeitos com o produto. Podem ser utilizadas ferramentas de gerenciamento de requisitos para prover facilidades como: um sistema de banco de dados para armazenamento de requisitos, gerenciamento de mudanças e rastreabilidade, etc.
21
2
A Engenharia de Requisitos nos modelos de qualidade
Vários modelos e padrões têm sido propostos ao longo dos últimos anos, devido ao crescimento do setor de software. O primeiro deles é a “política”, que representa um princípio governamental, tipicamente usado como base para regras, procedimentos ou padrões e geralmente estabelecido pela mais alta autoridade da organização [16]. Um “padrão” pode ser entendido como uma base para comparação e é usado para suportar tamanho, conteúdo, valor ou qualidade de um objeto ou atividade. Um “guia”, por sua vez, é uma prática, método ou procedimento sugerido. Um “modelo” pode ser definido como uma representação abstrata de um item ou processo, a partir de um ponto de vista específico. O objetivo do modelo é expressar a essência de algum aspecto de um item ou processo, sem prover detalhes desnecessários. Esses modelos têm sido fortemente adotados por organizações em todo o mundo. O SEI (Software Engineering Institute)[17] orgão internacional que tem contribuído bastante com o fortalecimento da área de qualidade de software, através da definição de modelos internacionais focados no processo de software, assim como na publicação de relatórios técnicos e artigos relacionados ao assunto. Em 1991 foi proposto pelo SEI, o CMM (Capability Maturity Model for Software )[18] que foi largamente adotado pela comunidade de software internacional. O CMM é um modelo focado na capacidade organizacional e seu desenvolvimento foi motivado por uma solicitação do Departamento de Defesa dos Estados Unidos, que precisava de um instrumento de avaliação dos fornecedores contratados pelo próprio Departamento. O CMM original era específico para a área de desenvolvimento de software, mas com o tempo foram surgindo necessidades de padrões também para outras áreas. Para isso, foram criados diversos “CMMs”, que não seguiam os mesmos padrões entre si. Assim, em 2002 foi lançado o CMMI (Capability Maturity Model Integration), sem abandonar o CMM original,
22
visando a integração de todos os CMMs e buscando corrigir as inconsistências existentes. Em 2003 foi então criado o modelo MPS-Br (Melhoria de Processo de Software Brasileiro) [1] coordenado pela SOFTEX - Associação para Promoção da Excelência do Software Brasileiro com o apoio do MCT (Ministério da Ciência e Tecnologia), FINEP (Financiadora de Estudos e Projetos) e o BID (Banco Interamericano de Desenvolvimento). O MPS-Br é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504. Essas normas são as mesmas em que o CMMI é baseado, assim pode-se dizer que os dois modelos tem equivalência. Neste trabalho serão abordados o CMMI e o MPS-Br, sendo que ambos os modelos possuem níveis de maturidade que definem a capacidade da empresa para trabalhar em projetos grandes e complexos. Na área de Gerência de Requisitos, tanto o CMMI quanto o MPS-Br apresentam práticas que podem ser adotadas para manter a qualidade do desenvolvimento. No CMMI [4], o nível 2 de maturidade é o responsável por tratar, entre outros aspectos, do gerenciamento de requisitos, enquanto que, no MPS-Br o nível G corresponde à Gerência de Requisitos e Gerência de Projetos [1].
2.1 CMMI O CMMI é um modelo que propõe a avaliação da capacidade e da maturidade de uma organização e indica diretrizes para a melhoria do processo de software. O termo capacitação diz respeito tanto à habilidade para desenvolver software com competência, quanto à capacidade de incorporar novas tecnologias [19]. É dividido em cinco níveis, após o nível 1, para se conquistar os outros níveis é preciso que a organização cumpra as chamadas Áreas de Processo. Podem ser utilizadas duas formas para representação no CMMI: •
Representação por Estágios: possui foco na maturidade organizacional e provê um caminho evolutivo para a melhoria do processo. Esta representação direciona e auxilia às organizações que desejam estabelecer a melhoria de processos de software. As áreas do processo são agrupadas em 5 níveis de maturidade, que devem ser atendidas na sua totalidade para viabilizar um estágio definido de melhorias. – Nível 1: Inicial ou Ad-hoc – Nível 2: Gerenciado – Nível 3: Definido – Nível 4: Quantitativamente gerenciado
23
– Nível 5: Em otimização •
Representação Contínua: possui foco na capabilidade do processo e oferece um caminho flexível para a implementação de melhorias. Permite que as organizações escolham áreas específicas do processo para a implementação de melhorias, bem como implementar níveis diferentes de capabilidade para diferentes processos. – Nível 0: Incompleto ou Ad-hoc – Nível 1: Executado ou Definido – Nível 2: Gerenciado – Nível 3: Definido – Nível 4: Quantitativamente gerenciado – Nível 5: Em otimização ou Optimizado
A figura 2.1 mostra as formas de representação no modelo de qualidade CMMI.
Figura 2.1: Representações do CMMI O CMMI não tem por finalidade, entrar em detalhes específicos sobre como os processos devem funcionar. Sua idéia é definir quais são os processos imprescindíveis, em que ordem devem ser implementados e como verificar se estão realmente institucionalizados na empresa [5]. Isto permite que cada empresa implemente o Modelo de acordo com a sua realidade (recursos, tipo de software desenvolvido, tamanho, cultura etc.). A definição de seus processos é, portanto, indelegável, embora a maioria das empresas conte com o auxílio e orientação de empresas de consultoria especializadas. Processos são tratados pelo CMMI sob a seguinte ótica:
24 • Ponto de vista gerencial; • Não trata do aspecto tecnológico; • Não diz como implementar determinadas práticas, apenas “o que” deve ser feito.
2.1.1 CMMI Nível 2: Gerenciamento de Requisitos O gerenciamento de requisitos é abordado pelo CMMI no seu nível 2 (Gerenciado), sendo que, uma empresa que conquista o CMMI nível 2, possui um diferencial em relação aos seus concorrentes, visto que o CMMI é reconhecido como uma garantia de qualidade do processo de desenvolvimento de software. Alem disso, seguindo corretamente as ações propostas, a empresa é capaz de executar e gerenciar seus projetos de acordo com o que foi planejado e documentado, cumprindo os prazos de entrega e consequentemente conquistando a confiança do cliente [19]. Para o nível 2 a empresa deve ter a capacidade de gerenciar um projeto. É preciso que todas as áreas de processo descritas abaixo sejam cumpridas: 1. Gerenciamento de Requisitos 2. Planejamento de Projeto 3. Monitorização e Controle de Projeto 4. Gerenciamento de Contrato com Fornecedor 5. Medição e Análise 6. Garantia de Qualidade de Processo e Produto 7. Gerenciamento de Configuração Estas áreas de processo são divididas em 5 sub-áreas: Meta, Compromisso, Habilidade, Atividade e Verificação. O propósito desta área é gerenciar os requisitos dos produtos do projeto, além de identificar possíveis erros decorrentes do desenvolvimento dos requisitos do projeto [4]. Para a área-chave de processo Gerenciamento de Requisitos temos a descrição das sub-áreas à seguir:
25
Meta: 1. Requisitos são gerenciados e inconsistências com os planos de projeto e produtos de trabalho são identificados. 2. O processo é estabelecido como um processo gerenciado.
Compromisso: 1. O projeto segue uma política estabelecida pela organização para o gerenciamento de requisitos de sistema alocados ao software.
Habilidade: 1. Estabelecer e manter o plano para efetuar o processo de gerenciamento dos requisitos. 2. Prover recursos adequados para efetuar o processo de gerenciamento de requisitos, desenvolvendo produtos de trabalho, e provendo serviços de processos. 3. Atribuir responsabilidade e autoridade para efetuar o processo, desenvolvendo produtos de trabalho, e provendo serviços do processo de gerenciamento de requisitos. 4. Os membros da equipe de desenvolvimento de software e outros grupos de software relacionados são treinados para realizar suas atividades de gestão de requisitos.
Atividade: 1. Colocar os produtos do projeto de gerenciamento de requisitos em níveis apropriados do gerenciamento de configuração. 2. Identificar e envolver os principais pontos do processo de gerenciamento de requisitos como planejado. 3. Monitorar e controlar o processo de gerenciamento de requisitos junto com o plano de desenvolvimento para tomar ações corretivas apropriadas.
Verificação: 1. Avaliar objetivamente a aderência do processo de gerenciamento de requisitos com suas descrições de processo, padrões, procedimentos, e não-conformidades.
26
2. Rever as atividades, estados, e resultados do processo de gerenciamento de requisitos com um nível maior de gerenciamento e resolver problemas.
2.2 MPS-Br O Brasil é um país cujo desenvolvimento de produtos de software está entre os maiores do mundo, e a cada dia, aumenta o nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos. A partir deste ponto, podemos observar que as empresas estão buscando cada vez mais a maturidade nos seus processos de software para atingir padronizações de qualidade e produtividade internacionais, que são essenciais para a sobrevivência no mercado de TI [20]. Porém, o custo de uma certificação internacional, como o CMMI, para uma empresa pode chegar à 400 mil dólares, que se torna inviável para empresas de micro, pequeno e médio porte. Então, em uma parceria entre a SOFTEX, Governo e Universidades, surgiu em 11/12/2003, o projeto MPS-Br (Melhoria de Processo de Software Brasileiro), que é a solução mais específica para a cultura, mercado e a realidade brasileira, sendo compatível com o modelo CMMI e estando em conformidade com as normas ISO/IEC 12207 para desenvolvimento de software e ISO/IEC 15504 para avaliação de processos de software.
2.2.1 Norma ISO/IEC 12207 Publicada internacionalmente em 1995 e no Brasil em 1998, passou por uma atualização em 2002 para acompanhar a evolução da engenharia de software, as necessidades vivenciadas pelos usuários da norma e a harmonização com a série de normas ISO/IEC 15504 - Avaliação de processos de software. Ela estabeleceu uma estrutura comum para os processos do ciclo de vida do software e ajudou as organizações a obter um melhor entendimento das atividades a serem executadas nas operações que envolvem de alguma forma o software. A estrutura da norma é composta de processos, atividades e tarefas que envolvam o software. A atualização de 2002 inseriu processos e acrescentou na sua descrição propósito e resultados de implementação, o que possibilita a avaliação de capacidade do processo. A norma, incluindo o seu anexo é composta por: •
Processos fundamentais: Aquisição, desenvolvimento, operação e manutenção.
27 •
Processos de apoio: Documentação, Gerência de configuração, Garantia de qualidade, Verificação, Validação, Revisão, Auditoria, Resolução de problemas e usabilidade.
•
Processos Organizacionais: Gerência, Infra-Estrutura, Melhoria, Recursos Humanos, Gestão de Ativos, Gestão de Programa de Reuso e engenharia de Domínio.
Cada processo é dividido em termos de suas próprias atividades e cada atividade é definida em termos de suas tarefas. A norma estabelece uma arquitetura de alto nível abrangendo desde a concepção até a descontinuidade do software.
2.2.2 Norma ISO/IEC 15504 Em setembro de 1992, a ISO realizou um estudo chamado “Necessidades e Exigências para uma Norma de Avaliação de Processo de Software”. O trabalho concluiu que era pertinente a elaboração de um padrão que fosse aplicável à melhoria de processos e a determinação da capacidade. Este padrão deveria considerar os métodos e normas já existentes e abranger todos os processos de software. A ISO/IEC 15504 foi publicada em 2003 e contempla a realização de avaliações de processos de software com dois objetivos: • A melhoria de processos; • A determinação da capacidade de processos de uma organização.
Se o objetivo for a melhoria de processos, a organização pode realizar a avaliação gerando um perfil dos procesos que será usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a empresa tem o objetivo de avaliar um fornecedor em potencial obtendo o seu perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de decisão de contratá-lo ou não.
2.2.3 Níveis de Maturidade O diferencial da certificação MPS-Br consiste na escala gradual de implementação dos níveis de maturidade. A proposta brasileira, diferente do CMMI, oferece sete níveis de maturidade, facilitando a escalada ao topo da qualidade. Ao adotar o MPS-Br, a empresa poderá
28
chegar a um nível inicial de maturidade e capacidade, com um grau menor de esforço e de investimento [20]. O MPS-Br é dividido em 3 componentes: MR-MPS (Modelo de referência para melhoria do processo de software), MA-MPS (Método de avaliação para melhoria do processo de software) e MN-MPS (Modelo de negócio para melhoria do processo de software). Neste trabalho apresentamos o Modelo de Referência para Melhoria do Processo de Software. Não daremos enfoque aos outros 2 componentes pois a justificativa do trabalho é analisar a gerência de requisitos que é apresentada no nível G de maturidade do MPS-Br.
MR-MPS: Modelo de referência para melhoria do processo de software O Modelo de Referência MR-MPS [1] define níveis de maturidade que são uma combinação entre processos e sua capacidade. Os 7 níveis de maturidade são:
A. Em Otimização B. Gerenciado quantitativamente; C. Definido; D. Largamente Definido; E. Parcialmente Definido; F. Gerenciado; G. Parcialmente Gerenciado; A capacidade do processo é a caracterização da habilidade do processo, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistos.
AP 1.1 O processo é executado; AP 1.2 O processo é gerenciado; AP 2.2 Os produtos de trabalho do processo são gerenciados; AP 3.1 O processo é definido; AP 3.2 O processo está implementado.
29
AP 4.1 O processo é medido. AP 4.2 O processo é controlado. AP 5.1 O processo é objeto de inovações. AP 5.2 O processo é otimizado continuamente. A figura 2.2 mostra a representação dos sete níveis de maturidade do modelo de qualidade MPS-Br.
Figura 2.2: Representação dos níveis de maturidade do MPS-Br [1]
2.2.4 Nível G: Gerência de Requisitos O nível G é composto pelas áreas de processo de Gerência de Projetos e Gerência de Requisitos. Um processo é denominado gerenciado quando ele é planejado, executado, medido e controlado. Os processos do nível G são parcialmente gerenciados porque as execuções dos processos são planejadas, executadas e controladas. As medições ainda são feitas de forma incipiente neste nível. Os produtos de trabalho gerados nas execuções, como por exemplo, planos de projetos e documentos de especificação de casos de uso, não sofrem um controle mais formal. Outra característica é que a organização ainda não precisa implementar os processos de Gerência de Configuração, Medição, Garantia da Qualidade, Gerência de Portfólio de Projetos e Aquisição que fariam com que ela pudesse ser considerada como Gerenciada.
30
Segundo o Guia Geral do MPS-Br [1], o propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. Na Gerência de Requisitos, além do levantamento das necessidades do cliente e do software, é necessário estabelecer formalmente o compromisso entre o cliente e a empresa sobre a compreensão e correção dos requisitos fornecidos. A forma de tratar a mudança dos requisitos também possui um papel fundamental trazendo mais transparência ao processo, pois é possível medir e avaliar os impactos dessas mudanças. O estabelecimento da rastreabilidade bidirecional proposto pelo nível G também ajuda na avaliação do impacto causado por um requisito no desenvolvimento do sistema e na aplicação de testes. Alguns resultados esperados quando da implantação do nível G em uma organização são:
GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos; GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é mantida; GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. .
31
3
Metodologias Tradicionais
As metodologias tradicionais são também chamadas de orientadas a documentação. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais. Na década de 90, o custo de fazer alterações e correções em projetos era muito alto, uma vez que o acesso aos computadores era limitado e não existiam modernas ferramentas de apoio ao desenvolvimento do software. Por isso o software era todo planejado e documentado antes de ser implementado. A principal metodologia tradicional criada naquela época e ainda utilizada até hoje é o modelo Clássico. O modelo Clássico ou Sequencial [11] foi o primeiro processo de desenvolvimento de software. É um modelo em que existe uma sequência a ser seguida de uma etapa a outra. Cada etapa tem associada ao seu término uma documentação padrão que deve ser aprovada para que se inicie a etapa imediatamente posterior. O problema do modelo em Sequencial é sua inflexível divisão do projeto em fases distintas, o que dificulta possíveis alterações que são comuns no desenvolvimento de um projeto. É um modelo que deve ser usado somente quando os requisitos forem bem compreendidos. A figura 3.1 ilustra as fases do modelo Clássico de Desenvolvimento.
Figura 3.1: Modelo Clássico de Desenvolvimento Mas, no desenvolvimento de software, nem sempre todos os requisitos estão explícitos
32
no início do projeto. Uma grande porcentagem dos requisitos são “descobertos” nas fases posteriores do desenvolvimento, criando assim o re-trabalho de analisar novamente o projeto e verificar onde esses novos requisitos serão tratados e o impacto causado por eles no software em produção [2]. Assim um novo modelo foi proposto chamado de Modelo Iterativo ou Incremental, onde a idéia básica é permitir ao desenvolvedor tirar vantagem daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma versão do sistema. O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema. A figura 3.2 ilustra as fases do Modelo Iterativo ou Incremental.
Figura 3.2: Modelo Iterativo ou Incremental [2]
Utilizando os conceitos do Modelo Iterativo como alternativa para resolução dos problemas encontrados no modelo de desenvolvimento de software sequencial ou “cascata”, surgiu o RUP ( Rational Unified Process) um produto/processo iterativo, incremental e customizável de Engenharia de Software que foi inicialmente desenvolvido e comercializado pela Rational, e R. desde 2003 pertencente à IBM Existem ainda outras metodologias tradicionais, sendo a maioria baseada em algum modelo de desenvolvimento, seja no modelo clássico ou cascata, no modelo iterativo, em prototipagem, por estágios, etc. Neste trabalho escolheu-se o modelo de desenvolvimento RUP pela sua diferenciada capacidade de gerenciar os requisitos de um sistema de software. O RUP apresenta uma abordagem disciplinada e construída no gerenciamento de requisitos [2], sendo possível priorizá-los, detectar inconsistências e permitindo até mesmo a criação de um repositório para requisitos do sistema.
33
3.1 RUP: Rational Unified Process “Processo” por definição e “produto” pela maneira como é comercializado, o RUP provê de uma maneira disciplinada, a atribuição de tarefas e responsabilidades dentro de um time de desenvolvimento. Seu maior objetivo é garantir a produção de software de alta qualidade e que satisfaça as expectativas e necessidades dos usuários finais dentro de um prazo e orçamento aceitáveis. A figura 3.3 mostra a arquitetura básica do RUP, onde pode-se perceber suas duas dimensões:
Figura 3.3: Arquitetura do Modelo RUP [2]
A horizontal representa o tempo de vida de um projeto, assim como os aspectos do ciclo de vida do processo, de acordo com o decorrer do projeto. Essa dimensão demonstra o aspecto dinâmico do processo, suas fases e iterações. A vertical representa os grupos de atividades lógicas que são realizadas durante o decorrer do tempo. Essa dimensão demonstra o aspecto estático do processo, que será composto por disciplinas, atividades, fluxos, artefatos e papéis. O RUP incorpora as melhores práticas de desenvolvimento de software de acordo com o sucesso apontado pela indústria de software, que são: • Desenvolvimento iterativo; • Gerenciamento de requisitos; • Arquitetura baseada em componentes;
34 • Modelo visual de software; • Verificação contínua da qualidade de software; • Controle de mudança de software.
O RUP trata o desenvolvimento de software de uma maneira iterativa e incremental, ou seja, substitui o modelo clássico de desenvolvimento em “cascata” para uma abordagem um pouco mais dinâmica, dividida em iterações, onde dentro de cada iteração, teremos a execução de cada uma de suas Disciplinas, em proporção de acordo com a Fase do projeto Em sua essência, o RUP é “centrado na arquitetura” e “dirigido por casos de uso”, isso significa que, para o RUP, os aspectos mais importantes do desenvolvimento de software, ou seja, os aspectos relacionados aos maiores riscos de um projeto de desenvolvimento estão intimamente ligados à arquitetura. Em KRUCHTEN [2] existe a seguinte definição de arquitetura: “tudo o que sobra quando você não pode tirar nada mais do sistema, mas ainda continua entendendo e explicando como ele funciona”. Sendo assim, deve-se tratar como centro do desenvolvimento, os requisitos arquiteturais do projeto. Além disso, o RUP é dirigido por casos de uso [21], podemos mostrar que para solucionar um problema, deve-se primeiro entender da melhor forma possível esse problema, dividí-lo e organizá-lo de uma maneira que todos os envolvidos no projeto de construção desse sistema possam compreender a situação. Para realizar essas atividades, o RUP encontra na UML a solução: Use Cases e seus atores.
3.1.1 Fases Como apresentado, o RUP é dividido em fases. Cada uma de suas quatro fases compreende um momento distinto dentro do ciclo de vida de um projeto de engenharia de software e, portanto, apresentam maior ou menor foco em algumas disciplinas, de acordo com a necessidade do projeto no decorrer de sua execução. Segundo KRUCHTEN [2] suas fases correspondem à:
Início ( Inception) Nessa fase deve-se conseguir dos stakeholders do projeto um consenso relacionado aos objetivos do ciclo de vida do projeto. Essa fase é focada em endereçar riscos de requisitos e negócio antes de continuar com o projeto. Para projetos de novos sistemas, essa fase certamente
35
será mais demorada, porém, para projetos relacionados a sistemas já existentes, a fase de início é mais breve, e continuará com foco de garantir que o projeto seja possível e viável. Os objetivos da fase de início incluem: • Estabelecer a visão do projeto: escopo, limites, condições, critérios de aceitação, etc; • Elencar os casos de uso críticos do sistema e conhecer os principais cenários das
funcionalidades centrais do sistema; • Exibir e demonstrar ao menos uma arquitetura candidata para atender a esses casos de
uso críticos; • Estimar o custo e prazo total do projeto como um todo e estimar de maneira detalhada a
fase seguinte (Elaboração); • Estimar os potenciais riscos do projeto; • Preparar o ambiente de suporte para o projeto.
As disciplinas mais aplicadas nessa fase são: Modelagem de Negócio, Requisitos, Gerenciamento de Projeto e Ambiente.
Elaboração ( Elaboration) Aqui fecha-se a arquitetura do sistema, estabelecendo uma base sólida para o design e implementação do sistema. A arquitetura deverá considerar os requisitos mais significantes, ou seja, aqueles que produzem um impacto na arquitetura do sistema, e uma avaliação de riscos. Essa arquitetura deverá ser avaliada através de um ou mais protótipos arquiteturais. Os objetivos da fase de elaboração incluem: • Garantir que a arquitetura, seus requisitos e o planejamento do projeto estão estáveis; • Prever custo e prazo da completude do desenvolvimento; • Endereçar todos os riscos arquiteturais significantes do projeto; • Estabelecer a linha arquitetural do projeto; • Demonstrar que a arquitetura selecionada suportará os requisitos do sistema através de
custo e prazo razoáveis;
36 • Estabelecer o ambiente de suporte para o projeto.
As disciplinas aplicadas nessa fase são: Requisitos, Análise e Design, Implementação, Testes, Gerenciamento de Projeto e Ambiente.
Construção (Construction) Na fase de construção, os requisitos restantes são levantados e aprovados e se completa o desenvolvimento do sistema, baseado na arquitetura definida. A ênfase aqui é passar do desenvolvimento teórico criado nas fases anteriores para o desenvolvimento de um produto pronto para entrega. Os objetivos da fase de construção incluem: • Minimizar custos de desenvolvimento, evitando re-trabalho desnecessário; • Alcançar uma qualidade adequada para o produto; • Criar versões utilizáveis do sistema; • Completar a Análise e Design e os testes da aplicação; • Desenvolver um produto completo de maneira incremental e iterativa; • Decidir se o sistema e os usuários estão prontos para o Deploy; • Alcançar certo nível de paralelismo nos trabalhos dos times de desenvolvimento.
As disciplinas mais aplicadas nessa fase são: Análise e Design, Implementação, Testes, Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto e Ambiente.
Transição (Transition) O foco da fase de transição é garantir que o produto desenvolvido esteja disponível para seus usuários finais. Essa fase pode estar dividida em várias iterações e inclui testar o produto na preparação para seu lançamento, pequenos ajustes de mercado baseados no feedback de usuários, etc. Ao final da fase de transição, os objetivos do ciclo de vida do projeto deverão ter sido alcançados e o projeto estará prestes a ser finalizado. Os objetivos da fase de transição incluem:
37 • Teste beta para validar o novo sistema de acordo com as expectativas dos usuários; • Operação paralela com os sistemas legados que serão substituídos; • Conversão de base de dados; • Treinamento de usuários; • Empacotamento e Deploy do sistema; • Validação da linha de Deploy em relação à visão completa do projeto e seus critérios de
aceitação do produto; • Alcançar o auto-suporte dos usuários; • Conseguir a validação final do usuário em relação ao produto.
As disciplinas mais aplicadas nessa fase são: Deployment , Gerenciamento de Configuração e Mudança e Gerenciamento de Projeto e Ambiente.
3.1.2 Disciplinas Durante cada fase do RUP, faz-se uso de suas nove disciplinas. Cada uma dessas disciplinas possui atividades que serão executadas por um papel distinto no processo e poderão ou não gerar artefatos. Seus focos e objetivos serão mostrados à seguir.
Modelagem de Negócio ( Business Modeling) Garantir que os objetivos e expectativas de todos os stakeholders do projeto estejam alinhados com os objetivos da organização, e assim derivar desses objetivos os requisitos de sistema que deverão ser atendidos para solucionar problemas e/ou necessidades.
Requisitos ( Requirements) Definir os limites do sistema e, de acordo com os requisitos desse novo sistema, criar os casos de uso que serão a base sólida para se estimar os custos e esforços de desenvolvimento. Aqui, todos os stakeholders do projeto devem compreender e aceitar tudo que o sistema deverá fazer.
38
Análise e Design ( Analysis & Design) Transformar os requisitos em desenhos do sistema que será construído. Devem ser produzidas as especificações técnicas que serão seguidas na implementação de cada caso de uso do sistema.
Implementação ( Implementation) Transformar os modelos lógicos e físicos criados na Análise e Design em código-fonte utilizável e testar unitariamente o código produzido.
Testes (Test) Encontrar, documentar e endereçar os defeitos na qualidade do software produzido. Esses defeitos surgem da comparação entre o que foi produzido com o que foi exposto nos requisitos e modelos lógicos e físicos do produto.
Deployment ( Deployment) Garantir que o software produzido fique disponível para seus usuários finais.
Gerenciamento de Configuração e Mudança ( Configuration & Change Management) Controlar as mudanças e manter a integridade de cada um dos artefatos produzidos no projeto. Cada um desses artefatos deve ser identificado, auditado e possuir níveis de configuração e manutenção definidos.
Gerenciamento de Projeto ( Project Management) Balancear objetivos que competem entre si, gerenciar riscos, monitorar o projeto e tratar regras que garantirão a entrega de um produto que irá atender às expectativas dos clientes e usuários finais.
Ambiente ( Environment) Configurar o ambiente para que o processo e suas atividades possam ser executados. Prover os processos e ferramentas necessárias para que todas as atividades do projeto possam ser
39
devidamente executadas por cada papel. Em uma era onde metodologias ágeis estão emergindo como resposta para problemas persistentes na produção de software de qualidade, tratar do RUP pode parecer um passo para trás. Porém, se entendermos os conceitos por trás do modelo, passamos a compreender que o objetivo não é prometer a resolução de todos os problemas encontrados no dia-a-dia da Tecnologia de Informação. Vale ressaltar que os conceitos básicos do RUP são: Iteratividade, Desenvolvimento Incremental e Customização [8]. Por ser um modelo que traz uma série de artefatos e uma quase infinidade de fluxos, atividades, etc, usuários do RUP geralmente esquecem o conceito de “Customização” citado acima e passam a acreditar que, para se ter bons resultados com o processo, é necessária a adoção de todo o “pacote“, o que não é necessariamente verdade. Além disso, o conceito de iterações, muito pregado também pelo Scrum, nem sempre é levado a sério quando trata-se da implantação do RUP. Isso ocorre, muitas vezes, por essa informação vital ser ofuscada por tantas outras que o processo traz, diferente do Scrum, onde as Sprints ficam sempre muito claras. A aplicação do RUP em parceria com metodologias ágeis, processos em cascatas e em ambientes com pouca ou muita documentação é possível e podemos constatar resultados bons provenientes de projetos utilizando esses processos juntos.
40
4
Metodologias Ágeis
Com a evolução dos software, cada vez mais é preciso inovar durante o desenvolvimento, desde novas tecnologias, funcionalidades até novas metodologias. Para suprir essa necessidade do mercado empresas desenvolvedoras de software vem buscando metodologias ágeis com o foco na redução de risco e aumento da produtividade. O termo “Metodologias Ágeis“ começou a ser divulgado em 2001 quando especialistas em processo de desenvolvimento de software representando os métodos Scrum [10], XP (Extreme Programing) [22], entre outros, propuseram princípios comuns utilizados por todos os métodos considerados ágeis. Nesse cenário foi então criada a Aliança Ágil e pouco tempo depois ainda no mesmo ano, publicado o Manifesto Ágil [23]. Os princípios compartilhados eram: • Indivíduos e iterações ao invés de processos e ferramentas; • Software executável ao invés de documentação; • Colaboração do cliente ao invés de negociação de contratos; • Respostas rápidas a mudanças ao invés de seguir planos.
Como citado nos princípios, as metodologias ágeis são baseadas no processo iterativo, mas usam a comunicação como mecanismo de controle primário, além do uso de versões do software desenvolvido, e para atender ao mercado de maneira rápida e eficiente a evolução é vista a todo o momento, seja em uma reunião, seja ao final de cada semana de trabalho. O foco principal é o desenvolvimento de software em períodos curtos. As iterações duram em média duas a quatro semanas e são tratadas como miniaturas do projeto. Ao final de cada período de iteração é possível ter um software já com partes funcionais, possível de ser usado. Além disso, elas possuem todas as etapas necessárias para o desenvolvimento do software.
41
É preciso ressaltar que, mudar a metodologia de desenvolvimento de software de uma empresa não acontece da noite para o dia, é preciso mudar o jeito de agir e pensar de todos os integrantes da equipe de desenvolvimento e outras pessoas envolvidas com essa equipe, ou seja, uma mudança cultural deve acontecer de forma gradual. O primeiro passo para essa mudança é adaptar os processos da metodologia ágil que será utilizada, pois as práticas propostas por essa metodologia nem sempre são necessárias para a sua empresa, ou mesmo não são totalmente acopláveis a sua equipe e visão cultural da empresa. Metodologias Ágeis não rejeitam os processos ou ferramentas, documentação, negociação de contratos ou o planejamento, mas para essas metodologias esses itens têm papel secundário quando comparados com indivíduos e iterações, com software executável e colaboração com o cliente [22]. Esses conceitos podem aproximar-se melhor do método de trabalho de pequenas e médias empresas. Os métodos ágeis mais conhecidos atualmente são: Scrum, XP, FDD (Feature Driven Development ), ASD ( Adaptive Software Development ), Crystal entre outros. Neste trabalho escolheu-se tratar sobre o Scrum, pois além de ser o método ágil mais adotado é um dos que apresenta melhores resultados quando aplicado a empresas de desenvolvimento de software.
4.1 Scrum O método ágil Scrum surgiu a partir de um jogo conhecido como Rugby . Neste jogo, o Scrum é uma jogada que envolve oito jogadores de cada time, onde eles se "encaixam", para se tornar uma muralha. O ponto forte dessa jogada é a vital importância do trabalho em equipe. Se um membro falhar na formação, o outro time se sobressai. É justamente pela importância desse trabalho integrado do time, que esta palavra foi utilizada como nome da metodologia. O fundamental é o time trabalhar junto, as pessoas são importantes e é por isso que bons resultados são alcançados utilizando essa metodologia. A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem como objetivo, segundo SCHWABER [9], definir um processo para projeto e desenvolvimento de software orientado a objeto, que seja focado nas pessoas e que seja indicado para ambientes em que os requisitos surgem e mudam rapidamente. O Scrum também é considerado um método específico para o gerenciamento do processo de desenvolvimento de software.
42
O método baseia-se ainda, conforme SCHWABER [9], em princípios como: • Equipes pequenas de, no máximo, 7 pessoas; • Requisitos que são pouco estáveis ou desconhecidos; • Iterações curtas.
No Scrum, os projetos são dividos em ciclos de, no máximo 30 dias, chamados de Sprints. O Sprint representa o tempo dentro do qual um conjunto de atividades deve ser executado. As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint , faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. Ainda na seleção das atividades a equipe pode realizar o Planning Poker que é um jogo onde as atividades recebem valores que podem significar pontos relativos ou horas de trabalho, assim a equipe chega a um consenso da dificuldade da tarefa. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. Acadadiadeuma Sprint , a equipe faz uma breve reunião, normalmente de manhã, chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. A figura 4.1 representa o ciclo de vida com as iterações da metodologia Scrum.
Figura 4.1: Ciclo da Metodologia Scrum Ao final de um Sprint , a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para
43
o planejamento do próximo Sprint . Este método não requer ou fornece qualquer técnica ou modelo específico para a fase de desenvolvimento de software, apenas estabelece conjuntos de regras e práticas gerenciais que devem ser adotadas para o sucesso de um projeto. A seguir serão apresentadas as características dos conceitos utilizados, segundo KNIBERG [24] e SCHWABER [9], bem como suas dependências e contribuições para o ciclo de vida do Scrum.
4.1.1 Product Owner É a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings. O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint . Estes itens transformam-se no Sprint Backlog. A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint . Requisitos podem mudar, mas apenas fora do Sprint . Uma vez que a equipe comece a trabalhar em um Sprint , ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.
4.1.2 Sprint Planning Meeting É uma reunião na qual estão presentes o Product Owner , o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. Durante o Sprint Planning Meeting , o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog. O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting. Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint , que é uma breve descrição daquilo que se tentará alcançar no Sprint . O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint .
44
Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner , mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer.
4.1.3 Product Backlog O Product Backlog é o ponto inicial do Scrum, sendo considerada a prática responsável pela coleta dos requisitos, conforme aponta SCHWABER [9]. Nesta prática, através de reuniões com todos stakeholders no projeto, são apontados os itens, que nesse contexto são chamados de histórias ou User Story, onde o cliente com suas palavras narra o que ele necessita que o sistema faça. Assim, todas as necessidades do negócio e os requisitos técnicos a serem desenvolvidos estarão contidos no Product Backlog que se torna uma lista de atividades que provavelmente serão desenvolvidas durante o projeto. O conteúdo desta lista é definido pelo Product Owner . O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários. Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.
4.1.4 Sprint Backlog É uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint . Os itens do Sprint Backlog são extraídos do Product Backlog pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades. A equipe deve determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.
45
Durante um Sprint , o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que as tarefas são completadas e quanto tempo ainda será necessário para completar as que ainda faltam. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart representado, como exemplo, na figura 4.2.
Figura 4.2: Exemplo de Burndown Chart
4.1.5 Planning Poker O Planning Poker é uma técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos, podendo seguir uma sequência expecífica, como por exemplo, a sequência de fibonacci, deixando o jogo mais interessante para os participantes. A figura 4.3 mostra um exemplo de cartas usadas no Planning Poker
Figura 4.3: Cartas usadas no Planning Poker
46
Uma pessoa apresenta a tarefa ou funcionalidade para o time, e após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência. As discussões devem ser breves, pois o objetivo é evitar longas argumentações técnicas, que não devem de forma alguma ser o foco de uma estimativa. Algumas vantagens do Planning Poker: • Equipe mais comprometida, pois todos participam; • Força a equipe a ter um conhecimento de negócio mais homogêneo; • Aumenta bastante a precisão das estimativas, pois considera a experiência de todos; • Mais divertida que as demais técnicas.
No Planning Poker só deverá existir estimativa com precisão em tarefas pequenas. Se a equipe estiver estimando em horas, um valor maior que oito é considerado um ”chute”, e geralmente significa que aquela tarefa deve ser particionada em pelo menos duas partes, e reestimada, portanto é recomendável assumir que cada tarefa deve ser pequena o suficiente para poder ser executada em um dia. As estimativas por horas ainda devem ser feitas sem considerar as interrupções, ou seja, o tempo que efetivamente levaría-se para concluir a tarefa em um dia ideal.
4.1.6 Daily Scrum A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Essas reuniões normalmente são realizadas no mesmo lugar e hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho. Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.
47
O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas diretamente ligadas ao problema ou que possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas: • O que você fez ontem? • O que você fará hoje? • Há algum impedimento no seu caminho?
Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de “status report ” na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual os membros da equipe assumem compromissos perante os demais. Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.
4.1.7 Sprint Review Meeting Nesta reunião, que é feita ao final de cada Sprint , o Scrum Team mostra o que foi alcançado durante o Sprint . Tipicamente, isso tem o formato de um demo das novas funcionalidades. Os participantes do Sprint Review incluem o Product Owner , o Scrum Team, o Scrum Master , gerência, clientes e engenheiros de outros projetos. Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint , determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint Backlog, mas o mais importante é que a equipe atinja o objetivo geral do Sprint .
4.1.8 Sprint Retrospective Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.
48
5
Análise sobre a Gerência de Requisitos e os Modelos de Qualidade
Utilizando os conceitos apresentados anteriormente, pode-se entender que a Engenharia de Requisitos trata de uma parte essencial no desenvolvimento de software. Seja qual for a metodologia de trabalho utilizada - RUP ou Scrum - os requisitos devem ser sempre tratados com a devida atenção, pois uma especificação equivocada ou errônea pode trazer impactos no desenvolvimento a longo prazo. Os modelos de qualidade CMMI e MPS-Br auxiliam o desenvolvimento de software, e em específico o gerenciamento de requisitos. Quando uma empresa utiliza uma metodologia de desenvolvimento existem algumas facilidades ou então impedimentos que ocorrem quando combina-se RUP e Scrum com CMMI e MPS-Br na busca pela certificação nos níveis que tratam de requisitos dos dois modelos. Neste capítulo a seção 5.1 trata dos problemas na obtenção dos requisitos, a seção 5.2 trata da obtenção e gerência de requisitos nas metodologias RUP e Scrum e a seção 5.3 trata da análise pela busca de certificação nos níveis referentes à requisitos nos modelos CMMI e MPS-Br.
5.1 Problemas na obtenção de requisitos Os requisitos de um software também apresentam problemas à quando seu levantamento é feito por parte do analista. Esses problemas, na maioria das vezes, estão entrelaçados, o que os torna mais complicados. Neste trabalho cita-se GANE et al[25] que descreve alguns problemas: 1. Dificuldade de entender o funcionamento da empresa/organização para determinar os requisitos do sistema olhando pela perspectiva do usuário: Nesse contexto geralmente encontra-se uma frase muito conhecida na área de desenvolvimento, onde o cliente diz “O sistema está bom, mas não era isso que os usuários necessitavam”. Isso acontece
49
devido à especificação incorreta dos requisitos. Outras causas desse problema são: • O analista não conseguiu utilizar as explanações dos clientes sobre as necessidades
para com o sistema; • Alguns requisitos importantes para o desenvolvimento terem sidos omitidos ou
“esquecidos” por parte do cliente; • O gerente de projeto mão entendeu a descrição dos requisitos feita pelo analista.
2. O cliente não conhece o suficiente sobre suas necessidades: a tecnologia ainda é muito nova para que as pessoas possam ter o conhecimento e a experiência que lhes permita imaginar como um novo software poderia ser benéfico para seu dia-a-dia. Isso traz um agravante no que se refere aos meios de comunicação mais populares: Televisão e Internet. Esses meios, podem passar a imagem que um software pode resolver todos os problemas de um estabelecimento em alguns cliques, ou por outro lado, pode tornar-se o maior pesadelo, gerando erros ilógicos e incompatíveis com o conhecimento do usuário. 3. Número excessivo de detalhes: O analista de requisitos, em sua busca por entender o funcionamento da organização para a qual um software está sendo projetado, pode ficar sobrecarregado de detalhes técnicos e sobre a organização. Os detalhes são reconhecidamente importantes, mas uma carga muito grande de detalhes pode acarretar a perda do controle sobre as prioridades do software. 4. O documento de especificação de requisitos é feito de maneira que o cliente não consegue ter uma compreensão total daquilo que irá ser desenvolvido: Muitos termos técnicos, fluxogramas de programação, códigos, não são aquilo que o cliente está acostumado a ver. Assim espera-se que o documento de especificação de requisitos seja algo entendível por ambas as partes pois, depois de assinado, torna-se um contrato garantindo que será entregue ao cliente aquilo descrito. 5. Especificação que limita a liberdade de ação do grupo de desenvolvimento: O analista pode gerar um documento de especificação de requisitos que não permita que a equipe de implementação faça uso das melhores técnicas para que o software possua melhor rendimento. Um dos desafios ainda existentes é a elaboração de novas formas de participação de usuários na engenharia de requisitos[15]. Uma tendência nas empresas que desenvolvem software é terceirizar sua produção, como consequencia disso, será necessário que os usuários de software
50
melhorem suas práticas de engenharia de requisitos. Eles terão que exigir mais para que possam obter o que desejam [25] [15]. Em CASTRO [15], num desenvolvimento comum, a equipe de análise de requisitos provavelmente seria parte da equipe de desenvolvimento do projeto em si, com a terceirização de uma das partes o cliente passa a ter um papel fundamental quando elicita os requisitos, pois um equívoco pode passar desapercebido e ser somente notado no final do projeto.
5.2 Obtenção e gerência de requisitos nas metodologias RUP e Scrum Nos capítulos 3 e 4 foram apresentados os conceitos de metodologias tradicionais e ágeis respectivamente. Cada metodologia possui uma maneira diferente de tratar os requisitos num desenvolvimento de software. Nesta seção apresenta-se as principais características que podem tanto agrupar quanto diferenciar os métodos RUP e Scrum. Tratamos primeiramente do RUP, que em sua divisão de fases, apresenta o gerenciamento de requisitos nas duas primeiras fases: Início e Elaboração. Essas fases são responsáveis por identificar os requisitos do sistema e seus riscos, priorizá-los, além de garantir que eles estejam estáveis o suficiente para se seja iniciada a fase de construção do software. Nas fases inicias do projeto, o RUP cria um artefato que caracteriza sua existência como metodologia tradicional: o Caso de Uso (Use Case). Tanto na fase de Início quanto na de Elaboração os Casos de Uso podem ser específicados, modificados, analisados e aprovados. Após isso o sistema ganha forma, os cenários das funcionalidades do sistema são criados e os requisitos principais e mais importantes são especificados e aceitos pelo cliente e não deveriam receber modificações a partir desse momento. A figura 5.1 ilustra um exemplo de um diagrama de caso de uso utilizado no RUP.
Figura 5.1: Exemplo de diagrama de caso de uso [2]
51
Em contra partida o Scrum trata dos requisitos de software através do Product Backlog e Sprint Backlog. Deve-se deixar bem claro que o método Scrum não possui definido em sua implantação um Gerenciamento de Requisitos, como acontece com o RUP, os requisitos são apenas identificados, tratados e tornam-se funcionalidades do sistema em desenvolvimento. As User Stories [26], artefatos que caracterizam algumas das metodologias ágeis, nesse caso o Scrum, são responsáveis por coletar os requisitos através do cliente, ou seja, é o próprio cliente quem cria as user stories. Depois elas são analisadas e tornam-se funcionalidades que são atribuídas ao Product Backlog e posteriormente ao Sprint Backlog no início de uma Sprint . A figura 5.2 ilustra um exemplo de uma User Story utilizada no Scrum.
Figura 5.2: Exemplo de uma User Story [3]
5.2.1 Use Case x User Story Mesmo que RUP e Scrum não sejam metodologias tão recentes, ainda existe muita discussão sobre igualdades e diferenças entre Casos de Uso e User Story. Casos de Uso são descrições não técnicas e não-tecnológicas daquilo que o usuário pode esperar do sistema. São descrições da interação do usuário com o sistema, compostos pelas ações que o usuário toma e o sistema responde até que o objetivo seja alcançado, não importando como sistema seja construído, ele apenas tem que funcionar daquela forma especificada. Um caso de uso agrupa todas as sequências específicas de ações e interações entre atores e o sistema em forma de cenários, regras de negócio, requisitos de interface, requisitos de desempenho, etc. Um cliente por sua vez, não tem a capacidade de agrupar todas essas informações, ele só está interessado no produto final.
52
User Stories são descrições simples e curtas daquilo que o sistema terá que fazer, sendo aconselhável que o cliente faça a user story, ou pelo menos esteja presente quando for criada [26]. User Stories podem ser particionadas em outras “mais simples” buscando aumentar a velocidade ou separar o trabalho de implementação por alguma razão prática, nos casos de uso os requisitos são atômicos, não podendo se divididos.
As user stories não ignoram o levantamento de requisitos, essa responsabilidade é repassada para o Product Owner . Uma User Story é uma menor quantidade de informações necessárias para que o cliente defina um caminho através de um sistema. Um caso de uso é uma descrição completa de uma seqüência de interações; ele não é normalmente um passo ou atividade individual em um processo. Algo que não traz unanimidade para desenvolvedores na escolha de uma metodologia é: como criar um conjunto de user stories sem passar pelo levantamento de requisitos? Para qualquer metodologia usada existe a necessidade de um levantamento de requisitos. Se esse levantamento é documentado ou não, é uma escolha à parte. O que persiste é que a lista de requisitos deve existir, assim nenhuma metodologia menospreza requisitos, mas metodologias ágeis não falam em documento de requisitos. Algumas das características que diferem os casos de uso das user stories são mostradas na tabela 5.1: Tabela 5.1: Características dos Use Cases e User Stories
Em resumo, o enfoque ao utilizar-se de casos de uso e seus relacionamentos é identificar os objetivos do usuário, em vez de funções do sistema. O caso de uso é uma visão externa do
53
sistema com um objetivo maior. O usuário pode escrever a descrição de um caso de uso da forma que puder, com grau de formalidade ou não, mas a organização em cenários não deverá ser feita por ele, a não ser que seja treinado para isso. Já um diagrama de caso de uso, que representa os objetivos do sistema é um artefato gerado que contribuiria para o entendimento do cliente, mesmo sendo coisas diferentes: diagramas e descrições do caso de uso. Já um User Story também se concentra no comportamento externo do sistema, mas ela é uma unidade de informação menor, menos arbitrária e “escrita pelo cliente” ou pelo menos, uma transcrição tão fiel quanto possível de uma história dele [3]. A descoberta de user stories é feita constantemente, desde um conjunto inicial, criado no início do projeto, que seria na forma de “levantamento de requisitos”, até o fim do projeto. É um processo constante, derivativo e refinador, onde à medida que novas expectativas de funcionalidades existentes são descobertas novas user stories são criadas para refinar tais descobertas. As comparações entre os dois artefatos são inevitáveis, na tabela 5.2 pode-se entender um pouco mais sobre as semelhanças e diferenças entre os casos de uso (use case) e as user stories. Tabela 5.2: Tabela Comparativa entre Use Case e User Story
Portanto pode-se sim usar as duas, mas a equipe de desenvolvimento deve escolher como usá-las. Uma mistura onde, user stories são utilizadas para incrementar e desenvolver e os casos de uso, simples descritivos, utilizados para a documentação, ajudando na rastreabilidade dos requisitos. Pode-se utilizar modelos gráficos, diagramas de caso de uso, de atividades e classes, para uma comunicação eficiente com o cliente e obter um feedback mais rápido, melhor e recebendo como resposta User Stories.
54
5.3 Análise sobre Metodologias e os Modelos de Qualidade No capítulo 2 foram apresentados os modelos de qualidade CMMI e MPS-Br no que referiam-se ao gerenciamento de requisitos. Percebe-se que ambos apresentam semelhanças, no caso, o MPS-Br na sua criação teve como uma de suas bases o CMMI, mas o processo para a qualificação nos dois modelos é diferente. O CMMI é o certificado internacional que garante a utilização de processos maduros de desenvolvimento e gerência de projetos. Uma organização com qualificação no CMMI pode fazer diferença na escolha de um fornecedor de software, devido justamente a confiabilidade em processos e qualidade que o modelo certifica. Um ponto chave para que as empresas desenvolvedoras de software no Brasil deixem de buscar a certificação no modelo CMMI é seu alto custo, criando um abismo ainda maior entre empresas grandes e empresas emergentes. Neste contexto, o MPS-Br é o modelo de qualidade adaptado às necessidades das empresas brasileiras. Com seu custo para a qualificação acessível, o modelo oferece facilidades para que pequenas e médias empresas brasileiras busquem qualificação, mantendo um padrão de avaliação reconhecido. Os dois modelos de qualidade apontam o caminho que deve-se seguir, cabe a metodologia de desenvolvimento escolhida percorrer esse caminho sem desvios nem erros. Empresas que utilizam tanto o Scrum como o RUP poderiam e deveriam buscar certificação nos modelos de qualidade, mas a dúvida gerada seria: qual modelo é o mais indicado para a metodologia aplicada na empresa. Depois da análise da gerência de requisitos nas metodologias RUP e Scrum mostra-se à seguir uma análise sobre qual o modelo de desenvolvimento mais adequado para a metodologia adotada numa empresa que busca uma certificação de nível 2 no CMMI e de nível G no MPS-Br.
5.3.1 Scrum Se por um lado as metodologias ágeis têm seu foco de desenvolvimento na equipe e no projeto, por outro o modelo CMMI usa a organização como foco. Por isso ainda existe muito questionamento sobre uma empresa que adote metodologias ágeis, como o Scrum, buscar a certificação CMMI. Como dito anteriormente, no nível de projeto, o CMMI foca mais em fazer o projeto enquanto o Scrum foca em desenvolver o produto. Mas, segundo GLASER et al [6], existe a possibilidade da utilização de modelos ágeis em conjunto com o CMMI. O que impossibilita
55
isso é que algumas abordagens ágeis não funcionam bem em todos os contextos, e alguns detalhes solicitados pelo CMMI podem ser considerados “um exagero” em um ambiente ágil. No caso de uma empresa que utiliza o Scrum optar pela certificação no MPS-Br a questão torna-se um pouco mais simples devido à flexibilidade do Scrum para adaptar-se a mudanças e mesmo que o Scrum Team não esteja preparado para a certificação. Um fato evidente é que no Brasil a quantidade de pequenas e médias empresas desenvolvedoras de software é grande e está em ascensão, e o MPS-Br é um método para avaliar e qualificar essas empresas, sendo que a maioria delas utiliza métodos ágeis de desenvolvimento. Seguindo esse raciocíno, pode-se entender que a parceria Scrum e MPS-Br seja mais interessante em comparação ao CMMI, tudo isso considerando o cenário brasileiro, mas é possível que uma empresa brasileira busque certificação no modelo CMMI utilizando a metodologia Scrum, tudo vai depender para qual finalidade a empresa estará buscando a certificação.
5.3.2 RUP A metodologia RUP ainda está associada à palavra “pesado”, para muitos desenvolvedores seu excesso de formalismo e documentação acaba fazendo com que não seja aplicada ou escolhida outra metodologia em seu lugar. Essa associação não é totalmente correta, o que ocorre é que atualmente existe uma busca por velocidade de desenvolvimento unida com a questão da qualidade, assim quando o termo “velocidade” entra em questão o RUP acaba perdendo alguns pontos já que seus artefatos priorizam o desenvolvimento à velocidade. Nesse quesito a busca pela certificação no modelo CMMI utilizando a metodologia RUP é propícia devido às características dos dois. Na realidade, a maneira com que o CMMI e o RUP tratam o desenvolvimento de projetos é bem próxima, buscando formalismo, análise específica e documentação. A certificação no MPS-Br de uma empresa que utiliza o RUP pode ocorrer de maneira similar ao que aconteceria com o CMMI, pois diferentemente do Scrum onde existem menos “detalhes”, o RUP apresenta já nas fases de Início e Elaboração a preocupação com riscos do desenvolvimento, estimativa de custo, garantia de uma arquitetura fixa e etc. Uma empresa que utiliza o RUP poderia buscar certificação em qualquer um dos dois modelos de qualidade apresentados, e se a empresa aplica o RUP com todas as suas características a certificação no CMMI, que seria algo complicado para o Scrum, seria menos trabalhoso para o RUP.
56
Conclusão Este trabalho apresentou como é feito o gerenciamento de requisitos no desenvolvimento de software, utilizando metodologias tradicionais, em específico o RUP, e metodologias ágeis, em específico o Scrum, aliado com os modelos de qualidade CMMI e MPS-Br, em seus níveis que tratam os requisitos. Percebe-se que as duas metodologias apresentadas têm maneiras diferentes de tratar os requisitos, o RUP utiliza-se de Use Case (Casos de Uso) enquanto o Scrum usa User Story. Mesmo os nomes parecendo iguais existem muitas diferenças, como pôde ser visto no capítulo 5.2, e essas diferenças não estão apenas na maneira como os requisitos são levantados, mas também em como eles são mantidos, documentados, no seu tempo de vida e na participação do cliente. Mesmo com as diferenças apresentadas, ainda existem pontos em comum nos dois artefatos que podem torná-los complementares se usados da maneira correta. O Scrum trata dos requisitos de maneira rápida, não documentada e com um tempo de vida curto, pois após a iteração em que é usado o requisito deixa de existir. O RUP pode tornar-se o complemento desse tratamento na medida em que a documentação feita para os requisitos é bem elaborada e o tempo de vida de um requisito pode extender-se até o final do projeto, mantendo um documento de requisitos. Dessa maneira, podemos contar com um tratamento híbrido entre RUP e Scrum no gerenciamento de requisitos de um desenvolvimento de software, aumentando a qualidade, a confibilidade e rastreamento dos requisitos do sistema. Os modelos de qualidade CMMI e MPS-Br tratam do gerenciamento de requisitos nos seus níveis mais baixos, nivel 2 e nível G respectivamente, mas eles somente especificam “o que” deve ser feito, cabe a metodologia utilizado mostrar “como” deve ser feito. Nessa questão, este trabalho mostrou no seu capítulo 5.3 que tanto o Scrum como o RUP podem buscar a certificação nos dois modelos, as diferenças ficam por conta da finalidade da obtenção da certificação. No cenário brasileiro, onde pequenas e médias empresas de desenvolvimento nascem a cada dia, a certificação no MPS-Br é mais indicada justamente pela maioria dessas empresas
57
adotarem metodologias ágeis de desenvolvimento, como o Scrum. Como já dito anteriormente, uma empresa que adota o RUP também pode buscar essa certificação e talvez até seja mais confortável se analisarmos a maneira que o RUP trata o desenvolvimento. Ainda sobre a questão do impasse CMMI x Ágile, onde alguns acreditam que não seja possível a certificação, em alguns casos, essa impossibilidade não é causada pelo conflito de práticas mas pela não-sincronia de pensamento dos utilizadores dos dois, ou seja, existem diferenças, mas são as pessoas (os desenvolvedores), que aumentam ou diminuem essa diferença. Para trabalhos futuros na área de Gerência de Requisitos trataremos da questão de ajuda na criação, levantamento e descrição dos requisitos de um software. Um banco de dados que armazene os artefatos completos e validados, e que permita a recuperação dos requisitos para uma reutilização seria de grande importância, já que essa área em específico, ainda oferece poucas opções de ferramentas ou algo que auxilie o levantamento de requisitos com o cliente.
58
Referências Bibliográficas [1] SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral. 2009. [2] KRUCHTEN, P. The Rational Unified Process: An Introduction. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003. ISBN 0321197704. [3] COHN, M. User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series). [S.l.]: Addison-Wesley Professional, 2004. ISBN 0321205685. [4] CMMI para Desenvolvimento, versão 1.2. [S.l.]: SEI - Software Engineering Institute, 2010. [5] JOKELA, T.; LALLI, T. Usability and CMMI: does a higher maturity level in product development mean better usability? In: CHI ’03: CHI ’03 extended abstracts on Human factors in computing systems. New York, NY, USA: ACM, 2003. p. 1010–1011. ISBN 158113-637-4. [6] GLASER, H. et al. CMMI or Agile: Why not embrace both! [S.l.], 2008. Technical Note CMU/SEI-2008-TN-003. [7] SILVA, S. M. A.; BONIN, M. R.; PALUDO, M. A. Levantamento de Requisitos segundo o método volere. In: . Curitiba, PR, BRA: [s.n.], 2005. [8] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. Unified Modeling Language User Guide, The (2nd Edition) (Addison-Wesley Object Technology Series). [S.l.]: Addison-Wesley Professional, 2005. ISBN 0321267974. [9] SCHWABER, K. Agile Project Management With Scrum. Redmond, WA, USA: Microsoft Press, 2004. ISBN 073561993X. [10] SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum . Upper Saddle River, NJ, USA: Prentice Hall PTR, 2001. ISBN 0130676349. [11] PRESSMAN, R. Engenharia de Software. 6.. ed. New York, NY, USA: McGraw-Hill, Inc., 2006. [12] SOMMERVILLE, I. Engenharia de Software. 6.. ed. München: Pearson Studium, 2003. [13] NUSEIBEH, B.; EASTERBROOK, S. Requirements engineering: a roadmap. In: ICSE ’00: Proceedings of the Conference on The Future of Software Engineering . New York, NY, USA: ACM, 2000. p. 35–46. ISBN 1-58113-253-0. [14] IEEE-STD-1233-1998. IEEE - Guide for Developing System Requirements Speci fications. In: . [S.l.]: IEEE Computer Society Press, 1998. ISBN 0738103373. URL=http://ieeexplore.ieee.org/iel4/5982/16016/00741940.pdf.
