Jos Andr Dorigan

Gerenciamento de Requisitos: Um Comparativo entre Metodologias Tradicionais e geis sob a tica dos Modelos de Qualidade

Londrina 2010

Jos Andr Dorigan

Gerenciamento de Requisitos: Um Comparativo entre Metodologias Tradicionais e geis sob a tica dos Modelos de Qualidade
Trabalho apresentado Universidade Estadual de Londrina, como parte do requisito para obteno do ttulo de Bacharel em Cincia da Computao.

Orientador: Prof. Dr. Rodolfo Miranda de Barros

U NIVERSIDADE E STADUAL DE L ONDRINA

Londrina 2010

Jos Andr Dorigan

Gerenciamento de Requisitos: Um Comparativo entre Metodologias Tradicionais e geis sob a tica dos Modelos de Qualidade

Prof. Dr. Rodolfo Miranda de Barros Universidade Estadual de Londrina

Prof. Dr. Mario Lemes Proena 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 irms e meus amigos...

Agradecimentos
Primeiramente, gostaria de agradecer aos meus pais, Jos Luis e Aparecida pelo incentivo, tanto na questo nanceira como no carinho e a compreenso que tiveram comigo ao longo desses 4 anos de curso. Mesmo estando to longe eu sempre soube que quando eu precisasse eles estariam l por mim. eles um muito obrigado seria pouco. As minhas irms Carina e Patrcia que me ajudaram em vrias oportunidades e que eu pude ajudar tambm com a pouco, mas inestimvel, experincia que eu pude ter morando longe de casa. A Deus, por me permitir ter tantas oportunidades acadmicas, sociais e prossionais. Ao Professor Dr. Rodolfo Miranda de Barros, que alm de orientador nesse trabalho um amigo que tenho muito orgunho de ter conhecido, sempre que precisei de algo me ajudou e continua ajudando nesse nal de caminhada. Espero ainda, que possamos trabalhar um bom tempo juntos no mestrado e quem sabe num possvel doutorado. Ao Professor Dr. Mario Lemes Proena Jr. com quem tive a oportunidade de trabalhar desde a metade do ano de 2009, no projeto de pesquisa GAIA - Fbrica de Projetos de TIC, juntamente com o Prof. Rodolfo, incentivou a mim e aos outros componentes da equipe mostrando que deveramos pensar frente, buscando utilizar novas tecnologias e sempre manter o comprometimento ao trabalho desenvolvido. A todos os professores e funcionrios do Departamento de Computao, que buscaram nos preparar ao mximo para que tivessemos uma tima qualicao acadmica. Mesmo nos momentos difceis, sempre existiu algum em quem pudemos conar e que trabalhou para nos oferecer o melhor. Aos meus amigos de longa data (os que caram l em Amparo e os de Londrina), aos meus amigos de hoje, e tambm aqueles que estiveram presentes nesse tempo que passei em Londrina. Sempre me lembrarei das risadas, festas e cervejadas em que estivemos juntos. Todos so e foram importantes para mim, e co muito feliz de t-los conhecido. Por m, a Universidade Estadual de Londrina, por oferecer a qualidade de ensino e o curso de Cincia da Computao.

"Ningum nasce odiando outra pessoa pela cor de sua pele, por sua origem ou ainda por sua religio. Para odiar, as pessoas precisam aprender e, se podem aprender a odiar, podem ser ensinadas a amar." Nelson Mandela

Resumo
Este trabalho tm por nalidade apresentar os conceitos e o gerencimento de requisitos na metodologia tradicional RUP (Rational Unied Process) e na metodologia gil Scrum, mostrar um comparativo entre Casos de Uso e User Story, suas semelhanas e diferenas no que diz respeito como os requisitos so levantados, como so mantidos, e qual a participao 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 certicao nos nveis 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 Unied 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 whats 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 certication levels that deals with the requirements.

Keywords: requirements management, Use Case, User Story, Agile Methodologies, Tradicional Methodologies, CMMI, MPS-Br.

Sumrio

Lista de Figuras Lista de Tabelas Lista de Abreviaturas Introduo 1 Engenharia de Requisitos: Conceitos 1.1 Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 1.1.3 1.1.4 1.2 2 Identicar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analisar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Validar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12 p. 13 p. 15 p. 16 p. 17 p. 18 p. 18 p. 18 p. 18 p. 21 p. 22 p. 24 p. 26 p. 26 p. 27 p. 27 p. 29

Gerenciamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . .

A Engenharia de Requisitos nos modelos de qualidade 2.1 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.2 CMMI Nvel 2: Gerenciamento de Requisitos . . . . . . . . . . . . .

MPS-Br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 Norma ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . Norma ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . Nveis de Maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . Nvel G: Gerncia de Requisitos . . . . . . . . . . . . . . . . . . . .

Metodologias Tradicionais 3.1 RUP: Rational Unied Process . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disciplinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 31 p. 33 p. 34 p. 37 p. 40 p. 41 p. 43 p. 43 p. 44 p. 44 p. 45 p. 46 p. 47 p. 47 p. 48 p. 48 p. 50 p. 51 p. 54 p. 54 p. 55 p. 56 p. 58

Metodologias geis 4.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint Planning Meeting . . . . . . . . . . . . . . . . . . . . . . . . Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint Review Meeting . . . . . . . . . . . . . . . . . . . . . . . . . Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . .

Anlise sobre a Gerncia de Requisitos e os Modelos de Qualidade 5.1 5.2 Problemas na obteno de requisitos . . . . . . . . . . . . . . . . . . . . . . Obteno e gerncia de requisitos nas metodologias RUP e Scrum . . . . . . 5.2.1 5.3 Use Case x User Story . . . . . . . . . . . . . . . . . . . . . . . . .

Anlise sobre Metodologias e os Modelos de Qualidade . . . . . . . . . . . . 5.3.1 5.3.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Concluso Referncias Bibliogrcas

Lista de Figuras
1.1 2.1 2.2 3.1 3.2 3.3 4.1 4.2 4.3 5.1 5.2 Conjunto de atividades da Engenharia de Requisitos . . . . . . . . . . . . . . Representaes do CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . Representao dos nveis de maturidade do MPS-Br [1] . . . . . . . . . . . . Modelo Clssico de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . Modelo Iterativo ou Incremental [2] . . . . . . . . . . . . . . . . . . . . . . Arquitetura do Modelo RUP [2] . . . . . . . . . . . . . . . . . . . . . . . . Ciclo da Metodologia Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . Cartas usadas no Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de diagrama de caso de uso [2] . . . . . . . . . . . . . . . . . . . . Exemplo de uma User Story [3] . . . . . . . . . . . . . . . . . . . . . . . . p. 17 p. 23 p. 29 p. 31 p. 32 p. 33 p. 42 p. 45 p. 45 p. 50 p. 51

Lista de Tabelas
5.1 5.2 Caractersticas dos Use Cases e User Stories . . . . . . . . . . . . . . . . . Tabela Comparativa entre Use Case e User Story . . . . . . . . . . . . . . . p. 52 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 Unied Process IEEE Institute of Electrical and Electronics Engineers UML Unied Modeling Language SEI Software Engineering Institute CMM Capability Maturity Model for Software MCT Ministrio da Cincia e Tecnologia FINEP Financiadora de Estudos e Projetos BID Banco Interamericano de Desenvolvimento IEC International Electrotechnical Commission TI Tecnologia de Informao MR-MPS Modelo de referncia para melhoria do processo de software MA-MPS Mtodo de avaliao para melhoria do processo de software MN-MPS Modelo de negcio para melhoria do processo de software IBM International Business Machines XP Extreme Programing FDD Feature Driven Development ASD Adaptive Software Development

13

Introduo
A Gerncia de Requisitos, sendo uma rea da Engenharia de Software, tem como preceito utilizar as diretrizes de modelos de referncia 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 prticas consideradas efetivas que estabelecem prioridades para o gerenciamento e a melhoria da qualidade. Essas prioridades so aplicadas criteriosamente no processo de desenvolvimento de software[5]. O MPS-Br nasceu com base nos moldes do CMMI, porm dentro de uma realidade mais especca da cultura e do mercado de pequenas e mdias empresas de desenvolvimento de software no Brasil. Embora com conceitos herdados, a proposta brasileira tambm se baseia em outras normas internacionais, como ISO - 12207 para desenvolvimento de software, e ISO 15504 para avaliao de processos de software. Uma das principais vantagens do modelo seu custo reduzido de certicao em relao s normas estrangeiras. Nas suas especicaes, os dois modelos apresentam o que deve ser feito para que as melhores prticas no desenvolvimento de software sejam obtidas, mas no apresentam como deve-se proceder para isso[6] [7]. A qualidade no desenvolvimento de software obtida quando so adotadas metodologias onde o processo de desenvolvimento ocorre de maneira organizada e padronizada. Essas metodologias podem ser tradicionais, usando como exemplo o RUP (Rational Unied Process) ou geis, como exemplo o Scrum. Existem diferenas entre metodologias tradicionais e geis quando as utilizamos em conjunto com os modelos de referncia. O RUP um produto de um processo da Engenharia de Software, ele fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organizao de desenvolvimento[2]. Tem por objetivo a produo de software com qualidade, que satisfaa s necessidades dos usurios nais dentro de prazos e oramentos previsveis. O RUP ainda pode ser adaptado para compor as necessidades da empresa que o utiliza[8]. O Scrum uma metodologia gil para gerncia de projetos. Ela baseada em ciclos de 30 dias chamados Sprints, onde trabalha-se para alcanar objetivos bem denidos. Estes

14

objetivos so representados no Product Backlog, uma lista de atividades serem feitas sendo constantemente atualizada e repriorizada. Essa metodologia provoca uma mudana cultural dentro das equipes de desenvolvimento[9]. Tm-se uma parceria entre times de prossionais e o acmulo de tarefas e atrasos na entrega dos projetos d lugar a uma cultura de ciclos curtos de desenvolvimento que aperfeioam um produto sempre funcional[10]. O Processo de software, ou processo de engenharia de software, uma seqncia coerente de prticas que objetiva o desenvolvimento ou evoluo de sistemas de software. Estas prticas englobam as atividades de especicao de requisitos, anlise, projeto, implementao, testes e caracterizam-se pela interao de ferramentas, pessoas e mtodos[11]. Na rea de requisitos, as atividades de anlise focam na identicao, especicao e descrio dos requisitos do sistema de software. Existem vrias interpretaes e classicaes sobre requisitos, como: requisitos funcionais, no funcionais, de usurio ou de sistema[11]. comum que o cliente no saiba o que ele realmente deseja, que haja problemas na comunicao e ainda que haja mudana constante de requisitos. Todos esses fatores so recrudescidos pela intangibilidade sobre caractersticas de sistemas de software, principalmente sobre o custo de cada requisito[12]. A metodologia RUP gerencia os requisitos de um projeto atravs de Casos de Uso, enquanto a metodologia Scrum no possui um gerenciamento de requisitos de maneira explcita como o RUP, mas armazena os requisitos atravs de histrias chamadas User Stories. Este trabalho busca analisar como so tratados os requisitos nessas duas metodologias de desenvolvimento, e quais so as diferenas e semelhanas 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 possvel a certicao de uma empresa que adote tanto o RUP como o Scrum, no nvel que trata de requisitos, nos dois modelos de qualidade. Este trabalho est dividido da seguinte forma: no Capitulo 1 sero apresentados os conceitos utilizados na Engenharia de Requisitos e no Gerenciamento de Requisitos, no Captulo 2, sero apresentados os modelos de qualidade CMMI e MPS-Br e como eles tratam a gerncia 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 anlise sobre a Gerncia de Requisitos, contendo os problemas na obteno de requisitos, um comparativo entre a gerncia de requisitos nas metodologias Scrum e RUP e como as metodologias podem buscar certicao nos modelos de qualidade. Por m sero apresentadas as consideraes nais e possveis trabalhos futuros.

15

Engenharia de Requisitos: Conceitos

Antes de abordar o processo de engenharia de requisitos, importante conceituar requisito, termo freqentemente utilizado em reunies e muitas vezes sem que as partes possuam uma compreenso nica de seu signicado. A Anlise de Requisitos a primeira atividade tcnica no desenvolvimento do software, e pode ser entendida como responsvel por denir os servios que um sistema deve realizar, sua interface com os demais elementos e sob quais restries o sistema deve operar. Os requisitos dos sistemas devem estabelecer o que o sistema deve e o que no deve fazer [7]. Levantar corretamente os requisitos umas das tarefas mais importantes na construo 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 nveis de abstrao[11], como mostrado a seguir: Requisitos de Negcio: correspondem aos objetivos do negcio ou do usurio, que devem ser satisfeitos pelo sistema. Normalmente so descritos atravs de um documento denominado viso ou escopo do sistema; Requisitos de Usurios: descrevem as atividades que os usurios devero ser capazes de executar com a utilizao do sistema; Requisitos Funcionais: so os que descrevem as funcionalidades que o sistema deve possuir para que o usurio possa executar suas atividades; Requisitos no funcionais: so compostos por padres, regulamentos e contratos com os quais o sistema deve ter conformidade, descrio de interfaces externas e requisitos de desempenho; Restries: so limitantes nas possibilidades de escolha do desenvolvedor no projeto e na implementao do produto, muitas vezes utilizadas para que o projeto no tome caminhos

16

indesejveis; Atributos de qualidade: ampliam a descrio das funcionalidades do sistema atravs da descrio de caractersticas de qualidade do produto, sendo essas caractersticas importantes para o cliente e para o desenvolvedor. Os requisitos de um projeto podem ser demandados por humanos, como usurios, clientes, rgos reguladores ou desenvolvedores e tambm podem ser demandados por no humanos, como sistema de rede, sistema legado, bases de dados e ambientes [7]. Aos Requisitos esto associados os principais problemas do desenvolvimento de software, na maioria dos casos eles no reetem as reais necessidades dos usurios, por serem incompletos ou inconsistentes. Uma das principais diculdades so as mudanas em requisitos j acordados, pois acarretam re-trabalho, atrasos no cronograma, custos ultrapassados e a insatisfao dos clientes e usurios de software. Muitos desses erros poderiam ser evitados se as organizaes dispusessem de um processo de engenharia de requisitos denido, controlado, medido e aprimorado. No entanto para muitos prossionais da rea de informtica esses conceitos no so muito claros, o que certamente diculta a ao dos gerentes no sentido de aprimorar os seus processos de desenvolvimento[13]. Antes de iniciar uma especicao de requisitos importante que a organizao tenha denido um documento que dever ser elaborado, visando um entendimento comum do que deve ser produzido. O IEEE Guide for Developing Systems Requeriments Specications [14] um exemplo de documento detalhado que pode ser utilizado com este propsito.

1.1

Engenharia de Requisitos

Para elaborar e manter uma especicao de requisitos necessrio que os desenvolvedores executem um conjunto estruturado de atividades destinadas a elicitar, documentar, analisar e validar requisitos. Este conjunto de atividades, iterativas por natureza, recebe o nome de Processo de Engenharia de Requisitos[12]. A gura 1.1 mostra como a Engenharia de Requisitos se relaciona com a Produo de Requisitos e a Gerncia de Requisitos.

17

Figura 1.1: Conjunto de atividades da Engenharia de Requisitos

Segundo NUSEIBEH et al [13], quando a organizao no dispe deste processo denido formalmente e amplamente divulgado, os desenvolvedores elaboram as especicaes de forma emprica, executando atividades no padronizadas e denidas individualmente. Se isto ocorre, a qualidade da especicao depender exclusivamente da experincia e formao das pessoas, com uma elevada probabilidade de ocorrerem conitos. As atividades relacionadas ao processo de Engenharia de Requisitos apontadas por SOMMERVILLE [12] e podem ser consideradas um conjunto de boas prticas que apiam a sua execuo so apresentadas a seguir.

1.1.1

Identicar

Corresponde atividade de obter e compreender os requisitos de um sistema, atravs de entrevistas com os interessados, da anlise do domnio do problema ou de estudos de mercado. Na identicao de requisitos podemos considerar como boas prticas: A redao de uma declarao de viso e escopo do sistema; A denio dos procedimentos para desenvolvimento dos requisitos; A identicao das classes de usurios e dos diferentes grupos de interesse no sistema; A identicao dos casos de uso; A anlise dos uxos de trabalho dos usurios;

18

A denio dos atributos de qualidade do sistema; O desenvolvimento de mecanismos que possibilitem o re-uso de requisitos.

1.1.2

Analisar

Na anlise, os requisitos identicados so compreendidos e detalhadamente analisados por todos os interessados no sistema. Nesta atividade surgem muitos conitos, sendo comum a necessidade de negociao para que os requisitos sejam aceitos por todos. As boas prticas de anlise referem-se : Elaborao de um diagrama de contexto do sistema; Criao de prottipos; Anlise de viabilidade; Priorizao dos requisitos.

1.1.3

Documentar

Uma vez compreendidos, analisados e aceitos, os requisitos devem ser documentados com um nvel de detalhamento adequado, produzindo a especicao de requisitos de software. Pode ser utilizada a linguagem natural ou diagramas, como os propostos pela UML (Unied Modeling Language) [8].

1.1.4

Validar

Aps terem sido documentados, necessrio que os requisitos sejam cuidadosamente validados, principalmente quanto consistncia e a completude. Esta atividade visa identicar problemas nos requisitos, antes do incio da implementao. A importncia dessa atividade caracterizada pelo fato de que, a correo de um erro nesta fase possui um custo muito inferior correo nas fases posteriores do processo de desenvolvimento.

1.2

Gerenciamento de Requisitos

O gerenciamento de requisitos corresponde ao conjunto de atividades que auxilia a equipe do projeto a identicar, controlar e rastrear os requisitos, bem como as alteraes nos requisitos

19

em muitos momentos do projeto. Em outras palavras, o processo que gerencia mudanas nos requisitos de um sistema[15]. Mudanas ocorrem conforme os clientes desenvolvem um melhor entendimento de suas reais necessidades ou em decorrncia de alteraes em circunstncias externas como novas leis ou regulamentaes introduzidas no ambiente de negcio. Novos requisitos surgem e h alteraes nos requisitos em todos os estgios do processo de desenvolvimento do sistema. So comuns os casos em que mais de 50% dos requisitos so alterados antes que o sistema seja posto em operao, o que causa srios problemas para os desenvolvedores. Para minimizar diculdades, os requisitos devem ser documentados e controlados. Quando no h controle de alteraes, mudanas de baixa prioridade podem ser implementadas antes daquelas de alta prioridade, alm de mudanas com alto custo no serem necessariamente aprovadas. Uma das principais reas problemticas do desenvolvimento e produo de software o gerenciamento de requisitos dos clientes[16]. As principais preocupaes de gerenciamento de requisitos so: Gerenciar mudanas nos requisitos acordados; Gerenciar os relacionamentos entre os requisitos; Gerenciar as dependncias entre o documento de requisitos e outros documentos do sistema. As mudanas nos requisitos podem ser devidas a erros e confuso no processo de engenharia de requisitos, design ou problemas de implementao[15]. Os requisitos no podem ser gerenciados de forma efetiva sem rastreabilidade. Um requisito rastrevel se for possvel: Identicar quem solicitou o requisito; Saber porque o requisito existe; Identicar quais outros requisitos se relacionam com ele; Saber como o relacionamento com outras informaes como: design do sistema, implementaes e documentos do usurio. Estas informaes so utilizadas para identicar todos os requisitos afetados por mudanas propostas.

20

Boas prticas de gerenciamento de requisitos, como uma manuteno de dependncias entre requisitos, tm benefcios longo prazo, como: maior satisfao do cliente e custos de desenvolvimento mais baixos. Uma vez que os retornos no so imediatos, o gerenciamento de requisitos pode parecer uma despesa desnecessria. Entretanto, sem gerncia, a economia de curto prazo ser devastada pelos custos longo prazo. Os problemas com gerenciamento de requisitos geralmente signicam que os clientes no caram 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 mudanas e rastreabilidade, etc.

21

A Engenharia de Requisitos nos modelos de qualidade

Vrios modelos e padres tm sido propostos ao longo dos ltimos anos, devido ao crescimento do setor de software. O primeiro deles a poltica, que representa um princpio governamental, tipicamente usado como base para regras, procedimentos ou padres e geralmente estabelecido pela mais alta autoridade da organizao [16]. Um padro pode ser entendido como uma base para comparao e usado para suportar tamanho, contedo, valor ou qualidade de um objeto ou atividade. Um guia, por sua vez, uma prtica, mtodo ou procedimento sugerido. Um modelo pode ser denido como uma representao abstrata de um item ou processo, a partir de um ponto de vista especco. O objetivo do modelo expressar a essncia de algum aspecto de um item ou processo, sem prover detalhes desnecessrios. Esses modelos tm sido fortemente adotados por organizaes em todo o mundo. O SEI (Software Engineering Institute)[17] orgo internacional que tem contribudo bastante com o fortalecimento da rea de qualidade de software, atravs da denio de modelos internacionais focados no processo de software, assim como na publicao de relatrios tcnicos 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 solicitao do Departamento de Defesa dos Estados Unidos, que precisava de um instrumento de avaliao dos fornecedores contratados pelo prprio Departamento. O CMM original era especco para a rea de desenvolvimento de software, mas com o tempo foram surgindo necessidades de padres tambm para outras reas. Para isso, foram criados diversos CMMs, que no seguiam os mesmos padres entre si. Assim, em 2002 foi lanado o CMMI (Capability Maturity Model Integration), sem abandonar o CMM original,

22

visando a integrao de todos os CMMs e buscando corrigir as inconsistncias existentes. Em 2003 foi ento criado o modelo MPS-Br (Melhoria de Processo de Software Brasileiro) [1] coordenado pela SOFTEX - Associao para Promoo da Excelncia do Software Brasileiro com o apoio do MCT (Ministrio da Cincia 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 so as mesmas em que o CMMI baseado, assim pode-se dizer que os dois modelos tem equivalncia. Neste trabalho sero abordados o CMMI e o MPS-Br, sendo que ambos os modelos possuem nveis de maturidade que denem a capacidade da empresa para trabalhar em projetos grandes e complexos. Na rea de Gerncia de Requisitos, tanto o CMMI quanto o MPS-Br apresentam prticas que podem ser adotadas para manter a qualidade do desenvolvimento. No CMMI [4], o nvel 2 de maturidade o responsvel por tratar, entre outros aspectos, do gerenciamento de requisitos, enquanto que, no MPS-Br o nvel G corresponde Gerncia de Requisitos e Gerncia de Projetos [1].

2.1

CMMI

O CMMI um modelo que prope a avaliao da capacidade e da maturidade de uma organizao e indica diretrizes para a melhoria do processo de software. O termo capacitao diz respeito tanto habilidade para desenvolver software com competncia, quanto capacidade de incorporar novas tecnologias [19]. dividido em cinco nveis, aps o nvel 1, para se conquistar os outros nveis preciso que a organizao cumpra as chamadas reas de Processo. Podem ser utilizadas duas formas para representao no CMMI: Representao por Estgios: possui foco na maturidade organizacional e prov um caminho evolutivo para a melhoria do processo. Esta representao direciona e auxilia s organizaes que desejam estabelecer a melhoria de processos de software. As reas do processo so agrupadas em 5 nveis de maturidade, que devem ser atendidas na sua totalidade para viabilizar um estgio denido de melhorias. Nvel 1: Inicial ou Ad-hoc Nvel 2: Gerenciado Nvel 3: Denido Nvel 4: Quantitativamente gerenciado

23

Nvel 5: Em otimizao Representao Contnua: possui foco na capabilidade do processo e oferece um caminho exvel para a implementao de melhorias. Permite que as organizaes escolham reas especcas do processo para a implementao de melhorias, bem como implementar nveis diferentes de capabilidade para diferentes processos. Nvel 0: Incompleto ou Ad-hoc Nvel 1: Executado ou Denido Nvel 2: Gerenciado Nvel 3: Denido Nvel 4: Quantitativamente gerenciado Nvel 5: Em otimizao ou Optimizado A gura 2.1 mostra as formas de representao no modelo de qualidade CMMI.

Figura 2.1: Representaes do CMMI

O CMMI no tem por nalidade, entrar em detalhes especcos sobre como os processos devem funcionar. Sua idia denir quais so os processos imprescindveis, em que ordem devem ser implementados e como vericar se esto 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 denio de seus processos , portanto, indelegvel, embora a maioria das empresas conte com o auxlio e orientao de empresas de consultoria especializadas. Processos so tratados pelo CMMI sob a seguinte tica:

24

Ponto de vista gerencial; No trata do aspecto tecnolgico; No diz como implementar determinadas prticas, apenas o que deve ser feito.

2.1.1

CMMI Nvel 2: Gerenciamento de Requisitos

O gerenciamento de requisitos abordado pelo CMMI no seu nvel 2 (Gerenciado), sendo que, uma empresa que conquista o CMMI nvel 2, possui um diferencial em relao aos seus concorrentes, visto que o CMMI reconhecido como uma garantia de qualidade do processo de desenvolvimento de software. Alem disso, seguindo corretamente as aes 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 conana do cliente [19]. Para o nvel 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. Monitorizao e Controle de Projeto 4. Gerenciamento de Contrato com Fornecedor 5. Medio e Anlise 6. Garantia de Qualidade de Processo e Produto 7. Gerenciamento de Congurao Estas reas de processo so divididas em 5 sub-reas: Meta, Compromisso, Habilidade, Atividade e Vericao. O propsito desta rea gerenciar os requisitos dos produtos do projeto, alm de identicar possveis erros decorrentes do desenvolvimento dos requisitos do projeto [4]. Para a rea-chave de processo Gerenciamento de Requisitos temos a descrio das sub-reas seguir:

25

Meta: 1. Requisitos so gerenciados e inconsistncias com os planos de projeto e produtos de trabalho so identicados. 2. O processo estabelecido como um processo gerenciado. Compromisso: 1. O projeto segue uma poltica estabelecida pela organizao 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 servios de processos. 3. Atribuir responsabilidade e autoridade para efetuar o processo, desenvolvendo produtos de trabalho, e provendo servios do processo de gerenciamento de requisitos. 4. Os membros da equipe de desenvolvimento de software e outros grupos de software relacionados so treinados para realizar suas atividades de gesto de requisitos. Atividade: 1. Colocar os produtos do projeto de gerenciamento de requisitos em nveis apropriados do gerenciamento de congurao. 2. Identicar 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 aes corretivas apropriadas. Vericao: 1. Avaliar objetivamente a aderncia do processo de gerenciamento de requisitos com suas descries de processo, padres, procedimentos, e no-conformidades.

26

2. Rever as atividades, estados, e resultados do processo de gerenciamento de requisitos com um nvel maior de gerenciamento e resolver problemas.

2.2

MPS-Br

O Brasil um pas cujo desenvolvimento de produtos de software est entre os maiores do mundo, e a cada dia, aumenta o nvel de exigncia por parte dos clientes no que diz respeito qualidade e complexidade dos produtos. A partir deste ponto, podemos observar que as empresas esto buscando cada vez mais a maturidade nos seus processos de software para atingir padronizaes de qualidade e produtividade internacionais, que so essenciais para a sobrevivncia no mercado de TI [20]. Porm, o custo de uma certicao internacional, como o CMMI, para uma empresa pode chegar 400 mil dlares, que se torna invivel para empresas de micro, pequeno e mdio porte. Ento, 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 soluo mais especca para a cultura, mercado e a realidade brasileira, sendo compatvel com o modelo CMMI e estando em conformidade com as normas ISO/IEC 12207 para desenvolvimento de software e ISO/IEC 15504 para avaliao de processos de software.

2.2.1

Norma ISO/IEC 12207

Publicada internacionalmente em 1995 e no Brasil em 1998, passou por uma atualizao em 2002 para acompanhar a evoluo da engenharia de software, as necessidades vivenciadas pelos usurios da norma e a harmonizao com a srie de normas ISO/IEC 15504 - Avaliao de processos de software. Ela estabeleceu uma estrutura comum para os processos do ciclo de vida do software e ajudou as organizaes a obter um melhor entendimento das atividades a serem executadas nas operaes que envolvem de alguma forma o software. A estrutura da norma composta de processos, atividades e tarefas que envolvam o software. A atualizao de 2002 inseriu processos e acrescentou na sua descrio propsito e resultados de implementao, o que possibilita a avaliao de capacidade do processo. A norma, incluindo o seu anexo composta por: Processos fundamentais: Aquisio, desenvolvimento, operao e manuteno.

27

Processos de apoio: Documentao, Gerncia de congurao, Garantia de qualidade, Vericao, Validao, Reviso, Auditoria, Resoluo de problemas e usabilidade. Processos Organizacionais: Gerncia, Infra-Estrutura, Melhoria, Recursos Humanos, Gesto de Ativos, Gesto de Programa de Reuso e engenharia de Domnio. Cada processo dividido em termos de suas prprias atividades e cada atividade denida em termos de suas tarefas. A norma estabelece uma arquitetura de alto nvel abrangendo desde a concepo at a descontinuidade do software.

2.2.2

Norma ISO/IEC 15504

Em setembro de 1992, a ISO realizou um estudo chamado Necessidades e Exigncias para uma Norma de Avaliao de Processo de Software. O trabalho concluiu que era pertinente a elaborao de um padro que fosse aplicvel melhoria de processos e a determinao da capacidade. Este padro deveria considerar os mtodos e normas j existentes e abranger todos os processos de software. A ISO/IEC 15504 foi publicada em 2003 e contempla a realizao de avaliaes de processos de software com dois objetivos: A melhoria de processos; A determinao da capacidade de processos de uma organizao. Se o objetivo for a melhoria de processos, a organizao pode realizar a avaliao gerando um perl dos procesos que ser usado para a elaborao de um plano de melhorias. A anlise dos resultados identica 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 perl de capacidade. O perl de capacidade permite ao contratante estimar o risco associado contratao daquele fornecedor em potencial para auxiliar na tomada de deciso de contrat-lo ou no.

2.2.3

Nveis de Maturidade

O diferencial da certicao MPS-Br consiste na escala gradual de implementao dos nveis de maturidade. A proposta brasileira, diferente do CMMI, oferece sete nveis de maturidade, facilitando a escalada ao topo da qualidade. Ao adotar o MPS-Br, a empresa poder

28

chegar a um nvel inicial de maturidade e capacidade, com um grau menor de esforo e de investimento [20]. O MPS-Br dividido em 3 componentes: MR-MPS (Modelo de referncia para melhoria do processo de software), MA-MPS (Mtodo de avaliao para melhoria do processo de software) e MN-MPS (Modelo de negcio para melhoria do processo de software). Neste trabalho apresentamos o Modelo de Referncia para Melhoria do Processo de Software. No daremos enfoque aos outros 2 componentes pois a justicativa do trabalho analisar a gerncia de requisitos que apresentada no nvel G de maturidade do MPS-Br. MR-MPS: Modelo de referncia para melhoria do processo de software O Modelo de Referncia MR-MPS [1] dene nveis de maturidade que so uma combinao entre processos e sua capacidade. Os 7 nveis de maturidade so: A. Em Otimizao B. Gerenciado quantitativamente; C. Denido; D. Largamente Denido; E. Parcialmente Denido; F. Gerenciado; G. Parcialmente Gerenciado; A capacidade do processo a caracterizao da habilidade do processo, onde so obtidos os resultados dos processos analisados, onde cada nvel de maturao possui um nmero denido 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 so gerenciados; AP 3.1 O processo denido; 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 inovaes. AP 5.2 O processo otimizado continuamente. A gura 2.2 mostra a representao dos sete nveis de maturidade do modelo de qualidade MPS-Br.

Figura 2.2: Representao dos nveis de maturidade do MPS-Br [1]

2.2.4

Nvel G: Gerncia de Requisitos

O nvel G composto pelas reas de processo de Gerncia de Projetos e Gerncia de Requisitos. Um processo denominado gerenciado quando ele planejado, executado, medido e controlado. Os processos do nvel G so parcialmente gerenciados porque as execues dos processos so planejadas, executadas e controladas. As medies ainda so feitas de forma incipiente neste nvel. Os produtos de trabalho gerados nas execues, como por exemplo, planos de projetos e documentos de especicao de casos de uso, no sofrem um controle mais formal. Outra caracterstica que a organizao ainda no precisa implementar os processos de Gerncia de Congurao, Medio, Garantia da Qualidade, Gerncia de Portflio de Projetos e Aquisio que fariam com que ela pudesse ser considerada como Gerenciada.

30

Segundo o Guia Geral do MPS-Br [1], o propsito do processo Gerncia de Projetos estabelecer e manter planos que denem as atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o andamento do projeto que permitam a realizao de correes quando houver desvios signicativos no desempenho do projeto. Na Gerncia de Requisitos, alm do levantamento das necessidades do cliente e do software, necessrio estabelecer formalmente o compromisso entre o cliente e a empresa sobre a compreenso e correo dos requisitos fornecidos. A forma de tratar a mudana dos requisitos tambm possui um papel fundamental trazendo mais transparncia ao processo, pois possvel medir e avaliar os impactos dessas mudanas. O estabelecimento da rastreabilidade bidirecional proposto pelo nvel G tambm ajuda na avaliao do impacto causado por um requisito no desenvolvimento do sistema e na aplicao de testes. Alguns resultados esperados quando da implantao do nvel G em uma organizao so: GRE 1. Os requisitos so entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critrios objetivos; GRE 2. O comprometimento da equipe tcnica com os requisitos aprovados obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho mantida; GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas visando identicar e corrigir inconsistncias em relao aos requisitos; GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto. .

31

Metodologias Tradicionais

As metodologias tradicionais so tambm chamadas de orientadas a documentao. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais. Na dcada de 90, o custo de fazer alteraes e correes em projetos era muito alto, uma vez que o acesso aos computadores era limitado e no 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 Clssico. O modelo Clssico ou Sequencial [11] foi o primeiro processo de desenvolvimento de software. um modelo em que existe uma sequncia a ser seguida de uma etapa a outra. Cada etapa tem associada ao seu trmino uma documentao padro que deve ser aprovada para que se inicie a etapa imediatamente posterior. O problema do modelo em Sequencial sua inexvel diviso do projeto em fases distintas, o que diculta possveis alteraes que so comuns no desenvolvimento de um projeto. um modelo que deve ser usado somente quando os requisitos forem bem compreendidos. A gura 3.1 ilustra as fases do modelo Clssico de Desenvolvimento.

Figura 3.1: Modelo Clssico de Desenvolvimento

Mas, no desenvolvimento de software, nem sempre todos os requisitos esto explcitos

32

no incio do projeto. Uma grande porcentagem dos requisitos so descobertos nas fases posteriores do desenvolvimento, criando assim o re-trabalho de analisar novamente o projeto e vericar onde esses novos requisitos sero tratados e o impacto causado por eles no software em produo [2]. Assim um novo modelo foi proposto chamado de Modelo Iterativo ou Incremental, onde a idia bsica permitir ao desenvolvedor tirar vantagem daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma verso do sistema. O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usurio do sistema. A gura 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 resoluo dos problemas encontrados no modelo de desenvolvimento de software sequencial ou cascata, surgiu o RUP (Rational Unied Process) um produto/processo iterativo, incremental e customizvel de Engenharia de Software que foi inicialmente desenvolvido e comercializado pela Rational, e desde 2003 pertencente IBM R . Existem ainda outras metodologias tradicionais, sendo a maioria baseada em algum modelo de desenvolvimento, seja no modelo clssico ou cascata, no modelo iterativo, em prototipagem, por estgios, 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 construda no gerenciamento de requisitos [2], sendo possvel prioriz-los, detectar inconsistncias e permitindo at mesmo a criao de um repositrio para requisitos do sistema.

33

3.1

RUP: Rational Unied Process

Processo por denio e produto pela maneira como comercializado, o RUP prov de uma maneira disciplinada, a atribuio de tarefas e responsabilidades dentro de um time de desenvolvimento. Seu maior objetivo garantir a produo de software de alta qualidade e que satisfaa as expectativas e necessidades dos usurios nais dentro de um prazo e oramento aceitveis. A gura 3.3 mostra a arquitetura bsica do RUP, onde pode-se perceber suas duas dimenses:

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 dimenso demonstra o aspecto dinmico do processo, suas fases e iteraes. A vertical representa os grupos de atividades lgicas que so realizadas durante o decorrer do tempo. Essa dimenso demonstra o aspecto esttico do processo, que ser composto por disciplinas, atividades, uxos, artefatos e papis. O RUP incorpora as melhores prticas de desenvolvimento de software de acordo com o sucesso apontado pela indstria de software, que so: Desenvolvimento iterativo; Gerenciamento de requisitos; Arquitetura baseada em componentes;

34

Modelo visual de software; Vericao contnua da qualidade de software; Controle de mudana de software. O RUP trata o desenvolvimento de software de uma maneira iterativa e incremental, ou seja, substitui o modelo clssico de desenvolvimento em cascata para uma abordagem um pouco mais dinmica, dividida em iteraes, onde dentro de cada iterao, teremos a execuo de cada uma de suas Disciplinas, em proporo de acordo com a Fase do projeto Em sua essncia, o RUP centrado na arquitetura e dirigido por casos de uso, isso signica 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 esto intimamente ligados arquitetura. Em KRUCHTEN [2] existe a seguinte denio de arquitetura: tudo o que sobra quando voc no 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. Alm disso, o RUP dirigido por casos de uso [21], podemos mostrar que para solucionar um problema, deve-se primeiro entender da melhor forma possvel esse problema, divid-lo e organiz-lo de uma maneira que todos os envolvidos no projeto de construo desse sistema possam compreender a situao. Para realizar essas atividades, o RUP encontra na UML a soluo: 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 execuo. Segundo KRUCHTEN [2] suas fases correspondem : Incio (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 enderear riscos de requisitos e negcio antes de continuar com o projeto. Para projetos de novos sistemas, essa fase certamente

35

ser mais demorada, porm, para projetos relacionados a sistemas j existentes, a fase de incio mais breve, e continuar com foco de garantir que o projeto seja possvel e vivel. Os objetivos da fase de incio incluem: Estabelecer a viso do projeto: escopo, limites, condies, critrios de aceitao, etc; Elencar os casos de uso crticos do sistema e conhecer os principais cenrios das funcionalidades centrais do sistema; Exibir e demonstrar ao menos uma arquitetura candidata para atender a esses casos de uso crticos; Estimar o custo e prazo total do projeto como um todo e estimar de maneira detalhada a fase seguinte (Elaborao); Estimar os potenciais riscos do projeto; Preparar o ambiente de suporte para o projeto. As disciplinas mais aplicadas nessa fase so: Modelagem de Negcio, Requisitos, Gerenciamento de Projeto e Ambiente. Elaborao (Elaboration) Aqui fecha-se a arquitetura do sistema, estabelecendo uma base slida para o design e implementao do sistema. A arquitetura dever considerar os requisitos mais signicantes, ou seja, aqueles que produzem um impacto na arquitetura do sistema, e uma avaliao de riscos. Essa arquitetura dever ser avaliada atravs de um ou mais prottipos arquiteturais. Os objetivos da fase de elaborao incluem: Garantir que a arquitetura, seus requisitos e o planejamento do projeto esto estveis; Prever custo e prazo da completude do desenvolvimento; Enderear todos os riscos arquiteturais signicantes do projeto; Estabelecer a linha arquitetural do projeto; Demonstrar que a arquitetura selecionada suportar os requisitos do sistema atravs de custo e prazo razoveis;

36

Estabelecer o ambiente de suporte para o projeto. As disciplinas aplicadas nessa fase so: Requisitos, Anlise e Design, Implementao, Testes, Gerenciamento de Projeto e Ambiente. Construo (Construction) Na fase de construo, os requisitos restantes so levantados e aprovados e se completa o desenvolvimento do sistema, baseado na arquitetura denida. A nfase aqui passar do desenvolvimento terico criado nas fases anteriores para o desenvolvimento de um produto pronto para entrega. Os objetivos da fase de construo incluem: Minimizar custos de desenvolvimento, evitando re-trabalho desnecessrio; Alcanar uma qualidade adequada para o produto; Criar verses utilizveis do sistema; Completar a Anlise e Design e os testes da aplicao; Desenvolver um produto completo de maneira incremental e iterativa; Decidir se o sistema e os usurios esto prontos para o Deploy; Alcanar certo nvel de paralelismo nos trabalhos dos times de desenvolvimento. As disciplinas mais aplicadas nessa fase so: Anlise e Design, Implementao, Testes, Gerenciamento de Congurao e Mudana, Gerenciamento de Projeto e Ambiente. Transio (Transition) O foco da fase de transio garantir que o produto desenvolvido esteja disponvel para seus usurios nais. Essa fase pode estar dividida em vrias iteraes e inclui testar o produto na preparao para seu lanamento, pequenos ajustes de mercado baseados no feedback de usurios, etc. Ao nal da fase de transio, os objetivos do ciclo de vida do projeto devero ter sido alcanados e o projeto estar prestes a ser nalizado. Os objetivos da fase de transio incluem:

37

Teste beta para validar o novo sistema de acordo com as expectativas dos usurios; Operao paralela com os sistemas legados que sero substitudos; Converso de base de dados; Treinamento de usurios; Empacotamento e Deploy do sistema; Validao da linha de Deploy em relao viso completa do projeto e seus critrios de aceitao do produto; Alcanar o auto-suporte dos usurios; Conseguir a validao nal do usurio em relao ao produto. As disciplinas mais aplicadas nessa fase so: Deployment, Gerenciamento de Congurao e Mudana 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 sero executadas por um papel distinto no processo e podero ou no gerar artefatos. Seus focos e objetivos sero mostrados seguir. Modelagem de Negcio (Business Modeling) Garantir que os objetivos e expectativas de todos os stakeholders do projeto estejam alinhados com os objetivos da organizao, e assim derivar desses objetivos os requisitos de sistema que devero ser atendidos para solucionar problemas e/ou necessidades. Requisitos (Requirements) Denir os limites do sistema e, de acordo com os requisitos desse novo sistema, criar os casos de uso que sero a base slida para se estimar os custos e esforos de desenvolvimento. Aqui, todos os stakeholders do projeto devem compreender e aceitar tudo que o sistema dever fazer.

38

Anlise e Design (Analysis & Design) Transformar os requisitos em desenhos do sistema que ser construdo. uso do sistema. Implementao (Implementation) Transformar os modelos lgicos e fsicos criados na Anlise e Design em cdigo-fonte utilizvel e testar unitariamente o cdigo produzido. Testes (Test) Encontrar, documentar e enderear os defeitos na qualidade do software produzido. Esses defeitos surgem da comparao entre o que foi produzido com o que foi exposto nos requisitos e modelos lgicos e fsicos do produto. Deployment (Deployment) Garantir que o software produzido que disponvel para seus usurios nais. Gerenciamento de Congurao e Mudana (Conguration & Change Management) Controlar as mudanas e manter a integridade de cada um dos artefatos produzidos no projeto. Cada um desses artefatos deve ser identicado, auditado e possuir nveis de congurao e manuteno denidos. Gerenciamento de Projeto (Project Management) Balancear objetivos que competem entre si, gerenciar riscos, monitorar o projeto e tratar regras que garantiro a entrega de um produto que ir atender s expectativas dos clientes e usurios nais. Ambiente (Environment) Congurar o ambiente para que o processo e suas atividades possam ser executados. Prover os processos e ferramentas necessrias para que todas as atividades do projeto possam ser Devem ser

produzidas as especicaes tcnicas que sero seguidas na implementao de cada caso de

39

devidamente executadas por cada papel. Em uma era onde metodologias geis esto emergindo como resposta para problemas persistentes na produo de software de qualidade, tratar do RUP pode parecer um passo para trs. Porm, se entendermos os conceitos por trs do modelo, passamos a compreender que o objetivo no prometer a resoluo de todos os problemas encontrados no dia-a-dia da Tecnologia de Informao. Vale ressaltar que os conceitos bsicos do RUP so: Iteratividade, Desenvolvimento Incremental e Customizao [8]. Por ser um modelo que traz uma srie de artefatos e uma quase innidade de uxos, atividades, etc, usurios do RUP geralmente esquecem o conceito de Customizao citado acima e passam a acreditar que, para se ter bons resultados com o processo, necessria a adoo de todo o pacote, o que no necessariamente verdade. Alm disso, o conceito de iteraes, muito pregado tambm pelo Scrum, nem sempre levado a srio quando trata-se da implantao do RUP. Isso ocorre, muitas vezes, por essa informao vital ser ofuscada por tantas outras que o processo traz, diferente do Scrum, onde as Sprints cam sempre muito claras. A aplicao do RUP em parceria com metodologias geis, processos em cascatas e em ambientes com pouca ou muita documentao possvel e podemos constatar resultados bons provenientes de projetos utilizando esses processos juntos.

40

Metodologias geis

Com a evoluo 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 reduo de risco e aumento da produtividade. O termo Metodologias geis comeou a ser divulgado em 2001 quando especialistas em processo de desenvolvimento de software representando os mtodos Scrum [10], XP (Extreme Programing) [22], entre outros, propuseram princpios comuns utilizados por todos os mtodos considerados geis. Nesse cenrio foi ento criada a Aliana gil e pouco tempo depois ainda no mesmo ano, publicado o Manifesto gil [23]. Os princpios compartilhados eram: Indivduos e iteraes ao invs de processos e ferramentas; Software executvel ao invs de documentao; Colaborao do cliente ao invs de negociao de contratos; Respostas rpidas a mudanas ao invs de seguir planos. Como citado nos princpios, as metodologias geis so baseadas no processo iterativo, mas usam a comunicao como mecanismo de controle primrio, alm do uso de verses do software desenvolvido, e para atender ao mercado de maneira rpida e eciente a evoluo vista a todo o momento, seja em uma reunio, seja ao nal de cada semana de trabalho. O foco principal o desenvolvimento de software em perodos curtos. As iteraes duram em mdia duas a quatro semanas e so tratadas como miniaturas do projeto. Ao nal de cada perodo de iterao possvel ter um software j com partes funcionais, possvel de ser usado. Alm disso, elas possuem todas as etapas necessrias para o desenvolvimento do software.

41

preciso ressaltar que, mudar a metodologia de desenvolvimento de software de uma empresa no 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 mudana cultural deve acontecer de forma gradual. O primeiro passo para essa mudana adaptar os processos da metodologia gil que ser utilizada, pois as prticas propostas por essa metodologia nem sempre so necessrias para a sua empresa, ou mesmo no so totalmente acoplveis a sua equipe e viso cultural da empresa. Metodologias geis no rejeitam os processos ou ferramentas, documentao, negociao de contratos ou o planejamento, mas para essas metodologias esses itens tm papel secundrio quando comparados com indivduos e iteraes, com software executvel e colaborao com o cliente [22]. Esses conceitos podem aproximar-se melhor do mtodo de trabalho de pequenas e mdias empresas. Os mtodos geis mais conhecidos atualmente so: Scrum, XP, FDD (Feature Driven Development), ASD (Adaptive Software Development), Crystal entre outros. Neste trabalho escolheu-se tratar sobre o Scrum, pois alm de ser o mtodo gil mais adotado um dos que apresenta melhores resultados quando aplicado a empresas de desenvolvimento de software.

4.1

Scrum

O mtodo 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 importncia do trabalho em equipe. Se um membro falhar na formao, o outro time se sobressai. justamente pela importncia desse trabalho integrado do time, que esta palavra foi utilizada como nome da metodologia. O fundamental o time trabalhar junto, as pessoas so importantes e por isso que bons resultados so alcanados utilizando essa metodologia. A funo primria do Scrum ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem como objetivo, segundo SCHWABER [9], denir 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 tambm considerado um mtodo especco para o gerenciamento do processo de desenvolvimento de software.

42

O mtodo baseia-se ainda, conforme SCHWABER [9], em princpios como: Equipes pequenas de, no mximo, 7 pessoas; Requisitos que so pouco estveis ou desconhecidos; Iteraes curtas. No Scrum, os projetos so dividos em ciclos de, no mximo 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 so mantidas em uma lista que conhecida como Product Backlog. No incio de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunio 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 seleo das atividades a equipe pode realizar o Planning Poker que um jogo onde as atividades recebem valores que podem signicar pontos relativos ou horas de trabalho, assim a equipe chega a um consenso da diculdade da tarefa. As tarefas alocadas em um Sprint so transferidas do Product Backlog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunio, normalmente de manh, chamada Daily Scrum. O objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identicar impedimentos e priorizar o trabalho do dia que se inicia. A gura 4.1 representa o ciclo de vida com as iteraes da metodologia Scrum.

Figura 4.1: Ciclo da Metodologia Scrum

Ao nal 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 prximo Sprint. Este mtodo no requer ou fornece qualquer tcnica ou modelo especco para a fase de desenvolvimento de software, apenas estabelece conjuntos de regras e prticas gerenciais que devem ser adotadas para o sucesso de um projeto. A seguir sero apresentadas as caractersticas dos conceitos utilizados, segundo KNIBERG [24] e SCHWABER [9], bem como suas dependncias e contribuies para o ciclo de vida do Scrum.

4.1.1

Product Owner

a pessoa que dene os itens que compem o Product Backlog e os prioriza nas Sprint Planning Meetings. O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritrios e se compromete a entreg-los ao nal 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 no 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 traado para o Sprint e novos requisitos no so aceitos.

4.1.2

Sprint Planning Meeting

uma reunio na qual esto presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerncia 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 reunio de modo que seja capaz de quebrar as funcionalidades em tarefas tcnicas, aps a reunio. Essas tarefas iro dar origem ao Sprint Backlog. O Product Owner no precisa descrever todos os itens que esto no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suciente descrever apenas os itens de maior prioridade, deixando a discusso dos itens de menor prioridade para o prximo Sprint Planning Meeting. Coletivamente, o Scrum Team e o Product Owner denem um objetivo para o Sprint, que uma breve descrio daquilo que se tentar alcanar no Sprint. O sucesso do Sprint ser avaliado mais adiante no Sprint Review Meeting em relao ao objetivo traado 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 negociao 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 prtica responsvel pela coleta dos requisitos, conforme aponta SCHWABER [9]. Nesta prtica, atravs de reunies com todos stakeholders no projeto, so apontados os itens, que nesse contexto so chamados de histrias ou User Story, onde o cliente com suas palavras narra o que ele necessita que o sistema faa. Assim, todas as necessidades do negcio e os requisitos tcnicos a serem desenvolvidos estaro contidos no Product Backlog que se torna uma lista de atividades que provavelmente sero desenvolvidas durante o projeto. O contedo desta lista denido pelo Product Owner. O Product Backlog no precisa estar completo no incio de um projeto. Pode-se comear 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 usurios. Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe ento determina que itens ser capaz de completar durante a Sprint que est por comear. Tais itens so, ento, 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 tcnicas 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 so extrados do Product Backlog pela equipe, com base nas prioridades denidas pelo Product Owner e a percepo da equipe sobre o tempo que ser necessrio para completar as vrias funcionalidades. A equipe deve determinar a quantidade de itens do Product Backlog que sero trazidos para o Sprint Backlog, j que ela quem ir se comprometer a implement-los.

45

Durante um Sprint, o Scrum Master mantm o Sprint Backlog atualizando-o para reetir que as tarefas so completadas e quanto tempo ainda ser necessrio para completar as que ainda faltam. A estimativa do trabalho que ainda resta a ser feito no Sprint calculada diariamente e colocada em um grco, resultando em um Sprint Burndown Chart representado, como exemplo, na gura 4.2.

Figura 4.2: Exemplo de Burndown Chart

4.1.5

Planning Poker

O Planning Poker uma tcnica de estimativa baseada no consenso de toda a equipe, onde utilizado um conjunto de cartas com valores especcos, podendo seguir uma sequncia expecca, como por exemplo, a sequncia de bonacci, deixando o jogo mais interessante para os participantes. A gura 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 aps uma breve discusso, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lanadas, elas so viradas e caso no haja consenso nos valores escolhidos, as diferenas so discutidas de forma breve, e uma nova rodada acontece at que haja a convergncia. As discusses devem ser breves, pois o objetivo evitar longas argumentaes tcnicas, que no devem de forma alguma ser o foco de uma estimativa. Algumas vantagens do Planning Poker: Equipe mais comprometida, pois todos participam; Fora a equipe a ter um conhecimento de negcio mais homogneo; Aumenta bastante a preciso das estimativas, pois considera a experincia de todos; Mais divertida que as demais tcnicas. No Planning Poker s dever existir estimativa com preciso em tarefas pequenas. Se a equipe estiver estimando em horas, um valor maior que oito considerado um chute, e geralmente signica que aquela tarefa deve ser particionada em pelo menos duas partes, e reestimada, portanto recomendvel assumir que cada tarefa deve ser pequena o suciente para poder ser executada em um dia. As estimativas por horas ainda devem ser feitas sem considerar as interrupes, ou seja, o tempo que efetivamente levara-se para concluir a tarefa em um dia ideal.

4.1.6

Daily Scrum

A cada dia do Sprint a equipe faz uma reunio diria, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identicar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Essas reunies normalmente so realizadas no mesmo lugar e hora do dia. Idealmente so 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 tambm podem estar presentes, mas s podero escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informaes sobre o estado do projeto.

47

O Daily Scrum no deve ser usado como uma reunio para resoluo de problemas. Questes levantadas devem ser levadas para fora da reunio 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 trs 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 compreenso sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum no uma reunio de status report na qual um chefe ca coletando informaes sobre quem est atrasado. Ao invs disso, uma reunio na qual os membros da equipe assumem compromissos perante os demais. Os impedimentos identicados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possvel.

4.1.7

Sprint Review Meeting

Nesta reunio, que feita ao nal de cada Sprint, o Scrum Team mostra o que foi alcanado 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, gerncia, clientes e engenheiros de outros projetos. Durante o Sprint Review, o projeto avaliado em relao 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 nal de um Sprint e serve para identicar o que funcionou bem, o que pode ser melhorado e que aes sero tomadas para melhorar.

48

Anlise sobre a Gerncia 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 ateno, pois uma especicao equivocada ou errnea pode trazer impactos no desenvolvimento a longo prazo. Os modelos de qualidade CMMI e MPS-Br auxiliam o desenvolvimento de software, e em especco o gerenciamento de requisitos. Quando uma empresa utiliza uma metodologia de desenvolvimento existem algumas facilidades ou ento impedimentos que ocorrem quando combina-se RUP e Scrum com CMMI e MPS-Br na busca pela certicao nos nveis que tratam de requisitos dos dois modelos. Neste captulo a seo 5.1 trata dos problemas na obteno dos requisitos, a seo 5.2 trata da obteno e gerncia de requisitos nas metodologias RUP e Scrum e a seo 5.3 trata da anlise pela busca de certicao nos nveis referentes requisitos nos modelos CMMI e MPS-Br.

5.1

Problemas na obteno de requisitos

Os requisitos de um software tambm apresentam problemas quando seu levantamento feito por parte do analista. Esses problemas, na maioria das vezes, esto entrelaados, o que os torna mais complicados. Neste trabalho cita-se GANE et al[25] que descreve alguns problemas: 1. Diculdade de entender o funcionamento da empresa/organizao para determinar os requisitos do sistema olhando pela perspectiva do usurio: Nesse contexto geralmente encontra-se uma frase muito conhecida na rea de desenvolvimento, onde o cliente diz O sistema est bom, mas no era isso que os usurios necessitavam. Isso acontece

49

devido especicao incorreta dos requisitos. Outras causas desse problema so: O analista no conseguiu utilizar as explanaes 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 mo entendeu a descrio dos requisitos feita pelo analista. 2. O cliente no conhece o suciente sobre suas necessidades: a tecnologia ainda muito nova para que as pessoas possam ter o conhecimento e a experincia que lhes permita imaginar como um novo software poderia ser benco para seu dia-a-dia. Isso traz um agravante no que se refere aos meios de comunicao mais populares: Televiso 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 ilgicos e incompatveis com o conhecimento do usurio. 3. Nmero excessivo de detalhes: O analista de requisitos, em sua busca por entender o funcionamento da organizao para a qual um software est sendo projetado, pode car sobrecarregado de detalhes tcnicos e sobre a organizao. perda do controle sobre as prioridades do software. 4. O documento de especicao de requisitos feito de maneira que o cliente no consegue ter uma compreenso total daquilo que ir ser desenvolvido: Muitos termos tcnicos, uxogramas de programao, cdigos, no so aquilo que o cliente est acostumado a ver. Assim espera-se que o documento de especicao de requisitos seja algo entendvel por ambas as partes pois, depois de assinado, torna-se um contrato garantindo que ser entregue ao cliente aquilo descrito. 5. Especicao que limita a liberdade de ao do grupo de desenvolvimento: O analista pode gerar um documento de especicao de requisitos que no permita que a equipe de implementao faa uso das melhores tcnicas para que o software possua melhor rendimento. Um dos desaos ainda existentes a elaborao de novas formas de participao de usurios na engenharia de requisitos[15]. Uma tendncia nas empresas que desenvolvem software terceirizar sua produo, como consequencia disso, ser necessrio que os usurios de software Os detalhes so reconhecidamente importantes, mas uma carga muito grande de detalhes pode acarretar a

50

melhorem suas prticas de engenharia de requisitos. Eles tero que exigir mais para que possam obter o que desejam [25] [15]. Em CASTRO [15], num desenvolvimento comum, a equipe de anlise de requisitos provavelmente seria parte da equipe de desenvolvimento do projeto em si, com a terceirizao de uma das partes o cliente passa a ter um papel fundamental quando elicita os requisitos, pois um equvoco pode passar desapercebido e ser somente notado no nal do projeto.

5.2

Obteno e gerncia de requisitos nas metodologias RUP e Scrum

Nos captulos 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 seo apresenta-se as principais caractersticas que podem tanto agrupar quanto diferenciar os mtodos RUP e Scrum. Tratamos primeiramente do RUP, que em sua diviso de fases, apresenta o gerenciamento de requisitos nas duas primeiras fases: Incio e Elaborao. Essas fases so responsveis por identicar os requisitos do sistema e seus riscos, prioriz-los, alm de garantir que eles estejam estveis o suciente para se seja iniciada a fase de construo do software. Nas fases inicias do projeto, o RUP cria um artefato que caracteriza sua existncia como metodologia tradicional: o Caso de Uso (Use Case). Tanto na fase de Incio quanto na de Elaborao os Casos de Uso podem ser especcados, modicados, analisados e aprovados. Aps isso o sistema ganha forma, os cenrios das funcionalidades do sistema so criados e os requisitos principais e mais importantes so especicados e aceitos pelo cliente e no deveriam receber modicaes a partir desse momento. A gura 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 atravs do Product Backlog e Sprint Backlog. Deve-se deixar bem claro que o mtodo Scrum no possui denido em sua implantao um Gerenciamento de Requisitos, como acontece com o RUP, os requisitos so apenas identicados, tratados e tornam-se funcionalidades do sistema em desenvolvimento. As User Stories [26], artefatos que caracterizam algumas das metodologias geis, nesse caso o Scrum, so responsveis por coletar os requisitos atravs do cliente, ou seja, o prprio cliente quem cria as user stories. Depois elas so analisadas e tornam-se funcionalidades que so atribudas ao Product Backlog e posteriormente ao Sprint Backlog no incio de uma Sprint. A gura 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 no sejam metodologias to recentes, ainda existe muita discusso sobre igualdades e diferenas entre Casos de Uso e User Story. Casos de Uso so descries no tcnicas e no-tecnolgicas daquilo que o usurio pode esperar do sistema. So descries da interao do usurio com o sistema, compostos pelas aes que o usurio toma e o sistema responde at que o objetivo seja alcanado, no importando como sistema seja construdo, ele apenas tem que funcionar daquela forma especicada. Um caso de uso agrupa todas as sequncias especcas de aes e interaes entre atores e o sistema em forma de cenrios, regras de negcio, requisitos de interface, requisitos de desempenho, etc. Um cliente por sua vez, no tem a capacidade de agrupar todas essas informaes, ele s est interessado no produto nal.

52

User Stories so descries simples e curtas daquilo que o sistema ter que fazer, sendo aconselhvel que o cliente faa 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 implementao por alguma razo prtica, nos casos de uso os requisitos so atmicos, no podendo se divididos. As user stories no ignoram o levantamento de requisitos, essa responsabilidade repassada para o Product Owner. Uma User Story uma menor quantidade de informaes necessrias para que o cliente dena um caminho atravs de um sistema. Um caso de uso uma descrio completa de uma seqncia de interaes; ele no normalmente um passo ou atividade individual em um processo. Algo que no 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 no, uma escolha parte. O que persiste que a lista de requisitos deve existir, assim nenhuma metodologia menospreza requisitos, mas metodologias geis no falam em documento de requisitos. Algumas das caractersticas que diferem os casos de uso das user stories so mostradas na tabela 5.1: Tabela 5.1: Caractersticas dos Use Cases e User Stories

Em resumo, o enfoque ao utilizar-se de casos de uso e seus relacionamentos identicar os objetivos do usurio, em vez de funes do sistema. O caso de uso uma viso externa do

53

sistema com um objetivo maior. O usurio pode escrever a descrio de um caso de uso da forma que puder, com grau de formalidade ou no, mas a organizao em cenrios no dever ser feita por ele, a no 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 descries do caso de uso. J um User Story tambm se concentra no comportamento externo do sistema, mas ela uma unidade de informao menor, menos arbitrria e escrita pelo cliente ou pelo menos, uma transcrio to el quanto possvel de uma histria dele [3]. A descoberta de user stories feita constantemente, desde um conjunto inicial, criado no incio do projeto, que seria na forma de levantamento de requisitos, at o m do projeto. um processo constante, derivativo e renador, onde medida que novas expectativas de funcionalidades existentes so descobertas novas user stories so criadas para renar tais descobertas. As comparaes entre os dois artefatos so inevitveis, na tabela 5.2 pode-se entender um pouco mais sobre as semelhanas e diferenas 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 so utilizadas para incrementar e desenvolver e os casos de uso, simples descritivos, utilizados para a documentao, ajudando na rastreabilidade dos requisitos. Pode-se utilizar modelos grcos, diagramas de caso de uso, de atividades e classes, para uma comunicao eciente com o cliente e obter um feedback mais rpido, melhor e recebendo como resposta User Stories.

54

5.3

Anlise sobre Metodologias e os Modelos de Qualidade

No captulo 2 foram apresentados os modelos de qualidade CMMI e MPS-Br no que referiam-se ao gerenciamento de requisitos. Percebe-se que ambos apresentam semelhanas, no caso, o MPS-Br na sua criao teve como uma de suas bases o CMMI, mas o processo para a qualicao nos dois modelos diferente. O CMMI o certicado internacional que garante a utilizao de processos maduros de desenvolvimento e gerncia de projetos. Uma organizao com qualicao no CMMI pode fazer diferena na escolha de um fornecedor de software, devido justamente a conabilidade em processos e qualidade que o modelo certica. Um ponto chave para que as empresas desenvolvedoras de software no Brasil deixem de buscar a certicao 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 qualicao acessvel, o modelo oferece facilidades para que pequenas e mdias empresas brasileiras busquem qualicao, mantendo um padro de avaliao 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 certicao nos modelos de qualidade, mas a dvida gerada seria: qual modelo o mais indicado para a metodologia aplicada na empresa. Depois da anlise da gerncia de requisitos nas metodologias RUP e Scrum mostra-se seguir uma anlise sobre qual o modelo de desenvolvimento mais adequado para a metodologia adotada numa empresa que busca uma certicao de nvel 2 no CMMI e de nvel G no MPS-Br.

5.3.1

Scrum

Se por um lado as metodologias geis tm seu foco de desenvolvimento na equipe e no projeto, por outro o modelo CMMI usa a organizao como foco. Por isso ainda existe muito questionamento sobre uma empresa que adote metodologias geis, como o Scrum, buscar a certicao CMMI. Como dito anteriormente, no nvel 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 utilizao de modelos geis em conjunto com o CMMI. O que impossibilita

55

isso que algumas abordagens geis no 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 certicao no MPS-Br a questo torna-se um pouco mais simples devido exibilidade do Scrum para adaptar-se a mudanas e mesmo que o Scrum Team no esteja preparado para a certicao. Um fato evidente que no Brasil a quantidade de pequenas e mdias empresas desenvolvedoras de software grande e est em ascenso, e o MPS-Br um mtodo para avaliar e qualicar essas empresas, sendo que a maioria delas utiliza mtodos geis de desenvolvimento. Seguindo esse raciocno, pode-se entender que a parceria Scrum e MPS-Br seja mais interessante em comparao ao CMMI, tudo isso considerando o cenrio brasileiro, mas possvel que uma empresa brasileira busque certicao no modelo CMMI utilizando a metodologia Scrum, tudo vai depender para qual nalidade a empresa estar buscando a certicao.

5.3.2

RUP

A metodologia RUP ainda est associada palavra pesado, para muitos desenvolvedores seu excesso de formalismo e documentao acaba fazendo com que no seja aplicada ou escolhida outra metodologia em seu lugar. Essa associao no totalmente correta, o que ocorre que atualmente existe uma busca por velocidade de desenvolvimento unida com a questo da qualidade, assim quando o termo velocidade entra em questo o RUP acaba perdendo alguns pontos j que seus artefatos priorizam o desenvolvimento velocidade. Nesse quesito a busca pela certicao no modelo CMMI utilizando a metodologia RUP propcia devido s caractersticas dos dois. Na realidade, a maneira com que o CMMI e o RUP tratam o desenvolvimento de projetos bem prxima, buscando formalismo, anlise especca e documentao. A certicao 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 Incio e Elaborao a preocupao com riscos do desenvolvimento, estimativa de custo, garantia de uma arquitetura xa e etc. Uma empresa que utiliza o RUP poderia buscar certicao em qualquer um dos dois modelos de qualidade apresentados, e se a empresa aplica o RUP com todas as suas caractersticas a certicao no CMMI, que seria algo complicado para o Scrum, seria menos trabalhoso para o RUP.

56

Concluso
Este trabalho apresentou como feito o gerenciamento de requisitos no desenvolvimento de software, utilizando metodologias tradicionais, em especco o RUP, e metodologias geis, em especco o Scrum, aliado com os modelos de qualidade CMMI e MPS-Br, em seus nveis que tratam os requisitos. Percebe-se que as duas metodologias apresentadas tm 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 diferenas, como pde ser visto no captulo 5.2, e essas diferenas no esto apenas na maneira como os requisitos so levantados, mas tambm em como eles so mantidos, documentados, no seu tempo de vida e na participao do cliente. Mesmo com as diferenas 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 rpida, no documentada e com um tempo de vida curto, pois aps a iterao em que usado o requisito deixa de existir. O RUP pode tornar-se o complemento desse tratamento na medida em que a documentao feita para os requisitos bem elaborada e o tempo de vida de um requisito pode extender-se at o nal do projeto, mantendo um documento de requisitos. Dessa maneira, podemos contar com um tratamento hbrido entre RUP e Scrum no gerenciamento de requisitos de um desenvolvimento de software, aumentando a qualidade, a conbilidade e rastreamento dos requisitos do sistema. Os modelos de qualidade CMMI e MPS-Br tratam do gerenciamento de requisitos nos seus nveis mais baixos, nivel 2 e nvel G respectivamente, mas eles somente especicam o que deve ser feito, cabe a metodologia utilizado mostrar como deve ser feito. Nessa questo, este trabalho mostrou no seu captulo 5.3 que tanto o Scrum como o RUP podem buscar a certicao nos dois modelos, as diferenas cam por conta da nalidade da obteno da certicao. No cenrio brasileiro, onde pequenas e mdias empresas de desenvolvimento nascem a cada dia, a certicao 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 tambm pode buscar essa certicao e talvez at seja mais confortvel se analisarmos a maneira que o RUP trata o desenvolvimento. Ainda sobre a questo do impasse CMMI x gile, onde alguns acreditam que no seja possvel a certicao, em alguns casos, essa impossibilidade no causada pelo conito de prticas mas pela no-sincronia de pensamento dos utilizadores dos dois, ou seja, existem diferenas, mas so as pessoas (os desenvolvedores), que aumentam ou diminuem essa diferena. Para trabalhos futuros na rea de Gerncia de Requisitos trataremos da questo de ajuda na criao, levantamento e descrio dos requisitos de um software. Um banco de dados que armazene os artefatos completos e validados, e que permita a recuperao dos requisitos para uma reutilizao seria de grande importncia, j que essa rea em especco, ainda oferece poucas opes de ferramentas ou algo que auxilie o levantamento de requisitos com o cliente.

58

Referncias Bibliogrcas
[1] SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral. 2009. [2] KRUCHTEN, P. The Rational Unied 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, verso 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. 10101011. 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 mtodo volere. In: . Curitiba, PR, BRA: [s.n.], 2005. [8] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. Unied 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. Mnchen: 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. 3546. ISBN 1-58113-253-0. [14] IEEE-STD-1233-1998. IEEE - Guide for Developing System Requirements Specications. In: . [S.l.]: IEEE Computer Society Press, 1998. ISBN 0738103373. URL=http://ieeexplore.ieee.org/iel4/5982/16016/00741940.pdf.

59

[15] CASTRO, J. F. B. Introduo a Engenharia de Requisitos. In: XIV Jornada de Atualizao em Informtica. Canela, RS, BRA: SBC, 1995. [16] HUMPHREY, W. S. Managing the software process. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1989. ISBN 0-201-18095-2. [17] SEI - Software Engineering Institute. 2010. Http://www.sei.cmu.edu/. [18] CMM - Capability Maturity Model for Software. 2010. Http://www.sei.cmu.edu/cmmi/. [19] LEITHISER, R.; HAMILTON, D. Agile versus CMMI - process template selection and integration with microsoft team foundation server. In: ACM-SE 46: Proceedings of the 46th Annual Southeast Regional Conference on XX. New York, NY, USA: ACM, 2008. p. 186 191. ISBN 978-1-60558-105-7. [20] FERREIRA, A. I. F. et al. Applying ISO 9001: 2000, MPS.BR and CMMI to Achieve Software Process Maturity: BL Informaticas Pathway. In: ICSE 07: Proceedings of the 29th international conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007. p. 642651. ISBN 0-7695-2828-7. [21] COCKBURN, A. Escrevendo Casos de Uso Ecazes. So Paulo, SP, BRA: Artmed Editora S.A., 2005. ISBN 853630457X. [22] BECK, K. Programao Extrema XP Explicada. [S.l.]: Editora Bookman, 2004. 182 p. ISBN 9788577801565. [23] BECK, K. et al. Agile Manifesto. [S.l.], 2001. Http://agilemanifesto.org/iso/en/. [24] KNIBERG, H. Scrum and XP from the Trenches. InfoQ, 2007. Disponvel em: <http://www.infoq.com/minibooks/scrum-xp-from-the-trenches>. [25] GANE, C. P.; SARSON, T. Anlise Estruturada de Sistemas. [S.l.]: LTC Ltda., 1983. ISBN 9788521602453. [26] KONTIO, M. Using user stories to dene project requirements. [S.l.]: IBM Developer Works, 2008.