Home

Gerenciamento de Requisitos de Software

1. c digo especifica es membros da equipe com um conhecimento hist rico para chegar a um entendimento do que o sistema faz agora Nossa recomenda o nesses casos aplicar o processo da Vis o Delta e definir suas caracter sticas e use cases ao redor das mudan as que voc estiver fazendo no sistema legado Ao seguir esse processo voc e sua equipe podem se concentrar naquilo que novo e naquilo que diferente no pr ximo release e seu cliente e sua equipe ir o obter os beneficios de um processo de requisitos bem gerenciado Al m disso o registro dos requisitos que voc cria ir fornecer um caminho de documenta o para outros que se seguirem 140 Cap tulo 18 O Campe o Pontos chaves e O campe o produto mant m a vis o do projeto e Todo projeto necessita de um indiv duo campe o ou de uma pequena equipe campe para defender o produto e Nos ambientes do produto de software o campe o do produto ir normalmente vir do marketing o Cap tulo 1 n s analisamos os desafios de projetos e descobrimos uma variedade de causas raizes com o gerenciamento de requisitos estabelecido pr ximo ao topo da lista No Cap tulo 177 n s definimos o documento da Vis o como um documento embrion rio dentro de um ciclo de vida de software complicado este documento ataca diretamente os desafios dos requisitos e um dos documentos que voc pode olhar em qualquer momento para ver o que o produto aplica o
2. 107 Co Controlar l mpada N s come amos com uma defini o menos formal do que iremos fornecer posteriormente Um use case descreve uma seqgii ncia de a es que um sistema executa para produzir um resultado de valor a um particular ator Em outras palavras use cases descrevem as intera es entre um usu rio e um sistema e eles focam sobre o que o sistema faz para o usu rio Al m disso como as a es s o descritas numa sequ ncia f cil seguir as a es e entender o que o sistema faz para o usu rio Em UML o use case representado por uma simples figura oval com um nome abaixo Na elucida o de requisitos use cases podem elucidar e capturar requisitos do sistema Cada use case descreve uma s rie de eventos nos quais um particular ator tal como a Jenny a Modelo interage com o sistema tal como o Sistema de Agendamento de Clientes da Ag ncia de Modelos Ad Lib para atingir um resultado de valor para a Jenny tal como a localiza o do pr ximo trabalho de desfile Construindo o Modelo Use Case O modelo use case de um sistema consiste de todos os atores do sistema e de todos os use cases com os quais os atores interagem no sistema O modelo use case descreve a totalidade do comportamento funcional do sistema O modelo use case tamb m mostra os relacionamentos entre use cases os quais facilitam nosso entendimento do sistema O primeiro passo na modelagem use case criar um di
3. Conforme voc negocia com o seu cliente seu princ pio guia para estabelecer um baseline deve ser n o prometa o que provavelmente n o possa ser cumprido e 165 liberado Isso assegura que caprichos inevit veis do desenvolvimento de software riscos tecnol gico n o previstos mudan as de requisitos atrasos no recebimento de componentes adquiridos dispensa imprevista de um membro chave da equipe entre outros possam ser acomodados dentro do seu cronograma de projeto Se acontecer de voc executar um projeto livre dessas circunst ncias indesej veis tudo bem no pior caso voc ter que se preocupar com a libera o antecipada Mesmo que seja o de fornecer ao menos alguma festa consider vel dentro de sua companhia Gerenciando o Baseline Gerentes de desenvolvimento de bem sucedidos criam margens de erro na estimativa de esfor o e levam em considera o o tempo para incorporar mudan as legitimadas durante o ciclo de desenvolvimento Esses gerentes tamb m resistem s caracter sticas desagrad veis as quais o autor Jerry Weinberg 1995 nos lembra que o escopo pode se elevar at 50 100 depois de iniciar o projeto Ao se concentrar no esfor o de desenvolvimento de prioridades cr ticas do cliente pode aliviar at os ambientes pol ticos hostis Com o escopo negociado dentro de um n vel ating vel e com o foco de desenvolvimento sempre voltado para o que deve ter do cliente a equipe ir alcan ar credibilidade por
4. o de sistemas bem como em outros fatores tecnol gicos Assim importante saber como chegar aqui e tratar os requisitos de forma apropriada importante reconhecer que a especifica o de requisitos derivados ir no final afetar a habilidade do sistema de fazer seu trabalho bem como a manutenibilidade e robustez do sistema 48 Na ind stria a intelig ncia antes existente nos componentes de hardware foram alocadas aos componentes de software Uma Revolu o Silenciosa A engenharia de sistemas tem sido tradicionalmente uma disciplina aplicada principalmente a sistemas f sicos tais como sistemas de aeronaves sistemas de freios de autom veis sistemas de fontes de energia e aparelhos de consumo de energia entre outros No entanto durante os ltimos 20 anos uma revolu o silenciosa vem ocorrendo na engenharia de sistemas de sistemas complexos Gradualmente nas ind strias de transportes telecomunica es equipamentos industriais equipamentos m dicos Instrumentos cient ficos e em muitas outras ind strias os sistemas e equipamentos v m se tornando cada vez menores Para atender a eleva o da complexidade e sofistica o mais e mais funcionalidades est o sendo alocadas aos subsistemas de software ao inv s de serem alocadas aos componentes de hardware Afinal de contas o software flex vel muitos algoritmos de medi o an lise e detec o s o mais f ceis ao menos muito mais barato
5. es apropriadas do dom nio f sico o tamanho peso localiza o e distribui o dos subsistemas tiverem sido otimizados no contexto global do sistema Aloca o de Requisitos na Engenharia de Sistemas O processo flow down de requisitos aloca funcionalidades do sistema aos subsistemas Mesmo que a engenharia de sistemas tenha propiciado realizar um bom trabalho de definir os requisitos do sistema o problema de gerenciamento de requisitos ainda n o est resolvido O que se passa com esses subsistemas Quais requisitos s o impostos para cada subsistema Em muitos casos o processo o de associar os requisitos do n vel de sistema aos subsistemas Subsistema B ir executar o algoritmo de velocidade instant nea e monitorar diretamente o display de alerta Este processo distribuir requisitos flow down o principal meio de assegurar que todos os requisitos do sistema ser o atendidos por um subsistema em algum lugar ou por um conjunto de subsistemas que se colaboram 47 Sobre Requisitos Derivados Algumas vezes descobrimos que n s criamos uma nova classe de requisitos requisitos derivados que podem ser impostos aos subsistemas Tipicamente existem duas subclasses de requisitos derivados 1 Requisitos de subsistemas s o aqueles que devem ser impostos apenas a subsistemas mas n o necessariamente fornece um benef cio direto ao usu rio final Subsistema A deve executar o algoritmo que comp
6. es de tamanho limitado fazendo com que o desenvolvimento de software se tornasse cada vez mais numa atividade individual Os programadores definiam projetavam escreviam e normalmente testavam seus pr prios trabalhos s vezes testers eram alocados para ajud los nessa terr vel tarefa mas o foco era claramente a atividade individual Programadores her is era um paradigma comum 17 Desenvolvimento de Software como uma Atividade de Equipe A hist ria do desenvolvimento de software revela o aumento em escala O processo de gerenciamento de requisitos afeta todos os membros da equipe embora de maneiras diferentes O gerenciamento efetivo de requisitos somente pode ser realizado por uma equipe de software efetiva O Desenvolvimento de Software transformou se num esporte de equipe Booch 1998 Em algum ponto houve a virada Porqu Watts Humphrey 1989 observou que a hist ria do desenvolvimento de software revela o aumento em escala Inicialmente alguns indiv duos podiam manipular pequenos programas o trabalho em pouco tempo cresceu al m de suas capacidades Ent o equipes de uma on duas d zias de pessoas foram usadas mas o sucesso era imprevis vel Ao mesmo tempo em que as organiza es resolviam problemas para pequenos sistemas a escala de nossos trabalhos continuaram a crescer Atualmente grandes projetos normalmente necessitam de trabalho coordenado de v rias equipes Hamp
7. o a Figura 22 7 Workflows da abordagem iterativa Durante cada itera o a equipe gasta tanto tempo quanto apropriado em cada workflow Assim uma itera o pode ser considerada como uma muini cascata atrav s de atividades de requisitos an lise e projeto e assim por diante mas cada mini cascata dedicada s necessidades espec ficas daquela itera o O tamanho da corcova da Figura 22 7 indica a quantidade relativa de esfor o investido num workflow Por exemplo na fase de elabora o tempo significativo gasto em refinar os requisitos e em definir a arquitetura que ir sustentar as funcionalidades As atividades podem ser sequenciais um verdadeiro mini cascata ou podem ser executadas concorrentemente quando apropriado ao projeto Da perspectiva de gerenciamento de requisitos a abordagem 1terativa tr s duas significativas vantagens 1 Obter o Sim mas desde o in cio Cada itera o produz uma release execut vel tal que logo no In cio clientes t m a oportunidade de ver o produto do trabalho Claro que a rea o do cliente ser um Sim mas mas nos est gios iniciais apenas um m nimo de investimento foi realizado Conforme as itera es v o sendo realizados os tamanhos do Sim mas devem decrescer e voc e seu cliente ir em algum momento convergir para um sistema correto 174 2 Melhor gerenciamento do escopo Se a primeira itera o ult
8. o Este cap tulo descreve o processo de entrevista e fornece um modelo gen rico para conduzir a entrevista de usu rios e stakeholders No entanto o processo de entrevista n o f cil pois nos for a a uma conviv ncia pr xima e pessoal e a enfrentar a sindrome Usu rio e o Desenvolvedor Al m disso uma das metas chaves da entrevista assegurar que a propens o e a predisposi o do entrevistador n o interfira com a livre troca de informa es Este um problema sutil e pernicioso Professores de sociologia opa uma outra classe de profissional que n s evitamos nos ensinam que imposs vel haver relacionamentos entre pessoas sem o filtro do mundo que o resultado de nosso pr prio ambiente e experi ncias acumuladas Al m disso como fornecedores de solu o raramente nos encontramos numa situa o em que n o temos id ia alguma sobre os tipos solu es poss veis que possam atacar o problema De fato em muitos casos operamos dentro de um dom nio ou contexto recorrente onde certos elementos da solu o s o bvios ou ao menos nos parecem bvios N s j resolvemos esse tipo de problemas antes e esperamos que nossa experi ncia se aplique totalmente neste caso Afinal estamos apenas construindo casas e martelos e pregos atender o bem a esse prop sito Naturalmente isso n o ruim porque o nosso contexto parte do que temos de valor Nosso ponto que n o devemos deixar que o contexto
9. o para duas t cnicas mais espec ficas de solucionar problemas as quais podem ser aplicadas em certos dom nios de aplica es No Cap tulo 5 n s veremos a modelagem de neg cio uma t cnica que podemos aplicar em aplica es de Sistemas de Informa o IS IT Information system information technology No Cap tulo 6 veremos a Engenharia de Sistemas para sistemas de software intensivo que pode ser aplicado para aplica o do dom nio de sistemas embutidos Quanto ao terceiro dom nio ISV Independent software vendors pertencente a fornecedores independentes de software as t cnicas de an lise de problemas est o normalmente focadas nas seguintes atividades 36 Identificar as oportunidades e segmentos de mercado Identificar as classes de potenciais usu rios e suas necessidades particulares Estudar a demografia da potencial base de usu rios Entender o potencial da demanda do pre o e da flexibilidade de pre os Entender as estrat gias de venda e canais de distribui o Claramente estes t picos s o interessantes mas para nos ajudar a gerenciar o escopo deste volume n s n o iremos explorar tais assuntos espec ficos No entanto voc pode ficar confiante e seguro de que as habilidades de equipe que iremos explorar nos pr ximos cap tulos ir o se aplicar igualmente bem para esta classe de aplica o como iremos demonstrar Nota Uma das coisas mais dif ceis que encontramos ao escre
10. usu rios normais e usu rios especialistas e Especificar o tempo de tarefas 188
11. A Entrevista Com um pouco de prepara o e com a entrevista estruturada no bolso qualquer membro da equipe pode fazer um trabalho adequado de entrevistar um usu rio ou cliente Mas seria melhor escolher membros da equipe que sejam mais extrovertidos Aqui est o algumas dicas para o sucesso da entrevista Preparar uma entrevista livre de contexto apropriadamente e anotar numa agenda para servir de refer ncia durante a entrevista Revise as quest es um momento antes da entrevista Antes da entrevista pesquise o hist rico dos stakeholders e da companhia a ser entrevistada N o sonde as pessoas sendo entrevistadas com quest es que voc poderia ter respondido antecipadamente Por outro lado n o ser prejudicial fazer uma breve verifica o dessas respostas com o entrevistado Anote respostas numa agenda durante a entrevista N o tente coletar os dados eletronicamente nesse momento Consulte o modelo durante a entrevista para se assegurar que as quest es corretas est o sendo perguntadas O entrevistador deve garantir que o roteiro n o crie constrangimento ao entrevistado Depois que a aproxima o tenha sido bem sucedida a entrevista provavelmente seguir o seu pr prio curso Os clientes podem cair num di logo de fluxo de consci ncia descrevendo com detalhes sangrentos o horror da situa o atual E esse exatamente o comportamento que voc est procurando Se acontecer com voc n o interrompa prematu
12. Codifica o Teste de unidade Plano de integra o e teste Valida o e verifica o do projeto Teste e integra o Teste de aceita o Desenvolver verificar o produto do pr ximo n vel Implementa o Planejar pr ximas fases Figura 22 3 O modelo espiral de desenvolvimento No modelo espiral o desenvolvimento inicialmente dirigido por uma s rie de prot tipos orientados a risco ent o um processo similar ao modelo cascata usado para produzir o sistema final Naturalmente quando usado mapropriadamente o modelo espiral pode exibir tantos problemas quanto o modelo cascata usado de forma incorreta Os projetos algumas vezes caem na abordagem reduzir e tentar liberando incrementos que devem ser expandidos e mantidos com chicletes e barbantes Alguns a referenciam como o processo de criar instantaneamente c digos legados O progresso medido pela nossa recente habilidade de criar c digos incompreens veis e que n o podem ser mantidos duas ou tr s vezes mais r pida do que a tecnologia anterior No entanto quando voc olha o modelo espiral com mais cuidado ele fornece um sens vel mapa que ajuda a atacar alguns dos desafios de requisitos apresentados neste volume Em especial o modelo espiral inicia com o planejamento de requisitos e valida o de conceitos seguido por um ou mais prot tipos para assistir na confirma o precoce de nosso entendimento sobre os requisitos do sistema
13. aeee erre area aaa nana anna EErEE r era SeSe eette aaa anna anna anda 1 22 CAPITULO orea DR 125 ORGANIZANDO INFORMA ES DE REQUISITOS 125 Organizando Requisitos de Sistemas Complexos de Hardware e Software 126 Requisitos de Organiza o para Fam lia de Produtos eee 129 Sobre os Requisitos Futuros eee eee aeee tecer ana n ee eeeeee Ekee eas EErEE EEEE e reese errereen 130 Requisitos de Neg cio e de Marketing versus Requisitos de Produto 130 O Caso de ESTUDOS uu prio cs UU CET LR a RO Da AU 131 SUTO ese SO E TE 132 CAPITULO 178 sis ondas atra la bi O EA TE fa O Ae AE ba AE Ra LAE O ra 133 O DOCUMENTO DA VIS O reentrada 133 Componentes do Documento da Vis o eee eee aeee ae teen aaeeeeeraanna 133 O Documento da Vis o Della aaa aaa aa arraia 137 Documento da Vis o pato Release 10 ag iai ATE a E TE da dd Ca 137 Docomento da Visdo parva Vers o 2 0 aniani adora utah pi ua afiadas dad a a aa O ida a dA said Ds Ra Sd rn 138 O Documento da Vis o Delkanim Ambiente de Sistema LscadoO s sans a dreitia naaa aaa aN Aa dd ao AGA 140 CAPI ULO 10 ssa doado pa aq a de a da a a 141 O CAMPE O ss sais siso soa SAD SS 141 O Papel do Campe o do Produto eterna rece erre a aeee coreana neeeeeeeeaaaeeeeeeaananaa 141 O Campe o do Produto num Ambiente de Produto de Software 142 O Campe o do Produto numa Empresa de ISIT 145 SUM RIO DA HA
14. amento de pessoal Tecnologia obrigat ria Sum rio Restri es fontes e l gica para o sistema de pedidos Restri o Uma c pia exata dos dados dos pedidos de venda deve permanecer na base de dados legado por um ano A aplica o n o deve utilizar mais que 20 megabytes da mem ria RAM do servidor O sistema deve ser desenvolvido no servidor existente novos hardwares clientes para usu rios ser o fornecidos Recursos fixos de pessoal sem terceiriza o Ser utilizada a nova metodologia orientada a objetos L gica O risco de perda de dados muito grande n s precisamos executar em paralelo durante um ano Existe limita o de mem ria no servidor custos e sistema Controle de conserva o do existente Custos operacionais fixos de acordo com o atual or amento N s acreditamos que esta tecnologia ir aumentar a produtividade e elevar a confiabilidade do software Completado este passo podemos ficar razoavelmente confiantes de que conseguimos Entender o problema a ser resolvido bem como as causas ra zes do problema Identificar os stakeholders que com seu julgamento coletivo ir ao final determinar o sucesso ou o fracasso do nosso sistema Obter uma no o da fronteira da solu o Conhecer as restri es e o grau de liberdade que temos para solucionar o problema Vislumbrando o Futuro Com esta base conceitual podemos agora voltar nossa aten
15. do resultado de m ltiplas combina es e aparentemente n o relacionadas de id ias de v rios stakeholders Qualquer processo que estimule este resultado um processo realmente poderoso Quando surge uma id ia ela registrada no material fornecido pela pessoa que teve a id ia Isso importante Para assegurar que sejam registradas com as palavras da pr pria pessoa Para assegurar que n o sejam perdidas Para permitir que sejam aproveitadas posteriormente Para prevenir atrasos no processo criativo que pode ser provocado por um nico secret rio tentando capturar todas as id ias num flipchart ou quadro branco em frente sala Assim que as id ias s o geradas o facilitador coleta e as afixa sobre uma parede da sala de reuni es Novamente nenhuma cr tica s id ias pode ser tolerada N o apropriado dizer Que id ia est pida ou mesmo J temos essa id ia afixada na parede O nico prop sito gerar id ias Mesmo um pac fico coment rio negativo pode ter o delet rio danoso efeito de suprimir futuras participa es da vitima Por outro lado coment rios tais como Que grande id ia s o apropriados e s o normalmente premiados com o cupom Que grande id ia o qual pode encorajar futuras participa es de todos os stakeholders A gera o de id ias deve prosseguir at que todos os participantes sintam que tenham chegado naturalmente ao seu final comum ocorr
16. ias que acham serem v lidas N o existe raz o para que qualquer participante fique na defensiva ou reivindique autoria de qualquer id ia qualquer participante pode apoiar ou refutar qualquer id ia Dica A presen a de id ias que podem ser facilmente expurgadas uma indica o do processo de qualidade A aus ncia de uma quantidade razo vel de id ias sem nexo e malucas indica que os participantes n o pensaram no out of the box suficientemente O facilitador apenas pergunta aos participantes se cada uma das id ias merece futura considera o e ent o simplesmente remove uma id ia inv lida mas se houver qualquer desacordo entre os participantes a id ia fica na lista Se participantes acharem duas anota es com a mesma id ia agrup las na parede E prefer vel fazer isso do que remover uma seu autor pode se sentir insultado Agrupando Id ias Pode ser til durante este processo iniciar agrupando id ias similares Isso feita de forma mais efetiva quando participantes volunt rios se dirigem parede e realizam o agrupamento Id ias relacionadas s o agrupadas em regi es da parede D nomes aos grupos de id ias relacionadas Por exemplo o grupo pode ser rotulado como Novas caracter sticas Assuntos de desempenho Evolu o das caracter sticas existentes Interface de usu rio e assuntos de usabilidade Ou podem concentrar especificamente nas capacidades do sistema e na maneira como eles
17. jogo Assim antes de aumentar o tamanho da equipe antes de desenvolver especifica es mais detalhadas antes de aplicar as id ias tecnol gicas ao projeto e antes de construir scripts de testes devemos parar e aprender como gerenciar o escopo do projeto A psicologia a tecnologia e o bom gerenciamento de projeto s o partes poderosas que esta Habilidade de Equipe ir fornecer para elevar a probabilidade de atingir sucesso em projetos 149 Cap tulo 19 O Problema do Escopo de Projeto Pontos chaves e escopo de projeto uma combina o de funcionalidade de produto recursos de projeto e tempo dispon vel e A lei de Brooks estabelece que adicionar trabalhadores ao projeto de software j em atraso torna o ainda mais atrasado e Seo esfor o necess rio para implementar as caracter sticas do sistema for igual a recursos sobre o tempo dispon vel o projeto ter um escopo ating vel e Projetos al m do escopo s o normais na ind stria e Em muitos projetos a fim de fornecer uma razo vel probabilidade de sucesso ser necess rio reduzir o escopo por um fator de dois omo em qualquer atividade profissional definir compromissos no desenvolvimento de aplica o envolve fazer avalia es real sticas dos recursos de projeto tempo dispon vel e objetivos antes de iniciar as atividades Para o desenvolvimento de software esses fatores combinados criam o escopo de projeto O escopo de projeto uma fun
18. necess ria uma abordagem consciente para a log stica e pagar dividendos na medida em que um workshop seja miseravelmente organizado certamente os resultados desejados n o ser o atingidos A log stica envolve todas as coisas desde estruturar apropriadamente os convites viagens acomoda es at a ilumina o da sala de reuni es do workshop Uma cren a literal nas leis de Murphy Se pode dar errado dar errado deve ser nosso guia aqui Se voc abordar a log stica com um alto grau de profissionalismo bvio que atender aos prop sitos num importante evento e eles ir o atuar de acordo Voc ter tamb m mais sucesso no workshop 81 Material de aquecimento estimula tanto o pensamento de quem faz parte do contexto quanto de fora do contexto out of box Material de Aquecimento Quarto envie materiais do workshop antecipadamente para preparar os participantes e tamb m elevar a produtividade nas sess es de workshop Esses materiais preparam o estado de esp rito dos participantes Chamamos isso de atingir um ideal estado de esp rito Uma das mensagens que n s precisamos passar que esta n o e mais uma reuni o Esta pode ser a unica chance de dizer isso de forma correta Recomendamos que voc forne a dois tipos separados de materiais de aquecimento 1 Informa es especificas do projeto o qual pode incluir o esbo o do documento de requisitos lista de caracter sticas f
19. ngua que eles falam e que informa es devemos obter dessas pessoas para completar com sucesso a nossa jornada jornada come a na ilha do problema O Dom nio do Problema Muitas jornadas de requisitos que obtiveram sucesso come aram com uma visita ilha do problema O dom nio do problema a casa dos verdadeiros usu rios e stakeholders pessoas cujas necessidades devem ser atendidas a fim de poder construir o sistema perfeito a casa das pessoas que necessitam da pedra ou de um sistema para dar entrada aos pedidos de venda ou um sistema de gerenciamento de configura es bom o suficiente para vencer a concorr ncia Provavelmente essas pessoas n o s o como n s As experi ncias t cnicas e econ micas s o diferentes dos nossos eles falam siglas engra adas eles v o a festas diferentes e tomam bebidas diferentes eles n o vestem camisetas para trabalhar e possuem motiva es que s o estranhos e impenetr veis O qu Voc n o gosta do filme Star Trek Em raras ocasi es eles s o como n s S o programadores procurando por uma nova ferramenta ou desenvolvedores de sistemas que pediram que voc desenvolvesse uma parte do sistema Nesses raros casos esta parte da jornada talvez seja f cil mas pode tamb m ser muito mais dif cil Mas normalmente esse n o o caso e n s nos encontramos na ilha do usu rio alien gena Esses usu rios t m neg cios ou problemas t cnicos que necessitam que n
20. o e da funcionalidade que deve ser liberada para atender as necessidades do usu rio e dos recursos dispon veis do projeto e do tempo dispon vel para executar a implementa o A Figura 19 1 fornece uma perspectiva retangular que podemos usar para representar o escopo de projeto Recursos Es copo ESSA Tempo dispon vel Prazo Final Figura 19 1 Escopo de Projeto Na Figura 19 1 a rea do ret ngulo representa o escopo ating vel do projeto O Escopo de projeto deriva dos seguintes elementos e Os Recursos consistem principalmente do trabalho de desenvolvedores testers documentadores pessoal da garantia de qualidade entre outros 150 No in cio dos anos de 1970 Fred Brooks 1975 demonstrou que adicionar recursos aos projetos de software a fim de aumentar o trabalho realizado na melhor das hip teses uma proposi o de risco De fato a lei de Brooks estabelece que adicionar trabalhadores a um projeto de software que est em atrasado torna o ainda mais atrasado Se a escala de tempo for suficiente longa tudo bem o trabalho pode realmente ser realizado mas n o ser proporcional aos recursos adicionados e a efici ncia geral do projeto tende a diminuir Adicionar recursos pode at reduzir a velocidade do projeto devido necessidade de treinar e apolar as novas pessoas reduzindo a produtividade daqueles que J estavam no projeto Como o mercado competitivo nos for a a abreviar o tempo dispon vel
21. o de uma resid ncia de ltima gera o A seguinte lista fornece maiores detalhes sobre os participantes Nome Eric Cathy Pete Jennifer Elmer Gene John Raquel Betty David V rios membros Papel Facilitador Participante Participante Participante Participante Participante Participante Participante Participante Participante Observador T tulo Diretor de Marketing Gerente de Projetos do HOLIS 2000 Gerente de Desenvolvimento de Software Diretor Executivo da empresa Equipe de Automa o Gerente da EuroControls Presidente da Krystel Eletric Presidente da Rosewind Construction Equipe de desenvolvimento Coment rios Defensor do projeto Respons vel pelo desenvolvimento do HOLIS 2000 Perspectiva do propriet rio Perspectiva do propriet rio Perspectiva do propriet rio Maior distribuidor da Lumenations Distribuidor Europeu da Lumenations Empreiteira El trica local Construtor de casas personalizadas Todos os membros da equipe que estiverem dispon veis 96 O Workshop Antes do workshop a equipe disponibilizou um pacote de aquecimento contendo Um artigo recente sobre tend ncias de ilumina o em automa o de casas C pias de entrevistas seletivas que haviam sido conduzidas Uma lista sumarizada das necessidades que foram identificadas at a data Eric preparou suas habilidades de facilitador e Cathy trabalhou na l
22. o conjunto de caracter sticas ou requisitos que se pretende liberar numa vers o especifica da aplica o Veja a Figura 20 1 Tanto o cliente quanto a equipe de desenvolvimento devem concordar com o baseline da pr xima release Em outras palavras o baseline deve e Ser ao menos aceit vel para o cliente e Ter uma razo vel probabilidade de sucesso na vis o da equipe Caracter stica 1 Caracter stica 2 Vers o 1 0 do baseline Figura 20 1 Baseline de requisitos 154 O primeiro passo na cria o do baseline listar as caracter sticas que ter o que ser definidas para a aplica o Controlar o n vel de detalhes neste processo uma importante chave de sucesso Na Habilidade de Equipe 3 sugerimos que qualquer novo sistema n o importa o qu o complexo seja pode ser descrito por uma lista de 25 a 99 caracter sticas Com mais do que isso voc estar visualizando o projeto num n vel de detalhes muito alto dificultando a comunica o efetiva com clientes e equipe de desenvolvimento Com menos que isso o n vel de detalhes pode ser muito baixo para fornecer suficiente compreens o da aplica o e do n vel necess rio de esfor o para a implementa o Se seguirmos o processo de workshop de requisitos Cap tulo 10 ou algum processo que gere resultados similares teremos nossa disposi o uma lista de 25 a 99 caracteristicas Esta lista fornece uma descri o de alto n vel das capacidades de um novo
23. sticas para representar o valor funcionalmente adicionado que devemos liberar ao usu rio Se o esfor o necess rio para implementar as caracteristicas requeridas pelo sistema igual aos recursos sobre o tempo que temos disposi o o escopo do projeto atingivel e n o teremos problemas Salvo circunst ncias inesperadas a equipe de software ir liberar no tempo sem sacrificar a qualidade No entanto a experi ncia tem mostrado que existe com frequ ncia uma pobre rela o entre esses fatores presentes na equa o do escopo De fato na turma de requisitos que lecionamos n s sempre perguntamos No in cio do projeto que quantidade de escopo s o normalmente disponibilizados pelos seus gerentes clientes ou stakeholders Em resposta apenas alguns iniciantes respondem inferior a 100 Os outros apresentam um n mero que varia de 125 a 500 A m dia e a mediana de cada enqu te tende mesma conclus o 151 aproximadamente 200 Este dado tem forte correla o com o que estabeleceu o Standish Group anteriormente ou seja que mais da metade de todos os projetos ir o custar pr ximo ao dobro de suas estimativas Talvez possamos agora entender o por que Uma Breve Hist ria sobre Escopo de Projeto Uma vez tivemos uma estudante que tinha sido recentemente promovida para exercer um novo papel a de gerente de produto para um novo produto de software Seu curr culo incluia muitos aspectos de desenvolvime
24. ver tocar e interagir com a implementa o pretendida pequena comparada resposta do cliente para o primeiro artefato tang vel do processo Assim independentemente do modelo de processo de desenvolvimento utilizado embora a nossa prefer ncia seja o modelo iterativo em projetos de desenvolvimento obrigat rio que a atividade de desenvolvimento forne a ao menos um prot tipo de avalia o robusto para obter o feedback do cliente antes que a maioria das atividades de projeto e codifica o seja executada Lembra da atividade de prototipa o que Royce 1970 sugeriu em seu primeiro modelo cascata Devido redu o da quantidade de mudan as ao n vel gerenci vel o desenvolvedor consegue fazer mudan as normalmente em interfaces de usu rio relat rios e outras sa das incrementalmente no projeto garantido uma implementa o robusta e de alt ssima qualidade A partir da um processo rigoroso de finalizar atividades de projeto codifica o testes de unidade e integra o de sistema ir fornecer um s lido fundamento para o produto enquanto que simultaneamente auxilia enormemente nas atividades de garantia de qualidade e teste 175 Sum rio da Habilidade de Equipe 4 Na Habilidade de Equipe 4 Gerenciando o Escopo aprendemos que o problema do escopo de projeto end mico Projetos normalmente s o iniciados com aproximadamente duas vezes a quantidade de funcionalidades que a equipe pode razoavelmente impl
25. 120 Sum rio da Habilidade de Equipe 2 Tr s sindromes contribuem com os desafios de entender as reais necessidades dos usu rios e de outros stakeholders A sindrome do Sim mas das Ru nas Desconhecidas e do Usu rio e o Desenvolvedor s o met foras que nos ajudam a entender melhor os desafios que est o nossa frente e fornecem um contexto para as t cnicas de elucida o que desenvolvemos para entender as necessidades dos usu rios Por m como s o raros os casos onde a equipe recebe especifica es efetivas de requisitos do sistema que eles ter o que construir eles t m que sair e obter as informa es que precisam para garantir o sucesso O termo elucida o de requisitos descreve este processo onde a equipe deve assumir um papel mais ativo Para ajudar a equipe nessa miss o uma variedade de t cnicas pode ser usada para atacar problemas e melhorar o entendimento das reais necessidades dos usu rios e de outros stakeholders Entrevistas e question rios Workshop de requisitos Brainstorming e redu o de id ias Storyboarding Use cases Role playing Prototipa o Embora nenhuma das t cnicas seja perfeita para todas as circunst ncias cada um representa um meio pr ativo de impulsionar o entendimento das necessidades do usu rio e converter requisitos confusos para requisitos que sejam melhor conhecidos Embora todas estas t cnicas funcionem em certa
26. Ambiente de Produto de Software Certa vez n s conduzimos um workshop para um provedor de servi os online confrontando requisitos desafiadores Quando n s chegamos na parte do tutorial enfatizando a no o de campe o do produto a sala ficou inquieta e o clima mudou nitidamente N s perguntamos para as 25 pessoas presentes incluindo os desenvolvedores engenheiros seniores e gerentes de marketing como essas duras decis es eram realizadas em seus ambientes Depois de alguns momentos ficou claro que ningu m fazia essas decis es Ap s discuss es entre eles o melhor que o grupo p de descrever foi um grupo cego seguindo informa es que vem e v o como as mar s Ningu m tinha a responsabilidade de tomar decis es Ningu m decidia quem seria suficientemente bom Eventualmente a equipe voltava se para tr s para um executivo de marketing por respostas talvez porque esse indiv duo tinha mais informa es no processo Ele olhou ao redor por um momento e ent o disse Voc sabe o que mais me apavora nesta equipe Eu posso pedir que algumas novas caracter sticas sejam adicionadas em algum momento do processo e ningu m nunca me dir n o Como esperar que consigamos liberar em algum momento um produto Ficou claro ap s esta explana o de que o cliente n o sabia quando um produto seria liberado verdade tamb m que a hist ria demonstra que houve uma inabilidade extremamente dolorosa deste cliente A
27. Habilidade de Equipe 4 Gerenciando o Escopo Cap tulo 19 Cap tulo 20 Cap tulo 21 Cap tulo 22 O Problema do Escopo de Projeto Estabelecendo o Escopo de Projeto Gerenciando seu Cliente Modelos de Gerenciamento de Escopo e Processos de Desenvolvimento de Software 148 At agora neste volume introduzimos as Habilidades de Equipe para analisar o problema entender as necessidades dos usu rios e definir o sistema Todas as tr s Habilidades de Equipe tinham o foco nas causas ra zes dos problemas de desenvolvimento de software preparar a equipe para entrar no espa o da solu o sem o conhecimento adequado do problema a ser resolvido Embora os membros da equipe precisem praticar estas habilidades a fim de desenvolv las isso n o demandar muito esfor o Recomendamos fortemente que gaste um pouco mais de tempo nestas atividades iniciais o conjunto total de atividades descritas at aqui deve consumir apenas uma pequena fra o do or amento do projeto talvez apenas 5 ou mais do custo total Embora os assuntos sejam complexos apenas alguns membros da equipe analistas gerentes de projeto l der t cnico campe o de projeto ou gerente de produto precisam estar fortemente envolvidos neste ponto No futuro no entanto o jogo muda dramaticamente conforme o tamanho da equipe se eleva significativamente Cada membro adicionado equipe deve participar do esfor o coordenado da equipe comunicando se efetivamente
28. a essas raz es o modelo cascata tornou se pouco popular Um resultado infeliz de tender a saltar direto para o c digo mesmo com o entendimento inadequado dos requisitos do sistema foi um dos principais problemas que estavam tentando resolver no modelo cascata i Codifica o e teste Integra o de sistema Opera o e manuten o Escopo do projeto l Caracter sticas a serem liberadas Recursos Tempo j Prazo final Figura 22 2 Aplicando o modelo cascata num projeto com escopo de 200 O Modelo Espiral O principal estudo do Barry Boehm 1988a recomendava uma estrutura diferente para guiar o processo de desenvolvimento de software Seu modelo espiral de desenvolvimento de software um modelo funcional para aqueles que acreditam que o sucesso segue um caminho de desenvolvimento mais orientado a riscos e incremental Figura 22 3 170 Custo acumulativo Progresso atrav s dos passos Avaliar alternativas Identificar e resolver riscos Determinar objetivos alternativas restri es An lise de riscos An lise de riscos An lise Prot tipo operacional Revis o Plano de requisitos plano de ciclo de vida da execu o Conceito de opera o Projeto de ttrecess produto de software Requisito de software Projeto detalhado Plano de desenvolvimento Valida o de requisitos
29. algumas habilidades de equipe que ir nos ajudar a obter as informa es que n s precisamos N s come aremos com a entrevista Cap tulo 9 71 Tabela 8 2 Atributos de caracter sticas Atributo Estado Prioridade Benef cio Esfor o Risco Estabilidade Meta de libera o Associado a Raz o Descri o Rastreia o progresso durante a defini o do baseline do projeto e desenvolvimento subsequentes Exemplo Proposto Aprovado e Incorporado Nenhuma caracter stica criada da mesma forma Classifica o por prioridade relativa ou beneficio para o usu rio final abre um di logo entre stakeholders e membros da equipe de desenvolvimento Usado no gerenciamento de escopo e determina o de prioridade Exemplo Cr tico Importante e Util Estimar o n mero da equipe ou pessoas m s linhas de c digo ou pontos de fun o ou apenas o n vel geral do esfor o ajuda configurar expectativas de o que pode e n o pode ser executado num dado quadro de tempo Exemplo Baixo M dio e Alto Uma medida de probabilidade que a caracter stica ir causar eventos indesej veis tais como exceder custo atrasar o cronograma ou mesmo cancelamento Exemplo Alto M dio e Alto Uma medida de probabilidade de que a caracter stica ir mudar ou de que o entendimento da equipe sobre as caracter sticas que ir o mudar Usado para ajudar a estabelecer prioridades de desenvolvimento e determinar aqueles itens par
30. articular os procedimentos que eles realizam ou as necessidades que devem ser atendidas Mesmo assim o trabalho realizado e eles nunca foram questionados sobre 1sso antes Al m disso mais dificil descrever do que ver Por exemplo tente descrever o procedimento de cal ar o seu sapato Muitos usu rios n o t m a liberdade de admitir que eles n o seguem os procedimentos prescritos ent o o que eles dizem para voc pode ou n o ser o que eles realmente fazem 112 Cada usu rio possui seu pr prio padr o de trabalho profundamente impregnado aplicam quebra galhos ou caminhos pr prios de implementa o os quais mascaram os problemas reais para quem os observa imposs vel para qualquer desenvolvedor antecipar todas as quest es que devem ser perguntadas ou para quaisquer usu rios saberem quais quest es que os desenvolvedores deveriam perguntar Para atender a essas causas em particular o simples ato de interpretar pap is role playing pode ser extremamente efetivo E barato e normalmente muito r pido Normalmente em uma hora ou meio dia a m gica ter sido realizada Como Interpretar o Papel Experimente Na forma mais simples de interpretar pap is o desenvolvedor o analista e potencialmente todos os membros da equipe de desenvolvimento simplesmente tomam o lugar do usu rio e executam as atividades de trabalho do cliente Por exemplo no caso do problema de entrada dos pedidos de ven
31. as informa es sobre as necessidades do usu rio foram apresentadas podemos agora aprimorar nosso entendimento do contexto do sistema HOLIS identificando os atores que ir o interagir com o HOLIS A Figura 6 6 ilustra 4 atores 1 O propriet rio que usa o HOLIS para controlar a luminosidade 2 As v rias l mpadas que o HOLIS por sua vez controla 3 Servi os da Lumenations o fabricante que tem a habilidade para remotamente conectar se ao HOLIS e realizar programa es remotamente 4 Receptor de Emerg ncias um ator indefinido que ir receber mensagens de emerg ncia i HOLIS L mpadas Propriet rio Recebedor de Emerg ncias TBD Servi os da Lumenations Figura 66 HOLIS com atores 56 Naturalmente a equipe tamb m descobriu v rios stakeholders n o atores tanto internos quanto externos empresa preocupados com os requisitos do HOLIS como mostra a Tabela 6 1 Tabela 6 1 Stakeholders n o atores do HOLIS Nome Coment rios O Distribuidor Externo Clientes diretos da Lumenations Clientes dos Clientes da Lumenations o contratado Construtores geral respons vel pela constru o da resid ncia Eletricistas Contratados Respons vel pela instala o e suporte Equipe de Desenvolvimento Interno Equipe da Lumenations Gerente de Marketing Produto Ser representado pela Cathy gerente de produto Gerente Geral da Lumenations Financiamento e contabilidade dos resultados Engenharia de Si
32. as inter relacionadas Claramente esta uma disciplina muito ampla e pondera es devem ser feitas para que traga resultados teis aos membros das equipes de software Assim o foco estar num processo e nas t cnicas especificas de gerenciamento de requisitos que possam ser aplicadas diretamente nos tr s tipos de aplica es de software descritos anteriormente IS IT ISV e sistemas embutidos 13 O Mapa da Mina Dom nio do Problema J que foi dada a largada para a jornada de se desenvolver software com qualidade dentro do prazo e cronograma previstos e que atenda as reais necessidades dos clientes seria muito til apresentar um mapa descrevendo este territ rio N o ser f cil uma vez que durante essa jornada em particular diversas pessoas que falam diferentes linguagens podem ser encontradas pelo caminho Muitas d vidas ir o aparecer e Isso uma necessidade ou um requisito e Isso uma coisa que deve ter ou que seria bom ter e Isso uma declara o do problema ou uma declara o de uma solu o e Isso um objetivo do sistema ou um requisito contratual e Ter que ser programado em Java Ent o quem ser o programador e Quem que n o gostou do novo sistema e onde est a pessoa que estava aqui antes A fim de caminhar com seguran a atrav s desse territ rio ser necess rio conhecer onde estaremos em alguns pontos do tempo quem ser o as pessoas que encontraremos pelo caminho a l
33. atender a 1 000 requisitos num pequeno produto de software a ser adquirido ou a 300 000 requisitos num Boeing 777 torna se bvio que surgir o problemas para organizar priorizar controlar o acesso e fornecer recursos pata esses v rios requisitos e Quais membros da equipe de projeto s o respons veis pelo requisito 278 e quem tem a permiss o de modific lo ou remov lo e Seo requisito 278 for modificado quais outros requisitos ser o afetados e Como assegurar que os c digos escritos e respectivos casos de testes desenvolvidos para satisfazer o requisito 278 ser o plenamente atendidos As atividades associadas e que respondem a estas e outras quest es s o as que constituem o Gerenciamento de Requisitos O Gerenciamento de Requisitos n o nada novo n o algo que tenha sido inventada por mero capricho ele formado por atividades do senso comum as quais muitas organiza es de desenvolvimento afirmam realizar de uma forma ou de outra Mas normalmente realizada de uma maneira informal e persistindo os problemas de um projeto a outro e algumas das atividades chaves s o provavelmente negligenciadas ou levemente alteradas devido s press es e pol ticas associadas maioria dos projetos de desenvolvimento Portanto o gerenciamento de requisitos pode ser entendido como um conjunto de t cnicas e processos organizados padronizados e sistematizados com o objetivo de lidar com requisito
34. atender o cronograma com qualidade e ocasionalmente com servi os que n o podiam ser previstos com anteced ncia Todavia seus clientes internos ou externos querem naturalmente a maior quantidade de funcionalidade poss vel em cada release do sistema de software Afinal de contas s o as funcionalidades liberadas que adicionam valor necess rio para atender a seus objetivos de neg cio De fato devemos ter um respeito salutar com os clientes que est o gerando a demanda pois s o essas funcionalidades que ir o em ltima inst ncia garantir o sucesso no mercado Clientes competentes na realidade s o os nicos que merecem ter demanda por funcionalidades No entanto n o considerar a demanda por mais e mais funcionalidades pode comprometer a qualidade e a viabilidade de todo o projeto O mais torna se inimigo do adequado O melhor torna se inimigo do suficientemente bom Se n s estivermos trabalhando num setor de neg cio onde a f sica esteja mais bem definida onde a ind stria tenha algumas centenas de anos de experi ncia em liberar produtos as coisas poderiam ser diferentes No entanto n s trabalhamos no mundo do software onde a f sica indeterminada os processos s o imaturos e a tecnologia mut vel Permita nos focar inicialmente em como fazer um servi o direito funcionalidade suficiente no tempo certo para atender as reais necessidades do cliente N s podemos refinar nosso processo mais tarde para ver se p
35. atributos do sistema ou atributos do ambiente do sistema elementos de nossa defini o elaborada Esta classifica o conveniente nos ajuda a entender mais sobre o sistema que estamos construindo Vamos ver cada um desses atributos em detalhes Usabilidade E importante descrever o qu o f cil o sistema pode ser aprendido e operado pelos pretensos usu rios Al m disso podemos precisar identificar as v rias categorias de usu rios iniciantes usu rios normais usu rios experientes usu rios analfabetos usu rios que n o s o fluentes na linguagem nativa dos usu rios normais entre outros Se voc quer que o seu cliente revise e participe desta discuss o o que seria muito bom voc tem que estar ciente de que independentemente do requisito que voc esteja escrevendo nesta rea ter que ser escrito em linguagem natural voc n o deveria querer uma m quina de estado finito para descrever a usabilidade Desde que a usabilidade tende a estar nos olhos de quem a v como faremos para especificar esse conjunto de requisitos t o confuso Seguem algumas sugest es e Especifique o tempo requerido de treinamento para o usu rio se tornar ligeiramente produtivo apto a realizar tarefas simples e operacionalmente produtivo apto para realizar tarefas normais do dia a dia Como pode se notar podemos precisar descrever posteriormente em termos de usu rios novatos aquele que nunca viu um computador antes at
36. cio pode ser o neg cio de desenvolvimento de software ou de fabrica o de rob s soldadores ou voc pode querer modelar um neg cio de filantropia organiza es de servi o processo intradepartamental ou fluxo de trabalho interno De qualquer forma o prop sito da modelagem de neg cio possui duas partes Entender a estrutura din mica da organiza o Assegurar que clientes usu rios finais e desenvolvedores tenham um entendimento comum da organiza o Essa abordagem d equipe uma maneira l gica de definir onde a utiliza o do software pode melhorar a produtividade do neg cio e ajudar na determina o de requisitos para essa utiliza o Usando T cnicas de Engenharia de Software para Modelar Neg cios Com a escolha da t cnica correta para modelar neg cios modelos use cases e modelos de objetos se tornar o artefatos comuns durante a atividade de solu cionar problemas Naturalmente v rias t cnicas podem ser aplicadas para se modelar neg cios No entanto seria conveniente que como desenvolvedores de software tiv ssemos nossa disposi o um conjunto rico em ferramentas e t cnicas j usadas na modelagem de nossos softwares De fato n s j sabemos modelar entidades objetos e classes relacionamentos depend ncias associa es entre outros processos complexos sequ ncia de atividades transi es de estados eventos condicionais entre outros e outros construtores que ocorrem na
37. cliente mercado rendimento ou de servi os aos novos clientes Se esse item n o for implementado alguns usu rios n o gostar o do produto e n o ir o compr lo Util significa que seria bom ter A caracter stica que torna a vida mais f cil faz o sistema mais apelativo mais divertido ou de grande utilidade Nota Com este esquema todas as id ias que sobreviveram ao processo de expurgo n7Z ter o ao menos um voto til evitando insultar a quem tenha submetido Num grupo grande de participantes cada item ter um misto de categorias mas n o realmente um problema O facilitador tem um truque Apenas multiplique os votos cr ticos por 9 importantes por 3 e teis por 1 e some os resultados Isto tende a espalhar os resultados pesadamente a favor dos votos 94 criticos e assim todas as necessidades cr ticas dos stakeholders borbulhar o para o topo da lista Brainstorming Baseado em Web At agora discutimos um processo para que o brainstorming funcione efetivamente bem quando todos os stakeholders reunidos ao mesmo tempo forem relativamente pr ativos e n o excessivamente inibidos quando o facilitador for experiente e pol ticas do stakeholder forem gerenci veis Sem d vida n o existe substituto para o tempo gasto em conjunto pelos desenvolvedores e stakeholders externos Cada um 1r se lembrar dos v rios pontos importantes e de assuntos discutidos por outros perspecti
38. companhia desenvolveu se de uma cultura tradicional de IT e tinha se transformado num provedor de 142 servi os on line recentemente A no o de uma aplica o como um produto de software era novo Os membros da equipe n o tinham precedentes para gui los atrav s do processo Embora n o exista uma forma correta de organizar e determinar um campe o do produto talvez n s possamos olhar para o nosso caso de estudos para obter alguma sugest o Afinal de contas n s o modelamos de acordo com uma equipe de projeto viva e efetiva Na Figura 18 1 a Cathy a gerente de produto quem faz o papel de campe o do produto Note que neste caso o gerente de produto se reporta diretamente com o marketing ao inv s de se reportar para a organiza o de engenharia Isso muito normal em empresas de produtos de software ao menos em tese que gerentes de produto estejam mais pr ximos aos clientes pois s o eles que determinar o o sucesso ou a falha do projeto Lumenations S A Divis o de Automa o para Ilumina o Residencial Organiza o da Equipe de Software Emily VP e GM Brooke Eric Diretor de Engenharia Diretor de Marketing Jack Michel Pete Cathy L der de QA Arquiteto Gerente de Gerente de Desenvolvimento de Produto Software Louise John Russ Mike L der de L der de L der de L der de Software Software Software Talvez o gerente de produto se reporte ger ncia de marketing porque no final de contas
39. de fazer Cada pessoa recebe 100 notas de id ias para gastar na compra de id ias Voc pode at mesmo adicionar um kit de notas de id ias no invent rio de cupons do workshop Cada participante convidado a escrever em seu bloco de notas o quanto pagaria para cada id ia Ent o depois que os participantes tiverem tido a chance de votar o facilitador ir tabular os resultados e fornecer a ordem de classifica o Pode tamb m ser til fazer um r pido 93 histograma dos resultados para que os participantes possam ver o Impacto visual de suas decis es Este processo extremamente simples e normalmente funciona bem No entanto voc deve ficar prevenido dos seguintes avisos Primeiro isso funcionar bem apenas uma vez Voc n o pode usar a mesma t cnica duas vezes no projeto porque uma vez que os resultados sejam conhecidos os participantes ir o influenciar os resultados na pr xima rodada Por exemplo se voc for um participante e a sua caracter stica favorita for o primeiro da lista mas se a sua segunda caracter stica favorita n o estiver numa posi o honrosa voc pode colocar todo o seu dinheiro sobre a sua segunda caracter stica Voc est confiante de que os outros eleitores ir o ver que a sua caracteristica favorita ainda faz a diferen a Da mesma forma voc pode achar necess rio limitar a quantidade de gastos de uma caracter stica Caso contr rio um participante trapaceiro conhe
40. de implementa o deve escolher pois algumas estrat gias podem ser muito caras ou podem levar muito tempo de execu o Por m informa es de or amento n o s o requisitos da mesma forma informa es que descrevem o como saber que os requisitos foram atendidos procedimentos de teste ou procedimentos de aceita o tamb m n o atendem a defini o e assim n o fazem parte da especifica o Normalmente achamos conveniente ir um pouco mais al m nesse assunto Em muitos casos til que os escritores de requisitos d em dicas de testes dispon veis para requisitos A final de contas os escritores de requisitos t m em mente um comportamento espec fico e razo vel dar a ajuda que for poss vel Exclua Informa es de Projeto Os requisitos tamb m n o devem incluir informa es sobre o projeto ou arquitetura do sistema Caso contr rio voc pode acidentalmente restringir sua equipe de prosseguir mesmo que as op es de projeto escolhidas fa am sentido para a sua aplica o Espere um pouco temos que projetar isso dessa maneira Isso n o um requisito Embora a elimina o dos detalhes de gerenciamento do projeto e de testes da lista de requisitos seja de certa forma simples a elimina o de detalhes de projeto implementa o normalmente mais dif cil e muito mais sutil Suponha por exemplo que o primeiro requisito da Tabela 23 1 tenha sido formulada como RS63 1 A informa o de te
41. de projeto Neste caso n s ainda n o sabemos onde tra ar o baseline mas se a intui o da 159 equipe for de que o escopo est acima de 100 a lista ter que ser cortada sem discuss o O pr ximo passo complicado Se n s assumimos por exemplo que as caracter sticas est o acima de 200 do escopo o baseline deve ser cortado pela metade ou mais Como fazer isso A primeira considera o se podemos realizar somente os itens cr ticos da lista Pergunte ao gerente de projeto Se tudo falhar podemos garantir ao menos os itens cr ticos no prazo final Afinal de contas se n s tivermos aplicado corretamente o esquema de prioriza o somente mais ou menos um ter o dos itens da lista ser o cr ticos para a release A menos que algumas caracter sticas cr ticas representem um n vel de esfor o desproporcionalmente alto a resposta deveria ser sim mesmo se o escopo seja de 200 Se a resposta sim e em nossa experi ncia sempre sim at mesmo nesse primeiro corte podemos iniciar um plano Se a resposta for n o o projeto est muito acima do escopo 300 400 ou mais e um projeto de menor escopo deve ser definido e repetido o processo de prioriza o Desde que a nossa abordagem foi grosseira n o podemos assegurar quantos item al m dos cr ticos podem ser realizados As estimativas de esfor o com base nos requisitos mais detalhados e nas estimativas de viabilidade t cnica podem ser usados para refi
42. defini o de requisitos para uma nica aplica o de software tal que possamos demonstrar mais claramente como o processo de gerenciamento de requisitos funciona 132 Cap tulo 17 O Documento da Vis o N Vis o Documento da Vis o para o meu projeto Pontos chaves e O documento da Vis o descreve a aplica o em termos gerais incluindo descri es do mercado alvo dos usu rios do sistema e das caracter sticas da aplica o e O documento da Vis o define num alto n vel de abstra o tanto o problema quanto a solu o e Virtualmente todos os projetos de software ir o se beneficiar ao ter um documento da Vis o e O documento da Vis o Delta concentra se no que foi mudado ste cap tulo concentra se no documento da Vis o Como nosso colega Philippe Kruchten disse recentemente Se me fosse permitido desenvolver apenas um nico documento modelo ou algum outro artefato para sustentar um projeto de software a minha escolha em resumo seria o documento da Vis o muito bem confeccionado O documento da Vis o combina dentro de um nico documento alguns elementos modestos tanto do documento dos requisitos de mercado quanto do documento dos requisitos de produto N s queremos desenvolver este documento em particular pelas seguintes raz es 1 Todo projeto precisa de um documento da Vis o 2 O documento da Vis o nos ajudar a demonstrar o processo de requisitos bem como alguns elementos c
43. do usu rio Desse modo n s nos dirigimos para o pr ximo n vel de especificidade e detalhes e criamos um modelo de requisitos rico e profundo para o sistema que ser constru do Naturalmente criamos tamb m informa es mais detalhadas as quais ter o que ser gerenciadas e para isso teremos que ser mais organizados para cuidar desses detalhes adicionais O n vel de especificidade necess ria neste pr ximo passo depende de v rios fatores incluindo o contexto da aplica o e das habilidades da equipe de desenvolvimento Em sistemas de software para equipamentos m dicos de alta seguran a aeronaves ou com rcio online o n vel de especificidade apropriadamente alto O processo de refinamento pode incluir mecanismos formais de garantia de qualidade revis es inspe es modelagem e outros similares Em sistemas cujas consequ ncias sejam menos catastr ficas frente a falhas o n vel de esfor o ser mais modesto Nestes casos o trabalho envolvido 179 est em simplesmente assegurar que a defini o est suficientemente precisa quanto compreensiva por todas as partes envolvidas e ainda forne a um ambiente de desenvolvimento eficiente e uma probabilidade suficientemente alta de sucesso O foco est no pragmatismo e na economia fazendo uma especifica o de requisitos que seja apenas o suficiente para garantir que o software desenvolvido o que o usu rio deseja Da mesma forma que n o existe uma linguagem d
44. e Outros Stakeholders do novo sistema Usu rios Outros Stakeholders Vendedores Diretor de SI e equipe de desenvolvimento Supervisor de Vendas Diretor Financeiro Controle da Produ o Gerente de Produ o Pessoal de Faturamento 31 Passo 4 Definir a Fronteira da Solu o Sist mica N s dividimos o mundo em duas classes 1 Nosso sistema 2 Coisas que interagem com o nosso sistema Ator Uma vez que se tenha chegado ao acordo sobre a declara o do problema e usu rios e stakeholders tenham sido identificados n s podemos voltar nossa aten o para a defini o do sistema que poder ser desenvolvido para atacar o problema Ao fazer isso n s entraremos numa importante transi o de estados onde teremos que manter duas coisas em mente a compreens o do problema e as considera es de uma solu o em potencial O pr ximo passo importante determinar a fronteira da solu o sist mica A fronteira do sistema define o limite entre a solu o e o mundo real que cerca a solu o Figura 4 3 Em outras palavras a fronteira do sistema descreve um inv lucro no qual a solu o est contida As informa es existentes nos formul rios de entrada e sa da s o repassadas para fora do sistema para usu rios que vivem fora do sistema Todas as intera es com o sistema ocorrem via interfaces entre o sistema e o mundo externo entradas sa das Figura 4 3 A associa o entrada sistema sa da Em outras
45. e caracter sticas do produto em alto n vel 1 2 Vis o Geral do Produto Estabelecer o prop sito da aplica o sua vers o e as novas caracter sticas a serem liberadas 1 3 Refer ncias Fornecer uma lista completa de todos os documentos referenciados neste documento Continua na pr xima p gina Figura 17 1 Modelo de documento da Vis o para um produto de software Corrente na psicologia 134 2 Descri o do Usu rio Descrever brevemente a perspectiva dos usu rios do seu sistema 2 1 Demografia do Usu rio Mercado Resumir os principais mercados demogr ficos que motivaram suas decis es de produto 2 2 Perfil do Usu rio Descrever brevemente os potenciais usu rios do sistema 2 3 Ambiente do Usu rio Detalhar o ambiente de trabalho dos usu rios alvo 2 4 Principais Necessidades do Usu rio Listar os principais problemas ou necessidades que s o percebidos pelo usu rio 2 5 Alternativas e Concorrentes Identificar quaisquer alternativas que o usu rio percebam que estejam dispon veis 3 Vis o Geral do Produto Fornecer uma vis o de alto n vel das capacidades do produto interfaces com outras aplica es e configura es do sistema 3 1 Perspectiva do Produto Fornecer um diagrama de blocos do produto ou sistema e suas interfaces com o ambiente externo 3 2 Declara o da Posi o do Produto Fornecer uma declara o geral sumarizando em alto n vel a posi o nica que
46. efetivo Para finalizar a t cnica do question rio como toda t cnica de elucida o satisfaz a um conjunto de desafios de requisitos que uma organiza o pode enfrentar 19 Cap tulo 10 Workshops de Requisitos Pontos chaves e Talvez o workshop de requisitos seja a t cnica mais poderosa para se elucidar requisitos e Re ne todos os principais stakeholders por um breve por m intenso per odo e O uso de um facilitador externo e experiente em gerenciamento de requisitos pode ajudar a assegurar o sucesso do workshop e O brainstorming a parte mais importante do workshop Acelerando o Processo de Decis o m dos esquemas de prioriza o que usamos enganosamente simples Pergunte ao stakeholder qual caracter stica feature ele escolheria caso tivesse que escolher apenas uma a qual seria implementada na pr xima libera o release Como na mente de algu m que vai para a forca esta quest o faz com que a mente maravilhosamente concentre se no que realmente importante Quando houver apenas uma nica oportunidade de elucidar requisitos uma que possamos aplicar em todas as circunst ncias sem se Importar com o contexto do projeto sem se importar com o per odo de tempo escolha o workshop de requisitos O workshop de requisitos pode ser muito bem ser a t cnica mais poderosa deste volume e uma das poucas que quando dominado pode realmente ajudar a mudar os resultados do projeto mesmo que seja a
47. entre Caracteristicas e Requisitos de Software B l Requisitos software No in cio n s gastamos algum tempo explorando as caracter sticas de um sistema As caracter sticas s o descri es simples de um comportamento desejado e til Agora podemos ver que existe um relacionamento entre caracter sticas e requisitos de software O documento da Vis o descreve as caracter sticas na linguagem do usu rio Os requisitos de software por sua vez expressam tais caracter sticas em termos mais detalhados usando um ou mais requisitos de software espec ficos descritos pelos desenvolvedores a fim de fornecer as caracter sticas para o usu rio Em outras palavras as caracter sticas nos ajudam a entender e a nos comunicar num n vel alto de abstra o mas provavelmente n o teremos condi es de escrever o c digo a partir dessas descri es Elas est o num n vel muito alto de abstra o para 1sso No entanto os requisitos de software s o espec ficos Podemos codificar a partir dos requisitos de software Os requisitos de software devem ser suficientemente espec ficos a ponto de podemos test los isto n s devemos estar aptos a testar um sistema verificando que ele realmente implementa os requisitos Por exemplo suponha que n s tenhamos desenvolvido um sistema de rastreamento de defeitos para uma empresa de manufatura em linha de montagem ou para uma empresa de desenvolvimento de software A Tabela 23 1 most
48. incluindo requisitos e caracter sticas b sicas do sistema que est o sendo propostos O modelo use case de sistema registra os use cases atrav s dos quais os v rios atores do sistema interagem com o HOLIS Ap s alguns debates a equipe decidiu documentar os requisitos de hardware tamanho peso pot ncia empacotamento para os tr s subsistemas do HOLIS numa nica especifica o dos requisitos de hardware Como cada subsistema do HOLIS intensa em software a equipe decidiu desenvolver uma especifica o de requisitos de software para cada um dos tr s subsistemas bem como um modelo use case de cada subsistema para mostrar como cada subsistema interage com os v rios atores Voc ter a oportunidade de ver esses artefatos de requisitos desenvolvidos posteriormente conforme avan amos no caso de estudos nos pr ximos cap tulos Um exemplo de cada um foi inclu do no Ap ndice A Sum rio Neste cap tulo n s examinamos uma variedade de documentos de requisitos para sistemas de diferentes complexidades No entanto em muitos casos o gerenciamento de requisitos eventualmente concentra se sobre um nico subsistema de software produto de software de prateleira ou aplica es standalone Exemplos desses produtos podem ser o Microsoft Excel Rational ClearCase produtos de fornecedores ISV ou o sistema de controle de ilumina o HOLIS Nos pr ximos cap tulos n s iremos fazer um zoom sobre o processo de
49. inexperientes em sistemas complexos n o sabiam diferenciar o peso da balan a ou a otimiza o sist mica de seu pr prio umbigo mas eles podiam fazer um microprocessador cantar em linguagem assembly Al m disso pareciam que eram formados por genes diferentes ou pelo menos por uma gera o diferente o qual adicionava complexidade do conflito cultural e de gera es ao processo de engenharia de sistemas Muitas situa es interessantes ocorreram Por algum tempo a batalha estava equilibrada engenheiros de sistemas atendiam as solicita es de particionar e alocar funcionalidades finais para o sistema Mas em muitas ind strias a tecnologia de software assumiu gradualmente o controle e a engenharia de sistemas havia sido dominado pelo menos em parte devido necessidade de atribuir ao sistema funcionalidades flex veis de software Existem in meras raz es t cnicas e s lidas para essa transi o Com o tempo v rios fatos ficaram bvios 49 Agora muitos sistemas devem sofrer otimiza es de software n o de hardware o software n o o hardware que ir determinar as funcionalidades finais do sistema bem como o sucesso do sistema nas m os de usu rios e no mercado o software n o o hardware que ir consumir a maior parte dos custos de pesquisa e desenvolvimento do sistema o software n o o hardware que estar no caminho cr tico e ir dessa forma determinar finalmente quando o siste
50. interativa tal como Dan Bricklin s Demo It Ferramentas tais como Director da Macromedia e Cinemation da Vividus Corp podem ser usados para criar anima es e simula es mais complexas Num exemplo simples ocorrido na RELA Inc um membro da equipe tamb m tinha interesse em cartooning No est gio de conceito de um projeto ele apenas esbo ou meia d zia de desenhos simples que mostravam os v rios aspectos da interface do produto em seu uso t pico Esta foi uma maneira simples e barata de provocar uma rea o dos potenciais usu rios Al m disso a natureza dos cartoons evitou alguns dos potenciais problemas do storyboards como veremos mais tarde Infelizmente nenhum outro cartunista foi encontrado depois que ele saiu da empresa deixando nos a procurar t cnicas alternativas de sotryboarding Em nosso atual esfor o cujo foco na maioria das vezes s o as aplica es ISV n s nos viramos muito bem usando o PowerPoint ou outros gerenciadores de apresenta o de desktop comum em combina o com amostrar de screen shots constru dos com as mesmas ferramentas usadas para construir GUIs Graphical User Interface de aplica es Interessantemente o incr vel avan o na t cnica de storyboarding pode muito bem ter sido a adi o da capacidade de anima o ao PowerPoint Repentinamente a nossa habilidade de expressar a din mica e interatividade aumentara enormemente Dicas do Storyboarding O storyboarding uma t cnica projet
51. interfira no entendimento do real problema a ser resolvido O Contexto da Entrevista As Quest es livres de contexto Ent o como evitar que nossas quest es prejudiquem a resposta do usu rio N s o fazemos formulando quest es sobre a natureza do problema do usu rio livre de 73 Uma quest o livre de contexto nos ajuda a entender os reais problemas sem influenciar o usu rio qualquer contexto da potencial solu o Para tratar deste problema Gause e Weinberg 1989 introduziram o conceito de quest es livres de contexto S o exemplos de tais quest es Quem o usu rio Quem o cliente As necessidades s o diferentes Onde mais podemos encontrar solu es para este problema Estas quest es nos for am a ouvir antes de tentar inventar ou descrever uma poss vel solu o Enquanto ouvimos entendemos melhor o problema do cliente bem como quaisquer problemas por detr s dos problemas Tais problemas afetam a motiva o e o comportamento do nosso cliente e devem ser atacados antes que possamos apresentar uma solu o Quest es livres de contexto possuem um paralelo com as quest es ensinadas aos vendedores como parte de uma t cnica chamada solu es de venda Nas solu es de venda os vendedores usam uma s rie de quest es focalizadas sobre a obten o inicial do entendimento do problema do cliente e quais solu es se existe algum o cliente j anteviu A inten o dessas que
52. ligam ou desligam as l mpadas Residentes ou reduzem a intensidade desejada de luz L mpadas Trocar Programa o Mudar ou configurar as a es para um Propriet rio particular bot o interruptor programador Programar Remotamente O provedor de servi os de ilumina o realiza Servi os de remotamente a programa o com base nas Ilumina o solicita es do residente Tirar F rias Propriet rios configuram a aus ncia por um Propriet rio longo per odo programador Configurar a Sequ ncia O propriet rio programa a segii ncia de Propriet rio de Tempo ilumina o autom tica com base no tempo programador 110 Sum rio Use cases fornecem uma nota o estruturada e razoavelmente formal para capturar um subconjunto mais importante das informa es de requisitos como o sistema interage com o usu rio para liberar sua funcionalidade Em muitas aplica es este subconjunto representa a principal carga de trabalho tal que use cases podem ser aplicados para expressar os principais requisitos do sistema Cada use case identificado define os comportamentos necess rios do sistema sob a perspectiva de uma classe particular de usu rio Como tal a t cnica muito til na elucida o das necessidades do usu rio e ajuda a equipe de desenvolvimento representar tais necessidades de maneira que seja prontamente compreens vel pelo usu rio Al m disso como os use cases podem ser usados posteriormente nos processos de projeto
53. mais ser corrigido Nos anos 70 1970 Winston Royce 1970 trabalhando na TRW definiu o que ficou conhecido como o modelo cascata de desenvolvimento de software O modelo cascata melhorou o modelo estritamente sequencial pelo e Reconhecimento da necessidade de loops de feedback entre est gios onde admitia que o projeto afeta os requisitos que a codifica o do sistema Ir fazer com que visitemos novamente o projeto e assim por diante e Desenvolvimento de um prot tipo de sistema em paralelo com as atividades de an lise e projeto Como ilustra a Figura 22 1 no modelo cascata as atividades de software progridem logicamente atrav s de uma sequ ncia de passos O trabalho em cada passo ap ia se em atividades do passo anterior O projeto segue logicamente os requisitos a codifica o vem depois do projeto e assim por diante O modelo cascata foi largamente seguido no passado por durante duas d cadas e serviu com sucesso como um modelo de processo para projetos de m dia a larga escala mi Codifica o e teste unit rio Integra o de sistema Opera o e manuten o Figura 22 1 Modelo cascata de desenvolvimento de software Note que como normalmente ocorre a Figura 22 1 n o referencia a atividades de prototipa o como foi prescrito Isto um infeliz mist rio da hist ria que iremos contar brevemente O modelo cascata teve algum sucesso ao refor ar a fun o dos requisitos como o prim
54. na Tabela 11 1 Tabela 11 1 Caracter sticas do workshop HOLIS ordenados por prioridade ID Caracter sticas Votos 23 Cenas de ilumina o personalizadas 121 16 Configura o do tempo autom tico de ilumina o etc 107 4 Caracter sticas de seguran a pr definidas p ex l mpadas e alarmes 105 6 100 de confiabilidade 90 8 F cil de programar unidade de controle n o PC 88 1 Facilidade de programar as esta es de controle Ta 5 Configura o de aus ncias 77 13 Toda l mpada pode ser apagada 74 9 Usar meu pr prio PC para programar 73 14 Caracter sticas de entretenimento 66 20 Portas da garagem fechadas 66 19 Ligar automaticamente as l mpadas quando a porta for aberta 55 3 Interface com o sistema de seguran a residencial 52 Facilidade para instalar 50 18 Ligar automaticamente as luzes quando algu m bate a porta 50 7 Ligar e desligar instant neo 44 11 Poder dirigir cortinas sombras bomba d gua e motores 44 15 Controlar a ilumina o via telefone 44 10 Interface com o sistema de automa o residencial 43 22 Modo gradual aumento ou redu o da luminosidade lentamente 34 26 Esta o de controle principal 31 12 Facilidade de expans o quando remodelado 25 25 Interface de usu rio internacionalizado 24 21 Interface com o sistema de udio v deo 23 24 Restaura o ap s falha no fornecimento de energia el trica 23 17 Controle HVAC 22 28 Ativa o via voz 7 27 Apresenta o no web site do usu rio An lise de
55. nica t cnica aplicada O workshop de requisitos projetado para alcan ar consenso sobre requisitos da aplica o e chegar rapidamente ao acordo sobre o curso das a es tudo num per odo de tempo muito curto Nesta t cnica os principais stakeholders do projeto s o reunidos por um breve e intensivo per odo normalmente n o mais que 1 ou 2 dias O workshop facilitado por um membro da equipe ou melhor ainda por um facilitador externo experiente concentrado na cria o ou na revis o das caracteristicas features de alto n vel que a nova aplica o deve ter Uma execu o apropriada do workshop de requisitos tr s muitos beneficios Ele ajuda na constru o de uma equipe efetiva comprometida com um nico prop sito comum o sucesso deste projeto Todos os stakeholders t m a sua vez de falar ningu m fica de fora Ele produz um acordo entre stakeholders e a equipe de desenvolvimento sobre o que a aplica o deve fazer Ele pode expor e resolver assuntos pol ticos que est o interferindo para o sucesso do projeto 80 O resultado que uma defini o preliminar do sistema em n vel de caracter sticas features imediatamente disponibilizado Muitas empresas t m alcan ado sucesso com a t cnica de workshop Juntos n s participamos em mais de 100 desses workshops e raramente se houve algum houve insucesso em atingir os objetivos desejados O workshop fornece oportunidade nica para stakeholder
56. o mercado no qual pretendemos vender Como o mercado est segmentado Os requisitos do usu rio est o nesses diferentes segmentos Quais classes de usu rios existem Quais necessidades o produto satisfaz De que tipo o produto Quais s o os principais benef cios do produto por que algu m deve compr lo Quem s o os concorrentes O que diferencia o produto de nossos concorrentes Em que ambiente o sistema ser usado Qual ser o custo de desenvolvimento Com que pre o voc pretende vender o produto Como o produto ser instalado distribu do e mantido O Caso de Estudos No Cap tulo 6 n s executamos algumas atividades da engenharia de sistemas no sistema HOLIS o nosso sistema de automa o de ilumina o residencial Neste ponto n o sabemos ainda muito sobre o HOLIS mas provavelmente sabemos o suficiente para fazer uma primeira tentativa em organizar as informa es de nossos requisitos Modelo use case de Especifica o de hardware Documento da Vis o do sistema do dos subsistemas HOLIS 2000 HOLIS 2000 Modelo use case Modelo use case Modelo use case do subsistema do subsistema do subsistema Figura 16 5 Organiza o das informa es dos requisitos do HOLIS 131 A Figura 16 5 ilustra que a equipe est usando os seguintes elementos para descrever os requisitos para o HOLIS O documento da Vis o que ir conter vis es de curto e longo prazo do HOLIS
57. o produto pretende preencher no mercado Moore 1991 recomenda que siga o seguinte formato Para cliente alvo Que declara o da necessidade ou oportunidade O nome do produto um categoria do produto Que declara o dos benef cios principais isto raz es para convencer a comprar Diferente principais alternativas da concorr ncia Nosso produto declara o das principais diferen as 3 3 Resumo das Capacidades Resumir os maiores benef cios e caracter sticas que o produto fornece Benef cios do Cliente Caracter sticas Suportadas Benef cio 1 Caracter stica Benef cio 2 Caracter stica Benef cio 3 Caracter stica Figura 17 1 Modelo de documento da Vis o para um produto de software continua 135 3 4 Suposi o e Depend ncias Listar as suposi es que se alteradas ir o afetar a vis o do produto 3 5 Custo e Pre o Registrar quaisquer restri es de custo e pre os que sejam relevantes 4 Atributos de Caracter sticas Descreva as caracter sticas que ser o usadas para avaliar rastrear priorizar e gerenciar as caracter sticas A seguir est o algumas sugest es Estado Proposto Aprovado Incorporado Prioridade Resultado do voto acumulado ordem de prioridade ou Cr tico Importante til Esfor o Baixo M dio Alto equipe semana ou pessoa m s Risco Baixo M dio Alto Estabilidade Baixo M dio Alto Release alvo N mero da vers o Associado a Nome Raz o C
58. palavras se n s tivermos que construir ou modificar algo esse algo ser parte de nossa solu o e estar dentro da fronteira caso contr rio ser externo ao nosso sistema Assim dividimos o mundo em duas classes interessantes 1 Nosso sistema 2 Coisas que interagem com o sistema Identificar as coisas que interagem com o nosso sistema o mesmo que identificar os atores de nosso sistema Afinal de contas eles possuem um papel para interpretar que o de fazer com que o nosso sistema trabalhe N s representamos um ator com um simples desenho de um ser humano N s definimos um ator como alen m ou alguma coisa fora do sistema que interage com o sistema Uma vez que temos a nota o de um ator podemos ilustrar a fronteira do sistema como ilustra a Figura 4 4 Fronteira do ge sistema 7 Usu rios locaioemimenemimemamemo E Outros sistemas Figura 4 4 Fronteira do sistema 32 Em muitos casos a fronteira do sistema bvia Por exemplo uma copiadora pessoal conectada a um PC NWindows 2000 tem a fronteira relativamente bem definida Existe apenas um usu rio e uma plataforma A interface entre o usu rio e a aplica o constru da por caixas de di logo o qual o usu rio utiliza para acessar informa es do sistema e configurar qualquer relat rio e caminhos de comunica o que o sistema utilize para documentar ou transmitir essas informa es Em nosso exemplo sistema de pedidos
59. passos que devem ser tomados a fim de alcan ar esse objetivo s o 1 Chegar ao acordo sobre a defini o do problema 2 Entender a causa raiz do problema o problema por detr s do problema 3 Identificar os stakeholders e usu rios 4 Definir a fronteira da solu o sist mica 5 Identificar as restri es que ser o impostas solu o Permita nos trabalhar cada um desses passos e ver se podemos desenvolver as habilidades de equipe que precisamos para chegar solu o pretendida Passo 1 Chegar ao Acordo sobre a Defini o do Problema O primeiro passo chegar ao acordo sobre a defini o do problema as ser resolvido Uma maneira simples de chegar a esse acordo simplesmente descrever o problema e ver se todos concordam 26 Como parte deste processo normalmente ben fico entender alguns dos benef cios propostos pela solu o seja cuidadoso assegurando se de que os benef cios sejam descritos utilizando termos fornecidos pelos clientes usu rios Descri es realizadas por usu rios fornecem fundamento contextual adicional ao real problema Ao ver os benef cios sob o ponto de vista do cliente tamb m obtemos a um melhor entendimento do problema do ponto de vista dos stakeholders A Declara o do Problema Voc poder achar til descrever o seu problema num formato padr o Tabela 4 1 O preenchimento da tabela ainda que simples uma t cnica poderosa para assegurar que todos os stak
60. playing dado a cada participante um conjunto de cart es descrevendo a classe ou objetos as responsabilidades ou comportamentos e colabora es ou com quem os objetos se comunicam de cada entidade sendo modelada Essas colabora es envolvem entidades do dom nio do problema tais como usu rios bot es l mpadas e elevador de carros ou objetos que vivem no dominio da solu o tais como Bot o Indicador de Luz Windows MDI e Elevador de Carro Quando o ator inicia um dado comportamento todos os participantes seguem o comportamento definido em seus cart es Quando o processo falhar devido a uma falta de informa o ou quando uma entidade precisar falar com uma outra e a colabora o n o estiver definida os cart es s o modificados e o jogo recome a 114 Por exemplo no caso de estudos HOLIS existir um momento em que a equipe precisar entender as intera es entre os tr s subsistemas a fim de determinar como o sistema Ir cooperar para atingir os objetivos e entender quais ser o os requisitos derivados criados Uma forma de fazer isso utilizar os cart es CRC como roteiro de acompanhamento Um membro da equipe deve fazer o papel de um subsistema ou ator e ent o a equipe deve acompanhar atrav s do use case ou cen rio Aqui est como um use case pode ser exercitado John O propriet rio acabou de pressionar um bot o que controla um Chave de banco de luz Ele ainda est pressionando a chave Eu enviarei a
61. processo sozinho ir resolver os problemas do mundo do desenvolvimento de aplica es No entanto com os passos que delineamos podemos esperar ter um efeito material sobre o escopo do problema permitindo que desenvolvedores de aplica o concentrem se nos subconjuntos cr ticos e libere incrementalmente sistemas de alt ssima qualidade e que atendam ou excedam as expectativas dos usu rios Al m disso ao engajar o cliente para que nos ajude a resolver o problema de gerenciamento de escopo eleva o comprometimento das partes estimulando a comunica o e confian a entre o chente e a equipe de desenvolvimento Com uma defini o compreensiva do produto documento da Vis o sob controle e o escopo num n vel razoavelmente gerenci vel mesmo que no In cio o escopo esteja exagerado teremos ao menos a oportunidade de ter sucesso nas pr ximas fases do projeto 176 Habilidade de Equipe 5 Refinando a Defini o do Sistema Cap tulo 23 Requisitos de Software Cap tulo 24 Refinando Use Cases Cap tulo 25 Uma Especifica o de Requisitos de Software Moderna Cap tulo 26 Sobre Ambiguidade e Especificidade Cap tulo 27 Medidas de Qualidade de Requisitos de Software Cap tulo 28 M todos T cnicos para Especifica o de Requisitos 177 Nas Habilidades de Equipe anteriores n s nos concentramos sobre o processo de analisar o problema elucidar necessidade do usu rio coletar documentar e gerenciar as caracter sticas do pro
62. que ser integrada a um sistema legado a fronteira n o t o clara O analista deve determinar se os dados ser o compartilhados com outras aplica es se a nova aplica o estar distribu da entre os v rios servidores e clientes e quem ser o os usu rios Por exemplo o pessoal de produ o ter acesso online os pedidos Existe um controle de qualidade ou fun es de auditoria que ter que ser fornecido O sistema executar num mainframe ou sobre um novo front end cliente servidor Relat rios gerenciais espec ficos ter o que ser fornecidos Embora possa parecer bastante bvio a identifica o de atores o principal passo anal tico da an lise do problema Como encontramos esses atores Aqui est o algumas quest es que poder o ajudar a encontrar esses atores Quem ir fornecer usar ou remover informa es do sistema Quem ir operar o sistema Quem ir realizar as manuten es no sistema Onde sistema ser usado Onde o sistema obt m suas informa es Quais outros sistemas externos ir o interagir com o sistema A partir das respostas para essas quest es o analista poder criar uma perspectiva do sistema um diagrama de blocos que descreve a fronteira do sistema os usu rios e outras interfaces A Figura 4 5 fornece uma perspectiva simplificada do sistema para o novo sistema de pedidos Fronteira do sistema Vendedor Novo Sistema de Pedidos Faturista Tran
63. rias circunst ncias verificamos que conveniente usar a Vis o Delta apenas para pequenas mudan as tais como para a vers o 1 1 ou 1 2 e iniciar com uma declara o completa do produto rigorosamente 139 Raramente se n o nunca pr tico documentar completamente os requisitos de um sistema legado de larga escala revisada a cada grande release tais como nas vers es 2 0 ou 3 0 Nesses casos a aplica o do documento da Vis o Delta deve ajudar a melhor gerenciar o processo de requisitos por permitir que sua equipe concentre se o que realmente Interessa em cada momento espec fico O Documento da Vis o Delta num Ambiente de Sistema Legado Um dos problemas mais melindrosos do gerenciamento de requisitos est em aplicar a habilidade de gerenciamento de requisitos para evoluir sistemas legados do tipo ISAT Raramente se n o nunca existem especifica es de requisitos completa ou adequada para as milh es de linhas de c digo de centenas de pessoas por anos de investimento refletidos nesses sistemas N o pr tico parar e redocumentar o passado Por vezes quando voc faz isso a necessidade passa e voc falha em sua miss o por escrever requisitos hist ricos quando voc deveria estar escrevendo o c digo Assim se voc est come ando do zero ou com uma documenta o m nima voc deve prosseguir com base no melhor esfor o usando qualquer recurso que voc possa encontrar ao seu redor
64. s iniciamos nosso passeio com a an lise do problema um conjunto de quest es que podemos fazer sobre as restri es que ser o impostas ao sistema a t cnica de modelagem de neg cio que podemos usar para v rias aplica es e a t cnica de engenharia de sistemas que podemos aplicar para sistemas complexos Nos cap tulos seguintes descreveremos t cnicas que provaram ser efetiva em atacar as tr s sindromes que acabamos de discutir Entre as t cnicas que iremos discutir est o Entrevistas e question rios Workshops de requisitos Brainstorming e redu o de id ias Storyboards Use cases Role playing Prototipa o A escolha de uma t cnica espec fica varia dependendo do tipo de aplica o a habilidade e sofistica o da equipe de desenvolvimento a habilidade e sofistica o do cliente a escala do problema urg ncia da aplica o a tecnologia usada e da exclusividade da aplica o 67 Cap tulo 8 As Caracteristicas Features de um Produto ou Sistema Pontos chaves e equipe de desenvolvimento deve interpretar um papel mais ativo na elucida o dos requisitos do sistema e As caracter sticas features do produto ou sistema s o express es de alto n vel do comportamento desejado do sistema e Caracter sticas do sistema devem estar limitadas a 25 99 com menos que 50 preferivelmente e Atributos fornecem informa es adicionais sobre as caracter sticas p s apresentar algu
65. sistema Esta lista de caracter sticas o principal artefato que iremos utilizar para gerenciar o escopo do projeto antes que investimentos significativos sejam realizados no refinamento de requisitos projeto codifica o teste entre outras atividades Por exemplo considere um produto de software de prateleira com as seguintes caracter sticas Caracter stica 1 Suporte a banco de dados relacional externo Caracter stica 2 Seguran a multiusu rio Caracter stica 3 Habilidade de clonar um projeto Caracter stica 4 Interface para releases de novos sistemas operacionais SO Caracter stica 5 Assistente de novos projetos Caracter stica 6 Importa o de dados externos por estilo Caracter stica 7 Implementar ferramenta de dicas Caracter stica 8 Integrar com o subsistema de gerenciamento de vers es Definindo as Prioridades Como discutimos em Habilidades de Equipe 2 Entendendo as Necessidades de Usu rios estabelecer as prioridades relativas do conjunto de caracter sticas parte integrante do gerenciamento de escopo Durante a prioriza o importante que clientes e usu rios gerentes de produto ou outros representantes exceto a equipe de desenvolvimento definam as prioridades de acordo com o mercado interno de seus departamentos De fato esta prioriza o inicial deve ser feita sem muita influ ncia da comunidade t cnica caso contr rio o n vel de dificuldade para se implementar as caracter stic
66. sobre as vendas de pedras clientes que compram cm Sala de Jantar Sala de Estudos pedra fornecedores concorr ncia e todas as outras informa es que s o necess rias para manter competitivo o neg cio de vendas de pedras via e commerce Os sistemas de software devido a sua natureza s o intang veis abstratos complexos e teoricamente ao menos est o infinitamente sujeitos a mudan as Assim se o cliente come ar a articular requisitos vagos para um sistema de pedras ele o faz supondo normalmente que ele poder esclarecer mudar e fornecer detalhes a posteriori Seria maravilhoso se desenvolvedores e quaisquer outras pessoas envolvidas na cria o teste implanta o e manuten o do sistema de pedras pudessem realizar esta tarefa em tempo zero e em custo zero mas isso n o acontece assim De fato isso n o acontece nunca Mais da metade dos projetos de sistemas de software que est o atualmente em andamento j ultrapassaram substancialmente o custo e o cronograma previstos e 25 a 33 desses projetos ser o cancelados antes que estejam finalizados normalmente ap s consumirem grandes somas de dinheiro Prevenir tais falhas e fornecer uma abordagem racional para construir sistemas que o cliente deseja o objetivo deste volume importante advertir que este volume n o trata de assuntos de programa o e muito menos escrito somente para desenvolvedores de software Este volume
67. software existente no mundo real A equipe que n s iremos modelar baseia se numa equipe de software do mundo real que provou ser efetivo em duas grandes reas 1 efetividade no gerenciamento de requisitos e 2 cumprimento do cronograma e or amento Naturalmente n s acreditamos que este seja um relacionamento bvio de causa efeito Al m disso n s admitimos que muitas outras habilidades devem estar presentes numa equipe que verdadeiramente cumpram sempre esses objetivos Em nosso caso de estudo a equipe trabalha para a empresa chamada Lumenations S A que ir desenvolver um Sistema de Automa o para Ilumina o de Resid ncias para uso em resid ncias de ltima gera o O Caso de Estudo N s poderemos atingir um outro objetivo neste volume se pudermos desenvolver um caso de estudo que n s trilhamos a partir dos requisitos iniciais at os requisitos finais Assim estaremos aptos n o s a aplicar as t cnicas que estaremos discutindo em nosso exemplo mas tamb m em fornecer exemplos dos produtos do trabalho ou artefatos que possam ilustrar os pontos chaves e servir de exemplos para os nossos pr prios projetos O ap ndice A deste livro fornece um conjunto de exemplos de artefatos do nosso caso de estudo Escopo do Caso de Estudo A Lumenations S A tem sido por 40 anos um fornecedor comercial mundial de sistemas de ilumina o para uso em produ es teatrais amadoras e profissionais Em 1999 seu rendimen
68. software que ser desenvolvido ou alou m que afetado pelo sistema durante ou ap s o seu desenvolvimento m de meus estudantes resumiu o assunto discutido neste volume como o problema da pedra Ela trabalha como engenheira de software num laborat rio de pesquisa onde seus clientes de projeto normalmente d o a miss o a qual ela descreve como Traga me uma pedra Mas quando voc lhe entrega a pedra o cliente diz Sim mas na verdade o que eu realmente queria era uma pequena pedra agul Ao entregar uma pequena pedra azul verifica se que o que o cliente realmente desejava era uma pequena pedra esf rica e azul No final concluiu se que o que o cliente estava querendo era uma pequena pedra de m rmore azul talvez ele n o estivesse seguro do que estava querendo mas um pequeno m rmore azul Bem talvez quem sabe um pequeno olho de gato azul de m rmore tamb m teria servido Provavelmente ele tenha mudado o seu desejo sobre o que queria entre a entrega da primeira pedra grande e a terceira pequena e azul A cada encontro subsequente com o cliente comum que o desenvolvedor pergunte O que voc quer fazer com isto O desenvolvedor fica frustrado porque ele pensou em algo totalmente diferente quando realizou o rduo trabalho de produzir uma pedra com as caracter sticas prescritas o cliente fica igualmente frustrado porque mesmo que ele tenha encontrado dificuldades para articular o que ele
69. suportam os v rios tipos de usu rios Por exemplo na previs o de um novo servi o de transporte e entrega as caracter sticas poderiam ser agrupadas em Roteamento e rastreio de pacotes Servi os aos clientes Marketing e vendas Servi os baseados na web Faturamento Gerenciamento de transporte A gera o de id ias pode ser remniciada agora para qualquer um desses grupos se os participantes acharem que o processo de agrupamento tenha estimulado o desenvolvimento de novas id ias ou que algumas reas de funcionalidades chave tenham sido deixadas de lado 92 Resultados da vota o acumulativa Id ia 1 Id ia 2 Id ia 3 Id ia 4 Id ia 5 380 200 180 140 Id ia 27 Defini o de Caracter sticas Neste ponto importante gastar algum tempo para escrever uma breve descri o sobre o que as id ias significam para a pessoa que a submeteu Isso d ao contribuidor a oportunidade de apresentar caracter sticas adicionais e ajudar a assegurar que os participantes tenham o mesmo entendimento dessas caracter sticas Desta maneira todos entender o o significado da id ia evitando se assim uma grande falha no processo de prioriza o Neste processo o facilitador visita cada id ia que n o foi expurgada e solicita ao contribuidor que forne a uma descri o em uma nica senten a Contexto da Aplica o Caracter stica Obtida Defini o da no Brainstorming Caracter stica
70. trata do assunto Gerenciamento de Requisitos para aplica es de software complexas Assim este volume foi escrito para todos os membros da equipe de desenvolvimento analistas desenvolvedores testers pessoal da Garantia de Qualidade QA gerentes de projetos pessoal de documenta o entre outros assim como para aqueles membros da equipe de chentes usu rios e outros stakeholders da rea de marketing e gerenciamento enfim todos que de fato tenham necessidade e desejos de contribuir com a solu o de requisitos Ir se descobrir qu o crucial que membros de ambas as equipes incluindo pessoas da equipe externa que n o s o da rea t cnica dominem as habilidades necess rias para definir e gerenciar com sucesso o processo de requisitos para o novo sistema isso por uma nica raz o s o eles que criam inicialmente os requisitos e que no final determinam o sucesso ou a falha do sistema Os programadores her is e solit rios s o figuras do passado Eles podem descansar em paz Uma simples compara o Um empreiteiro n o precisa ser convencido de que s o necess rias v rias conversas cuidadosamente orquestradas com o dono da casa para que n o seja constru da uma casa com dois quartos quando o dono queria tr s Mas igualmente importante que esses requisitos sejam discutidos e negociados com as autoridades governamentais respons veis pelo c digo de constru o civil e leis de zoneamento e convers
71. uns com os outros Al m disso o investimento ou a taxa de gastos do projeto se eleva dramaticamente Criamos documentos dos planos de testes constru mos modelos refinamos requisitos de projeto elaboramos use cases desenvolvemos c digos para que atrav s disso possamos criar condi es favor veis de trabalho coordenado e que pode ser mudado se a defini o n o for bem entendida ou se os requisitos ambientais mudarem A pir mide de requisitos pela sua forma larga na base corretamente sugere que muito mais trabalho nos espera pela frente A Habilidade de Equipe 4 desenvolve uma estrat gia para uma das atividades mais cruciais gerenciar o escopo De acordo com dados do Standish Group 1994 53 dos projetos ir o custar 189 do estimado Os dados de nossa experi ncia s o um pouco pior quase todos os projetos de softwares se atrasam em 50 a 100 Assumindo que as outras causas ra zes do desenvolvimento de software n o ser o solucionados do dia para a noite fica claro que a nossa ind stria ou incompetente ou est tentando fazer muito com muito poucos recursos habilidades e ferramentas N s estamos tentando encher dez pontos de funcionalidades desejadas numa sacola que cabe apenas cinco Embora a f sica do desenvolvimento de software n o seja clara bvio que este elemento de nossa estrat gia digno de aten o e que a qualidade tanto dos produtos de nosso trabalho quanto de nossa reputa o est o em
72. 12 00 Brainstorning Caracter sticas do brainstorning da aplica o 12 00 13 00 Almo o Trabalhar durante o almo o para evitar perder o momento 14 00 15 00 Defini o da caracter stica Escrever 2 ou 3 defini es de senten a para as caracter sticas features 15 00 16 00 Redu o e prioriza o de Priorizar as caracter sticas id ias features 16 00 17 00 Fechamento Sum rio e itens de a o atacar os itens de estacionamento Executando o Workshop Problemas e Truques do Of cio Voc pode ver que o facilitador interpreta um papel crucial Para tornar o assunto mais interessante esses workshops s o caracterizados normalmente por uma atmosfera altamente carregada Em outras palavras existem raz es para que seja dif cil chegar ao consenso nos projetos quase todas aparecer o no workshop De fato o cen rio pode at estar carregado e conflituoso politicamente Esta a outra raz o para ter um facilitador deixar o facilitador aquecer e gerenciar a reuni o de forma que n o exacerbe qualquer problema seja do passado presente ou do futuro entre os stakeholders Muitos facilitadores carregam uma mala de truques que o auxiliam a gerenciar esta atmosfera altamente carregada Na RELA desenvolvemos um conjunto muito til de truques de workshop Embora eles pare am estranhamente bonitos e at infantil a primeira vista voc pode acreditar eles provaram o seu valor
73. A principal vantagem deste processo a disponibilidade de oportunidades para m ltiplos feedbacks de usu rios e clientes dos quais pretendemos obter um Sim mas logo no in cio Oponentes desta rigorosa abordagem dizem que nos ambientes atuais n o podemos nos dar ao luxo de aplicar o tempo para realizar uma valida o completa dos conceitos criar dois ou tr s prot tipos para ent o aplicar rigorosamente o modelo cascata 171 Retornando pergunta o que acontece no modelo espiral quando um projeto iniciado com um escopo de 200 A Figura 22 4 ilustra o resultado N s podemos dizer que o resultado n o muito melhor do que o plano desastroso quando se utiliza o modelo cascata outros dizem no prazo final teremos apenas um ou dois prot tipos operacionais e um feedback do cliente Naturalmente esse feedback estar focado na inutilidade dos softwares que est o para ser liberado para produ o Prazo Final Projeto e valida o de projeto Plano de integra o Projeto detalhado Codifica o N Prot tipo 2 An lise de riscos w Teste de unidade Integra o N Plano de requisitos Plano de desenvolvimento Valida o de Prot tipo 1 requisitos Requisito de software Figura 22 4 Aplicando o modelo espiral num projeto com 200 de escopo A Abordagem Iterativa Na d cada passada muitas equipes migraram para um
74. Automa o de Configura o da O propriet rio pode criar ilumina o residencial ilumina o autom tica previamente cronogramas para certos eventos com base nas horas do dia Sistema de entrada de R pido R pido o suficiente para pedidos de venda que o tempo n o interfira nas opera es normais Sistema de rastreamento Notifica o autom tica Todas as partes de defeitos registradas ser o notificadas via e mail quando algo for mudado Uma caracter stica de rob de solda como soldagem autom tica pode ter sido suficientemente descrita n o necessitando de nenhum trabalho adicional No entanto importante n o cair nessa armadilha a descri o n o deve levar mais do que alguns minutos por id ia Voc precisa capturar apenas a ess ncia da id ia Prioriza o Em algumas situa es a gera o de id ias o nico objetivo assim o processo est completo No entanto na maioria dos casos incluindo o workshop de requisitos necess rio priorizar as id ias que permaneceram ap s o expurgo Afinal de contas nenhuma equipe de desenvolvimento pode fazer tudo o que todos pensaram Uma vez que o agrupamento tenha se estabilizado e atingido o consenso hora de ir para o pr ximo passo Novamente v rias t cnicas podem ser usadas n s Iremos descrever duas que usamos rotineiramente Vota o Acumulativa Teste dos Cem D lares Este simples teste divertido legal e f cil
75. BILIDADE DE EQUIPE 3 ssaiaasaesa snsc inicio Quais caos dali a dadas aaa 147 HABILIDADE DE LOUPE A usaria canis cadinao N iaa les E EAEE bobina salsa do cual Juno c naao E AENA 148 GERENCIANDO O ESCOPO Rear r errante 148 CAPITULO O rss srs a RD Da RO E Rg DP RS AS RR RR Rana 150 O PROBLEMA DO ESCOPO DE PROJETO erre rer ear nene 150 A Dificil QUEST O estos pisos e Isin O E E e EU e 153 CAPIR LOS Ds aA ne DR dg e q SS q a A EOE EET 154 ESTABELECENDO O ESCOPO DE PROJETO erre rear rear rea nreaad 154 O Baseline de Requisitos eee ee eterna aeee erre a aaa te cera a EEEE EEEEEEEEEEEEEEEEEE REEERE Eese eet 154 Definindo as Prioridades rear aaa aaa Ena renne 155 Avaliando O ESTOR O norria a a N EN A E ATN E A A A A a 156 Adicionando o Elemento R SCO aaa aaa rear 158 Reduzindo o ESCOPO e rrreeee aaa aee eee ee eee eerre eee anaaaaaaaa aeee eee rerreeeenanaaaaaaaeeteeeeereer eee nnananaaaeeta 159 Uma Estimativa Inicial Razo vel susana s sais UR sa Cos a SSIS L a UU TURCO EU a DURO CC UCO a a E US A ES ASa CASES GUS 159 O Caso de ESTUDOS adro d eia dad Sa da 55d SD E e E Dc 161 CAPITULO Das sa od a ira Da a a E O E aC 164 GERENCIANDO O SEU CLIENTE errar reatar r aaa rear 164 Engajando Clientes para Gerenciar Seu Escopo de Projeto ee 164 Comunicando os Resultados arara rear 164 Negociando com o Cliente reter aee terre a ee coreana terrena
76. BRAINSTORMING E A REDU O DE DEIAS aaa 89 Brainstorming Presencial erre eee e erre nana terre aaa aeee rrenan aeee erre aaaeeeeereeeaananeeeoo 90 Redu o de IACIAS si saite sas aa ad 91 EDUARD Cp a 92 Pa Neaga je ciao 6 Ed SIL ADERIR RI a PURO REDE RPPS REDES ARE RREO UR REPRISE RE POTRO UR 92 Definicao de Caracteristicas sao d aaa ad a Rd a A a SS DR n 93 PROPIZA O nas ron nto ii a a RD o AD O CR a Ea en aa 93 Brainstorming Baseado em Web eee e terrena aeee erre a aeee erre aa eee rereeeaananeteo 95 O Caso de Estudos O Workshop de Requisitos do HOLIS 2000 95 Parc partes ed pulo ONENE EERE dai o e dpi ab ld ria bad a a 95 CV Ork NO nata trap NEEE Uai pag a ONECO E apta aa rg a ORNER ROER 97 NASCE O OM otite ca E E A De a a 97 Analisede Resultados morera E A E A EE EE A EE d 98 CAPITULO Toia e RR RU O 100 STORYBOARDING e a inon sas nda ii iai Data EE ido CD iq GR o CADA DE aii ada ARE pi ts 100 Tipos de StorVDOArAS sas nissan A AA A ai 101 O que os Storyboards Fazem errante eee e coreana core a aee coreana aerea aee eerenaaeceeeenaaceeea 102 Ferramentas e T cnicas para o Storyboarding eretas 103 Dicas do Storyboarding ns acisisi sia sia E AD A nsere en ent 103 SUMO a UC a seas aU Do a E DD CSA 104 CAPITU VO sra tis A E T T E 107 APLICANDO USE CASES ss sas a E E A ia a E A 107 Construindo o Modelo Use Case erre teor eterna correa n aee erea nato rena eeerenaaeeera 108 Aplica
77. Existe o fator desconforto Esta t cnica n o nos motiva ao ter que fazer mal feito um simples pedido de venda enquanto nossos clientes ou pessoas que entram com um pedido de venda nos observam Al m disso existe o fator delicado e confuso Ser for ado a interagir com pessoas reais ao inv s de com um teclado nos faz sair da nossa zona de conforto afinal de contas n s queremos compilar classes te ricas deixem que nossos colegas participem de um drama No entanto n o h d vidas de que se n s conseguirmos vencer essa pequena dificuldade o role playing ser uma das t cnicas mais acess veis e eficazes para assistir no descobrimento de requisitos 115 Cap tulo 15 Prototipa o Pontos chaves e prototipa o especialmente efetiva para atacar as s ndromes Sim mas e Ru nas Desconhecidas e Um prot tipo de requisitos de software uma implementa o parcial do sistema de software constru do para auxiliar os desenvolvedores usu rios e clientes a melhor entenderem os requisitos do sistema e Crie prot tipos para requisitos confusos aqueles que embora conhecidos ou impl citos suas defini es s o pobres e mal compreendidas s prot tipos de software como encarna es de um sistema de software demonstram uma por o da funcionalidade de um novo sistema Dado o que discutimos at aqui n s esperamos que fique obvio de que a prototipa o pode ser muito til para descob
78. IDA O DE REQUISITOS aeee 64 Obst culos da Elucida o reter aeee aeee eee sssr eee a aee serrr nsr tranen renan aee eerenanecerenanda 64 ASmndr medo Sim MIS sis AD nao DA RA SAN O O SO O RUE Sa O a E 64 A S ndrome das Ru nas Desconhecidas eee ereto eee aa terre ae ecra neeeea 65 A S ndrome Usu rio e o Desenvolvedor eee ereto eee ne terrena terre neeeea 66 T cnicas de Elucida o de Requisitos ereto teor neeeeeeaneio 67 CAPITULOS ups dana Db na a aaa adia 68 As CARACTER STICAS FEATURES DE UM PRODUTO OU SISTEMA cires 68 Stakeholders e Necessidades do Usu rio eee core a aeee erereeanereea 68 Caracter sticas Features retrato eee e correa aeee eee a neto rena ESEE PSSE EEEo narr renner eesnere rannt 69 Gerenciando a Complexidade Escolhendo o Nivel de PSirac o raaa antrais pior tosa ARA ani a tendas Dede dd ENTERRA EA APIDAE dO Ud EANNA 71 Atributos das Catacterisucas do ProdUtOsiins eaae a a a aaa a a a data anai aaae pa a na 71 CART O Srn a NV DRDS NEN 73 ENTREVISTA asso E E E A SA GA AN E TTN 73 O Contexto da Entrevista assa Dias ad RSS Dido ta RL EEEE PSEren dn Sit 73 As Quest es liyres de CONE Oepie Eta an tan ne Gui anesaadn aii ceu EEEE sean cano Orca cana EAEE AEE TEA REEE A E SS 73 A Import ncia do Contexto da Solu o eee terrena terre aerea arena 74 O Momento da Verdade A Entrevista eee eee eee ee
79. O devolu es o mercadoria obsoleta m defeitos de manufatura OU O 49 f e U Sam O Ou DB outros Contribui es Figura 4 2 Gr fico de Pareto das causas ra zes 29 Passo O entendimento das necessidades dos usu rios e stakeholders o fator chave para o desenvolvimento de uma solu o efetiva Posteriormente a an lise do diagrama espinha de peixe pode ser usada para determinar quais tipos espec ficos de erros contribuem para o problema de pedidos errados de vendas Esses dados mais detalhados podem ent o ser usados para definir as caracter sticas do sistema de software para atacar tais erros Para o nosso prop sito no entanto podemos finalizar a nossa an lise e concordar com a troca do sistema de pedidos que ao menos uma solu o parcial para o problema de muitos desperd cios Uma vez que identificamos pedidos errados como uma das causas ra zes do problema que vale a pena ser resolvido n s podemos criar uma declara o do problema para o problema dos pedidos de venda como ilustrado na Tabela 4 2 Tabela 4 2 Declara o do problema dos pedidos de venda Elementos Descri o O problema de pedidos errados afeta o pessoal de vendas clientes fabricantes transportadores e servi o de atendimento ao cliente devido ao aumento de desperd cios excessiva manipula o de custos Insatisfa o de clientes e baixa lucratividade Os benef cios desse n
80. Produto A fim de ajudar a melhor gerenciar esta informa o introduzimos a no o de atributos de caracter sticas ou elementos de dados que fornecem informa es adicionais sobre o item Atributos s o usados para associar a caracteristica ou dados de requisitos a outros tipos de informa es de projeto N s podemos usar atributos para rastrear nome ou identificador nico estado dados hist ricos aloca o rastreado para entre outros para priorizar campo de prioridade e para gerenciar estado as caracter sticas propostas para a implementa o Por exemplo o atributo prioridade pode ser usado para capturar os resultados da vota o cumulativa numa sess o de brainstorming o atributo numero da vers o pode ser usado para registrar as libera es de software espec ficas com as caracter sticas espec ficas que pretendemos implementar Por anexar v rios atributos s caracter sticas voc pode gerenciar melhor a complexidade da informa o Embora n o existam limites para os tipos de atributos que voc pode ter a experi ncia tem demonstrado que alguns atributos comuns de caracter sticas se aplicam a muitas circunst ncias de projeto Tabela 8 2 No restante deste volume usaremos esses atributos para ajudar a gerenciar a complexidade dos dados de caracter sticas e requisitos e para gerenciar relacionamentos tais como as depend ncias entre os v rios tipos de requisitos do sistema Assim deixe nos prosseguir com
81. Resultados Os resultados do processo apresentaram se como esperado exceto por dois itens significativos 1 Seguran a pr definida surgiu na lista com alta prioridade Esta caracter stica havia sido mencionada em entrevistas anteriores mas n o foi colocada na lista de prioridades de qualquer entrevistado Depois de uma r pida revis o Cathy notou que a seguran a pr definida tais como a habilidade de flash de luz a sirene opcional e 98 sistemas de chamada para emerg ncias aparentemente n o eram fornecidos pelos sistemas da concorr ncia Os participantes comentaram que embora tenha sido uma surpresa esta informa o eles acham que isso deve ser uma diferencia o competitiva e de acordo com isso ser uma caracter stica de alta prioridade Krys e David concordaram Com base nessa conclus o o marketing decidiu incluir esta funcionalidade e coloc la como o seu nico diferencial competitivo no mercado Esta ser uma das caracteristicas que definem o HOLIS 2 Al m disso a caracter stica 25 Internacionaliza o da interface do usu rio n o recebeu muitos votos Isto pareceu fazer sentido equipe porque os propriet rios localizados nos Estados Unidos n o podem se preocupar com o como o produto ser vendido na Europa O distribuidor no entanto disse sem rodeios de que se o produto n o estiver internacionalizado desde a vers o 1 0 ele n o seria introduzido na Europa equipe anotou esta pos
82. Volme UNIFIED PROCESS amp UNIFIED MODELING LANGUAGE LABORAT RIO DE ENGENHARIA DE SOFIWARE Gerenciamento de Requisitos de Software LABORAT RIO DE ENGENHARIA DE SOFTWARE Gerenciamento de Requisitos de Software Leffingwell Dean amp Widrig Don Managing Software Requirements A Unified Approach Addison Wesley object technology series Addison Wesley 2000 ISBN 0 201 61593 2 Tradu o e Revis o T cnica O Osvaldo Kotaro Takai e mail otakai M uol com br ndice 190 0 SI DS ENREDO RR NR PR NPR RD ARS PR ND A RED 3 CAPITULO Asasidotae a aiii gale lados indigo alada el adaga ada adia 8 O PROBLEMA DA PEDRA POR ED YOURDON e rreeeerereeeeeeeereeaeeeereeeaneeeeraa 8 CAPITULO S essas A a a aa RO A ata 11 INTRODU O AO GERENCIAMENTO DE REQUISITOS 11 DETINI ES eei a EEEE EE A A NA 11 Douce Gnr ReiS O an a a aT a a a E R A 11 Cuque cio Gerencamentode Requisitos spasjranii dona orid pudada ibn a E Ra DC aA 11 Aplica o das T cnicas de Gerenciamento de Requisitos eee 13 Tipos de inlica es de SOLAR parta sas andante Eau DSO ari E a EEA 13 Aplica es de Sistemas opuia das oa raro da ia sra RaLasa Recs nau a a asa O uu O ada aa a RIC gu R 13 OMPI ca MIA SS EO ES a N 14 ODomnmo do Problema mea ma eran T EEA E EEE T EE EE ET a eN 14 Necessidades dos Stakehold tsi incerane e E E EET E N A E e e a a A A A E A E 15 Caminhando em Dire o ao Dom nio da Solu o sa g
83. a es usadas s o relevantes para essa aplica o Se sim fale um pouco sobre elas Quais s o as suas expectativas para a usabilidade do produto Quais s o as suas expectativas para o tempo de treinamento Que tipo de aux lio ao usu rio voc precisa p ex c pia impressa ou documentos on line Parte IV Recapturando para Entender Voc me disse que Liste os problemas que o cliente descreveu com suas pr prias palavras Eles representam adequadamente os problemas que voc est tendo com a solu o existente Quais outros problemas caso exista voc est enfrentando Parte V Suposi es do Analista sobre o Problema do Cliente Valide ou invalide suposi es Se n o foi discutido Quais problemas se houver est o associados Liste quaisquer necessidades needs ou problemas adicionais que voc acha que est preocupando o cliente ou o usu rio J J 75 Para cada problema sugerido pergunte e Esse um problema real e Quais s o as raz es deste problema e Como voc gostaria de resolv lo e Qual o peso da solu o desse problema comparado aos outros que voc mencionou Parte VI Avaliando a sua Solu o se aplic vel Resuma as principais capacidades da solu o que voc prop s O que aconteceria se voc conseguisse Como voc classificaria cada uma dessas capacidades por ordem de sua import ncia Parte VII Avaliando a Oportunidade Quem na sua organiza o pr
84. a o A engenharia de sistemas considera tanto o neg cio quanto as necessidades t cnicas de todos os clientes com o objetivo de fornecer um produto de qualidade que atenda as necessidades dos usu rios Ufa Essa defini o muito longa No entanto pela defini o a engenharia de sistemas pode ser considerada uma t cnica de an lise de problemas embora que neste volume n o esperamos cobri la em sua totalidade Para maiores detalhes veja Rechtin 1997 No escopo deste volume a engenharia de sistemas pode nos ajudar a entender as necessidades do espa o do problema e os requisitos que s o Impostos solu o Nesse contexto a engenharia de sistemas nos ajuda a entender os requisitos que s o impostos s aplica es de software e que executem dentro da solu o sist mica Em outras palavras n s aplicamos a engenharia de sistemas como uma t cnica de an lise de problemas para nos ajudar a entender os requisitos de nossas aplica es de software se elas executarem sobre um microprocessador embutido ou num sistema UNIX dentro do contexto de um sistema mundial de telecomunica o Princ pios Pragm ticos da Engenharia de Sistemas Se considerarmos que a engenharia de sistemas uma t cnica de an lise de problemas os passos espec ficos ou pelo menos os princ pios b sicos da disciplina devem nos fornecer os passos necess rios para aplicar a engenharia de sistemas para analisar o problema dentro do nosso contexto de
85. a o ou informa es associadas ao gerenciamento de projeto e devemos evitar informa es sobre como o sistema ser testado Dessa forma os 182 requisitos focam o comportamento do sistema e sua volatilidade depende da volatilidade do comportamento ou da tend ncia de mudan as Exclua Informa es do Projeto Informa es relacionadas ao projeto tais como cronogramas plano de gerenciamento de configura es planos de verifica o e valida o or amento e hor rios de turnos s o algumas vezes inseridas no conjunto de requisitos por conveni ncia do gerente de projetos Em geral isso deve ser evitado uma vez que mudan as nessa informa o tal como mudan a do cronograma eleva a volatilidade e a tend ncia desses requisitos de ficarem desatualizados Quando os requisitos s o datados eles se tornam menos confi veis com maior probabilidade de serem ignorados Al m disso debates inevit veis sobre essas quest es deveriam ficar separados da discuss o sobre o que o sistema deve fazer Existem diferentes stakeholders envolvidos e cada um serve a prop sitos diferentes O or amento pode tamb m ter sido colocado como um requisito no entanto um outro tipo de informa o que n o satisfaz a nossa defini o e assim n o deve fazer parte dos requisitos gerais do sistema ou do software O or amento pode se tornar uma pe a importante de informa o quando o desenvolvedor precisa decidir qual estrat gia
86. a diretamente 145 Embora n o existam prescri es que possam ser seguidas para criar um campe o de projeto extremamente importante para a sua equipe identificar um promov lo ou delegar para algu m que j esteja aparentemente liderando o processo Ent o e responsabilidade da equipe assisti lo de todas as maneiras poss veis no gerenciamento de requisitos da aplica o Isso ir ajudar a atingir o sucesso Al m disso se voc n o ajudar essa pessoa a atingir o sucesso ela poder convid la para que voc seja o campe o do projeto num pr ximo projeto 146 Sum rio da Habilidade de Equipe 3 Na Habilidade de Equipe 3 n s nos movemos do entendimento das necessidades do usu rio para iniciar a defini o da solu o Ao fazermos 1sso n s demos a engatinhada inicial para sairmos do dom nio do problema a ilha do usu rio e entrarmos no dom nio da solu o o lugar onde n s trabalhamos para definir um sistema que solucione o problema que temos em m os N s tamb m aprendemos que sistemas complexos necessitam de estrat gias claras para gerenciar informa es de requisitos e algumas maneiras de organizar informa es de requisitos N s reconhecemos que n s realmente temos uma hierarquia de informa es come ando pelas necessidades dos usu rios passando pelas caracter sticas chegando finalmente aos requisitos de software mais detalhados representado pelos use cases ou formas tradicionais de expres
87. a 4 4 Potenciais restri es do sistema Fonte Econ mica Pol tica T cnica Sist mica Ambiental De planejamento e recursos Exemplo de Considera es Que restri es financeiras ou or ament rias s o aplic veis Existem custos associados nas vendas de mercadorias ou considera es sobre pre o de produtos Existe algum problema de licenciamento Existem problemas pol ticos internos ou externos que possam potencialmente afetar a solu o Existem problemas interdepartamentais Temos restri es quanto escolha de tecnologia Temos restri es para trabalhar com a plataforma ou tecnologias existentes Utilizaremos algum pacote de software adquirido A solu o ser constru da sobre o sistema existente Devemos manter compatibilidade com a solu o existente Que sistemas operacionais e ambientes devem ser suportados Existem restri es ambientais ou legais Existem requisitos de seguran a Estamos restritos a algum padr o O planejamento est definido Estamos restritos aos recursos existentes Podemos utilizar trabalho externo Podemos aumentar os recursos tempor rios ou permanentes Retornando ao nosso exemplo quais restri es podem ser impostas sobre o novo sistema de pedidos A Tabela 4 5 sumariza os recursos e restri es que foram impostas sobre o novo sistema 35 Tabela 4 5 Fonte Operacional Sistema e SO Or amento de equipamentos Or
88. a baixo O Membro da Equipe disse 4qui por que voc n o faz isso e passou uma tesoura para o cliente O cliente pegou a tesoura e o Membro da Equipe deixou a sala O cliente continuou a sess o de projeto interativo com feltros e tesouras Uma hora mais tarde o cliente olhou a parede e disse Est muito bom construa o Permita nos descobrir a moral da est ria com uma pequena leitura de pergunta e resposta Pergunta Por que a loucura do feltro funcionou e a impress o colorida n o Resposta Existem duas raz es m Interatividade O que o cliente pode fazer com cinco desenhos dos quais apenas uma parte satisfat ria m Usabilidade Qu o assustador pode ser cortar um grande peda o de feltro O cliente que tinha o dom nio da especialidade mas n o necessariamente o projeto projetou uma solu o adequada para o seu pr prio problema N s adotamos a casa de feltro como nossa e fixamos na parede como uma constante lembran a sobre o que n s aprendemos A interface do usu rio embora n o tenha sido uma solu o tima nunca mudou e se adequou aos prop sitos dos interessados Mas infelizmente o projeto n o foi um grande sucesso de venda embora o produto tenha ido para o mercado e alcan ado sucesso Como dissemos anteriormente este foi apenas um dos problemas enfrentados neste particular projeto m Li o 1 Entender as necessidades do usu rio um problema fr gil e confuso Utilize fe
89. a estrutura gestalt do produto a partir de todas as perspectivas significativas de forma breve abstrata leg vel e manej vel Como tal o documento da Vis o o principal foco nas fases iniciais do projeto e muito investimento feito no processo de obter as informa es que ir o satisfazer o conhecido retorno nas fases posteriores Uma vez que virtualmente todos os projetos de softwares podem se beneficiar do documento da Vis o n s o descreveremos em detalhes Embora o nosso exemplo esteja orientado para um produto espec fico de software n o ser dificil modific lo para o seu contexto particular de produto A Figura 17 1 fornece um exemplo do documento da Vis o com um breve coment rio Estes coment rios foram usados com personaliza es em centenas de produtos de software e numa grande variedade de aplica es de software Uma vers o totalmente comentada deste documento consta no Ap ndice B Em resumo o documento da Vis o uma descri o concisa de todas as coisas que voc considera ser mais importante sobre o produto ou aplica o O documento da Vis o deve ser escrito com um n vel de detalhes e de claridade suficientes para permitir que seja prontamente lido e compreendido pelos stakeholders do projeto 1 Introdu o Esta se o deve fornecer um resumo completo do documento da Vis o 1 1 Prop sito do Documento da Vis o Este documento re ne analisa e define as necessidades do usu rio
90. a nova abordagem uma que combina o que existe de melhor nos modelos cascata e espiral e que um h brido desses dois A nova abordagem tamb m incorpora algumas constru es adicionais avan adas da disciplina de engenharia de processos de software A abordagem 1terativa introduzida por Kruchten 1995 tem sido bem descrito em in meros textos incluindo Kruchten 1999 e Royce 1998 Esta abordagem tem provado a sua efetividade em v rios tipos de projetos e pode exibir in meras vantagens sobre os modelos de desenvolvimento cascata e espiral Nos modelos de desenvolvimento de software tradicionais o tempo se segue atrav s de uma s rie de atividades sequenciais com o requisito precedendo o projeto o projeto precedendo a implementa o e assim por diante Isso parece ser bastante l gico Na abordagem 1terativa as fases do ciclo de vida n o est o acopladas s atividades l gicas de software que ocorrem em cada fase permitindo nos revisitar as v rias atividades tais como requisitos projetos e implementa o em v rias itera es do projeto Al m disso como no modelo espiral cada itera o projetada para reduzir quaisquer riscos presentes no est gio de atividade de desenvolvimento 172 Fases do Ciclo de Vida A abordagem iterativa consiste de quatro fases do ciclo de vida concep o elabora o constru o e transi o as quais correspondem claramente aos estados naturais do projeto ao longo do tem
91. a os quais elucida o adicional a pr xima a o apropriada Registro das vers es pretendidas de produtos onde as caracter sticas aparecer o pela primeira vez Quando combinado com o campo Estado sua equipe pode propor registrar e discutir v rias caracter sticas sem liber las para o desenvolvimento Em muitos projetos caracter sticas estar o associadas a equipes de caracter sticas respons veis em promover a elucida o escrever os requisitos de software e talvez realizar a implementa o Usado para rastrear a fonte das solicita es de caracter sticas Por exemplo a refer ncia pode ser a p gina e o n mero da linha de uma especifica o do produto ou um marcador de minuto num v deo de uma importante entrevista do cliente 72 Cap tulo 9 Entrevista Pontos chaves e entrevista uma t cnica simples e direta e Quest es livres de contexto podem nos ajudar a conduzir com tranquilidade as entrevistas e Ent o a entrevista pode ser apropriada para encontrar requisitos n o descobertos por explorar solu es e Conyverg ncias sobre algumas necessidades comuns ir o iniciar um reposit rio de requisitos para ser utilizado durante o projeto Um question rio n o substitui uma entrevista ma das t cnicas mais importantes e mais simples de obten o de requisitos a entrevista de usu rios uma t cnica simples e direta e que pode ser usada em virtualmente qualquer situa
92. ada para registrar as tr s necessidades needs ou problemas mais importantes descobertas na entrevista Em muitos casos ap s algumas entrevistas tais necessidades needs de alta prioridade come ar o a se repetir Isso significa que voc come ou a encontrar converg ncia sobre algumas necessidades needs comuns Isso esperado especialmente entre aqueles usu rios e stakeholders que compartilham das mesmas perspectivas Ent o em dez entrevistas normalmente s o criados apenas 10 15 necessidades needs diferentes Este o in cio do seu reposit rio de requisitos um conjunto de recursos que voc ir construir e usar com grandes vantagens no decorrer do projeto Esses dados simples e inexpressivos por si s ajudar o voc e a sua equipe a construir uma base mais s lida para dar in cio ao seu projeto O Estudo de Caso A equipe do HOLIS decidiu que a equipe de marketing Eric e Cathy desenvolveria as quest es para a entrevista mas procura algu m da equipe para experimentar o processo e ter a oportunidade de encontrar clientes face a fase e assim ver o problema e uma prov vel solu o sob a perspectiva do cliente Assim a equipe dividiu a lista de clientes e distribuidores e cada membro da equipe teve que entrevistar duas pessoas A equipe usou o Resumo do Analista para sumarizar as necessidades needs que foram fornecidas e duplicidades foram extra das Depois de quinze entrevistas a equipe identific
93. ada para obter um feedback inicial do usu rio usando ferramentas inexpressivas Assim storyboards s o particularmente efetivos em atacar a s ndrome Sim mas Eles ajudam tamb m a atacar a sindrome das Ru nas Desconhecidas elucidando imediatamente o feedback de usu rios tal como o que o sistema parece que n o deve fazer Mas como em qualquer t cnica certas advert ncias de aplicam Aqui est o algumas dicas que devemos ter em mente quando se pratica a t cnica do storyboarding N o invista muito tempo no storyboarding Clientes ficar o intimidados a fazer mudan as se o storyboard se parecer muito com o produto real ou eles podem pensar que est o insultando voc um problema particularmente dificil em algumas culturas Tudo bem mantenha o 103 storyboard deselegante e grosseiro at mesmo cru Veja a est ria do storyboarding no final deste cap tulo Se voc n o fizer nenhuma mudan a voc n o aprender qualquer coisa Fa a o storyboard para que seja f cil de modificar Voc deve estar apto a modificar um storyboard em algumas horas N o fa a o storyboard muito bom Se voc fizer isso os clientes ir o querer lev lo Num projeto real n s sofremos por anos tendo que dar suporte num produto Excel VB que nunca pretendeu ser mais do que um storyboard Mantenha o storyboard como rascunho use ferramentas e t cnicas que n o causem perigo neste campo especialmente para storyboards que s o
94. adicionar recursos durante um projeto impratic vel Al m disso como os or amentos de desenvolvimento s o geralmente apertados nesses anos de Internet adicionar recursos simplesmente n o uma op o poss vel Com o prop sito fazer a an lise do escopo permita nos assumir que recursos no eixo y da Figura 19 1 s o constantes enquanto durar o projeto e O Tempo talvez aqui tenha um limite flex vel sujeito a mudan as se os recursos dispon veis forem inadequados para atingir a funcionalidade desejada Para o prop sito de nossa an lise de escopo o tempo no eixo x um fator estabelecido Certamente a hist ria ir demonstrar que liberar software com atraso normalmente o esperado Por outro lado muitas equipes de desenvolvimento t m dificuldades de fixar o prazo final Exemplos disso incluem um programa para declara o de um novo imposto que ser liberado definido por lei apresenta o de um novo produto durante uma exposi o ou o prazo final fixado contratualmente pelo cliente Al m disso se quisermos assegurar nossa credibilidade profissional e ganhar a confid ncia de nossos clientes importante n o errarmos no cronograma A funcionalidade total que podemos liberar obviamente limitada pelo tempo dispon vel fixado e pelos recursos dispon veis tamb m fixados que temos para usar assim o escopo dispon vel a rea do ret ngulo Neste volume n s usamos a no o de caracter
95. ado para um caf da manh com um membro da equipe de projeto Membro da Equipe O Membro da Equipe tamb m um costureiro arrancou o fundo de feltro de um pano cortou com a tesoura e depois de colori lo disse Eu gostaria de facilitar a parte da interface do usu rio na reuni o usando essas ferramentas Autor Voc est brincando n o tem como fazer isso funcionar Isso parecer tolo e anti profissional Membro da Equipe Eu entendo mas qu o efetivo fomos ontem 105 O Autor politicamente correto n o disse a primeira palavra que lhe veio mente A segunda palavra foi OK O pr ximo dia o tom na sala de reuni es foi muito diferente A equipe do cliente tinha novamente chegado cedo mas desta vez estavam silenciosos e carrancudos ao inv s de descomedido e excitado An lise Agora eles sabem o quanto n s est vamos atados e sem respostas Eles haviam planejado nos matar mas agora sabem que est vamos sendo injusti ados Para iniciar a reuni o o Membro da Equipe colocou uma pe a de feltro de 3 por S 1 x 2 m sobre a parede gerando risos mas n o desinteresse por parte do cliente O Membro da Equipe colocou grandes interruptores para chaves de pot ncia e v rios bot es de modo terapia feitos de feltro sobre o painel frontal e disse Agora este projeto funciona O cliente olhou para a parede e disse N o mas por que voc n o desloca o bot o de parede de emerg ncia par
96. aerea aee erre aeee cera aneeereanda 165 Gerenciando o BaseliPe cc Rara aaa ra anna 166 NUA AO CTA camas onsena a E e E E EE E R A Ea 167 M danca NO so CIA eeraa ra DD r a RD RD R E A O an 167 CAPERULO 2 ses ua A os a a UDN N DR RI do E a Da 168 GERENCIAMENTO DE ESCOPO E MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 168 O Modelo Cascal uni a o a tda E dt a O 168 O Modelo ESpILAL sas ss pissmsssa sound aluDoo uol ses AISO EU peS UEC Sad dEUS INN AD AC S abuse cs alo assa ida salada 170 A Abordagem lIterativa terre eta e erre aaa aeee rere can aa aeee erre ea n aa eee eereeaaaaeee erra neern nnt 72 Fases do Ciclo de Vidar ein ri e E E SE CEEE e a a e a E e a A e e e a Ud ES iiin 173 DECR ACO Smo e REEE fd R a Rd a E de RA T EER TT 173 EIN d ONE A P E EA A E AAS ESA 174 O que fazer O que fazer tetra aeee eee esett aeee erre nana tee eee EEPE EEEEEEEEEEEEEEEEEEEE EEEE ESERE EEEE 175 SUM RIO DA HABILIDADE DE EQUIDE A io ras isa E Ea aa na sa doca dao es numa a NA 176 HABILIDADE DE EQUIPE Senanin ata sfa cais asda das a Ia SE SETTE ad aii 177 REFINANDO A DEFINI O DO SISTEMA errar aerea errar 177 CAPITULOS as bt doa ssa dl a a ad aaa E a a Sa a o 179 REQUISITOS DE SOFTWARE rr a on ooon oroe noS o rD P naon Se oD aerea aaa eeens eeno 179 Cap tulo 1 O Problema da Pedra por Ed Yourdon Ponto chave o Stakeholder algu m que tem interesse no sistema de
97. agrama do sistema que descreva a fronteira do sistema e identifique os atores do sistema Isso apresenta um belo paralelo com os passos 3 e 4 dos cinco passos da an lise do problema onde n s identificamos os stakeholders do sistema e definimos a fronteira do sistema N s tamb m aprendemos nos Cap tulos 4 5 e 6 como identificar os atores que ir o interagir com o sistema Por exemplo num sistema de gerenciamento de estoques Jacobson et al 1992 a fronteira do sistema pode se parecer como a Figura 13 1 O E ca do Escrit rio Anlo D Chefe do Estoque Use Case Use Case Sistema de Gerenciamento de lt gt Estoques Acme Motorista de paat C gt Caminh o Use Case NS Q Estoquista Operador de Empilhadeira Figura 13 1 O sistema de estoque inicial com atores identificados 108 Voc pode ver que o sistema usado por alguns usu rios cada um dos quais interagem com o sistema para tingir um objetivo operacional espec fico A an lise futura do sistema determina que certas linhas de comportamento do sistema s o necess rias para suportar as necessidades dos usu rios Essas linhas s o OS use cases ou a sequ ncia espec fica pelas quais os usu rios interagem com o sistema para realizar um objetivo espec fico Exemplos desses use cases de sistema podem incluir Distribui o manual dos itens dentro de estoque Inser o de um novo item no estoque a Verificar itens de estoque Aplicando Use Case
98. ais e o total de tempo dispon vel para o projeto a equipe pode determinar onde tra ar o baseline inicial Se o baseline contiver o conjunto de caracter sticas cr ticas tudo bem sen o o projeto estar fora do escopo e um novo projeto por m menor dever ser definido 156 Gerente de Produto Qual a dificuldade de implementar esta caracter stica Equipe de Desenvolvimento N s n o sabemos N s ainda n o temos quaisquer reguisitos ou o seu projeto Gerente de Produto Tudo bem mas a coisa mais f cil que n s j fizemos Equipe de Desenvolvimento N o Gerente de Produto Certo a caracteristica mais dificil da lista Equipe de Desenvolvimento N o Gerente de Produto Numa escala de baixo m dio dif cil podemos dizer que m dio Equipe de Desenvolvimento Sim m dio Gerente de Produto Certo agora vamos avaliar a pr xima caracter stica Por que n s n o permitimos um processo que crie requisitos e informa es detalhadas de projeto para cada caracter stica a fim de permitir a realiza o de estimativas mais significativas Isso n o seria a maneira profissional de abordar o problema Se no cronograma houver tempo para permitir realizar estimativas mais detalhadas ent o devemos faz lo No entanto n s acreditamos que seja crucial estarmos prontos para tomar algumas decis es r pidas sobre o escopo da atividade sem que exista uma estimativa mais detalhada Por que Porque caso con
99. alguns slots a mais para permitir futuras expans es Finalmente veja se voc pode encontrar alguns daqueles anci es para lhe ajudar com a engenharia de sistemas Eles estiveram aqui antes e sua experi ncia pode ser muito valiosa para voc Al m disso voc poderia assim a ajudar a por um fim nesse conflito de gera es 52 Uma est ria Particionando Grandes Sistemas de Software em Subsistemas para Equipes Distribu das de Desenvolvimento Numa aula Rusty um gerente de software experiente nos abordou e definiu o seguinte problema descrito como um di logo Rusty Estamos construindo uma grande aplica o que ser executada num unico sistema servidor Nosso possuimos duas equipes separadas contendo cada uma 30 pessoas uma das equipes vive no lado leste do rio da cidade de Nova York e o outro vive no lado oeste As duas equipes possuem gerentes diferentes e compet ncias diferentes Como dividir o trabalho e criar um sistema que funcione Bem Rust uma maneira de pensar sobre este problema como um problema de engenharia de sistemas Isto e estabelecer a forma de particionar o sistema em dois subsistemas l gicos Vamos chamar de Leste e Oeste e alocar os requisitos para os subsistemas como se eles fossem sistemas f sicos separados Defina uma interface complete com as defini es de classes e servi os comuns a serem usados isso permitir que os dois subsistemas aplica es se cooperem para atingir a f
100. alquer outra coisa para atingir esse prop sito Quando voc tiver terminado voc simplesmente o descarta mantendo apenas o conhecimento apreendido nesse exerc cio Evolucion rio implica que voc implementou o prot tipo na mesma arquitetura que voc pretende usar no sistema final e que voc ser capaz de construir o sistema final a partir da evolu o do prot tipo 116 Se a principal rea de risco de seu projeto a interface do usu rio por contrate voc ir querer desenvolver um prot tipo de requisitos usando qualquer tecnologia que permita a voc desenvolver interfaces do usu rio muito rapidamente A Figura 15 1 ilustra uma rvore de decis o que voc pode usar para selecionar um tipo de prot tipo que fa a mais sentido para o seu projeto Vertical Dist ncia Estreita do risco E soja d Descart vel i strategia e G Investimento SR Vertical Evolucion rio Dist ncia Estreita igi do risco Requisitos a Larga Horizontal Risco de BRO N Vertical Dist ncia Estreita do risco gi Descart vel Te DOLORO Estrat gia de baigi investimento Horizontal i Es Vertical Evolucion rio Dist ncia streita do risco b Larga Horizontal Figura 15 1 rvore de decis o para sele o do tipo de prot tipo a prot tipos de requisitos b prot tipos atquiteturais Prot tipos de Requisitos Para prop sitos de elucida o de requisitos n s nos concentramos sobre os tipos de prot tipos sob
101. amente na natureza do software como um processo intelectual intang vel Para piorar ainda mais as coisas nossa equipe de desenvolvimento normalmente contribui com o problema deixando de fornecer precocemente o c digo produzido aos usu rios para que eles possam interagir e avaliar os resultados A rea o dos usu rios faz parte da natureza humana e ocorre em v rias outras circunst ncias do dia a dia Os usu rios que n o viram o seu sistema ou qualquer outro similar n o entender o o que voc pensou quando descreveu o sistema e agora que est o na frente do sistema agora pela primeira vez depois de meses ou anos de espera eles tem a oportunidade de interagir com o sistema Agora adivinhe o acontece O sistema n o exatamente o que eles esperavam que fosse Por analogia deixe nos comparar este processo de software com o desenvolvimento de dispositivos mec nicos cujas tecnologias e processos de desenvolvimento antecedem o software por uns meros cem anos Sistemas mec nicos possuem uma disciplina razoavelmente bem definida dos modelos de prova de conceitos moldes modelos prototipa o incremental dispositivos de produ o piloto entre outros todos eles possuindo aspectos tang veis e a maioria vis vel percept vel e atua como dispositivos que est sendo desenvolvido Os usu rios podem ver os dispositivos precocemente toc los pensar sobre eles ou mesmo interagir com eles antes mesmo dos detalhes de impl
102. ampo texto 5 Caracter sticas do Produto Esta se o do documento lista as caracter sticas do produto 5 1 Caracter stica 1 5 2 Caracter stica 2 6 Principais Use Cases Descreve alguns use cases principais talvez aqueles que s o arquiteturalmente significantes ou aqueles que ir o mais prontamente ajudar o leitor a entender como o sistema pretende ser usado 7 Outros Requisitos de Produtos 7 1 Padr es Aplic veis Lista todos os padr es que o produto deve cumprir 7 2 Requisitos do Sistema Definir quaisquer requisitos necess rios para sustentar a aplica o 7 3 Licenciamento e Instala o Descreva quaisquer requisitos de instala o que tamb m afete a codifica o ou que crie a necessidade para separar o software de instala o 7 4 Requisitos de Desempenho Use esta se o para detalhar os requisitos de desempenho 8 Requisitos de Documenta o Descreva as documenta es que devem ser desenvolvidas para sustentar a implanta o da aplica o com sucesso Figura 17 1 Modelo de documento da Vis o para um produto de software continua 136 8 1 Manual do Usu rio Descreva o prop sito e o conte do do manual do usu rio do produto 8 2 Help Online Requisitos do help online dicas de ferramentas entre outros 8 3 Guia de Instala o Configura o e Arquivos Leia me 8 4 Endere amento e Empacotamento 8 5 Gloss rio Figura 17 1 Modelo de documento da Vis o pa
103. aos Modelos de Sistemas Uma das vantagens desta abordagem de modelagem de neg cio a maneira clara e concisa de mostrar depend ncias entre modelos do neg cio e modelos do sistema Esta claridade eleva a produtividades do processo de desenvolvimento de software e tamb m ajuda a assegurar que o sistema que est sendo desenvolvido resolve as reais necessidades do neg cio Veja a figura 5 3 System Development Figura 5 3 Modelos de neg cio sistema A transi o entre os dois modelos pode ser resumida da seguinte forma Workers de neg cio ir o se tornar atores do sistema que n s desenvolvemos ou um elemento do pr prio sistema Por exemplo caixa de um banco e caixa eletr nico de um banco Comportamentos descritos para os workers de neg cio s o coisas que podem ser automatizados de tal forma que eles ir o ajudar a encontrar os use cases de sistema e definir as funcionalidades necess rias Entidades de neg cio s o coisas que queremos que o sistema nos ajude a manter Assim eles podem ajudar a encontrar classes entidades do modelo de an lise do sistema Ao realizar a transi o a modelagem de neg cio facilita o processo de ir do entendimento do neg cio e do problema dentro do neg cio para potenciais aplica es que podem ser implementadas para gerar as solu es do problema identificado Quando Usar a Modelagem de Neg cio A modelagem de neg cio n o algo que recomendamos para todos os projetos de
104. aplica o de software O modelo para esta entrevista fornecido na Figura 9 1 A entrevista consiste tanto de se es livres de contexto quanto de se es n o livres de contexto Tamb m fornece quest es designadas para nos assegurar que todos os aspectos dos requisitos incluindo alguns daqueles requisitos te enganei de seguran a suportabilidade entre outros tenham sido perfeitamente explorados 14 Parte I Estabelecendo o Perfil do Cliente ou Usu rio Nome Empresa Ind stria Ocupa o As informa es acima podem normalmente ser preenchidas antecipadamente Quais s o as suas responsabilidades Quais s o os produtos do seu trabalho Para quem voc gera esses produtos Como medido o seu sucesso Quais s o os problemas que interferem para o sucesso de seu trabalho O que se existe facilita ou dificulta o seu trabalho Parte II Avaliando o Problema Para quais problemas faltam boas solu es tipo de aplica o Quais s o Dica Continue perguntando Mais algum Para cada problema pergunte e Por que esse problema existe e Agora como resolv lo e Como voc poderia resolv lo Parte III Entendendo o Ambiente do Usu rio Quem s o os usu rios Qual a sua forma o Qual a sua experi ncia em computa o Os usu rios s o experientes nesse tipo de aplica o Quais plataformas s o usadas Quais s o os planos para a futura plataforma Outras aplic
105. ar com os moradores das casas vizinhas antes de podar algumas rvores sob a propriedade onde a casa ser constru da Os agentes fiscais da constru o civil e das leis de zoneamento bem como os vizinhos est o entre os stakeholders que junto com a pessoa que pretende pagar pela casa e morar ir o determinar se a casa ap s sua constru o atender ao conjunto total de requisitos claro tamb m que muitos stakeholders tais como vizinhos e agentes fiscais n o ser o os moradores dessa casa ou usu rios do sistema e parece igualmente bvio que as perspectivas desses stakeholders sobre o que uma casa ou sistema de qualidade pode variar bastante Vale ressaltar que estamos discutindo aplica es de software neste volume n o sobre casas e pedras Os requisitos de uma casa podem ser descritos ao menos em parte por um conjunto de desenhos e projetos de engenharia da mesma forma um sistema de software pode ser descrito com diagramas e modelos Mas apenas os desenhos da casa s o usados como mecanismo de comunica o e negocia o entre pessoas leigas advogados agentes fiscais e vizinhos abelhudos e engenheiros 9 Assim diagramas t cnicos associados ao sistema de software tamb m podem ser criados com o objetivo de permitir que qualquer pessoa possa entend los Muitos requisitos cruciais e importantes n o necessitam de quaisquer diagramas por exemplo potenciais compradores da casa podem escrever req
106. ar uma cota ating vel para a sua equipe de venda ou negociar recursos adicionais para o seu projeto No interesse do seu projeto e dos objetivos de neg cio do cliente voc pode precisar negociar o compromisso de escopo para a sua equipe A equipe deve tamb m ter em mente que em muitos casos que o cliente j pode ter desenvolvido a habilidade de negocia o e ir naturalmente us la durante as discuss es com voc e sua equipe Assim se voc um l der de equipe gerente de projeto ou campe o de projeto voc deve desenvolver muito bem essas habilidades A negocia o uma atividade de neg cio profissional N o um processo particularmente dificil e pode ser realizado com integridade gra a e estilo Aproveite a oportunidade para ter algum treinamento nesse processo seu departamento de recursos humanos provavelmente pode ajud lo ou voc pode querer participar de um semin rio externo Se 1sso falhar voc deve ao menos se familiarizar com algumas regras do jogo Por exemplo uma boa revis o do processo de negocia o pode ser encontrada em Fisher Ury e Patton s 1983 Getting to Yes o qual pode ser lido em poucas horas Eles recomendam que pequeno guia para a sess o de negocia o e Comece otimista sem ser irracional e Separe as pessoas do problema e Concentre se nos interesses n o nas posi es e Entenda e mantenha sua posi o e Invente op es para ganho m tuo e Aplique crit rios objetivos
107. aracter stica 8 Integrar com o subsistema de gerenciamento til Alto de vers es Adicionando o Elemento Risco Um outro aspecto do gerenciamento de escopo a estimativa do risco associado a cada caracter stica Neste contexto iremos considerar o risco como sendo a probabilidade de que a implementa o de uma caracter stica provocar impacto imprevis vel no cronograma e no or amento O risco nos d uma medida relativa do potencial impacto de incluir uma particular caracter stica dentro do baseline de projeto Uma caracter stica de risco alto tem potencial para gerar impacto negativo no projeto mesmo se todas as outras caracter sticas possam ser realizadas dentro do tempo designado A equipe de desenvolvimento estabelece o risco com base em alguma heur stica conveniente usando a mesma escala baixo m dio alto usada para avaliar o esfor o A Tabela 20 3 ilustra a lista de caracter sticas revisada de nosso exemplo Tabela 20 3 Lista de caracter sticas com adi o do risco Caracter stica Prioridade Esfor o Risco Caracter stica 1 Suporte a BD relacional externo Cr tica M dio Baixo Caracter stica 4 Interface para releases de novos SO Cr tica Alto M dio Caracter stica 6 Importa o de dados externos por estilo Cr tica Baixo Alto Caracter stica 3 Habilidade de clonar um projeto Importante Alto M dio Caracter stica 2 Seguran a multiusu rio Importante Baixo Alto Caracter stica 5 Assistente de novos projet
108. are cada um dos quais compartilham algumas funcionalidades mas que podem precisar compartilhar dados ou de algum jeito se comunicar com um outro quando em uso Em tais casos voc pode considerar a seguinte abordagem Desenvolver um documento da Vis o da fam lia de produtos que descreva a maneira como os produtos pretendem trabalhar em conjunto e outras caracter sticas que podem ser compartilhadas Para entender melhor o modelo de uso compartilhado voc pode tamb m desenvolver um conjunto de use cases mostrando como os usu rios ir o se interagir com as v rias aplica es executando em conjunto Desenvolver uma especifica o dos requisitos de software comuns que defina os requisitos espec ficos para funcionalidades compartilhadas tais como estruturas de menu e protocolos de comunica o Para cada produto da fam lia desenvolver um documento da Vis o a especifica o dos requisitos de software e um modelo use case que defina as funcionalidades espec ficas A organiza o resultante mostrada na Figura 16 4 N Vis o Documento da Vis o da Co fam lia de produtos E a o o Requisitos de Modelo use case software comuns comuns fam lia Figura 16 4 Organiza o dos requisitos para uma fam lia de produtos de software 129 As especifica es dos requisitos para cada membro individual pode conter refer ncias links ou traced from para o documento da familia de produtos ou pode re
109. artamentos pessoas e processos o dom nio consiste de conectores fontes de energia racks de equipamentos componentes eletr nicos e el tricos perif ricos de controle de fluidos outros sistemas de software subsistemas mec nicos e pticos entre outros Aqui a modelagem de neg cio n o pode ajudar muito Ao inv s disso devemos adotar uma estrat gia diferente para responder o por que e onde a aplica o deve existir O que Engenharia de Sistemas De acordo com o conselho internacional de engenharia de sistemas INCOSE International Council on Engineering Systems 1999 A engenharia de sistemas uma abordagem interdisciplinar e pretende viabilizar a realiza o de sistemas de sucesso O foco est em definir as TE E Envia y A PR Dna a E o processo de derivar e alocar requisitos a todos os n veis da decomposi o sist mica 44 necessidades dos clientes e funcionalidades solicitadas no in cio do ciclo de desenvolvimento documentando requisitos e ent o procedendo com a sintese do projeto e valida o do sistema considerando como um todo o problema de Opera o Desempenho Teste Manufatura Custo e Cronograma Treinamento e suporte Disponibiliza o A engenharia de sistemas integra todas as disciplinas e grupos de especialidades dentro de um esfor o de equipe formando assim um processo de desenvolvimento estruturado que progride do conceito para a produ o e chegando na sua oper
110. as poder influenciar a prioriza o realizada pelo cliente e o resultado do processo poder ficar comprometido a ponto de n o atender as reais necessidades do cliente Existir oportunidade para que as quest es t cnicas sejam consideradas ap s o processo de prioriza o No nosso exemplo de projeto assumimos que foi realizada uma vota o para a prioriza o das caracter sticas usando uma escala critica rmportante til os resultados deste exerc cio est o apresentados na Tabela 20 1 155 Tabela 20 1 Caracter sticas priorizadas Caracter stica Prioridade Caracter stica 1 Suporte a BD relacional externo Cr tica Caracter stica 4 Interface para releases de novos SO Cr tica Caracter stica 6 Importa o de dados externos por estilo Cr tica Caracter stica 3 Habilidade de clonar um projeto Importante Caracter stica 2 Seguran a multiusu rio Importante Caracter stica 5 Assistente de novos projetos Importante Caracter stica 7 Implementar ferramenta de dicas til Caracter stica 8 Integrar com o subsistema de gerenciamento de vers es Util Avaliando o Esfor o A prioriza o apenas uma pe a do quebra cabe a do escopo Afinal de contas se pud ssemos implementar todas as caracter sticas de uma s vez n o seria necess ria a prioriza o No entanto independentemente de termos ou n o o potencial de implementar o conjunto de caracter sticas de uma s vez a verdade que ainda n o temos nem como i
111. atolar em detalhes No entanto existe uma interrup o no processo desta discuss o qual seja Se a equipe abandonar a discuss o sem um entendimento das reais necessidades por detr s das caracter sticas ent o haver um real risco Se as caracter sticas n o resolverem as reais necessidades por alguma raz o ent o o sistema poder falhar em atender os objetivos dos usu rios mesmo que a implementa o tenha sido derivada das caracter sticas que foram exigidas Em qualquer caso n s encontramos esta abstra o de alto n vel essas caracter sticas s o formas teis e convenientes de descrever funcionalidades de um novo sistema sem se atolar em detalhes De fato n s dirigimos a maior parte de nossas atividades de requisitos a partir desta id ia de caracter stica No come o definimos uma caracter stica como um Servi o que o sistema fornece para atender um ou mais necessidades dos stakeholders Com esta defini o caracter sticas de usu rios n o podem estar t o longe das necessidades e temos uma maneira c moda de iniciar a defini o do sistema Nosso foco est em entender as necessidades dos usu rios a fim de elucidar e organizar as necessidades e caracteristicas do sistema proposto Algumas vezes obtermos todas as necessidades e nenhuma caracter stica Algumas vezes obtemos todas as caracter sticas e nenhuma necessidade Algumas vezes n s n o somos capazes de perceber a separa o Mas desde que t
112. avelmente j ter uma boa id ia sobre as caracter sticas do novo produto Afinal de contas poucos projetos come am com passado totalmente limpo Dessa forma al m de revisar as caracter sticas sugeridas do produto o workshop fornece a oportunidade de solicitar novas informa es mudar e combinar essas novas caracter sticas com aquelas que j estavam sob considera o Este processo ir nos ajudar na nossa meta de encontrar as ru nas desconhecidas e atrav s disso assegurar a integridade das informa es e que todas as necessidades dos stakeholders foram cobertas Tipicamente uma parte do workshop dedicada ao brainstorming de novas id ias e caracter sticas da aplica o O Brainstorming uma cole o de t cnicas que s o teis quando os stakeholders est o lado a lado Esta t cnica de elucida o tem como benef cios principais Encorajar a participa o de todas as partes presentes Permitir que os participantes engatem uma id ia com a outra Registro de todas as coisas discutidas pelo facilitador ou secret rio assim nada perdido Alta quantidade de informa es Normalmente gera um grande conjunto de poss veis solu es para qualquer que seja o problema proposto Encoraja o pensamento out of the box isto sem as limita es das restri es normais O brainstorming tem duas fases gera o de id ias e redu o de id ias O objetivo principal durante a gera
113. bela 7 1 A sindrome Usu rio e o Desenvolvedor Problema Usu rios n o sabem o que querem ou sabem o que querem mas n o sabem dizer Usu rios pensam que sabem o que querem at que os desenvolvedores lhes digam o que eles disseram que queriam Analistas pensam que entenderam o problema do usu rio melhor do que os pr prios usu rios Todos acreditam que todos est o politicamente motivados Solu o Reconhecer e apreciar o usu rio como especialista do dom nio tentar t cnicas alternativas de comunica o e elucida o Fornecer t cnicas de elucida o alternativas o quanto antes storyboarding role playing prot tipos descart veis entre outros Coloque o analista no lugar do usu rio Fa a com que o analista interprete o papel do usu rio durante uma hora ou um dia Sim faz parte da natureza humana ent o vamos continuar com o programa T cnicas de Elucida o de Requisitos Alcan ar melhor entendimento das necessidades do usu rio leva nos do dom nio de bits e bytes onde muitos desenvolvedores est o mais confort veis para o dominio das pessoas reais e problemas do mundo real Da mesma forma que v rias t cnicas podem ser usadas para analisar e projetar solu es de software v rias t cnicas podem ser usadas para entender necessidades de usu rios e stakeholders Algumas t cnicas s o seguidas por equipes de projeto em circunst ncias particulares Nos Cap tulos 4 5 e 6 n
114. belecida para o projeto A CCM foi constitu da de tr s executivos seniores cada um com a responsabilidade numa rea funcional Inicialmente Tracy facilitou o processo de tomada de decis o da CCM estabelecendo prioridades relativas para as releases iniciais Desde ent o a CCM e somente a CCM tem a autoridade de adicionar ou remover caracter sticas com recomenda es realizadas pela campe do produto Desta maneira existe apenas uma campe Tracy e os resultados da elucida o e a vis o do projeto existem em sua cabe a e no Documento da Vis o mas a responsabilidade de tomar as decis es dificeis foi delegada CCM A campe tinha apenas que ver que as caracter sticas acordadas tinham sido apropriadamente elaboradas e comunicadas equipe de desenvolvimento Desde que Tracy foi delegada para dirigir o processo em conjunto com a CCM a qual inclu a membros da ger ncia s nior obtendo respaldo necess rio para tomar decis es o projeto alcan ou seu sucesso e foi usado como um modelo organizacional para novos projetos Alocou se um novo campe o para cada novo projeto Isso criava a oportunidade para que as pessoas pudessem crescer e se desenvolverem individualmente O papel de campe o do produto tornou se muito importante dentro da empresa N o podemos nos esquecer naturalmente da CCM Para cada novo projeto estabelecia se uma nova CCM com base nos temas de cada nova release e na organiza o que poderia ser mais afetad
115. bsistema A B Figura 6 2 Um sistema composto por dois subsistemas Este processo de decomposi o ou refinamento sucessivo prossegue at que o engenheiro de sistemas atinja os resultados corretos de acordo com as medidas quantitativas espec ficas do dom nio da engenharia de sistemas E muitos casos os subsistemas definidos na composi o inicial s o por sua vez decompostos em outros subsistemas como ilustra a Figura 6 3 46 Sistema Subsistema A Subsistema Subsistema Subsistema B A l A 2 Figura 6 3 Um subsistema composto por dois subsistemas Em muitos sistemas complexos esse processo continua at que um grande n mero de subsistemas tenha sido desenvolvido Dizem que a aeronave F22 por exemplo composta de 152 subsistemas O engenheiro de sistemas descobre que o trabalho realizado est correto quando distribui o e particionamento das funcionalidades estiverem otimizadas para atingir a funcionalidade global do sistema com o m nimo de custo e m xima flexibilidade Cada subsistema puder ser definido projetado e constru do por uma equipe de tamanho pequeno ou ao menos modesto Cada subsistema puder ser manufaturado dentro das restri es f sicas e tecnol gicas do processo de manufatura dispon vel Cada subsistema puder ser seguramente testado como um subsistema com disponibilidade de acess rios e pe as apropriadas que simulem as interfaces com outros sistemas Considera
116. ca es de sistemas embutidos ou simplesmente de aplica es embutidas A natureza das aplica es desenvolvidas nestes tr s tipos de sistemas extremamente adversa Elas podem consistir de 5 000 000 linhas de programas COBOL executados num mainframe e desenvolvidos ao longo de muitos anos por 50 a 100 indiv duos Elas podem consistir de 10 000 linhas de c digo em Java executados sobre uma aplica o cliente Web e escrita em apenas um ano por uma equipe de uma a duas pessoas Ou elas podem consistir de 1 000 000 de linhas de c digo C de tempo extremamente cr tico e executada sobre um sistema de telefonia complexo de tempo real Pode se afirmar que as t cnicas de Gerenciamento de Requisitos apresentadas neste volume podem ser aplicadas em qualquer um desses tr s tipos de sistemas Muitas dessas t cnicas s o independentes do tipo de aplica o outros podem necessitar de um refinamento para que possam ser aplicadas no contexto espec fico da aplica o Para elevar o entendimento pelo leitor ser o fornecidos exemplos para ilustrar a aplica o dessas diversas t cnicas Aplica es de Sistemas O Gerenciamento de Requisitos pode tamb m ser aplicado no desenvolvimento de quaisquer outros tipos de sistemas V rias t cnicas apresentadas neste volume podem ser teis no gerenciamento de requisitos de sistemas arbitrariamente complexos contendo subsistemas mec nicos subsistemas computacionais subsistemas qu micos e pe
117. campe o em tal ambiente Talvez n s possamos novamente aprender com um exemplo Numa empresa um novo sistema de apoio empresarial foi desenvolvido para prover acesso global 24 horas do dia aos clientes registrados para suporte a vendas e gerenciamento de licen as O exerc cio de an lise do problema identificou os seguintes stakeholders marketing corporativo televendas licenciamento e suporte marketing de unidade de neg cio ger ncia financeira da unidade de neg cio execu o de pedidos e garantia Cada um destes departamentos tinha fortes necessidades mesmo assim estava claro que nem todas as necessidades poderiam ser atendidas A quest o Quem o dono do documento da Vis o apresenta se como uma met fora para a quest o Quem gostaria de fazer uma grande mudan a em sua carreira limitada tentando gerenciar este projeto Na an lise ficou claro que nenhuma das lideran as da equipe de desenvolvimento tinha autoridade para fazer tais decis es mas ainda necess rio um campe o Neste caso a equipe decidiu chamar Tracy a l der de projeto atual como a campe do produto dando lhe autoridade para produzir e organizar os requisitos Ela se apropriou do documento da Vis o Ela entrevistou os usu rios estabeleceu suas prioridades relativas e coletou dados num formato orientado a caracteristica Mas um comit diretor especial ou comiss o de controle de mudan as CCM de projeto fora tamb m imediatamente esta
118. cas baseadas sobre um entendimento inadequado do problema a ser resolvido Como esperado o sistema resultante n o atende as necessidades dos usu rios e stakeholders Entre as consequ ncias desse insucesso est o o baixo retorno financeiro de clientes e desenvolvedores do sistema usu rios insatisfeitos e problemas constantes Assim parece bvio que um investimento incremental na an lise do problema ir produzir resultados gratificantes O objetivo desta habilidade de equipe fornecer um guia para a an lise do problema definindo metas para esta habilidade no desenvolvimento da aplica o Nos cap tulos seguintes iremos explorar maneiras e meios de definir exatamente o que um problema Afinal se sua equipe n o puder definir o problema ser dif cil encontrar uma solu o apropriada 24 Cap tulo 4 Os Cinco Passos da An lise do Problema Pontos chaves e A an lise de problemas o processo de entender problemas do mundo real entender as necessidades dos usu rios e propor solu es que satisfa am tais necessidades e O objetivo da an lise do problema adquirir maior entendimento do problema a ser resolvido antes que se inicie o desenvolvimento e Para identificar a causa raiz do problema ou o problema por detr s do problema pergunte s pessoas diretamente envolvidas e Identificar os atores envolvidos no sistema o principal passo da an lise do problema ste cap tulo descreve as maneiras em
119. ce coisa certa a fazer Mas mesmo Normalmente n o informa es da qualidade mostram com freq ncia que muitas causas ra zes n o valem a pena serem corrigidas quando o custo de corrigir excede o custo do problema Ent o como vou saber quais causas ra zes devo corrigir Resposta Voc deve determinar a import ncia ou a contribui o de cada causa raiz Os resultados dessa investiga o podem ser colocados num gr fico como o de Pareto ou num simples histograma que exponha visualmente os verdadeiros culpados De volta ao nosso exemplo Suponha que os resultados dos dados obtidos tenham produzido o gr fico da Figura 4 2 Como voc pode ver a equipe descobriu que uma nica causa raiz pedidos errados produziu a metade de todos os desperd cios Se por sua vez o sistema de pedidos existente for um exemplo de um c digo legado ruim associado a uma interface de usu rio cheia de v cios e n o houver tratamento de erros online esta pode ser a oportunidade de reduzir o desperd cio atrav s do desenvolvimento de um novo sistema neste ponto e somente neste ponto que a equipe ir conseguir justificar o prop sito de trocar o sistema de entrada de pedidos existentes Al m disso a justificativa de custo desse novo sistema pode ser quantificada determinando o custo do desenvolvimento e o retorno deste investimento atrav s da redu o do desperd cio DB pedidos errados E danos no transporte
120. cendo perfeitamente que outros itens tais como Execu o r pida e Facilidade de uso fazem o corte para o topo da lista pode gastar todo o seu dinheiro sobre Executar na plataforma Mac e elev la para uma prioridade maior Por outro lado voc pode desejar a permiss o de um limite elevado contanto que voc queira saber onde estar o os grandes votos Eles podem representar necessidades de alta prioridade de uma comunidade restrita de stakeholders A Categoriza o Cr tica Importante e til Um colega nos ensinou uma outra t cnica que tamb m bastante efetiva especialmente com um pequeno grupo de stakeholders ou mesmo com apenas um stakeholder tal como quando voc precisar da opini o do seu chefe de suas prioridades Nesta t cnica dado a cada participante um n mero de votos igual ao n mero de id ias mas cada voto deve ser categorizado como cr tico importante ou til O truque nesta t cnica a regra de que cada stakeholder d apenas um dos tr s votos de cada categoria assim apenas um ter o das id ias podem ser consideradas cr ticas Cr tico significa indispens vel sugerindo que um stakeholder n o poderia estar apto a usar um sistema sem esta caracter stica Sem a caracter stica o sistema n o cumpriria a sua miss o principal seu papel e assim digno de liberar Importante significa que seria uma significativa perda de utilidade para o segmento de
121. cio e modelo de objetos de negocio Um odelo use case de neg cio um modelo das funcionalidades pretendidas do neg cio e usado como uma das fontes essenciais para identificar pap is e produtos da organiza o Como tal o modelo use case de neg cio consiste de atores de neg cio usu rios e sistemas que interagem com o neg cio e os use cases de neg cio sequ ncia de eventos pelos quais os atores de neg cio interagem com os elementos de neg cio para realizar seu trabalho Juntos atores de neg cio e use cases de neg cio descrevem quem est envolvido nas atividades de neg cio e como essas atividades ocorrem A Figura 5 1 ilustra o modelo use case de neg cio Note que os cones possuem uma barra indicando que o ator e o use case s o de neg cio ao inv s de serem de sistema Figura 5 1 Modelo use case de neg cio 40 Um modelo use case de neg cio ent o consiste de atores de neg cio e use case de neg cio com atores de neg cio representando pap is externos ao neg cio por exemplo clientes e fornecedores e use cases de neg cio representando processos Abaixo est o alguns exemplos de use cases de neg cio Tiberar pagamento de empregados E Negociar os termos do contrato com o cliente Exemplos de atores de neg cio Cliente Fornecedor Secretaria dos Neg cios da Fazenda do Estado O modelo de objetos de neg cio descreve as entidades departam
122. codificados Dica Se a aplica o ser implementada em Java escreva o storyboard em VB Sempre que possivel fa a o storyboard interativo A experi ncia do cliente ao usar a aplica o ir gerar maior feedback e permitir descobrir mais requisitos novos do que o storyboard passivo Sum rio Neste cap tulo n s aprendemos sobre uma t cnica muito simples e barata para elucidar requisitos De ser forma um storyboard qualquer coisa que voc pode construir rapidamente e economicamente que elucide uma rea o Sim mas do usu rio N s podemos afirmar com certeza que nunca deixamos de aprender alguma coisa com o storyboard e nunca houve um caso em que n s tenhamos sa do de um storyboard com exatamente o mesmo conhecimento que tinhamos antes de entrarmos Assim nosso aviso para a equipe de desenvolvimento Storyboard no In cio Storyboard com frequ ncia Storyboard em todos os projetos que possuam conte dos novos e inovadores Ao fazer isso voc Ir ouvir o quanto antes o Sim mas o qual ir lhe ajudar a construir sistemas que melhor atenda as necessidades dos usu rios reais E talvez voc ir rapidamente e economicamente ver seu trabalho realizado Uma Est ria de Storyboarding Alguns fatos foram alterados para proteger inocentes e culpados desta quase verdadeira est ria A est ria ocorreu durante o desenvolvimento de um perif rico eletromec nico complexo para um hospital far
123. da caracter stica funciona Al m disso uma vez que existem certas interdepend ncias dentro de cada caracter stica no caso mais t pico nada funciona direito quando o prazo final estiver vencido O prazo final est comprometido dramaticamente Todos os compromissos ser o atrasados um novo prazo final programado e uma nova marcha para a morte recome a No pior caso toda a equipe demitida ap s realizarem v rias horas extras durante meses a fio na fase final desta primeira tentativa declarada a fase chamada promo o dos que n o participaram e um novo gerente adicionado ao projeto O que acontece com a qualidade do software durante uma destas situa es O c digo que foi finalizado s pressas pr ximo ao final tem um projeto pobre e possuem erros grosseiros testes foram reduzidos ao minimo ou foram totalmente descartados e as documenta es e sistemas de ajuda foram eliminados Clientes realizam tanto os testes funcionais quanto os de garantia de qualidade Em pouco tempo os clientes reagem ao seu extraordin rio esfor o da seguinte forma 152 Embora tenhamos ficado inicialmente desapontados com o seu atraso ou com as poucas coisas funcionando comparado s nossas expectativas agora n s estamos realmente insatisfeitos porque descobrimos que voc nos entregou um lixo A Dif cil Quest o Claramente para que a equipe de projeto tenha alguma esperan a de sucesso o escopo deve ser ger
124. da da Habilidade de Equipe 1 alertamos para o fato de que os pedidos de venda imprecisos era o principal condutor para o alto custo de desperd cios e atrav s disso criar vantagens do problema Quando n s olhamos para o processo de pedidos de venda n s esperamos encontrar uma s rie de passos diferentes e fontes de erros Existem ao menos duas maneiras de descobrir as raizes causas 1 Use a t cnica da espinha de peixe que descrevemos junto com a entrevista de usu rios e analise os pedidos de venda que reconhecidamente possuem erros Quantifique os erros por tipos e ataque os mais graves no projeto de um novo sistema Isso pode fornecer um entendimento quantitativo para o problema e provavelmente ser bastante efetivo No entanto isso n o lhe d a impress o qualitativa do problema aquela que possa talvez mudar tanto a percep o quanto a sua estrat gia de solu o A fim de conseguir isso talvez exista uma maneira mais eficiente para verdadeiramente entender o problema 2 O desenvolvedor analista pode experimentar os problemas e imprecis es intr nsecas ao sistema de entrada de pedidos existente apenas sentando se e entrando com alguns pedidos de venda A experi ncia obtida em 1 hora ir mudar para sempre o entendimento da equipe sobre o problema N s podemos dizer que as experi ncias obtidas no role playing podem ficar com os desenvolvedores pelo o resto da vida Nossa vis o pessoal do mundo foi mudando de acor
125. dade a quaisquer itens de a o em aberto que foram registradas na reuni o e organiz los para distribuir aos participantes Normalmente as informa es da reuni o apresentam se como uma lista de id ias ou caracteristicas sugeridas para produto que podem modificar imediatamente as futuras a es da equipe de desenvolvimento Em alguns casos workshops adicionais com outros stakeholders ser o programados ou esfor os adicionais de elucida o ser o necess rios para ganhar melhor entendimento das id ias estimuladas no workshop A cria o dessas id ias o centro de todo o processo do workshop No pr ximo cap tulo veremos mais de perto esta parte do processo 88 Cap tulo 11 Brainstorming e a Redu o de Id ias Pontos chaves e O brainstorming trata tanto da gera o de id ias quanto da redu o de id ias e As id ias mais criativas e inovadoras normalmente resultam da combina o m ltipla aparentemente de id ias desassociadas e V rias t cnicas de vota o podem ser usadas para priorizar as id ias criadas e Embora seja prefer vel o brainstorming presencial o brainstorming baseado em web pode ser uma alternativa vi vel em algumas situa es e voc est configurando um workshop como vimos no Cap tulo 10 ou se voc procura por novas id ias ou solu es criativas para problemas o brainstorming uma t cnica muito til E simples f cil e divertido Na configura o do workshop voc prov
126. das necessidades por novas funcionalidades deve ser Os requisitos bem conhecidos e bem entendidos n o precisam ser prototipados a menos que sejam necess rios para ajudar a visualizar o contexto de outras necessidades de usu rios constru los ir consumir os j parcos recursos Superabund ncia qualquer que produz efeito nocivo 118 existentes e como j est o bem compreendidos aprenderemos muito pouco com eles Os requisitos desconhecidos no entanto s o as Ru nas Desconhecidas que n s desejamos conhecer Infelizmente n s n o podemos realmente prototip los se pud ssemos n o seria desconhecido Assim sobra como alvo de prototipa o as partes Confusas que est o no meio Esses requisitos podem ser conhecidos ou impl citos mas sua defini o e entendimento s o pobres Construindo o Prot tipo A escolha da tecnologia usada para constru o do prot tipo depende das decis es tomadas considerando a rvore de decis o da Figura 15 1 Por exemplo a escolha por um prot tipo descart vel da GUI nos leva a escolher qualquer tecnologia que seja barata e r pida para implementar exemplos de GUIs Se um prot tipo evolucion rio for selecionado voc deve escolher a linguagem e o ambiente de desenvolvimento que ser utilizado para produzir a implementa o final Voc tamb m ter que fazer esfor os significativos para projetar a arquitetura de software do sistema bem como aplicar quaisquer padr e
127. de ter for ado o uso do Visual Basic para todas as aplica es que ser o desenvolvidas Para assegurar a conformidade e prevenir que esta pol tica n o seja ignorada gerentes insistem em colocar Visual Basic sempre que poss vel nos documentos de requisitos Se um desenvolvedor t cnico decidiu inserir uma refer ncia ao Visual Basic devido a uma prefer ncia arbitr ria por esta linguagem bvio que essa refer ncia n o ocupa um local legitimo na lista de requisitos Se o usu rio forneceu o requisito a coisa come a a ficar um pouco mais dificil Se o cliente se recusar a pagar pelo sistema amenos que seja escrito em Visual Basic o melhor a fazer trat lo como um requisito mas um requisito de uma classe especial chamada restri es de projeto de tal forma a ficar separado dos requisitos normais No entanto uma restri o de implementa o que foi imposta equipe de desenvolvimento A prop sito se voc achar que esse exemplo n o real stico considere um requisito comum que o Departamento de Defesa Norte Americana impunha em seus contratos de software at o final dos anos 90 onde se exigia o uso da linguagem Ada na constru o de sistemas A discuss o sobre a refer ncia do Visual Basic neste exemplo pode ter obscurecido uma an lise de requisitos mais sutil e talvez a mais importante Por que a informa o de tend ncia tem que ser exibida num relat rio com um histograma Por que n o um gr fico de barras
128. de dados cores e fontes devem ser deixados para as fases posteriores A Figura 13 2 ilustra uma por o exemplo de uma especifica o use case Use Case Redistribui o dos Itens de Estoque O chefe do estoque d um comando para redistribui o do estoque A janela na Figura xxx apresentada ao chefe do estoque Os itens podem ser ordenados de v rias formas A ordem indicada com a sele o do menu Ordenar Ordem alfab tica Ordem por ndice Ordem de armazenamento Na tabela Lugar podemos optar em ver ou todos os Lugares do atual estoque ou se selecionado um item os lugares onde esse item existe Figura 13 2 Especifica o use case para a distribui o manual do estoque Caso de Estudos Os Use Cases do HOLIS Impressionado com o poder dos use cases a equipe de desenvolvimento do HOLIS decidiu usar esta t cnica para descrever a funcionalidade do sistema HOLIS em alto n vel A fim de fazer isso a equipe organizou uma sess o de brainstorming para definir os use cases significantes os quais ser o desenvolvidos mais tarde nas atividades posteriores Esta an lise do modelo use case identificou 20 use cases alguns dos quais s o os seguintes Nome Descri o Atores Criar Cena de Ilumina o Residentes criam uma cena de ilumina o Residente Personalizada personalizada L mpada Iniciar Emerg ncia Residentes iniciam a o de emerg ncia Resid ncia Controlar Ilumina o Residentes
129. de especifica o dos requisitos de software As seguintes se es descrevem o que fazer em cada um dos casos Alguns ou todos estes casos podem ser combinados por exemplo um documento pode conter o conjunto total de requisitos a partir do qual subconjuntos selecionados podem ser usados para gerar releases espec ficos bem como todos os requisitos de neg cio Organizando Requisitos de Sistemas Complexos de Hardware e Software Embora este volume tenha como principal foco os requisitos de software importante reconhecer que eles s o apenas um subconjunto do processo de gerenciamento de requisitos na maioria dos esfor os de desenvolvimento de sistemas Como descrevemos no Cap tulo 6 alguns sistemas s o t o complexos que a nica forma de visualiz los e constru los como um sistema de subsistemas os quais por sua vez s o visualizados como sistemas de subsistemas e assim por diante como ilustra a Figura 16 1 Num caso extremo tal como uma 126 aeronave de transportes o sistema pode ser composto de centenas de subsistemas que por sua vez possuem componentes de hardware e software Subsistema A 1 Subsistema A 2 Figura 16 1 Um sistema de sistemas Nesses casos criada uma especifica o de requisitos ao n vel sist mico que descreve o comportamento externo do sistema tais como capacidade de combust vel velocidade de decolagem ou altitude m xima sem conhecer ou referenciar qualquer de seus subsistemas Como d
130. de informa es interface por contrato mensagens ao inv s de compartilhamento de dados em seu trabalho de engenharia de sistemas Se poss vel desenvolva o software como um todo n o como um monte de pe as individuais um para cada subsistema f sico Uma das caracter sticas do sistema de chamin s que em ambos os lados da interface bem ou mau definidas o software precisa reconstruir o estado dos elementos chaves objetos que s o necess rios para tomar decis es em ambos os lados diferentemente do hardware cuja aloca o dos requisitos em ambos os lados n o representa uma divis o clara Quando codificar interfaces use c digos comuns em ambos os lados da interface Caso contr rio surgir o varia es sutis frequentemente provocados pelas otimiza es isso far com que a sincroniza o de estados torne se muito dif cil Assim se a fronteira entre os dois subsistemas f sicos posteriormente desaparecerem isto se a engenharia de sistemas achar que os processadores s o suficientes para suportar ambos os subsistemas e B o engenheiro de software ir ter um momento dif cil para consolidar as duas pe as de software se forem diferentes claro Definir especifica es de interface que possam fazer mais do que o necess rio ou seja mais do que simplesmente atender as condi es conhecidas Investir numa largura de banda um pouco maior portas de entrada sa da extras ou adicionar
131. dido nos pap is falta de informa o dispon vel sobre um ator ou subsistema ou falta de um comportamento espec fico necess rio para que atores possam ter sucesso em seus esfor os Por exemplo certa vez n s constru mos um roteiro de acompanhamento que mostrava como o professor e estudantes deviam interagir com um dispositivo autom tico de prova pontua o usado na sala de aula N s usamos um prot tipo do dispositivo e tinhamos membros da equipe e representantes do cliente interpretando os pap is de alunos e de professor O roteiro de acompanhamento continha muitas cenas tais como pontua o dos estudantes em suas provas e professor pontuando um grande lote de provas durante a aula O roteiro de acompanhamento foi muito til para perceber o ambiente de uma sala de aula e a equipe aprendeu algumas coisas novas durante a experi ncia Foi muito divertido Uma das vantagens do roteiro de acompanhamento que o roteiro pode ser modificado e reexecutado quantas vezes forem necess rias at que os atores fa am direito O roteiro pode tamb m ser reusado para educar novos membros da equipe Ele pode ser modificado e reusado quando o comportamento do sistema for alterado Assim o roteiro se transforma num storyboard vivo do projeto Cart es CRC Classe Responsabilidade Colabora o Um derivado do role playing frequentemente aplicado como parte de um esfor o de an lise orientado a objetos Neste caso especial de role
132. do com tais experi ncias incluindo os simples pap is de soldar uma pe a complexa da maneira que se sup em que os rob s fa am misturar compostos farmac uticos num depurador de fluxo laminar identificar uma televis o comercial com apenas quatro resumos de tela e uma trilha de udio usar ferramentas de software para gerenciamento de requisitos imaturos entre muitos outros N s aprendemos sempre alguma coisa e desenvolvemos uma grande empatia com os usu rios com os quais estivemos 113 T cnicas Similares ao Role Playing Um roteiro de acompanhamento um jogo no papel Naturalmente o role playing n o funcionam em todas as situa es Em muitos casos o papel do usu rio m nimo e o problema a ser resolvido algoritmicamente ao inv s de funcionalmente intenso E em muitos casos simplesmente n o pr tica N s n o gostar amos de ser o primeiro volunt rio para fazer o papel de paciente num cen rio de cirurgia auxiliada por equipamentos eletr nicos ou de operador de uma f brica nuclear no per odo noturno ou piloto de um 747 Em muitos casos outras t cnicas nos aproximam das experi ncias de usu rios sem ter que sangrar pelos lados Roteiro de Acompanhamento Num roteiro de acompanhamento scripted walkthrough cada participante segue um roteiro que define um papel espec fico dentro do jogo O acompanhamento ir demonstrar qualquer mal enten
133. do documento mas deixando claramente identificados aqueles requisitos que est o planejados para o atual release Requisitos de Neg cio e de Marketing versus Requisitos de Produto O planejamento de um novo produto n o ocorre num mundo t cnico desprovido de considera es de neg cio Devem ser feitas considera es sobre oportunidades de mercado mercado alvo empacotamento do produto canais de distribui o funcionalidades custo de marketing disponibilidade de recursos margens amortiza o sobre um grande n mero de c pias vendidas entre outras Tais considera es devem ser documentadas mas elas n o pertencem as especifica es de requisitos Algumas organiza es usam um documento dos requisitos de mercado DRM para facilitar a comunica o entre o pessoal de gerenciamento marketing e desenvolvedores e para auxiliar nas decis es de neg cio sobre intelig ncia de mercado incluindo todas as decis es importantes de vamos ou n o vamos em frente O DRM tamb m fornece aos clientes e desenvolvedores uma r pida verifica o da comunica o para adiantar o entendimento do produto em seus termos mais gerais e estabelecer o escopo geral do produto O DRM deve responder as seguintes quest es gt A diferen a entre o valor da mercadoria produzida por um assalariado e o sal rio que lhe pago lucro em longo prazo que n o visto de imediato 130 Quem o cliente Quem s o os usu rios Qual
134. documento e voc n o ter que preench lo O documento da Vis o deve conter ao menos os seguintes itens veja a Figura 17 2 Informa es gerais e introdut rias Uma descri o dos usu rios do sistema mercado alvo e caracter sticas pretendidas na vers o 1 0 Outros requisitos tais como de regula o e ambiental Caracter sticas futuras que tenham sido elucidadas mas que n o ser o incorporadas no release 1 0 137 N Vis o Documento da Vis o v2 0 N Introdu o Vis o Usu rios e mercado Caracter sticas do 1 0 Documento da Vis o Outros requisitos para a vers o 1 0 Caracter sticas futuras Figura 17 2 Documento da Vis o v1 0 Este documento serve de base para o release 1 0 e dirige os requisitos e use cases mais detalhados do sistema os quais ser o muito mais elaborados Documento da Vis o para a Vers o 2 0 Com a evolu o do projeto caracter sticas v o sendo mais bem definidas normalmente isso significa que elas ser o mais bem elaboradas no documento da Vis o Al m disso novas caracter sticas ser o descobertas e adicionadas ao documento Assim o documento tende a crescer tornando se mais valoroso para a equipe Quando chegarmos a abordar a vers o 2 0 certamente iremos querer manter esse documento que t o bem nos serviu O pr ximo passo l gico na evolu o do projeto e deste documento extrair as caracter sticas futuras que foram inclu das na vers o 1 0 d
135. dos Enquanto o processo de entrevista estava em andamento a equipe de desenvolvimento reuniu se com o marketing e decidiu realizar um workshop de requisitos para o projeto HOLIS 2000 Participantes Depois de pensar sobre o assunto a equipe decidiu n o trazer um facilitador externo ao inv s disso definiram que Eric o diretor de marketing facilitaria o workshop A equipe tamb m decidiu que haveria a participa o de dois membros da equipe de desenvolvimento Cathy a gerente de produto e Pete o gerente de desenvolvimento A equipe sentiu que tanto Cathy quanto Pete poderiam falar pela equipe e que estavam aptas em contribuir com o conte do ambas como novas propriet rias Os outros membros da equipe n o iriam participar mas iriam simplesmente assistir o workshop a fim de observar o processo ouvir os clientes e ver diretamente os resultados 95 A equipe tamb m decidiu incluir a representa o de quatro classes de clientes e convidou os seguintes participantes 1 Distribuidores John diretor executivo da maior companhia de distribui o e Raquel a gerente geral da companhia de distribui o exclusiva na Europa David um construtor de casas local com experi ncia em comprar e 2 3 4 instalar sistemas concorrentes no mercado Betty uma empreiteira el trica local As perspectivas de propriet rios identificadas com a ajuda de Betty que passou por um processo de constru o ou considerou a constru
136. dos Distribuidores Um produto que ofere a competitividade Alguma forte diferencia o do produto Facilidade de treinar o pessoal de vendas Poder ser demonstrado em minha loja Alta margem bruta Uma Nota sobre Question rios N o existe substituto para a entrevista Execute a primeiro Fxecute a para cada nova classe de problemas Fxecute a para cada novo projeto Question rios podem ser usados para validar suposi es e obter dados estat sticos sobre prefer ncias N s nos perguntamos com frequ ncia se a equipe pode substituir este processo de entrevista por um question rio Em alguns casos isso expressa apenas um desejo de efici ncia Eu poderia fazer 100 question rios no tempo em que se leva para fazer uma nica entrevista Em outros casos isso pode expressar algum desejo suspeito Eu realmente tenho que falar com essas pessoas Eu n o poderia apenas enviar uma carta Independentemente da motiva o a resposta n o N o existe nenhum substituto para o contato pessoal constru o do entendimento e intera o em formato livre da t cnica de entrevista N s lhe asseguramos que ap s um ou duas entrevistas nossa vis o do mundo ter mudado Mais importante que 1sso a vis o da solu o ter mudado junto com ele Primeiro executa a entrevista Execute a para cada nova classe de problema Execute a para cada novo projeto No entanto quando usada apropriada
137. duto desejado Uma vez que as caracter sticas do produto tenham sido especificadas a pr xima tarefa refinar a especifica o at atingir um n vel de detalhes adequado para orientar os processos de projeto codifica o e teste Na Habilidade de Equipe 5 examinamos um m todo organizado para elaborar organizar e comunicar os requisitos de software Iremos finalizar a Habilidade de Equipe 5 com uma vis o de um assunto mais intrincado como estabelecer os requisitos de forma clara e concisa Independentemente do m todo que voc utilize para coletar os requisitos crucial que voc adote a filosofia de que os requisitos coletados e somente esses requisitos ir o dirigir o projeto Se descobrirmos que eles s o insuficientes ou errados eles devem ser rapidamente e oficialmente alterados a fim de manter as regras corretas Desta forma a equipe toda ter um alvo n o amb guo e seus esfor os podem se concentrar em descobrir e implementar requisitos minimizando o tempo gasto em coisas sem relev ncia Iremos come ar examinando a natureza dos pr prios requisitos Dom nio do Problema Rastreabilidade Espa o da Solu o Produto a ser 7 rnancetriida Requisitos de Software Procedimentos de Teste Proieto Docs Usu rio 178 Cap tulo 23 Requisitos de Software Pontos chaves e Um conjunto completo de requisitos pode ser determinado pela defini o das entradas sa das fun e
138. e de hardware Eric 19 Ligar automaticamente as l mpadas quando a porta for 55 Baixo Alto aberta 18 Ligar automaticamente as luzes quando algu m bate a porta 50 M dio M dio 15 Controlar a ilumina o via telefone 44 Alto Alto 10 Interface com o sistema de automa o residencial 43 Alto Alto 26 Esta o de controle principal 31 Alto Alto 12 Facilidade de expans o quando remodelado 25 M dio M dio 25 Interface de usu rio internacionalizado 24 M dio Alto 21 Interface com o sistema de udio v deo 23 Alto Alto 24 Restaura o ap s falha no fornecimento de energia el trica 23 N A N A 17 Controle HVAC 22 Alto Alto 28 Ativa o via voz Alto Alto 27 Apresenta o no web site do usu rio 4 M dio Baixo 163 Cap tulo 21 Gerenciando o Seu Cliente Pontos chaves Engajando de Projeto Gerenciar seu cliente significa engaj lo no gerenciamento de seus requisitos e no sem ESCOpO de projeto Clientes que s o partes do processo ser o respons veis pelos resultados Fazer o trabalho correto significa fornecer funcionalidade suficiente no tempo certo para atender as reais necessidades do cliente Habilidades de negocia o d o apoio indispens vel para o desafio de gerenciar escopo Clientes para Gerenciar Seu Escopo A redu o do escopo de projeto para adequar ao tempo e recursos dispon veis tem o potencial de criar uma rela o antag nica entre a equipe de projeto e seus clientes cujas necessidades devem ser ate
139. e e Popular Mechanics em casa realizam cursos de programa o de computadores no col gio estudam Engenharia ou Ci ncia da Computa o na faculdade e por isso direcionam suas vidas para seguir especificamente o caminho da tecnologia Para outros devido capacidade de demonstrar e de realizar descobertas encontraram um lugar no tempo e no espa o quando a necessidade por software era premente e acabaram por se comprometer gradualmente com esta rea em tempo integral Em muitos casos a atra o por tecnologia manteve a chama acesa N s amamos bits e bytes os sistemas operacionais os bancos de dados as ferramentas de desenvolvimento atalhos de teclado e as linguagens de programa o Quem mais sen o os desenvolvedores de software poderiam ter criado o sistema operacional UNIX Nosso foco est na tecnologia essa a nossa motiva o Talvez pela tend ncia gen tica inata ou talvez por n o ter assistido todas as aulas bobas na faculdade psicologia sociologia ou pior Portugu s n s geralmente focamos menos nas pessoas de nosso neg cio e muito mais em bits e bytes N s tendemos a n o participar de festas e alguns de n s temos problemas em se relacionar com pessoas fora do trabalho onde n o existe sustenta o tecnol gica comum que possam servir de base para uma discuss o Como consequ ncia desse comportamento surgiram ferramentas de natureza monousu ria utilizada para desenvolver aplica
140. e interface para Programador PC opcional poder esperar at a vers o 2 0 Isso fez com que a equipe alterasse a caracter stica 25 de Interface de usu rio internacionalizado para Interface UCC internacionalizado e a adicionasse uma 8 Durante o desenvolvimento a equipe decidiu que na pr tica tinha at o final de Fevereiro para liberar a vers o 1 0 final Com isso houve a adi o de mais 6 semanas cruciais pois a equipe estava convencida de que precisava realizar modifica es finais com base no feedback obtido na exposi o 161 nova caracter stica Programador PC internacionalizado para a lista de caracter sticas futuras Tabela 20 6 Caracter sticas do HOLIS 2000 com os atributos de esfor o e risco ID Caracter sticas Votos Esfor o Risco 23 Cenas de ilumina o personalizadas 121 M dio Baixo 16 Configura o do tempo autom tico de ilumina o etc 107 Baixo Baixo 4 Caracter sticas de seguran a pr definidas p ex l mpadas e alarmes 105 Baixo Alto 6 100 de confiabilidade 90 Alto Alto 8 F cil de programar unidade de controle n o PC 88 Alto M dio 1 Facilidade de programar as esta es de controle 77 M dio M dio 5 Configura o de aus ncias 77 Baixo M dio 13 Toda l mpada pode ser apagada 74 Baixo Baixo 9 Usar meu pr prio PC para programar 73 Alto M dio 14 Caracter sticas de entretenimento 66 Baixo Baixo 20 Portas da garagem fechadas 66 Baixo Baixo 19 Ligar automaticamente as l
141. e para a an lise do problema e engenharia de sistemas do HOLIS N s iremos retornar a este caso de estudos nos pr ximos cap tulos 60 Sum rio da Habilidade de Equipe 1 A Habilidade de Equipe 1 Analisando o Problema introduziu um conjunto de habilidades que sua equipe pode aplicar para entender o problema a ser resolvido antes de come ar o desenvolvimento da aplica o N s introduzimos de forma simples os cinco passos da t cnica de an lise de problemas que podem ajudar a sua equipe a conseguir obter melhor entendimento do problema a ser resolvido Chegar ao acordo sobre a defini o do problema Entender a causa raiz do problema o problema por detr s do problema Identificar os stakeholders e usu rios Definir a fronteira da solu o sist mica Identificar as restri es que ser o impostas solu o E A an lise do problema desta forma sistem tica ir aperfei oar a habilidade de sua equipe em atacar futuros desafios fornecendo uma solu o do problema a ser resolvido N s tamb m apontamos as v rias t cnicas que podem ser usadas na an lise do problema Em especial vimos modelagem de neg cios a qual funciona bem para sistemas de informa o complexos que sustentam as principais infra estruturas do neg cio A equipe pode usar a modelagem de neg cios tanto para entender como o neg cio funciona quanto para definir onde o sistema dentro do neg cio pode ser aplicado de forma mais prod
142. e programa o certa para todas as aplica es n o existe nenhuma maneira correta de desenvolver as especifica es mais detalhadas Diferentes ambientes clamam por t cnicas diferentes Assim gerentes e engenheiros de requisitos ter o que provavelmente desenvolver um misto de habilidades para se adaptarem a diversas circunst ncias N s aplicamos in meras t cnicas em v rias circunst ncias desde documentos de requisitos rigorosamente precisos banco de dados personalizado ou reposit rio de requisitos at modelos use case e m todos mais formais No entanto o lugar t pico do esfor o est na especifica o em linguagem natural escrita com clareza suficiente para o entendimento de todos os stakeholders clientes usu rios desenvolvedores e testers mas suficientemente espec fico Os 4 eixos devem ter uma velocidade m xima de 1 metro segundo para permitir a verifica o e demonstra o da conformidade Antes de come armos a coletar os requisitos do sistema n s iremos inicialmente considerar a natureza dos requisitos que voc precisar descobrir e definir Defini o de Requisitos de Software No Cap tulo 2 n s apresentamos esta defini o de requisito extremamente simples e Uma capacidade de software que o usu rio precisa a fim de resolver um problema e atingir seu objetivo e Uma capacidade de software que deve ser atendida ou possu da por um sistema ou componentes do sistema para satisfazer um contra
143. e testes eles fornecem uma representa o consistente e uma linha consistente atrav s das atividades de requisitos an lise projeto e testes Desta forma a t cnica constr i antecipadamente recursos de projeto reutiliz veis que ajudam a aperfei oar a efici ncia global do processo de desenvolvimento de software Mais ainda com a consist ncia da representa o e o suporte fornecido pela UML e por diversas ferramentas de desenvolvimento de aplica es use cases podem ajudar na automa o de v rios elementos da atividade de gerenciamento de requisitos Por estas raz es use cases s o nota es t o importantes que n s os aplicamos deste ponto em diante como parte integrante das atividades de gerenciamento de requisitos de equipe 111 Cap tulo 14 Role Playing Pontos chaves e O role playing permite que a equipe de desenvolvimento experimente o mundo do usu rio a partir da perspectiva do usu rio e Um roteiro de acompanhamento pode substituir o role playing em algumas situa es com o script se tornando num storyboard vivo e Os cart es CRC Classe Responsabilidade Colabora o frequentemente usados na an lise orientada a objetos s o um derivado do role playing t agora na Habilidade de Equipe 2 temos discutido uma variedade de t cnicas para entender as necessidades dos stakeholders com respeito ao novo sistema que estamos construindo N s falamos cara a cara sobre o sistema entrevista n s discut
144. eatures sugeridas c pias de entrevistas com os futuros usu rios relat rio do analista sobre tend ncias na ind stria cartas de clientes relat rio de erros do sistema existente novas diretivas de gerenciamento novos dados de marketing entre outros Embora seja importante n o sufocar com dados os nossos futuros participantes Importante assegurar que eles recebam os dados corretos 2 Prepara o do pensamento out of box Parte do atingir um ideal estado de espirito est em encorajar o pensamento out of the box Esque a por um minuto o que voc conhece e o que n o pode ser feito devido pol tica Esque a o que voc tentou colocar em atividade na ltima vez e falhou Esque a que n s n o solidificamos nosso processo de desenvolvimento Apenas traga suas sugest es sobre caracter sticas features deste novo projeto e esteja preparado para pensar out of the box Como l der do workshop voc pode ajudar neste processo fornecendo pensamentos provocativos e estimulando o acordo sobre o processo de criatividade regras para o brainstorming gerenciamento de requisitos gerenciamento de escopo entre outros Nesta atmosfera solu es criativas ser o as mais prov veis Dica N o envie dados com muita anteced ncia Voc n o Ir querer que os participantes leiam e esque am o que leram e voc n o ir querer que um longo ciclo de planejamento reduza o sentido de urg ncia Env
145. ecem o processo possam parecer muito simples n o A maneira como estabelecido tem grande efeito sobre as consequ ncias da sess o Como exemplo as seguintes quest es d o algumas das formas de estabelecer os objetivos Quais caracter sticas voc gostaria que o produto tivesse Quais servi os voc gostaria que o produto fornecesse Que informa es voc gostaria que o produto mantivesse Note que os objetivos tamb m ajudam voc a decidir quando a sess o est terminada Quando os objetivos forem alcan ados e n o houver mais nada a acrescentar fim Depois que os objetivos do processo tiverem sido estabelecidos o facilitador convida os participantes para que expressem suas id ias em voz alta e escreva as uma em cada folha Id ias s o ditas em voz alta para permitir que outros possam engatar suas id ias Isto pensar em relacionar id ias e seguir a regra 4 mudar e combinar id ias Neste processo no entanto a primeira regra sem cr ticas ou debates deve estar frente na mente das pessoas Se esta regra n o for impingida o processo ser silenciado muitas pessoas brilhantes por m sens veis s cr ticas n o se sentir o confort veis em colocar suas id ias uma tr gica perda 90 Dica Em nossa experi ncia as id ias mais criativas e movadoras aquelas que verdadeiramente revolucionam o conceito do produto n o resultaram da id ia de uma nica pessoa mas ao inv s disso
146. ecisa dessa aplica o Quantos usu rios desse tipo usariam a aplica o O que voc considera que seja uma solu o bem sucedida Parte VIII Avaliando Necessidades needs de Seguran a Desempenho e Suportabilidade Quais s o suas expectativas sobre a seguran a Quais s o suas expectativas sobre o desempenho Voc ir dar suporte ao produto ou ser o outras pessoas que far o isso Voc tem necessidades needs especiais de suporte O que voc pensa sobre a manuten o e servi os de rede Quais s o os requisitos de seguran a Quais s o os requisitos de instala o e configura o Existem requisitos especiais de licenciamento Como o software ser distribuido Existem requisitos de etiquetagem ou de empacotamento Parte IX Outros Requisitos Existe algum requisito legal de regula o ambiental ou de padroniza o que deva ser atendido Voc acha que existem outros requisitos que devemos conhecer Parte X Fechamento Existe alguma outra quest o que eu deveria ter feito Se depois eu tiver alguma d vida posso ligar para voc Voc concorda em participar de uma revis o de requisitos Parte XI Resumo do Analista Depois da entrevista e enquanto as informa es estiverem frescas em sua mente resuma as tr s necessidades needs ou problemas de maior prioridade identificados pelo usu rio cliente l 2 J Figura 9 1 A entrevista livre de contexto gen rica 76 O Momento da Verdade
147. ee aeee eee ae terre aeereanda IF Compilando os Dados de Necessidade Needs nnnssesssessserrssserrrssssrrssssrrrsssrrrsssrrrsss 77 O Resumo do Analista 10 10 10 O ug a SA O re seere eee eat 78 OEsudo de C an Ra DR A A A E A a in 78 Uma Nota sobre Question rios era eee e acer na terrena e erre a aee ere aee eerenaneeeeeenaneio 79 CAPITOLO TO iss is Oo dd 80 WORKSHOPS DE REQUISITOS eee rrreeeeee erre aeee erre aaearereeanaaa rena aaeaereeeanacarerananta 80 Acelerando o Processo de Decis o eee aeee erra aeee ee rrreea nana eee reeeaneaeeereraa 80 Preparando o Workshop eee teto roer een t ttet teessa seet Ettr e naaaaaaaaeeeeeeeeererereenanaaaaaeeeta 81 Vendendo CONCER ear e UR Boa ON UR A RL A 81 Assegurando a Prepara o dos Stakeholders Corretos eee 81 Ee quo ro Ro RR R EN O SEO RO RD RR A RO RP RR OGU E SUR RR Ro EO RE RP 81 Nele AJUS meno aura so ar nana irao E E O as cuia O E fa ara ENEE ddr an aa dao ipa da desuso 82 Papel do FaACIItador ssasisntssssosisipasodiina o dida ada a a ode E RE 84 Preparando Agenda essas asda O DD O A 84 Executando o Workshop eee teto tecer eee na aaa a ane ee ee eeeerreee een aaaaaaaeeeeeeeeerereeeenaananaaneea 85 Problemas e Tunes do O CIO pas ea a a a Bo a a a 85 Erainstormine e Reducao des Ta Cias si T dr EAE dd 87 Produ o Continuidade sas ai ad ic a A o a a 88 CAPITULO ss EE EE a a E PAE TEETE A DE a Ja RE ata 89
148. eholders do seu projeto estejam trabalhando em dire o aos mesmos objetivos Tabela 4 1 Formato da Declara o do problema Elementos Descri o O problema Descrever o problema afeta Identificar os stakeholders afetados pelo problema devido Descrever o impacto deste problema nos stakeholders e atividades de neg cio Os benef cios desse Indicar a solu o proposta e listar os principais benef cios Gastar tempo para chegar ao acordo sobre o problema a ser resolvido pode parecer um passo pequeno e insignificante e em muitas circunst ncias isso verdade Mas algumas vezes n o Por exemplo um de nossos clientes um fabricante de equipamentos foi realizar uma grande atualiza o no seu sistema de informa o o qual realiza o faturamento e fornece relat rios financeiros entre a empresa e seus fornecedores O tema para o novo programa foi aperfei oar comunica es com fornecedores Dito isso a equipe tinha iniciado um esfor o significativo para o desenvolvimento de um novo sistema Um exerc cio de como chegar ao acordo sobre o problema a ser resolvido foi realizado A equipe de desenvolvimento definiu uma solu o prevendo um novo sistema poderos ssimo que fornecia relat rios financeiros muito melhores aperfei oamento do faturamento e do formato da fatura tratamento de pedidos online e e mail Ah a prop sito a equipe esperava em algum momento fornecer a capacidade de transfer ncia de fundos eletro
149. eiro passo necess rio para o desenvolvimento de software b sico para as atividades de projeto e codifica o Por m essa for a tornou se tamb m numa fonte de dificuldades pois deu nfase na elabora o completa dos requisitos e documenta es de projeto transformando se numa barreira para sair de cada fase Al m disso talvez esse grave engano das equipes de desenvolvimento tenha feito com que esse modelo representasse uma abordagem fixa e rigida de desenvolvimento onde os requisitos s o congelados durante a execu o do 169 projeto onde mudan as representam um sacril gio e onde o processo de desenvolvimento imp e sua pr pria vida Neste caso com o tempo a equipe pode ficar completamente desligada do mundo real de onde o projeto originalmente foi concebido O modelo cascata encontrou press o adicional quando foi associado aos desafios do gerenciamento de requisitos Figura 22 2 Especificamente se o modelo cascata aplicado a um projeto que possui inicialmente 200 de escopo o resultado pode ser desastroso No prazo final nada realmente funciona testes de unidade e de integra o do sistema s o interrompidos ou abandonados foram realizados investimentos significativos na especifica o projeto e codifica o de caracter sticas de sistema que nunca ser o liberados Resultado n o existe nada que possa ser liberado existem apenas o caos a baixa qualidade e sucata de software Devido principalmente
150. ele que tem a responsabilidade pelo N mero isto pela receita associada com cada produto liberado assim que deve ser o marketing em ltima an lise o respons vel pelas vendas e deve assim ser respons vel pelo mercado e pelas decis es dificeis caso contr rio suas presta es de contas n o ter o sentido Como voc classificaria os pap is e responsabilidades nessa mescla de requisitos tecnologias clientes e desenvolvedores Imagme o seguinte di logo uma varia o do que ocorreu recentemente numa nova empresa que foi classificar seus pap is 143 Gerente de Produto o Campe o Gerente de Desenvolvimento Gerente de Produto Dever possuir as caracter sticas A Be C e voc deve construir usando a tecnologia X Eu acho que deveria ter a caracter stica D e n o a C e nos usar a tecnologia Y Eu disse que tem que ter A Be C Afinal de contas sou eu que tenho que atender s quotas de venda e o que preciso para atender s necessidades dos clientes Se voc quiser se responsabilizar voc pode adicionar a caracter stica D desde que voc ainda atenda o cronograma Gerente de Desenvolvimento Hummm pensando melhor no significado de gastar seu tempo ajudando sua equipe a atender quota Eu n o tenha certeza se isso uma boa id ia N s implementaremos A B e C Mas voc se responsabiliza se na pr tica isso n o funcionar Gerente de Produto antevendo o conhecimen
151. em Assembly ser usada na Chave de Controle Um prot tipo do sistema deve ser apresentado numa exposi o comercial de Automa o Residencial em Dezembro O subsistema de microprocessamento da Unidade de Controle Central deve ser copiado da divis o profissional de projetos de sistemas de ilumina o avan a ALSP Apenas o Programador PC dever ser compat vel com o Windows 98 Contratar no m ximo dois empregados de tempo integral somente ap s o t rmino da fase de concep o quando as habilidades necess rias ao projeto estar o determinadas O microprocessador KCH5444 deve ser usado na Chave de Controle Aquisi es de componentes de software poss vel contanto que n o exista nenhuma obriga o de pagamentos cont nuos de royalty pela empresa L gica A nica oportunidade de lan amento do produto neste ano N s acreditamos que estas tecnologias fornecem aumento de produtividade e produzem sistemas robustos Devido consist ncia e tamb m manutenibilidade pois a equipe conhece estas linguagens Para obter pedidos de distribuidores do QI FY 2000 um projeto existente e uma pe a existente em estoque Faz parte do escopo de gerenciamento para a libera o da vers o 1 0 Contrata o m xima permitida para expans o da equipe J em uso pela companhia Nenhum custo de longo prazo poder causar impacto no custo de software Por agora isto o suficient
152. em v rias situa es Quanto mais dificil o workshop mais valioso ser Eles tamb m tendem a estimular o pensamento out of box O mais interessante que eles s o divertidos e contribuem para o tom positivo da sess o A Figura 10 2 fornece um exemplo desse conjunto de truque de workshop Sinta se livre para adapt los e us los junto com as instru es de uso A Tabela 10 2 descreve algum dos problemas que podem ocorrer numa prepara o do workshop e tamb m fornece sugest es sobre como voc pode usar os truques de workshop para atacar os problemas O facilitador deve tamb m introduzir essas regras no in cio da reuni o e idealmente obter aprova o consensual para aplicar essas tolas regras por um dia 85 Atraso ap s o Intervalo Regra Inicialmente cada participante recebe um cupom gr tis quando chegar atrasado Depois disso o participante contribui com 1 de multa Que grande Regra Inicialmente cada participante inicia com dois cupons Os participantes d o o cupom para qualquer participante que forne a uma grande id ia O objetivo gastar seus cupons Objetivo Incentivar e gratificar pensamentos criativos 5 minutos para falar Figura 10 2 Truques de workshop 1 Ofensa gratuita e deliberada Regra Inicialmente cada participante recebe um cupom para dar um toque sobre uma pessoa ou departamento Depois disso o participante contribui com 1 de multa Objetiv
153. ema digno de ser atacado Ainda com base nesta defini o nosso colega Elemer Magaziner notou que existem v rias maneiras de se atacar um problema Por exemplo mudar o desejo ou percep o do usu rio pode ser a abordagem de melhor custo efetivo Assim pode ser uma quest o de ajuste e gerenciamento de expectativas fornecendo solu es de contorno ou aperfei oamento incremental para sistemas existentes fornecendo solu es alternativas que n o requeiram o desenvolvimento de novos sistemas ou fornecendo treinamento adicional A experi ncia pr tica mostra muitos exemplos onde mudar a percep o da diferen a tem conduzido a solu es vantajosas r pidas baratas e de alt ssima qualidade Como solucionadores de problemas estamos incumbidos em explorar essas solu es alternativas antes de saltar para a solu o de um novo sistema Todavia quando a atividade de encontrar uma solu o alternativa para reduzir a diferen a entre o percebido e o desejado falhar estaremos diante de um grande desafio o de efetivamente reduzir a dist ncia entre o percebido e a realidade Isso n s devemos realizar definindo e implementando novos sistemas que reduzam a diferen a entre o percebido e o desejado Como em qualquer exerc cio de solu o de problemas complexos devemos iniciar tendo um objetivo em mente O objetivo da an lise de problemas adquirir melhor entendimento do problema a ser resolvido antes de iniciar o desenvolvimento Os
154. ementa o estarem finalizadas verdade que tecnologias espec ficas tal como a litografia onde um r pido prot tipo constru do durante a noite a partir da inje o de um l quido viscoso a alta temperatura foram desenvolvidas exclusivamente com o prop sito de fornecer o feedback imediato e precoce da defini o conceitual do produto Apesar disso no software com sua enorme complexidade esperamos fazer direito logo na primeira vez Embora possa ser frustrante aceitar a sindrome Sim Mas como uma realidade pode ajudar a discernir a realidade e auxiliar os membros da equipe a reduzirem esta sindrome em futuros projetos A sindrome Sim Mas faz parte da natureza humana e parte integral do desenvolvimento de aplica es Podemos reduzir drasticamente esta sindrome aplicando t cnicas que busquem os Mas desde o in cio Ao fazer 1sso elucidamos as respostas do Sim Mas no in cio e ent o podemos come ar a investir a maior parte dos esfor os de nosso desenvolvimento no software que j tenha passado pelo teste do Sim Mas A Sindrome das Ru nas Desconhecidas Corners area uma rea definida por fronteiras comuns dos estados do Colorado Novo M xico Utah e Arizona A rota do nibus de turismo inclu a o majestoso pico da cadeia de montanhas La Plata a extens o das antigas ru nas Anasazi do Mesa Verde e reas pr ximas As perguntas dos turistas s o uma constante fonte de diver
155. ementar com qualidade Isso n o deveria nos surpreender isso faz parte da natureza humana clientes querem mais o mercado deseja mais e n s tamb m queremos mais N s apenas precisamos garantir que nos impusemos uma dieta suficiente para assegurar que podemos liberar as coisas dentro do prazo N s vimos v rias t cnicas para estabelecer prioridades e definimos a no o de baseline um acordo sobre o que o sistema ir fazer um produto chave do projeto a nossa pedra fundamental e ponto de refer ncia para decis o e avalia o Aprendemos que se o escopo e a respectiva expectativa exceder a realidade em todas as probabilidades algumas not cias ruins ter o que ser dadas Decidimos adotar uma abordagem filos fica que engaje nosso cliente nas decis es dificeis Afinal de contas n s somos apenas os recursos n o os respons veis por tomar decis es o projeto do cliente Ent o a quest o Dado os recursos que est o dispon veis para o projeto o que exatamente deve ser realizada na pr xima release Apesar de tudo esperamos fazer alguma negocia o a vida e certamente o neg cio s o num dado sentido uma negocia o e n o dever amos ficar surpresos com isso N s mencionamos brevemente algumas habilidades de negocia o e demos dicas de quais dessas habilidades a equipe pode precisar nessas ocasi es N s n o podemos esperar que este processo elimine os desafios de escopo muito mais do que qualquer outro
156. emos simplificar a discuss o evitando a esquizofrenia do problema oportunidade concentrando nos em apenas um dos lados da moeda o lado do problema Afinal de contas gostamos de pensar que somos os solucionadores de problemas Definimos a an lise de problemas como o processo de entender problemas do mundo real entender as necessidades dos usu rios e propor solu es que satisfa am tais necessidades 25 As vezes a solu o mais simples uma solu o de contorno ou uma revis o do processo de neg cio ao inv s de um novo sistema O objetivo da an lise de problemas adquirir melhor entendimento do problema a ser resolvido antes de iniciar O desenvolvimento Dito isso o dom nio do problema deve ser analisado e entendido e uma variedade de dom nios da solu o devem ser explorados Normalmente v rias solu es s o poss veis e nosso trabalho encontrar a solu o que seja o timo para o problema a ser resolvido Para estarmos aptos a realizar a an lise de problemas ser til definir o que um problema De acordo com Gause e Weinberg 1989 um problema pode ser definido como a diferen a entre coisas s o desejadas e coisas que s o percebidas Essa defini o pelo menos elimina o problema de desenvolvedores acharem que o real problema que o usu rio n o sabe qual o real problema De acordo com a defini o se o usu rio percebe algo como problema esse um real probl
157. enciado antes e durante o esfor o de desenvolvimento No entanto o cen rio t pico amedronta Se come armos o esfor o de desenvolvimento com de fato a expectativa de escopo em 200 ser necess rio reduzir o escopo do projeto por um fator de 2 se quisermos obter alguma chance de sucesso O dilema da equipe ao enfrentar este problema talvez leve dura quest o enfrentada pela equipe O que podemos fazer para reduzir o escopo e manter o cliente satisfeito Bem nem tudo est perdido N s iremos cobrir algumas maneiras de lidar com esta quest o nos dois pr ximos cap tulos 153 Cap tulo 20 Estabelecendo o Escopo de Projeto Pontos chaves e O primeiro passo para estabelecer o escopo de projeto definir um baseline de requisitos de alto n vel um conjunto de caracter sticas que se pretende liberar numa vers o espec fica do produto e O segundo passo estabelecer o esbo o do n vel de esfor o requerido para cada caracter stica do baseline e Depois estimar o risco para cada caracter sticas ou a probabilidade de que ao implement las causar um impacto negativo no cronograma e no or amento e Usando esses dados a equipe estabelece e assegura que o baseline de libera o ir conter as caracter sticas que s o cr ticas para o sucesso do projeto O Baseline de Requisitos O prop sito do gerenciamento de escopo estabelecer um baseline de requisitos de alto n vel para o projeto Definimos baseline como
158. endem a ser prot tipos de requisitos e s o usados principalmente para capturar aspectos da interface do usu rio do sistema a ser constru do Existem provavelmente duas raz es para isso 1 A emerg ncia de uma pletora de ferramentas baratas e amplamente dispon veis para construir interfaces de usu rios rapidamente 2 Para sistemas cujas Interfaces de usu rio sejam intensas um prot tipo de interface de usu rio revela tamb m muitos outros requisitos tais como as fun es que s o fornecidas ao usu rio quando cada fun o est dispon vel aos usu rios e quais fun es n o s o acess veis aos usu rios No entanto precisamos estar certos de que a disponibilidade de ferramentas n o nos leve a prototipar partes do sistema que n o apresentem inicialmente riscos muito altos O que Prototipar Como vamos saber qual por o do sistema devemos prototipar Numa situa o t pica nosso entendimento das necessidades dos usu rios ir variar desde o bem conhecido e f cil de verbalizar at o totalmente desconhecido Figura 15 2 rr rS Bem conhecido Confuso Desconhecido Figura 15 2 O sistema de estoque inicial com atores identificados Os requisitos bem conhecidos podem ser bvios no contexto do dom nio da aplica o e a experi ncia do usu rio e da equipe com sistemas desse tipo Por exemplo se estivermos simplesmente estendendo um sistema existente teremos claramente a id ia de como a maioria
159. engenharia de software Modelos de neg cio adicionam valor quando o ambiente da aplica o complexa e multidimensional e quando muitas pessoas est o diretamente envolvidas no uso do sistema Por exemplo se voc estiver construindo uma caracter stica adicional para um componente de chaveamento de telecomunica es voc n o deveria usar a modelagem de neg cio Por outro lado se voc estiver construindo um sistema de pedidos para o GoodsAreUs n s 42 recomendamos que utilize a modelagem de neg cio para ganhar vantagem na an lise do problema Sum rio Neste cap tulo n s descrevemos uma t cnica espec fica de an lise de problema a modelagem de neg cio Ao fazer isso definimos Porque voc precisa modelar o neg cio Como usando a UML n s transpomos as t cnicas de desenvolvimento da engenharia de software e a usamos para a modelagem de neg cio Os principais artefatos da modelagem de neg cio o modelo use case de neg cio e o modelo de objetos de neg cio Como voc pode definir aplica es de software e gerar requisitos de software a partir dos modelos de neg cio Vislumbrando o Futuro No pr ximo cap tulo veremos a engenharia de sistemas para sistemas de software uma outra t cnica de an lise de problemas a qual ir ajudar a formatar a aplica o de sistemas do tipo embutido 43 Cap tulo 6 Engenharia de Sistemas de Software Intensivos Pontos chaves e engenharia de
160. entos contadores sistemas e como eles se interagem para gerar as funcionalidades necess rias a fim de realizar os use cases de neg cio A Figura 5 2 representa o modelo de objetos de neg cio Os cones com um ator dentro de uma circunfer ncia representam um worker trabalhador que aparece dentro do processo de neg cio tais como secret ria chefe ou diretor As circunfer ncias com as barras representam uma entidade de neg cio ou alguma coisa que os workers de neg cio usa ou produz tais como contratos cadastro de funcion rios e produtos Figura 5 2 Modelo de objetos de neg cio Um modelo de objetos de neg cio tamb m possui realiza es de use cases de neg cio os quais mostram como os use cases de neg cio s o executados em termos de intera es de workers de neg cio e entidades de neg cio Para refletir grupos de departamentos numa organiza o workers de neg cio e entidades de neg cio podem ser agrupados dentro de unidades organizacionais Todos juntos os dois modelos fornecem uma vis o geral compreensiva de como o neg cio funciona e permite que a equipe de desenvolvimento concentre se nas reas no qual o sistema pode ser fornecido com o objetivo de elevar a efici ncia geral do neg cio Os modelos tamb m ajudam a equipe a entender quais mudan as ter o que ser realizadas dentro do processo de neg cio a fim de que o novo sistema possa ser efetivamente implementado 41 Da Modelagem de Neg cio
161. er stica cr tica com esfor o m dio e de baixo risco pode ser um candidato para receber recursos de projeto imediato Entre esses extremos podemos encontrar o ponto ideal onde podemos aplicar nossos recursos pr definidos de forma a maximizar os benef cios que ser o disponibilizados ao cliente A Tabela 20 4 fornece um pequeno guia para priorizar o desenvolvimento de caracter sticas cr ticas com base nesses atributos Tabela 20 4 T cnicas de prioriza o de escopo Atributos Considere Prioridade Cr tica Alerta Estabele a imediatamente uma estrat gia de redu o de riscos aloque recursos concentre se na sua viabilidade arquitetural Esfor o Alto Ea RRR SN ARGIT Risco Alto Prioridade Cr tica Concentre se nos prov veis item cujos recursos s o limitados e cr ticos Esfor o Alto aloque recursos imediatamente Risco Baixo Prioridade Cr tica Considere alocar recursos s por seguran a ou postergue essa aloca o Esfor o Baixo para uma pr xima oportunidade Risco Baixo Uma Estimativa Inicial Razo vel Se a equipe utilizar uma estimativa baseada em atividades mesmo que grosseira ela poder determinar o baseline apenas adicionando as estimativas de atividades at que o limite de tempo seja alcan ado assim a equipe ter estabelecido o baseline do projeto Normalmente no entanto a equipe n o tem sequer nenhum dado dispon vel e ainda assim deve fazer um primeiro corte no escopo
162. er sticas animadas ou desenhos animados come am com storyboards Eles representam informa es cruas de cria o usadas no desenvolvimento de personagens e no enredo da est ria Em software storyboards s o usados com maior frequ ncia para trabalhar detalhes de interfaces homem m quina Nesta rea geralmente uma das mais vol teis cada usu rio provavelmente possui diferentes opini es sobre como a interface deve funcionar Storyboards para sistemas baseados em usu rios lida com tr s elementos essenciais de qualquer atividade 1 Quem s o os jogadores 2 O que acontece com eles 3 Como acontece O elemento quem define os jogadores ou usu rios do sistema Num sistema de software como discutimos anteriormente o quem s o jogadores tais como usu rios e outros sistemas ou perif ricos os atores que interagem com a solu o sist mica que estamos construindo Para usu rios a intera o tipicamente descrita via informa es de telas ou de formul rios de entrada de dados dados e relat rios de sa da ou via outros tipos de perif ricos de entrada e sa da tais como bot es chaves displays e monitores Para perif ricos e sistemas Intera es s o realizadas via uma interface de software ou hardware tais como protocolo de comunica o ou sinais do drive de controle de motor O elemento o que representa o comportamento de como os usu rios interagem com o sistema ou alternativamente o comportamento de como o
163. er calmaria durante a gera o de id ias Isso n o motivo para parar o processo A calmaria tende a cessar assim que uma nova id ia gerada Longas calmarias podem fazer com que o facilitador repasse os objetivos ou fa a perguntas associadas Muitas sess es de gera o de id ias duram por volta de uma hora mas algumas duram de 2 a 3 horas Sob nenhuma condi o deve o facilitador finalizar uma sess o que esteja caminhando bem com coment rios como Eu sei que estamos todos fazendo grandes progressos mas precisamos prosseguir para a pr xima fase Para os participantes isso soa como Nossas id ias n o s o t o Importantes quanto o cronograma A quantidade de id ias geradas depende de qu o f rtil foi a discuss o mas comum gerar de 100 a 200 id ias O processo tende a terminar naturalmente em algum ponto os stakeholders ficar o sem id ias novas Isso caracterizado por um longo e grande intervalo entre submiss es de id ias Nesse ponto o facilitador finaliza a sess o e pode ser um bom momento para fazer uma pausa Redu o de Id ias Quando a fase de gera o de id ias termina a vez de iniciar a redu o de id ias V rios passos est o envolvidos 91 Expurgando O primeiro passo o expurgo daquelas id ias que n o s o t o valiosas para merecer maior investimento pelo grupo O facilitador inicia visitando brevemente cada id ia e solicitando a coopera o do grupo para indicar as id
164. erente de tecnologia da informa o l der de projeto Mas independente do t tulo o trabalho o mesmo um grande trabalho O campe o deve 141 Gerenciar o processo de elucida o e ficar tranquilo quando s o descobertos requisitos suficientes Gerenciar as entradas conflitantes de todos os stakeholders Fazer as concess es necess rias para encontrar o conjunto de caracter sticas que liberem o mais alto valor para o maior n mero de stakeholders Apropriar se da vis o do produto Defender o produto Negociar com gerentes usu rios e desenvolvedores Defender frente a requisitos estranhos Manter uma saud vel excita o entre o que o cliente deseja e o que o a equipe de desenvolvimento pode liberar dentro do prazo do release Sero representante oficial entre o cliente e a equipe de desenvolvimento Gerenciar expectativas dos clentes gerentes executivos e os departamentos internos de marketing e engenharia Comunicar as caracter sticas do release para todos os stakeholders Revisar as especifica es de software para assegurar que eles conformam com a vis o representada pelas caracteristicas Gerenciar as prioridades das mudan as e a adi o e remo o das caracter sticas Esta pessoa a nica a quem o documento da Vis o pode ser realmente confiada e encontrar o campe o correto para esse prop sito a chave de sucesso ou falha do projeto O Campe o do Produto num
165. es a usarem seus cupons de 5 minutos para falar e Que grande id ia Ele deixa claro que ningu m deve deixar o workshop sem ter usado os cupons ou terem recebido um cupom Que grande id ia de outros Sugest o D uma pequena premia o para quem usar o cupom 5 minutos para falar dando lhe um cupom Que grande id ia Use o cupom 1 Ofensa gratuita e deliberada at que os participantes n o tenham mais nenhum depois disso t m que dar contribui es para a caixinha de contribui es para caridade o grupo decide quanto Almo o leve cafezmhos r pidos rearranjo da sala rearranjo dos locais dos participantes alterar a luminosidade e temperatura Fa a o que voc puder fazer para manter as coisas funcionando Brainstorming e Redu o de Id ias A parte mais importante do workshop o processo de brainstorming Esta t cnica idealmente adaptada para o ambiente de workshop e estimula uma atmosfera criativa e positiva e estimula contribui es de todos os stakeholders N s iremos tratar do brainstorming no pr ximo cap tulo 87 Produ o e Continuidade Depois do workshop o facilitador distribui os minutos da reuni o para registrar algumas outras informa es Assim o trabalho do facilitador est terminado e a responsabilidade do sucesso volta novamente para a equipe de desenvolvimento Depois disso o l der de projeto tem a responsabilidade de dar continui
166. escrevemos no Cap tulo 6 uma vez que se tenha chegado a um acordo sobre os requisitos do sistema uma atividade de engenharia de sistemas executada A engenharia de sistemas refina um sistema em subsistemas descrevendo as interfaces detalhadas entre subsistemas e alocando cada um dos requisitos do n vel sist mico para um ou mais subsistemas A arquitetura do sistema resultante descreve esse particionamento e interfaces entre sistemas Depois uma especifica o de requisitos desenvolvida para cada subsistema Estas especifica es devem descrever por completo o comportamento externo do subsistema sem referenciar quaisquer de seus subsistemas Este processo provoca o surgimento de uma nova classe de requisitos os requisitos derivados Este tipo de requisito nem de longo descreve o comportamento externo do sistema ao inv s disso descreve o comportamento externo do novo subsistema Assim o processo de projeto de sistemas cria novos requisitos para os subsistemas dos quais o sistema composto Em particular as interfaces entre esses subsistemas tornam se requisitos chaves essencialmente um contrato entre um subsistema e os outros ou uma promessa de desempenho conforme acordado Uma vez que se tenha chegado a um acordo sobre os requisitos o projeto do sistema novamente executado se necess rio dividindo cada subsistema em subsistemas e desenvolver especifica es de requisitos para cada um O resultado uma hierarquia de
167. especifica es como ilustra a Figura 16 2 Em todos os n veis requisitos do n vel anterior s o alocados para as especifica es apropriadas do n vel posterior Por exemplo o requisito da capacidade de combust vel alocado para o subsistema de controle de combust vel e para o subsistema de armazenamento de combust vel e novos requisitos s o descobertos e definidos quando apropriado Como ilustra a Figura 16 3 especifica es que por sua vez s o refinadas em especifica es adicionais de subsistema s o chamadas de especifica es dos requisitos de sistemas ou especifica es dos requisitos ao n vel sist mico As 127 especifica es do ltimo n vel isto aqueles que n o ser o futuramente decompostas normalmente correspondem a subsistemas de software somente ou de hardware somente e s o chamados especifica es dos requisitos de software ou especifica es dos requisitos de hardware respectivamente Al m disso toda especifica o dos requisitos da Figura 16 3 pode precisar experimentar um processo evolucion rio conforme os detalhes forem mais bem compreendidos Especifica o geral dos Requisitos do sistema Especifica o dos Especifica o dos Especifica o dos requisitos do sistema requisitos do sistema requisitos do sistema para o Subsistema A para o Subsistema B para o Subsistema C Especifica o dos Especifica o dos Especifica o dos Especifica o dos requisitos do sistema requis
168. etermina a causa raiz Bem isso depende Em muitos casos isso apenas uma quest o de perguntar s pessoas diretamente envolvidas sobre o que eles acham que a causa raiz incr vel como a maioria dessas pessoas conhece o problema por detr s do problema apenas isso mais nada pelo que n s entendemos de gerenciamento sempre pergunte antes Assim pergunte e pergunte v rias vezes o D O by A o EA A Ea gt D E E ta muito desperdicio g S S Se S S go S E na Y S o E S a amp o F Figura 4 1 Diagrama espinha de peixe de causa raiz 28 Dados de qualidade demonstram que muitas causas ra zes n o valem a pena serem corrigidas Se o problema mais s rio e levianamente ficarmos perguntando o que pode estar causando o problema poder gerar um ambiente desconfort vel pode ser necess rio realizar uma investiga o detalhada de cada causa do problema e quantificar individualmente seu impacto Isso pode ser feito utilizando desde um simples brainstorming com participantes que tenham conhecimento do dom nio do problema at um pequeno projeto de coleta de dados ou potencialmente at uma investiga o cient fica mais rigorosa Em muitos casos o objetivo quantificar as contribui es prov veis para cada causa raiz Atacando a Causa Raiz Naturalmente o engenheiro em todos n s gostaria de corrigir todas as causas ra zes identificadas nos ossos do diagrama Isso pare
169. foi apresentado um saco cheio de lixo para obter algum folga no cronograma No final a decis o foi sim mas o viso da Emily foi N s aceitamos a proposta da release 1 0 do HOLIS mas voc s devem estar cientes de que o CEO diretor respons vel da empresa Mark ordenou ao meu chefe Jason o qual me disse a senhora n o poder falhar na libera o do produto em Janeiro conforme seu comprometimento A Emily al m disso comentou N o estou segura do que ele quis dizer com 1sso Acho que ele quis dizer que se n s falharmos eu estarei comprometida mas eu n o quero descobrir voc quer 162 Ouvindo claramente as palavras de Emily os membros da equipe se responsabilizaram em liberar na data e prosseguir com a pr xima fase O pr ximo milestone no plano de projeto ser a itera o de elabora o a qual incluir uma prototipa o r pida do HOLIS que dever estar dispon vel para demonstra o at o dia primeiro de Agosto Tabela 20 7 Baseline v1 0 do HOLIS 2000 ID Caracter sticas Votos Esfor o Risco Coment rios de Marketing 23 Cenas de ilumina o personalizadas 121 M dio Baixo T o flex vel quanto poss vel 16 Configura o do tempo autom tico de ilumina o etc 107 Baixo Baixo T o flex vel quanto poss vel 4 Caracter sticas de seguran a pr definidas p ex l mpadas e 105 Baixo Alto Fazer mais pesquisas de mercado alarmes 6 100 de confiabilidade 90 Alto Alto Atingir tanto quan
170. gr fico de setores ou uma outra forma de representa o Al m do mais a palavra relat rio significa um documento impresso em papel ou tamb m significa que a informa o pode ser exibida na tela do computador preciso capturar a informa o de forma que ela 184 possa ser importada por outros programas ou enviadas para uma extranet corporativa As caracter sticas descritas no documento da Vis o podem ser sempre preenchidas de v rias maneiras alguma das quais trazem v rias consequ ncias implementa o Em muitos casos a descri o de um problema a partir do qual um requisito pode ser formulado influenciada pela percep o do usu rio da potencial solu o dispon vel para resolver o problema O mesmo verdade para os desenvolvedores que participam com o usu rio na formula o das caracteristicas que comp em o documento da Vis o e de requisitos Como um antigo prov rbio nos lembra se sua nica ferramenta um martelo todos os seus problemas ir o se parecer com um prego Mas precisamos ficar atentos nas restri es de implementa o desnecess rias e inconsistentes infiltradas nos requisitos sempre que pudermos precisamos remov las Mais sobre Requisitos versus Projeto Requisitos O que o sistema precisa fazer Projeto Como o sistema ir fazer At agora n s falamos dos requisitos de software decis es de projeto e restri es de projeto como se eles fossem entidades distin
171. grandes quantidades de caracter sticas do sistema para atender a uma nica necessidade do usu rio Come amos tamb m a fornecer especificidades adicionais para facilitar a defini o do comportamento do sistema desse modo a quantidade de informa es que devemos gerenciar aumenta Dom nio do Problema Dom nio da Solu o Requisitos de Software Figura 1 Caracter sticas na pir mide de requisitos Al m disso a equipe deve agora tamb m se preocupar com v rios outros assuntos que s o nicos no espa o da solu o mas que t m um pouco a ver com o dom nio do problema Por exemplo se n s estivermos desenvolvendo um produto de software para ser vendido ao usu rio devemos nos preocupar com empacotamento instala o e licenciamento cada um dos quais podem ser nicos para a solu o que estamos fornecendo Se estivermos desenvolvendo um sistema para atender as necessidades de IS IT na empresa do cliente pode ser que precisemos nos preocupar com os requisitos de implanta o e manuten o os quais s o de pouco ou nenhum interesse ao usu rio que n o est usando o sistema 123 No entanto devemos ainda manter a abstra o suficientemente alta para n o nos perdermos em detalhes muito rapidamente n o nos permitindo ver a floresta entre as rvores Al m disso importante parar por um segundo para organizar as informa es de requisitos antes de nos movermos de se o da pir mide de requis
172. have de Controle ter que ter em fun o da UCC Este conjunto de requisitos derivado da nossa decomposi o do sistema HOLIS 2000 0000 L Propriet rio Programador PC j opcional Unidade de Controle Central Programador Figura 6 9 Subsistema Programador PC com seus atores Na Figura 6 9 a perspectiva do sistema sob o ponto de vista do Programador PC n s vemos que n o aprendemos qualquer coisa nova ao menos em termos de atores e subsistemas eles foram todos identificados anteriormente A Figura 6 10 no entanto apresenta se uma vis o um pouco mais rica e n s vemos que UCC possui mais atores do que qualquer outro Isso parece fazer sentido se n s pensarmos que a UCC o c rebro do HOLIS e faz sentido pensar que ele tem muitas coisas a fazer e muitos atores a atender Propriet rio L mpadas Programador pr HOLIS 2000 Pro dor PC a OOOO Recebedor de opcional a NE HR Emerg ncias TBD OO O Unidade de OO Controle Central Servi os da Chave de Lumenations Controle Figura 6 10 Subsistema Unidade Controle Central com seus atores 59 Tabela 6 2 Restri es do projeto HOLIS ID Nome l A vers o 1 0 dever ser liberada para manufatura em 5 de Janeiro de 2000 A equipe deve adotar a modelagem UML m todos baseados em OO e o Processo de Desenvolvimento Unificado O software para a Unidade de Controle Central e o Programador PC devem ser escritos em C A linguag
173. haves desse processo registrados nesse documento O documento da Vis o descreve a aplica o em termos gerais incluindo descri es do mercado alvo dos usu rios do sistema e das caracter sticas da aplica o Por anos vimos constatando a utilidade deste documento tanto que o desenvolvimento deste documento tornou se para n s um padr o de melhor pr tica na defini o de uma aplica o de software Componentes do Documento da Vis o O documento da Vis o talvez o unico documento mais importante de um projeto de software captura as necessidades do usu rio as caracter sticas do sistema e outros requisitos comuns do projeto Como tal o escopo do documento da Vis o estende sobre os dois primeiros n veis da pir mide de requisitos atrav s dos quais define se num n vel alto de abstra o tanto o problema quando a solu o 133 LN LN Escopo do documento da vis o Para um produto de software o documento da Vis o tamb m serve de base para a discuss o e contrato entre as tr s principais comunidades de stakeholders do projeto 1 O departamento de marketing que serve como representante de clientes e usu rios e que no final ser o respons vel pelo sucesso do produto ap s a sua libera o 2 A equipe de projeto que desenvolver a aplica o 3 A equipe de gerenciamento a qual ser respons vel pelos resultados do esfor o de neg cio O documento da Vis o poderoso porque ele representa
174. hrey observou que a complexidade ultrapassa a nossa habilidade de resolver problemas intuitivamente Por exemplo estamos envolvidos num projeto de requisitos que afeta simultaneamente aproximadamente 30 produtos de uma grande fam lia de produtos Os requisitos que s o gerados influenciam em tempo real software que est o sendo escritos por mais de 400 programadores distribu dos em diversas localiza es O sucesso deste projeto depende da coordena o intensa de uma equipe de equipes todas trabalhando com uma metodologia comum para atender os desafios impostos pelos requisitos O que fazer Claramente teremos que trabalhar em equipe e trabalhar bem Como Boehm 1981 concluiu em seu modelo de estimativas de custo COCOMO a capacidade da equipe tem grande impacto na produ o de software Davis 1995b sustenta em sua discuss o sobre produtividade da equipe otimizar a produtividade de todos os indiv duos n o resulta necessariamente na otimiza o da produtividade da equipe p gina 170 Assim parece l gico investir algum recurso para tornar a equipe de software mais produtiva Habilidades da Equipe de Requisitos para o Gerenciamento Efetivo de Requisitos Este m dulo foi organizado em fun o de 6 habilidades de equipe necess rias para uma equipe moderna de software enfrentar os desafios de requisitos e Na Habilidade de Equipe 1 Analisando o Problema n s desenvolvemos um conjunto de t cnicas que a equipe p
175. i o e concordou em explorar o esfor o necess rio para alcan ar a internacionaliza o na release 1 0 Este assunto demonstra que um dos problemas com a vota o acumulativa Nem todos os stakeholders s o criados igualmente Falhas em atingir a internacionaliza o que n o havia aparecido no visor do radar da equipe antes do workshop poderia se tornar um equivoco de requisitos estrat gicos de propor es significativas 99 Cap tulo 12 Storyboarding Pontos chaves e O prop sito do storyboarding elucidar as rea es iniciais Sim mas e Os storyboards podem ser passivos ativos ou interativos e Cs storyboards identificam os jogadores explicam o que acontece com eles e descreve como acontece e Fazer com que o esbo o do storyboard seja f cil de modificar e n o dispon vel e Os storyboards iniciais s o comuns em todos os projetos que tenham conte dos novos e inovadores alvez nenhuma outra t cnica de elucida o tenha recebido tantas interpreta es quanto o storyboarding Apesar disso v rias dessas interpreta es concordam com o prop sito do storyboarding que o de descobrir as rea es Iniciais dos usu rios sobre o conceito proposto pela aplica o Ao fazer isso storyboards oferecem uma das t cnicas mais efetivas de atacar a sindrome Sim mas Com o storyboarding as rea es dos usu rios podem ser observadas logo no in cio do ciclo de vida bem antes que os co
176. ibutos do sistema Desempenho Confiabilidade Taxa de transfer ncia etc Figura 23 1 Elementos do sistema is Saidas do sistema uma descri o dos perif ricos de sa da tais como sintetizador de voz ou apresenta o visual que devem ser suportados bem como o protocolo e a forma da informa o gerada pelo sistema Fun es do sistema o mapeamento das entradas e sa das e suas v rias combina es Atributos do sistema tais como requisitos n o comportamentais t picos como confiabilidade facilidade de manuten o disponibilidade e taxa de transfer ncia que os desenvolvedores devem levar em considera o Atributos do ambiente do sistema s o os requisitos n o comportamentais adicionais como a habilidade do sistema operar dentro de certas restri es de opera o carga e compatibilidade com o sistema operacional N s usamos esta categoriza o h v rios anos e achamos que funciona muito bem pois ela nos ajuda a pensar sobre o problema de requisitos de maneira consistente e completa De acordo com 1sso podemos determinar um conjunto completo de requisitos de software definindo e Entradas do sistema e Sa das do sistema e Fun es do sistema e Atributos do sistema e Atributos do ambiente do sistema r Al m disso estaremos aptos a avaliar se uma coisa um requisito de software confrontando a com esta defini o 181 Documento da Vis o Ed Relacionamentos
177. ie os dados entre 2 dias e semana de anteced ncia De qualquer forma muito prov vel que os participantes s ler o o plano no ltimo minuto Tudo bem isso ajudar a preparar o estado de esp rito para a sess o Para ajudar voc com o pensamento out of box e auxiliar a configurar o contexto das atividades do workshop n s fornecemos um modelo de um memorando na Figura 10 1 Entre par nteses n s iremos tamb m ler entre linhas partes do texto para entender alguns desafios que voc pode enfrentar em seu projeto e sobre como o workshop pretende atac lo 82 Memorando Para Stakeholder do projeto Assunto Realiza o do Workshop de Requisitos De Nome do Lider de Projeto Eu sou o gerente de projeto produto O projeto foi ou ir ser iniciado em e ser finalizado na data de N s sabemos n s entendemos e pretendemos finalizar nesse per odo Como em muitos projetos temos dificuldades de chegar a um consenso sobre as novas caracter sticas desta aplica o e em definir uma vers o inicial que atenda as necessidades de nossos diversos grupos de stakeholders E muito dif cil chegar a um acordo sobre qualquer coisa com este grupo ent o n s estamos tentando algo um pouco diferente e aqui est o que isso A fim de facilitar este processo n s estamos organizando um workshop de requisitos em O objetivo deste workshop de fechar as novas caracter sticas para a pr xima vers o do
178. imos em grupo sobre o sistema workshops n s apresentamos nossas id ias sobre o sistema storyboard e n s analisamos como os atores interagem com o sistema use cases Todas essas t cnicas s o boas elas definem uma estrutura para a nossa compreens o Mas vamos admitir n s n o experimentamos o sistema Neste cap tulo n s discutimos o role playmg o qual permite a equipe de desenvolvimento experimentar diretamente o mundo do usu rio pela interpreta o do papel do usu rio O conceito por detr s do role playing muito simples Embora seja verdade que a observa o e o questionamento auxiliam o entendimento seria ingenuidade assumir que apenas atraves da observa o o desenvolvedor analista possa chegar verdade entendendo em profundidade o problema a ser resolvido ou atraves disso entender claramente os requisitos do sistema que deve solucionar o problema Esta uma das causas prim rias do problema Sim mas Como os soci logos nos ensinam todos n s vemos o mundo atrav s de nosso nico filtro conceitual imposs vel separar as nossas experi ncias de vida e influ ncias culturais das observa es que fazemos Por exemplo podemos observar uma outra cultura realizando uma cerim nia ritual stica quando quisermos mas provavelmente ser imposs vel entendermos o que eles significam O que isso significa para a nossa busca por entender requisitos Devemos entender que muitos usu rios n o conseguem
179. io sagrada e GG O SA UA SAS A Uai 15 Caracteiisticas EOT E daria EE E EEE EE E E O E E E E A A E E TT 15 Requisitos de SOW abe rri aa o ra aE N E RA NP E A ANEAN NO OA EO EATON E E 15 Uma lntroducioAos Use Cases san rann e e E a E E a E a A E S 16 Resumo nspa E A a a 16 CAPITULOS usa OG ENR 17 A EQUIPE DE SOFTWARE sec e reeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaa aaa ESEESE ESEESE eenean 17 Desenvolvimento de Software como uma Atividade de Equipe eee 18 Habilidades da Equipe de Requisitos para o Gerenciamento Efetivo de Requisitos ee sseseseeesersessrrsssretssrrerssrerrssrerrerterrereensereessrreessrreessrees 18 Membrosda Eduipepos ucni Habilidades DistntAs inaire inaa aa E E S E S A A 19 A Organizacao da Equipe de SOFIWare iiri t ira a EA AE lo A Go aa A SOA aca 19 O Caso de ESTUDO eenaa a ae dd 20 Escopodo Caso de E sind oira eE E E O N EE A E OENE AE E E N E EOE E ada 20 Equpede Desenvolvimento do Software TOLLIS Lea aena a a ea dns 21 DUTO socios is ind sa a 22 HABILIDADE DE EOUIPE Dici ENEE ET 23 ANALISANDO O PROBLEMA ear erre era a aeee re era a aaa r arara Eeee rr rare eee steere 23 CAPITULO A a aa a die 25 Os Cinco PASSOS DA AN LISE DO PROBLEMA eee 25 Passo 1 Chegar ao Acordo sobre a Defini o do Problema 26 e Deciarncio do PRO jlGn alas do ns rea s ODE SUA cede EA a de URL O RA Sa a ERA de a 21 Passo 2 Entender a causa raiz do problema o problema po
180. itos de software Isso ser visto na Habilidade de Equipe 5 Refinando a Defini o do Sistema Por agora iremos cobrir a organiza o das informa es de requisitos Capitulo 16 a defini o de uma vis o Cap tulo 17 e a organiza o de nossa equipe para atacar os desafios de gerenciamento de requisitos para o sistema Cap tulo 18 124 Cap tulo 16 Organizando Informa es de Requisitos Pontos chaves e Para aplica es n o triviais requisitos devem ser capturados e registrados numa base de dados de documentos modelos e ferramentas e Tipos diferentes de projetos requerem diferentes t cnicas de organiza o de requisitos e Sistemas complexos exigem especifica o de requisitos para cada subsistema equisitos devem ser capturados e documentados Se voc for um desenvolvedor solit rio de um sistema no qual tamb m ser o usu rio e o mantenedor voc pode pensar em fazer o projeto e a codifica o imediatamente ap s identificar suas necessidades No entanto poucos desenvolvimentos de sistemas s o assim t o simples E muito prov vel que desenvolvedores e usu rios sejam mutuamente exclusivos e que stakeholders usu rios desenvolvedores analistas testers arquitetos e outros membros da equipe estejam envolvidos Todos devem chegar a um acordo sobre o sistema que ser desenvolvido A realidade do or amento e do cronograma n o torna razo vel satisfazer todas as necessidades do usu rio em qualq
181. itos do sistema requisitos do sistema requisitos do sistema para o Subsistema A 1 para o Subsistema A 2 para o Subsistema C 1 para o Subsistema C 2 Figura 16 2 Hierarquia de especifica es resultante do projeto de sistemas Especifica o geral dos Requisitos do sistema Especifica o dos Especifica o dos Especifica o dos requisitos do sistema requisitos do sistema requisitos do sistema para o Subsistema A para o Subsistema B para o Subsistema C Especifica o dos Especifica o dos Especifica o dos Especifica o dos requisitos do sistema requisitos do sistema requisitos do sistema requisitos do sistema para o Subsistema A 1 para o Subsistema A 2 para o Subsistema C 1 para o Subsistema C 2 Subsistema A 2 Subsistema A 2 Especifica o dos re Especifica o dos re quisitos de hardware quisitos de software Figura 16 3 Hierarquia de especifica es resultante do projeto de sistemas incluindo os n veis de software e hardware 128 Requisitos de Organiza o para Fam lia de Produtos Muitas ind strias constroem conjuntos de produtos intimamente relacionados que cont m funcionalidades em comuns mas com cada um contendo algumas caracter sticas pr prias Exemplos de tas fam lias de produtos pode ser sistemas de controle de invent rio m quinas de respostas telef nicas sistemas de alarme contra ladr es entre outros Como exemplo suponha que voc esteja construindo um conjunto de produtos de softw
182. lders tendem a serem encontrados al m do escopo de neg cio ou nos arredores do ambiente de uma particular aplica o Ainda em outros casos esses stakeholders ser o removidos do ambiente da aplica o Incluem se por exemplo as pessoas e organiza es envolvidas no desenvolvimento do sistema subcontratados os clientes dos clientes ag ncias externas tais como a FAA U S Federal Aviation Administration ou a FDA Food and Drug 30 Administration ou outras ag ncias que interagem com o sistema ou com o processo de desenvolvimento Cada uma dessas classes de stakeholders pode influenciar os requisitos do sistema ou ir de alguma forma estar envolvida com os resultados do sistema O entendimento de quem s o os stakeholders e de suas necessidades particulares um Stakeholders que o E o q fator importante para o desenvolvimento de uma solu o efetiva Dependendo do n o s o usu rios ne E i i i devem tamb m ser dom nio de especialidade da equipe de desenvolvimento identificar stakeholders pode ser identificados e uma tarefa trivial ou n o na an lise do problema Freq entemente isso envolve tratados simplesmente entrevistar as pessoas que decidem usu rios potenciais outras partes interessadas As seguintes quest es podem ser teis nesse processo Quem s o os usu rios do sistema Quem o cliente aquele que paga do sistema Quem mais ser afetado pelas sa das que o sistema i
183. les que afetam o comportamento do sistema no ambiente do usu rio No fim n s investimos mais na prioriza o gerenciamento e identifica o de requisitos de subsistemas do que naqueles que afetam o usu rio final Isso n o parece ser uma coisa completamente positiva E o que acontece se n s n o fizermos um bom trabalho de engenharia de sistemas O sistema se tornar fr gil e resistir a mudan as porque o peso das propriedades de requisitos ir amarrar nossa implementa o Os nossos requisitos de subsistemas tomar o o controle da flexibilidade de projeto e uma mudan a num subsistema afetar outros subsistemas esse o sistema de chamin s da legenda e como tal resistente a mudan as Em interfaces de subsistemas o problema pode ser pior Se as interfaces n o forem especificadas apropriadamente o sistema se tornar fr gil e n o estar apto a evoluir para atender as necessidades de mudan as a menos que sejam feitas substanciais altera es nas interfaces e em todos os subsistemas dos quais dependem dessas interfaces Quando Subsistemas S o Subcontratos Surge mais uma outra complica o Uma vez que subsistemas s o normalmente desenvolvidos por diferentes equipes a final de contas esta uma das raz es de criarmos subsistemas os requisitos de subsistemas e interfaces tendem por sua vez a se tornarem contratos entre as equipes Meu subsistema apresenta os resultados da computa o de ve
184. lhor iniciar logo a implementa o porque estamos atrasados no cronograma e temos pressa N s podemos determinar os requisitos mais tarde Mas quase sempre esta abordagem embora bem intencionada degenera se para um esfor o de desenvolvimento ca tico sem nenhuma seguran a sobre o que o usu rio realmente deseja ou o que o sistema assim constru do realmente faz Com o potencial das ferramentas de prototipa o de f cil utiliza o existe a percep o de que se os desenvolvedores podem construir um rascunho aproximado do que os usu rios desejam num prot tipo o usu rio pode indicar as caracter sticas que necessitam ser adicionadas removidas ou modificadas Isso pode funcionar e um importante aspecto do desenvolvimento interativo Mas devido em parte ao extremo custo em corrigir erros de requisitos este processo precisa fazer parte do contexto global da estrat gia de gerenciamento de requisitos caso contr rio resultar no caos Como saberemos o que o sistema dever fazer Como manteremos a trilha do estado atual dos requisitos Como determinar o impacto de uma mudan a Devido a quest es como essas o gerenciamento de requisitos come ou a emergir como uma disciplina de engenharia de software pr tica N s introduzimos uma filosofia confinada ao gerenctamento de requisitos e fornecemos um conjunto de defini es que sustentam tais atividades Visto que a hist ria do desenvolvimento de software bem como o futuro
185. lmente Gerenciando a Complexidade Escolhendo o N vel de Abstra o O n mero de caracteristicas que consideramos para n s mesmos ir efetivamente determinar o n vel de abstra o da defini o Para gerenciar a complexidade de sistemas que estamos vislumbrando seja de um novo sistema ou incremento de um sistema existente recomendamos que existam entre 25 a 99 caracter sticas abstraidas em n vel suficientemente alto sendo melhor pouco menos de 50 Desta forma uma quantidade relativamente pequena e gerenci vel de informa es fornecem a base compreensiva e completa para a defini o do produto a comunica o com os stakeholders o gerenciamento de escopo e o gerenciamento de projeto Com 25 a 99 caracter sticas convenientemente categorizadas e organizadas podemos estar aptos a descrever e comunicar a estrutura do sistema do nibus espacial reentrada e reuso ou de uma ferramenta de software tend ncia autom tica de defeitos Em Habilidade de Equipe 5 tais caracter sticas ser o transformadas em requisitos espec ficos suficientemente detalhadas para permitir a implementa o N s iremos chamar aqueles de requisitos de software para diferenci los de outras caracter sticas de alto n vel N s iremos lidar com estas necessidades para incrementar a especifica o posteriormente Por agora no entanto n s iremos manter nosso pensamento em n vel de caracter sticas Atributos das Caracter sticas do
186. lo do mundo real uma empresa chamada GoodsAreUs vende produtos atrav s de cat logos enviados por e mail manufatura e vende uma variedade de itens baratos para uso residencial e pessoal Essa empresa mobilizada para atacar o problema de baixa lucratividade utiliza t cnicas de gerenciamento de qualidade total TQM aprendido em seu programa de qualidade para solucionar o problema Baseada em sua experi ncia a empresa rapidamente concentrou seu foco para o custo da n o conformidade que o custo de todas as coisas que est o erradas e que geram perdas detritos e outros custos excessivos Este custo inclui o re trabalho detritos insatisfa o de clientes rotatividade de empregados e outros fatores que contribuem negativamente Quando a empresa quantificou seu custo de n o conformidade suspeitou que as perdas na produ o ou desperd cio era um dos principais fatores que contribu am para a baixa lucratividade da empresa O pr ximo passo para descobrir a causa raiz ou o problema por detr s do problema de desperd cio determinar quais fatores contribuem para o problema de desperd cio O TQM nos ensina que devemos usar o diagrama espinha de peixe veja a Figura 4 1 para identificar o problema por detr s do problema Em nossa an lise espec fica a empresa identificou muitas fontes que contribu fam para o desperd cio Cada fonte foi identificada em cada um dos ossos do diagrama Muito bem ent o como voc d
187. locidade instant nea neste exato formato De fato em alguns casos um subsistema pode ser desenvolvido por um subcontratado cuja nota fiscal possui um logotipo diferente do seu Neste caso o nosso desafio de requisitos deixa o contexto t cnico e sist mico e passa a ser a da pol tica do futebol Darn Os requisitos n o podem ser mudados a menos que o contrato seja renegociado Em breve o projeto pode estar intimamente amarrado suas cal as Uma forte advert ncia Muitas tentativas de se construir grandes sistemas encontraram sua morte nas m os deste problema Fazendo o Trabalho de Corretamente O que devemos fazer Bem fazer um bom trabalho de engenharia de sistemas o objetivo principal Como participante dessa atividade de desenvolver sistemas de software Intensivos voc precisar considerar as seguintes recomenda es Desenvolver entender e manter os requisitos e use cases que permeiam os subsistemas e que descrevem a funcionalidade global do sistema em alto n vel Tais use cases fornecem o contexto de como o sistema dever trabalhar e 51 assegurar que voc n o se perdeu na floresta entre as rvores Eles tamb m ajudar o a assegurar que a arquitetura do sistema foi projetada para sustentar os principais cen rios Fa a o melhor trabalho poss vel de particionar e isolar funcionalidades de subsistemas Use princ pios da tecnologia de objetos encapsulamento e ocultamento
188. lto Baixo gerenciamento de vers es 160 As caracter sticas que est o abaixo do baseline s o agora caracteristicas futuras e ser o consideradas nas pr ximas releases Tais caracter sticas podem posteriormente ser promovidas com prioridade maior levando se em considera o os itens que poder o ser realizados em m dio prazo e nas futuras solicita es do cliente Naturalmente as caracter sticas n o s o sempre independentes Muitas vezes algumas caracter sticas abaixo do baseline parte integrante de algumas caracter sticas que est o acima do baseline ou podem ser implementadas mais prontamente como um resultado de ter realizado uma outra caracter stica Ou quem sabe a equipe de projeto seja excelente ou esteja com sorte e realize as caracter sticas al m do cronograma previsto uma no o conceb vel ou encontre uma biblioteca de classes que torne f cil implementar as caracter sticas abaixo do baseline Nesses casos a equipe deve estar autorizada a trazer tais caracter sticas para dentro do baseline incluindo as na release corrente refazer a prioriza o e redefinir o baseline desde que se sujeitem naturalmente a comunicar tais altera es aos clientes Dessa forma a equipe deveria estar apta a criar um plano de projeto ao menos uma primeira vers o aproxima o No entanto em todos os casos muitas caracter sticas desejadas foram cortadas e ser necess rio gerenciar as expectativas seja de dentr
189. m cia O cliente era um fabricante da Fortune 1000 o fornecedor a nossa empresa havia sido contratada para desenvolver este novo produto um sistema eletromec nico ptico complexo para controle de flu dos O projeto estava com problemas Um dia o chefe dos gerentes do projeto contratado o chamaremos de autor recebeu a seguinte chamada telef nica da ger ncia superior do cliente um vice 104 presidente S nior Sr Big uma pessoa poderosa quem n s nunca hav amos conhecido antes Sr Big Autor como anda o nosso projeto favorito Autor N o muito bem Sr Big Estou ouvindo direito Tudo bem n o existe problema grande o suficiente que n o possa ser resolvido Re na sua equipe evenha at aqui para uma reuni o Que tal na quarta feira Autor afobadamente folheando a agenda da equipe para quarta feira Quarta feira est perfeito Sr Big Excelente Venha e traga toda a sua equipe Outra coisa n o se preocupe com os custos de viagem N s cobriremos Pro inferno Compre aquelas passagens s de ida Autor Engolindo seco Est bem obrigado N s nos veremos na quarta No dia indicado n s entramos num grande sal o de confer ncia com a equipe de projeto do cliente todos sentados na extremidade remota A equipe claramente estava reunida j algum tempo Quest o Por que a equipe sentiu necessidade de se reunir antes que a verdadeira reuni o come asse O Autor que n o um marinheiro de
190. m GUT e Eu quero um ve culo com ABS Denominamos essas express es de alto n vel sobre o comportamento desejado do sistema de caracteristicas features Essas caracter sticas n o s o normalmente bem definidos e podem at serem conflitantes entre si Eu quero aumentar a m dia de processamento de pedidos e Eu quero fornecer uma interface amig vel para ajudar os novos empregados aprenderem a usar o sistema mas eles s o no entanto uma representa o das reais necessidades O que est acontecendo nesta discuss o O stakeholder j traduziu a necessidade real produtividade e seguran a no comportamento do sistema o qual ele acha que ir atender s suas necessidades veja Figura 8 1 Ao fazer isso o o que Eu necessito foi substitu do pelo como O que eu penso que o sistema deva fazer para satisfazer esta necessidade Isso n o uma coisa ruim nas vezes quando o usu rio tem real especialidade do dom nio e real percep o do valor da caracter stica Tamb m por causa da facilidade de se discutir tais caracter sticas em linguagem natural document las e comunic las aos outros adicionam tremenda riqueza ao esquema de requisitos Necessidade LU Caracter stica Requisitos de Software Figura 8 1 As necessidades e caracter sticas est o intimamente relacionadas 69 Caracter sticas s o formas convenientes de descrever as funcionalidades sem ter que se
191. ma ir para o mercado Fo software n o o hardware que ir absorver a maioria das mudan as ocorridas durante o desenvolvimento de sistemas e que ser evolu do no passar dos anos para atender as necessidades por mudan as do sistema E talvez o mais surpreendente Os custos do desenvolvimento e manuten o de software definem os custos agregados e amortizados durante o ciclo de vida do produto tornando se o principal componente na forma o dos pre os de venda dos produtos em alguns casos igual ou maior que o do hardware tal que se tornou o santo gral dos fabricantes de sistemas custo total de fabrica o Este ltimo fato deu o golpe de miseric rdia pois indica que voc deve considerar para otimiza o dos custos do sistema n o o hardware ou manufatura mas o desenvolvimento manuten o evolu o e aprimoramento de software contidos no sistema Isso mudou significativamente o jogo Por agora a engenharia de sistemas deve ser realizada considerando o computador a ser utilizado Isso significa que a engenharia de sistemas deve normalmente Maximizar a habilidade de executar software fornecendo mais do que recursos adequados de computa o mas adicionando mais microprocessadores RAM ROM mem ria de armazenamento de massa largura de banda ou quaisquer recursos que o sistema necessite para executar seu software e ajudar a reduzir o custo de venda de produtos Fornecer interfaces de comunica o adequada
192. maginar quanto desse total temos reais condi es de fazer e conseq entemente n o temos condi es de tra ar o baseline do projeto O pr ximo passo estabelecer de maneira aproximada o esfor o necess rio para implementar cada uma das caracter sticas do baseline proposto Vale lembrar que nesta fase existem poucas informa es dispon veis n s ainda n o detalhamos os requisitos muito menos definimos algum projeto no qual pud ssemos utilizar para balizar as nossas estimativas O melhor que podemos fazer determinar em ordem de magnitude grosseira o n vel do esfor o de cada caracter stica Estimar esfor os nesta fase precoce uma Habilidade de Equipe que aprendida Naturalmente a equipe de engenharia relutar em fornecer estimativas sem que as caracter sticas e requisitos tenham sido totalmente entendidos Por m este primeiro corte durante o gerenciamento de escopo deve ocorrer antes que esses detalhes sejam conhecidos Permita nos assumir que o gerente de produto ou de projeto seja o campe o de nosso projeto e que tenha o seguinte di logo com os desenvolvedores do projeto 7 A equipe pode querer usar equipe semanas ou equipe meses como uma estimativa aproximada do impacto total de uma caracter stica sobre o projeto Esta heur stica grosseira serve como substituto para uma estimativa mais detalhada e comprovadamente melhor do que o resultado deste di logo Assim aos usar estes tot
193. mente a t cnica do question rio pode tamb m exercer um papel leg timo na obten o das necessidades needs do usu rio Embora a t cnica do question rio seja frequentemente usada e pare a cient fico por causa da oportunidade de se fazer an lise estat stica de resultados quantitativos a t cnica n o substitui a entrevista Quando aplicada na obten o de requisitos a t cnica do question rio apresenta alguns problemas fundamentais Quest es relevantes podem n o ser levada adiante As suposi es por detr s das quest es influenciam as respostas Exemplo Esta classe atende a suas expectativas Suposi o Que a pessoa possui expectativas dif cil explorar novos dom nios O que voc realmente deveria ter perguntado e n o existe intera o para explorar dominios que precisam ser explorados Respostas n o claras do usu rio s o dificeis de perseguir De fato alguns conclu ram que a t cnica do question rio suprime quase todas as coisas boas da obten o de requisitos e assim n s geralmente n o a recomendamos para este prop sito No entanto a t cnica do question rio pode ser aplicada com bons resultados ap s a entrevista Inicial e atividades de an lise Por exemplo se a aplica o tiver v rios usu rios em potencial ou existente e se a meta obter informa es estat sticas das prefer ncias de usu rios ou clientes entre um conjunto limitado de escolhas o question rio pode ser
194. mente para melhor prepar lo N s precisamos que voc esteja aqui para contribuir e nos ajudar a conduzir este projeto de maneira apropriada Certo de poder contar com a vossa participa o agrade o antecipadamente Cordialmente Nome do Lider de Projeto Figura 10 1 Exemplo de memorando para r pido in cio de um workshop de requisitos 83 Papel do Facilitador Se poss vel tenha um facilitador que n o seja da equipe para executar o workshop Para garantir o sucesso n s recomendamos que o workshop seja executado por algu m de fora e que tenha experi ncia em enfrentar os desafios do processo de gerenciamento de requisitos No entanto se isso n o for uma alternativa pr tica em seu ambiente o workshop pode ser facilitado por um membro da equipe desde que esta pessoa Tenha recebido algum treinamento neste processo Tenha solidamente demonstrado habilidade de construir consenso ou equipe Seja elegante e bem respeitado tanto pelos membros internos quanto externos Seja forte o suficiente para conduzir a reuni o a qual pode ser um encontro desafiador No entanto se o workshop for facilitado por um membro da equipe essa pessoa n o deve contribuir com id ias e assuntos da reuni o Caso contr rio o workshop estar em grave perigo de perder a objetividade que necess ria para obter os fatos reais e pode n o estimular um verdadeiro ambiente onde o consenso possa emergir Em alguns casos
195. mpadas quando a porta for aberta 55 Baixo Alto 3 Interface com o sistema de seguran a residencial 52 Alto Alto 2 Facilidade para instalar 50 M dio M dio 18 Ligar automaticamente as luzes quando algu m bate a porta 50 M dio M dio 7 Ligar e desligar instant neo 44 Alto Alto 11 Poder dirigir cortinas sombras bomba d gua e motores 44 Baixo Baixo 15 Controlar a ilumina o via telefone 44 Alto Alto 10 Interface com o sistema de automa o residencial 43 Alto Alto 22 Modo gradual aumento ou redu o da luminosidade lentamente 34 M dio Baixo 26 Esta o de controle principal 31 Alto Alto 12 Facilidade de expans o quando remodelado 25 M dio M dio 25 Interface de usu rio internacionalizado 24 M dio Alto 21 Interface com o sistema de udio v deo 23 Alto Alto 24 Restaura o ap s falha no fornecimento de energia el trica 23 N A N A 17 Controle HVAC 22 Alto Alto 28 Ativa o via voz 7 Alto Alto 27 Apresenta o no web site do usu rio 4 M dio Baixo Ent o com base na atividade de estimativa revisada a equipe prop s o baseline apresentado na Tabela 20 7 Este baseline foi proposto e enviado para todos da equipe executiva onde Emily a VP vice presidente tomar a decis o final Entretanto antes de fazer isso ela precisa que a equipe apresente os detalhes do plano de projeto para que ela possa ver as depend ncias A equipe suspeita de que o que ela realmente quer ver se a li o de casa foi realizada ou se
196. nar o pr ximo baseline Al m disso esta a hora de fazer o plano detalhado do projeto para validar as suposi es que fizemos No entanto pela nossa experi ncia tra ar o baseline contendo apenas os requisitos cr ticos e incluir um ou dois itens importantes suficiente para muitos projetos do mundo real Deixe que a equipe de desenvolvimento decida quais itens importantes ir o incluir durante o progresso do projeto Clora isso n o cient fico Por m funciona Se as expectativas forem estabelecidas e gerenciadas corretamente qualquer coisa que possa ser executada num futuro baseline ser um b nus A Tabela 20 5 aplica esta simples heur stica ao baseline de nosso projeto exemplo Tabela 20 5 Lista de caracter sticas priorizadas Caracter stica Prioridade Esfor o Risco Caracter stica 1 Suporte a BD relacional externo Cr tica M dio Baixo Caracter stica 4 Interface para releases de novos SO Cr tica Alto M dio Caracter stica 6 Importa o de dados externos por estilo Cr tica Baixo Alto Caracter stica 3 Habilidade de clonar um projeto Importante M dio M dio Baseline as caracter sticas acima desta linha s o caracter sticas acordadas com o cliente Caracter stica 2 Seguran a multiusu rio Importante Baixo Alto Caracter stica 5 Assistente de novos projetos Importante Baixo Baixo Caracter stica 7 Implementar ferramenta de dicas til Baixo Alto Caracter stica 8 Integrar com o subsistema de til A
197. nceitos tenham comprometido o c digo e em muitos casos at antes que as especifica es detalhadas tenham sido desenvolvidas Os especialistas em fatores humanos por anos nos t m dito que o poder dos storyboards n o deve ser subestimado De fato a ind stria do cinema tem usado esta t cnica desde que a primeira centelha de luz foi projetada na tela Os storyboarding efetivos aplicam ferramentas que s o baratas e f ceis de usar O storyboarding extremamente barato amig vel informal e interativo Fornece uma revis o inicial das interfaces de usu rio do sistema f cil de criar e modificar Os storyboards s o tamb m uma forma poderosa de facilitar a sindrome da p gina branca Quando os usu rios n o sabem o que querem at um storyboard muito pobre bom para elucidar uma resposta como N o isto n o o que eu queria deveria ser o seguinte e o Jogo come a Storyboards podem ser usados para acelerar o desenvolvimento conceitual de v rias diferentes facetas de uma aplica o Storyboards podem ser usados para entender a visualiza o de dados para definir e entender as regras de neg cio que ser o implementadas numa nova aplica o de neg cio para definir algoritmos e outras constru es matem ticas que ser o executados dentro de um sistema embutido ou para demonstrar relat rios e outras sa das impressas da revis o inicial De fato os storyboards podem e devem ser usados
198. nd ncia ser apresentada num relat rio escrito em Visual Basic contendo um histograma informando o tempo no eixo x e o n mero de defeitos encontrados no eixo y veja a figura 23 2 183 Bi E Muito despedicio j E Dificuldade de reciclagem O Impacto ambiental E O Recursos naturais limitados o E Fessoas podem fazer dinheiro N mero de Defeitos 10 E Outras raz es Fatores que Contribuiem Figura 23 2 Diagrama de Pareto Embora a refer ncia linguagem Visual Basic pare a ser uma viola o bastante grosseira das orienta es recomendadas pois n o representa uma entrada sa da fun o ou atributo comportamental til perguntar Quem decidiu impor o requisito de que o histograma deve ser implementado em Visual Basic e por que foi tomada essa decis o As poss veis respostas para esta quest o podem ser e Um dos membros do grupo com alguma orienta o t cnica e que est definindo o documento da Vis o decidiu que o Visual Basic deveria ser especificado porque a melhor solu o para o problema e O usu rio pode ter especificado Sabendo que a tecnologia pode gerar preju zos o usu rio quis que a tecnologia VB fosse usada O usu rio n o quer que uma outra tecnologia uma mais cara ou menos dispon vel fosse adotada pelas pessoas t cnicas pois ele sabe que o VB est dispon vel e relativamente barato e Uma decis o pol tica interna da organiza o de desenvolvimento po
199. ndidas Deixe me ser honesto Todos n s j passamos por isto Felizmente isso n o tem que ser assim Ao inv s disso podemos engajar ativamente nossos clientes no gerenciamento de seus requisitos e do seu escopo de projeto para garantir a qualidade e pontualidade na libera o do software Esta conclus o baseia se em algumas percep es importantes Os nossos clientes s o os principais interessados em atender seus compromissos financeiros com o seu mercado externo Assim liberar uma aplica o de alta qualidade e se necess rio de escopo reduzido dentro do cronograma e or amento o maior benef cio que a equipe pode fornecer A aplica o as suas caracter sticas chaves e as necessidades de neg cio pertencem todos aos clientes e n o equipe de desenvolvimento da aplica o Precisamos que clientes nos d em informa es para podemos tomar decis es s eles podem verdadeiramente determinar como gerenciar o escopo e chegar a um resultado til N s somos os seus humildes servos tecnol gicos O projeto deles Comunicando os Resultados Se o escopo do projeto tiver que ser reduzido assegure se que o cliente esteja participando desse processo ativamente Um cliente que fa a parte do processo ir se responsabilizar pelos resultados obtidos Um cliente exclu do desse processo 164 n o ficar feliz com os resultados e ira naturalmente culpar os desenvolvedores por n o terem se empenhado suficienteme
200. ndo Use Cases para Elucida o de Requisitos eeeeeerreeio 109 Caso de Estudos Os Use Cases do HOLIS eee eee eereeaaeeees 110 SUMA O N R O a N Ta 111 CAPITULO Ao a R E T T E 112 ROLE PLAYING 2 A AAT A E AEAEE A 112 Como Interpretar o Papel eae eterna reto erre ttet esett tree E raet EEEE ESPEN EEEE EEREN EEEE Eese rr ret 113 T cnicas Similares ao Role Playing sesnsssersssssrssssrrisssssresssrrrssssrrrsssrrrsssrrrsssrrrrssen 114 Roteifode com panhamento a O A a R 114 Cartoes CRE Clisse RespaansablidideColaDOrI AO suas eer a A RE AE SIS OSS RUE 114 QUINT O EAE A NEE N AAA A a A a aa RR 115 CAPITULO Sassi ro an SD 116 PROTOTIPA O Ss Riad oe dE ia ai GC A Cc t SR Ra RR 116 Tipos de ProtOUIDOS a as ADS SS la EE 116 Prot tipos de Requisitos eee ee tee erre aeee tecer anna neto cera EEEE EEEE EEEEEEEEEEEEEEEEEEEEE EEEE EE EEEa Erre 117 Oque PrOLOTIDAR oesie aaa o a aa e aa E a 118 Construindo o Prot tipo eesssrrrrrsseririitssstttttt testrit tetest ttre aet EEEE EEEEEEEEEEEEEEEEEEEEEE REEERE EEEE Eee 119 Avaliando os Resultados terre eee eee rere aaa aeee tr ssrt tter ssrt Erer SSs EEE re nennen ernennen nnna 119 SUMA O eana aaa a aaa o a EA 120 SUM RIO DA HABILIDADE DE EQUIPE 2 sesesesessssosesessosososesesessosososesesessosososesesesessosososesesessososesesssosososesees 121 HABILIDADE DE EQUIPE Sarcona AEE ETE E ao Damaia oia 122 DEFININDO O SISTEMA
201. nforma es de usu rios como o fator mais comum entre os desafios de projetos Embora 13 dos entrevistados tivessem citado as causas ra zes como o principal fator 12 citaram as especifica es e requisitos incompletos como fator principal A partir disso tornou se aparente que a falta de entendimento das reais necessidades dos usu rios e provavelmente de outros stakeholders representava mais de um quarto de todos os desafios de projeto e era o problema mais s rio que interferia para o sucesso do projeto A menos que num belo dia todos os usu rios do mundo acordassem repentinamente e come assem dispostos a entender e a comunicar seus requisitos a equipe de desenvolvimento ter que tomar sua iniciativa Em outras palavras nossa equipe precisar desenvolver a habilidade necess ria para elucidar esses requisitos Na Habilidade de Equipe 1 n s desenvolvemos a habilidade que ajudar a entender o problema a ser resolvido Na Habilidade de Equipe 2 n s descrevemos v rias t cnicas que a equipe de desenvolvimento pode usar para obter e entender as reais necessidades na perspectiva de usu rios e stakeholders Fazendo isso come amos a ganhar compreens o dos potenciais requisitos do sistema que pretendemos desenvolver para satisfazer essas necessidades Enquanto estivermos fazendo isso n s iremos nos concentrar principalmente nas necessidades dos stakeholders que vivem no topo da pir mide de requisitos As t cnicas
202. nicamente entre a empresa e seus fornecedores Durante o exerc cio de fazer a declara o do problema a ger ncia da empresa tinha a oportunidade de fornecer informa es A vis o dos gerentes foi substancialmente diferente O principal objetivo do novo sistema era Zransferir fundos eletronicamente para melhorar o fluxo de caixa da empresa Depois de uma discuss o acalorada ficou claro que o principal problema a ser atendido pelo novo sistema era a transfer ncia eletr nica de fundos e mail e outras caracter sticas de comunica o com fornecedores foram considerados como algo que poderia ter Desnecess rio dizer que foi uma substancial reorienta o dos objetivos do novo sistema incluindo uma nova defini o do problema que identifica a transfer ncia de fundos como principal problema a ser resolvido Esta reorienta o tamb m disparou o desenvolvimento de uma arquitetura diferente daquele que havia sido previsto o qual foi completado com a capacidade de seguran a consistente com o risco inerente ao banco eletr nico 2 Passo 2 Entender a causa raiz do problema o problema por detr s do problema Sua equipe pode usar uma variedade de t cnicas para obter um entendimento do real problema e suas reais causas Uma dessas t cnicas a an lise causa raiz a qual uma forma sistem tica de descobrir a causa raiz ou a origem de um problema identificado ou um sintoma de um problema Por exemplo considere um exemp
203. ns problemas nos cap tulos anteriores ficou claro que a equipe de desenvolvimento raramente se n o nunca tem em m os uma especifica o perfeita ou talvez razo vel que possa ser usada como base para o desenvolvimento do sistema No Cap tulo 7 aprendemos sobre as raz es disso Uma conclus o que chegamos foi que se n s n o nos prepararmos para dar as melhores defini es n s n o iremos colher os resultados Em outras palavras a fim de obter sucesso a equipe de desenvolvimento ter que interpretar mais ativamente seu papel na elucida o de requisitos Como descobrimos embora possamos delegar a maioria das responsabilidades para um l der s nior analista ou gerente de produto no final toda a equipe estar envolvida com um ou mais pontos do processo Stakeholders e Necessidades do Usu rio Parece bvio mas a equipe de desenvolvimento somente ir construir sistemas melhores quando eles entenderem as reais necessidades needs dos stakeholders Esse entendimento dar equipe a informa o que necessita para tomar melhores decis es na defini o e implementa o de sistemas Esse conjunto de informa es o qual chamamos de necessidades needs de stakeholders ou simplesmente de necessidades do usu rio fornece a pe a central do quebra cabe a Normalmente as necessidades do usu rio s o vagas e amb guas Por exemplo seu stakeholder pode dizer Eu preciso de algo f cil para saber o estado do meu est
204. nte Engajar o cliente nesse di logo ajuda a amansar o problema de gerenciar o escopo de forma extremamente gentil na porta de sua casa E com a filosofia que descrevemos no cap tulo anterior clientes inteligentes ir o se comprometer junto ao seu mercado externo apenas com os itens cr ticos inclu dos no baseline As dificuldades advindas do cronograma atrasado e caracter sticas n o implementadas ser o evitadas Quaisquer caracter sticas extras implementadas al m do baseline ser o recebidas de positivamente pois estar excedendo as expectativas Algumas vezes a descoberta do problema de gerenciamento de escopo ocorre sem que o cliente esteja engajado nesse caso h grande chance de termos que informar o nosso cliente sobre as m s not cias Informar e ou gerenciar nossos clientes um processo delicado pois requer habilidades de negocia o e total responsabilidade e comprometimento com o cronograma e escopo apresentados Ap s apresentar as m s not cias n o podemos nos permitir falhar com a nossa promessa sob a pena de no m nimo perder a nossa credibilidade Negociando com o Cliente O princ pio guia para o gerenciamento de escopo n o prometa o que provavelmente n o possa ser cumprido e liberado Quase todos os processos de neg cio requerem negocia o Considere negociar a posterga o da data de libera o com um cliente negociar um valor maior negociar o aumento anual com o seu gerente negoci
205. nto de produto e marketing de produto mas n o tinha experi ncia direta no desenvolvimento de software Depois de ouvir as respostas para a nossa quest o sobre escopo ela mostrou se incr dula Ela olhou ao redor da sala e disse N o entendi direito voc s aprovam projetos com aproximadamente duas vezes a quantidade de trabalho que pode ser razoavelmente realizado num per odo de tempo dispon vel Que tipo de profiss o esta Voc s est o loucos Os desenvolvedores trocaram olhares t midos e unanimemente responderam sim O que acontece se o projeto continuar com os 200 de escopo inicial e Se as caracter sticas da aplica o forem completamente independentes n o razo vel que apenas a metade deles funcionem quando o prazo final estiver vencido O projeto est avan ando com dificuldades mas fornece apenas a metade da funcionalidade pretendida E n o uma metade hol stica As caracter sticas n o funcionam em conjunto e n o produzem quaisquer funcionalidades agregadas que sejam teis Uma aplica o de escopo drasticamente reduzido rapidamente remendado e embarcado Como consequ ncia surgem s rias insatisfa es por parte dos clientes devido s suas expectativas n o terem sido atendidas compromissos de mercado n o poderem ser atendidas e materiais promocionais e manuais imprecisos terem que ser rapidamente retrabalhados Toda a equipe fica frustrada e desmotivada e No prazo final apenas 50 de ca
206. ntos inadequados do problema a ser resolvido Em poucos anos veremos um aumento sem precedentes no poder das ferramentas e tecnologias que os desenvolvedores de software usar o para construir aplica es empresariais Novas linguagens ir o elevar o n vel de abstra o e aumentar a produtividade de atacar e resolver problemas de usu rios A utiliza o de m todos orientados a objetos tem produzido projetos que s o mais robustos e extens veis Ferramentas de gerenciamento de vers es gerenciamento de requisitos an lise e projeto rastreamento de falhas e testes automatizados t m ajudado os desenvolvedores de software a gerenciar a complexidade de milhares de requisitos e centenas de milhares de linhas de c digos Com a eleva o da produtividade dos ambientes de desenvolvimento de software ser mais f cil desenvolver sistemas de software que atendam as reais necessidades de neg cio No entanto como vimos as pesquisas demonstram que continuamos sendo desafiados em entender e satisfazer verdadeiramente essas necessidades Talvez exista uma explica o simples para essa dificuldade o problema por detr s do problema A equipe de desenvolvimento gasta muito ponco tempo em entender os reais problemas de neg cio as necessidades dos usu rios e de outros stakeholders e a natureza do ambiente na qual suas aplica es devem ter sucesso N s desenvolvedores tendemos a avan ar constantemente fornecendo solu es tecnol gi
207. o delinear tantas id ias quanto sejam poss veis o objetivo ampliar as id ias n o necessariamente aprofund las O objetivo 89 principal da redu o de id ias aparar organizar priorizar expandir agrupar refinar e assim por diante Brainstorming Presencial Embora o brainstorming possa ser abordado de diferentes maneiras o processo simples que descrevemos provou ser efetivo em v rios cen rios Inicialmente todos os stakeholders importantes s o reunidos numa sala e recursos s o distribu dos Os recursos distribu dos a cada participante podem ser t o simples quanto um bloco de folhas de anota es e um marcador preto grosso para escrever as anota es As folhas devem ter ao menos 3 x 5 7 cm x 12 cm e n o maior que 5 x 7 12 cm x 17 cm Cada participante deve ter ao menos 25 folhas para cada sess o de brainstorming Post Its ou cart es de indices funcionam bem Se cart es de ndice s o usados s o necess rios alfinetes e quadro de isopor ou corti a Ent o as regras do brainstorming s o apresentadas veja a Figura 11 1 e o objetivo da sess o claramente e concisamente estabelecidos Regras do Brainstorming CL N o se permitem cr ticas ou debates CL Solte a imagina o Q Gere quantas id ias quanto forem poss veis Q Mude e combine id ias Figura 11 1 Regras do brainstorming O facilitador tamb m exp e os objetivos do processo Embora os objetivos que estabel
208. o Controle Bob uma mensagem assim que a chave estiver totalmente pressionada e enviarei ao Bob uma mensagem a cada segundo em que a chave ficar pressionada Bob Quando eu receber a primeira mensagem mudarei o estado da Unidade de sa da de Desligado para Ligado Quando eu receber a segunda Controle mensagem sei que o propriet rio est reduzindo a intensidade do Central banco de luz Assim a cada mensagem recebida reduzirei a intensidade da luz em 10 John n o esque a de me dizer qual bot o est pressionado Mike Eu estou fisicamente conectado sa da do dimmer Eu percebo o L mpada dimmer como n s falamos Nota Na elucida o das necessidades do usu rio o processo CRC direcionado para os comportamentos externos que s o aparentes aos atores mas esta t cnica pode tamb m ser usado para projetar sistemas orientados a objetos Neste exerc cio o foco estava em entender o trabalho interno do software n o nas intera es com o ambiente externo No entanto at nesses casos a t cnica ajuda a descobrir erros ou enganos de requisitos do sistema Voc deve ter notado um efeito colateral interessante Os jogadores invariavelmente acham que existem falhas ou defici ncias no roteiro e os corrigem resultando normalmente no aperfei oamento no entendimento do sistema Sum rio O role playing uma excelente t cnica embora n o a tenhamos visto em uso com muita frequ ncia Por que As raz es s o muitas
209. o Fazer com que a pessoa fique ciente dos assuntos pol ticos do projeto de forma divertida Que grande 5 minutos para falar Regra O participante gasta este cupom em algum momento O facilitador d a palavra ao participante e marca seu tempo Todos ouvem N o h interrup o Objetivo Viabilizar a participa o organizada Assegurar que todos d em sua opini o 86 Tabela 10 2 Problemas e solu es na configura o do workshop de requisitos Problema Gerenciamento do tempo e dif cil reiniciar as atividades ap s os intervalos e Os principais stakeholders podem se atrasar Discurso exagerado e dominador visando impressionar e receber ova o do p blico Car ncia de dos stakeholders contribui es Coment rios negativos comportamento de baixo escal o e clima de guerra Energia debilitada ap s os intervalos Solu o O facilitador mant m controle do tempo de servi os de cozinha em todos os intervalos Participantes que chegarem atrasados devem contribuir com um cupom Atraso ap s o intervalo ou pagar 1 para a caixinha de contribui es para caridade O facilitador refor a a regra 5 minutos para falar para regular o discurso Ele tamb m cria uma lista de assuntos pendentes para posteriormente poder voltar as id ias que mere am ser discutida mas que n o s o relevantes ao item do momento de acordo com a agenda O facilitador encoraja os participant
210. o normalmente n o til ter um requisito funcional declarado na forma Quando voc pressionar o bot o o sistema ativado e inicia a opera o Por outro lado uma declara o de requisito que ocupe v rias p ginas de texto provavelmente muito especifico mas pode estar correto em v rios casos especiais N s iremos retornar a essa discuss o no Cap tulo 26 N s achamos que a maioria dos requisitos funcionais pode ser descrita de forma declarativa ou na forma de use cases a qual iremos descrever no pr ximo cap tulo A experi ncia nos tem mostrado que uma ou duas senten as declarativas de um requisito normalmente a melhor maneira de satisfazer as necessidades do usu rio com um n vel de especificidade que o desenvolvedor pode lidar 187 Requisitos N o Funcionais de Software At aqui neste cap tulo a maioria dos exemplos de requisitos envolvia requisitos comportamentais ou funcionais de um sistema concentrando se nas entradas sa das e detalhes de processamento Os requisitos funcionais nos dizem como o sistema deve se comportar quando apresentado a certas entradas ou condi es Mas 1sso n o suficiente para descrever todos os requisitos de um sistema N s devemos considerar tamb m coisas que Grady 1992 chamou de requisitos n o funcionais e Usabilidade e Confiabilidade e Desempenho e Suportabilidade Esses requisitos s o usados com maior frequ ncia para expressar alguns
211. o documento e n o implementadas e program las para a vers o 2 0 Em outras palavras queremos encontrar e promover algumas caracter sticas que ser o importantes para o release 2 0 Voc pode tamb m querer programar um outro workshop de requisitos ou outros processos de elucida o a fim de descobrir novas caracter sticas que entrar o na programa o do release 2 0 e algumas novas caracter sticas futuras que precisar o ser registradas e documentadas Algumas dessas caracter sticas ser o bvias com base no retorno do cliente feedback outras ir o ser definidas com base na experi ncia da equipe Em qualquer dos casos registrar essas novas caracter sticas descobertas na vers o 2 0 do documento da Vis o ou como programadas para ser inclu das na vers o 2 0 ou como novas caracter sticas futuras Provavelmente voc descobrir que algumas caracteristicas implementadas na vers o 1 0 n o liberaram o valor pretendido seja devido a mudan as ambientais ocorridas durante o processo quando tais caracteristicas deixaram de ser necess rias seja pela substitui o por novas caracter sticas ou talvez pelo cliente que simplesmente n o necessitou dessas caracteristicas como ele pensava que iria necessitar Em qualquer caso voc provavelmente descobrir que ser necess rio remover algumas caracter sticas no pr ximo release Como registrar esses anti requisitos Simplesmente utilize o documento da Vis o para regi
212. o facilitador tem o papel central para o sucesso do workshop Afinal de contas voc est com todos os principais stakeholders reunidos talvez pela primeira vez e ltima vez no projeto e voc n o pode se permitir errar o alvo Algumas das responsabilidades do facilitador s o Estabelecer um tom profissional e objetivo para a reuni o Iniciar e finalizar a reuni o dentro do tempo Estabelecer e impingir as regras da reuni o Introduzir as metas e a agenda da reuni o Gerenciar a reuni o e manter a equipe na trilha Facilitar o processo de decis o e o consenso mas evitar participar do conte do Gerenciar qualquer instrumento e assuntos de log stica para assegurar que o foco permane a na agenda Assegurar que todos os stakeholders participem e sejam ouvidos Controlar comportamentos desordeiros ou improdutivos Preparando a Agenda A agenda do workshop ter como base as necessidades do particular projeto e no conte do que deve ser desenvolvido no workshop Ningu m preenche toda a agenda No entanto workshops de requisitos estruturados podem seguir um formato padr o claro A Tabela 10 1 fornece uma agenda t pica 84 Tabela 10 1 Exemplo de agenda para o workshop de requisitos Hora Item de Agenda Descri o 8 00 8 30 Introdu o Agenda recursos e regras 8 30 10 00 Contexto Estado do projeto necessidade do mercado resultados da entrevista do usu rio etc 10 00
213. o mercado imaturo e nenhuma empresa j estabelecida ocupa a posi o de dom nio do mercado O forte canal de distribui o mundial da Lumenations ser a real vantagem para ocupar posi o no mercado e os distribuidores est o vidos por novos produtos Procurando uma grande oportunidade 20 A Equipe de Desenvolvimento do Software HOLIS O projeto que n s escolhemos desenvolver ser o HOLIS nosso codinome para o novo Sistema de Automa o de Ilumina o Residencial HOme Lighting automation System da Lumenations O tamanho e escopo da equipe HOLIS normal Para o prop sito do nosso caso de estudos n s procuramos mant lo pequeno composto por apenas 15 pessoas mas grande o suficiente para cobrir todas as habilidades necess rias perfeitamente representadas por indiv duos com algum grau de especializa o em suas fun es O mais importante a estrutura da equipe a qual permite adicionar mais desenvolvedores e testers A estrutura da equipe HOLIS fornece boa escalabilidade permitindo elevar o tamanho da equipe para 30 a 50 pessoas proporcionalmente muito maior do que o sistema HOLIS necessita Para atender o novo mercado a Lumenations configurou uma nova divis o a Divis o de Automa o para Ilumina o Residencial Como a divis o e a tecnologia s o novidades para a Lumenations a equipe HOLIS foi montada num novo local embora alguns poucos membros da equipe tenham sido transferidos da divis o de il
214. o ou de fora da empresa Cobriremos este t pico no pr ximo cap tulo Mas primeiro vamos dar uma olhada no caso de estudos e ver se o que a equipe planeja para a release v1 0 do HOLIS O Caso de Estudos Depois de executar o workshop de requisitos a equipe do HOLIS recebeu a incumb ncia de avaliar o n vel de esfor o de cada caracteristica e apresentar um primeiro rascunho do baseline v1 0 Um gerenciamento rigoroso seria aplicado devido s restri es impostas equipe incluindo a data limite de ter que disponibilizar um prot tipo para uma exposi o em Dezembro e a data rigida de uma release que deveria estar pronta em Janeiro A equipe estimou o n vel de esfor o de cada caracter stica via a heur stica alto m dio baixo e ent o adicionou a sua avalia o de risco para cada caracter stica A Tabela 20 6 apresenta a lista total de caracteristicas com o acr scimo desses atributos Para o pr ximo passo a equipe forneceu estimativas grosseiras para cada caracter stica e desenvolveu um plano de projeto detalhado mostrando certas interdepend ncias e marcos de projeto cr ticos Al m disso ap s a negocia o com o departamento de marketing o qual por sua vez negociou com Raquel seu distribuidor internacional a equipe determinou que na release 1 0 era adequado internacionalizar apenas a interface de usu rio do UCC o que reduziu imensamente o escopo desta caracter stica A internacionaliza o final do software d
215. o por n o automatizar sua resid ncia Os beneficios desse sistema de automa o para correta de ilumina o s o Alta satisfa o dos propriet rios e orgulho de possu lo Elevada flexibilidade e usabilidade da resid ncia Melhoria na seguran a conforto e conveni ncia Elementos Descri o O problema a falta de op es para escolha de produtos da funcionalidade limitada e alto custo dos sistemas de ilumina o de resid ncias afeta os distribuidores e construtores de sistemas residenciais de ltima gera o devido a poucas oportunidades de diferencia o no mercado e nenhuma nova oportunidade para aumentar a margem de lucro Os benef cios desse sistema de automa o para correta de ilumina o s o Diferencia o Alto rendimento e alto lucro Aumento na participa o de mercado 55 HOLIS O Sistema Atores e Stakeholders Deixe nos voltar ao nosso projeto de engenharia de sistemas Da perspectiva do sistema a nossa primeira impress o do sistema HOLIS simplesmente de um sistema dentro da resid ncia do propriet rio A Figura 6 5 ilustra um simples diagrama mostrando o HOLIS no contexto da resid ncia do propriet rio Figura 6 5 Contexto do sistema HOLIS no seu ambiente O passo 3 da an lise do problema requer que n s identifiquemos os stakeholders e usu rios do sistema O passo 4 da an lise do problema diz para definir a fronteira da solu o sist mica Dado que
216. o ramo superior desta rvore Definimos um prot tipo de requisitos de software como uma implementa o de um sistema de software constru da para ajudar desenvolvedores usu rios e clientes a melhor entender os requisitos do sistema Com o prop sito de elucidar requisitos n s frequentemente escolhemos construir um prot tipo descart vel horizontal interface do usu rio Horizontal implica que n s iremos tentar construir uma grande quantidade de funcionalidade do sistema um prot tipo vertical por outro lado constroem se apenas alguns requisitos de maneira qualitativa Interface de usu rio implica que n s iremos construir principalmente a interface do sistema para seus usu rios ao inv s de implementar a l gica e os algoritmos que residem dentro do software ou 117 prototipar interfaces para outros dispositivos ou sistemas Como uma ferramenta de elucida o os prot tipos Constru idos por desenvolvedores podem ser usados para obter confirma o de que o desenvolvedor entendeu os requisitos Constru dos por desenvolvedores podem ser usados como um catalisador para encorajar o cliente a pensar em mais outros requisitos Construidos pelo cliente podem comunicar requisitos ao desenvolvedor Em todos os tr s casos a meta construir o prot tipo de maneira que consuma poucos recursos Se ficar muito caro construir pode ser melhor construir o sistema real Muitos prot tipos de software t
217. ode usar para obter entendimento apropriado do problema que o novo sistema de software pretende resolver e Na Habilidade de Equipe 2 Entendendo as Necessidades dos Usu rios n s introduzimos v rias t cnicas que a equipe pode usar para elucidar requisitos a partir dos usu rios do sistema e stakeholders Nenhum conjunto de t cnicas ir funcionar em todas as situa es nem ser necess rio que a equipe se especialize em todas as t cnicas Mas com um pouco de pr tica e alguma coer ncia nas sele es e escolhas a equipe ir elevar sua habilidade de entender as reais necessidades que o sistema dever atender e Na Habilidade de Equipe 3 Definindo o Sistema n s descrevemos o processo inicial pelo qual a equipe converte o entendimento do problema e necessidades 18 dos usu rios para uma defini o inicial do sistema que dever atender tais necessidades e Na Habilidade de Equipe 4 Gerenciamento do Escopo n s municiamos a equipe com a habilidade de gerenciar melhor o escopo de um projeto A final de contas n o importa qu o bem entendamos as necessidades a equipe n o pode fazer o imposs vel e normalmente ser necess rio negociar o que ser entregue antes que o sucesso possa ser obtido e Na Habilidade de Equipe 5 Refinando a Defini o do Sistema n s ajudamos a equipe a organizar as informa es dos requisitos Al m disso n s introduzimos um conjunto de t cnicas que a equipe pode usar para elabo
218. odemos superar as expectativas mas por agora vamos apenas nos concentrar em atend los Para isso precisamos gerenciar o baseline Uma vez estabelecido o baseline fornece o centro focal de muitas atividades de projeto O baseline de caracter sticas pode ser usado para avaliar realisticamente o progresso Recursos podem ser ajustados com base no progresso relativo do baseline As caracter sticas dentro do baseline podem ser refinadas em detalhes suficientes para satisfazer o desenvolvimento do c digo A rastreabilidade de requisitos pode ser aplicada desde as necessidades do usu rio passando pelas 166 caracter sticas do baseline A rastreabilidade pode ser posteriormente estendida das caracter sticas at as especifica es adicionais e implementa es Talvez o mais importante o baseline de alto n vel pode ser usado como parte de um processo efetivo de gerenciamento de mudan as As mudan as s o parte integrante de todas as atividades de desenvolvimento O gerenciamento de mudan as t o cr tico que n s dedicamos para tratar desse assunto no Cap tulo 34 Por agora iremos ver como podemos aplicar o baseline de caracter sticas para este aspecto Importante do gerenciamento de software Mudan a Oficial O baseline de caracter sticas fornece um excelente mecanismo para gerenciar mudan as de alto n vel Por exemplo quando o cliente solicita uma nova capacidade do sistema uma mudan a oficial e essa capacidade n o pa
219. og stica do workshop sess o A sess o foi realizada num hotel pr ximo ao aeroporto e come ou prontamente s 8 00 horas Eric apresentou a agenda do dia e as regras do workshop incluindo os cupons de workshop A Figura 11 2 fornece uma vis o do workshop A o Cathy Pete Gerente de Cereme de Desenvolvimento Produto Perspectiva de Software dos propriet rios Regras do Workshop Observadores David a ici Presidente d Facilitador Participantes Pa o Eric Diretor de Constict Marketing RS Emily Gerente Geral Raquel Gerente da John Gerente Betty da Krystel EuroControls Exucutivo da Eletric Distribuidor Europeu Automation Equip da Lumenations maior distribuidor da Lumenations Membros dispon veis da equipe de desenvolvimento HOLIS Figura 11 2 Estrutura do workshop de requisitos do HOLIS 2000 Em geral o workshop caminhou muito bem e todos os participantes estavam preparados para dar suas informa es prontamente Eric fez um bom trabalho de facilitar a reuni o mas uma situa o desagrad vel ocorreu quando Eric argumentou com a Cathy sobre as prioridades de duas caracter sticas A equipe decidiu que nos futuros workshops um facilitador externo seria contratado Eric conduziu uma sess o de brainstorming sobre as caracter sticas potenciais do 97 HOLIS e a equipe usou a vota o acumulativa para decidir as prioridades relativas Os resultados s o apresentados
220. olvido de forma iterativa e incremental Elabora A A A A A A A Release R el ea Release Release Release Release Release Release Figura 22 6 Itera es de fases resultando em releases vi veis A sele o das itera es depende de v rios crit rios As itera es iniciais devem ser projetadas para avaliar a viabilidade da arquitetura escolhida contra alguns dos mais use cases importantes cercados de riscos 173 Workflows Na abordagem 1terativa as atividades associadas ao desenvolvimento de software s o organizadas num conjunto de workflows Cada workflow consiste de um conjunto de atividades logicamente relacionadas cada um definindo como as atividades devem ser sequenciadas produzir um produto de trabalho ou artefato vi vel Embora a quantidade de workflows possa variar dependendo da empresa ou das circunst ncias do projeto existem normalmente seis workflows como ilustra a Figura 22 7 p S 1 Workflows do 7 Requisitos An lise e Projeto e e e E Teste pa PERES resp pa PA pa pa 1 ir PES DP Implanta o _ l m sd a E E e Sid e a 7 A RE E REED E E DEM E ERES Implementa o lh d
221. omemos cuidado em distingui los em nossas mentes poderemos a todo o momento aprender informa es valiosas sobre o que o sistema deve fazer A caracteristicas s o facilmente descritas em linguagem natural e consiste de uma frase curta alguns exemplos s o mostrados na Tabela 8 1 Raramente ou nunca caracter sticas s o elaboradas em maiores detalhes Caracter sticas s o tamb m construtores muito teis para dar in cio do gerenciamento do escopo do projeto para estabelecer negocia es e processos de acordo A declara o de caracter sticas n o exige uma grande quantidade de investimento e s o f ceis de descrev las e relacion las Tabela 8 1 Exemplos de caracter sticas Dom nio da Aplica o Exemplo de uma Caracter stica Feature Sistema de controle de elevador Controle manual de portas durante inc ndios Sistema de controle de estoque Fornecer o estado de todos os itens de estoque Sistema de rastreamento de Fornecer informa es de tend ncia e defeitos qualidade do produto Sistema de pagamento Relat rio de dedu es por data e por categoria HOLIS Sistema de automa o Configura o para longos per odos de de ilumina o de resid ncias aus ncias Sistema de controle de armas Obrigatoriedade de no minimo duas confirma es de ataque Aplica o de uma copiadora Compatibilidade com o Windows 2000 70 Caracter sticas do sistema devem estar limitadas a 25 99 com menos que 50 preferive
222. oque ou Eu gostaria de ver um grande aumento de produtividade nas entradas dos pedidos de venda Mesmo assim essas declara es definem o contexto mais importante de todas as outras atividades que vir o Por serem t o importantes gastaremos algum tempo e energia tentando entend los N s definimos uma necessidade needs do stakeholder como 68 uma reflex o de neg cio pessoal ou de problema operacional ou de oportunidade que deve ser atendida a fim de justificar a considera o compra ou uso de um novo sistema Caracteristicas Features Uma coisa interessante que ocorre quando entrevistamos stakeholders para conhecer suas necessidades ou os requisitos para um novo sistema que normalmente esses stakeholders n o falam nada disso ao menos em termos das defini es que fornecemos anteriormente Esses stakeholders n o dizem a voc nenhuma de suas reais necessidades Se eu n o aumentar a produtividade deste departamento eu n o ganharei meu b nus este ano ou Eu quero reduzir a velocidade deste ve culo o mais r pido que puder sem derrapar nem os reais requisitos do sistema Eu preciso reduzir o tempo de processar as transa es de entrada dos pedidos de venda em 50 ou O ve culo deve ter um sistema de controle computadorizado para cada roda Ao inv s disso eles descrevem o que acham ser uma abstra o de algo como Eu necessito de uma nova tela de entrada de pedidos baseado e
223. os Assim importante descobrir quais s o os requisitos do sistema descrev los organiz los e rastrear os eventos que provocam as suas mudan as Dessa forma define se Gerenciamento de Requisitos como 11 Uma abordagem sistem tica de elucidar organizar e documentar os requisitos do sistema e Ur processo que estabelece e mant m um contrato entre cliente e a equipe de projeto sobre as mudan as de requisitos do sistema e Qualquer um que j tenha se envolvido com o desenvolvimento de sistemas de software complexo seja na perspectiva de cliente ou de desenvolvedor sabe que a habilidade mais importante a habilidade de e uctdar requisitos de usu rios e stakeholders e Uma vez que centenas se n o milhares de requisitos podem estar associados a um sistema importante organiz los e J queo ser humano n o possu a capacidade de manipular mais do que 12 pe as de informa es simultaneamente importante documentar os requisitos para garantir a comunica o efetiva entre os v rios stakeholders Os requisitos devem ser registrados em algum meio acess vel documento modelo base de dados ou em uma lista sobre o quadro negro Mas o que isso t m a ver com o gerenciamento de requisitos O tamanho e a complexidade de um projeto s o os principais fatores aqui ningu m se preocuparia em gerenciar requisitos num projeto com duas pessoas e que tivesse apenas 10 requisitos para serem atendidos Mas ao tentar
224. os Importante Baixo Baixo Caracter stica 7 Implementar ferramenta de dicas Util Baixo Alto Caracter stica 8 Integrar com o subsistema de Util Alto Baixo gerenciamento de vers es 158 A estrat gia de reduzir riscos varia de projeto a projeto e n o iremos cobrir esse t pico aqui Para o prop sito de gerenciamento de escopo basta ter consci ncia sobre os riscos associados com cada caracter stica tal que decis es inteligentes possam ser tomadas desde o in cio do projeto Por exemplo se uma caracter stica com prioridade cr tica tiver um alto risco ent o ser obrigat rio aplicar alguma estrat gia efetiva de redu o desse risco Se a prioridade for importante e a caracter stica estiver pr xima ao baseline o item pode ser descartado ou simplesmente desenvolvido se houver tempo disponivel N o h problemas nesse processo contanto que nenhum compromisso tenha sido assumido em incluir esse item na release Se o benef cio de um item de alto risco for apenas util considere descart lo completamente Reduzindo o Escopo N s j fizemos substancial progresso N s priorizamos um conjunto de caracter sticas com esfor o e risco associados Note que normalmente n o existe correla o entre a prioridade esfor o e risco Al m disso a v rios itens cr ticos s o de baixo esfor o v rios itens que s o teis exigem alto esfor o Isso pode ajudar a equipe na prioriza o de caracter sticas Por exemplo uma caract
225. os aos stakeholders externos No entanto a experi ncia mostra que a amea a de uma outra classe de mudan as muito mais subversivo ao processo de desenvolvimento No Cap tulo 34 discutiremos os damos obscuros dessas mudan as e adquirir muni o adicional para atacar esse desafio de gerenciamento de escopo 167 Cap tulo 22 Gerenciamento de Escopo e Modelos de Processo de Desenvolvimento de Software Pontos chaves e O processo de desenvolvimento da equipe define quem est fazendo o que quando como e No modelo cascata as atividades progridem atrav s de uma sequ ncia de passos com cada passo apoiado nas atividades do passo anterior e O modelo espiral inicia com uma s rie de prot tipos dirigidos pelo risco seguido por um processo estruturado similar ao modelo cascata e A abordagem iterativa um h brido dos modelos cascata e espiral separa as fases do ciclo de vida das atividades de software que ocorrem em cada fase e Independentemente de qual modelo voc use voc deve desenvolver ao menos um prot tipo inicial para obter o feedback do cliente te agora n s n o falamos muito sobre o processo de desenvolvimento de software como um todo e seu relacionamento com a habilidade da equipe atingir os resultados desejados No entanto o gerenciamento de requisitos que seja efetivo n o pode ocorrer sem o contexto de um processo de software razoavelmente bem definido que defina o conjunto total de atividades q
226. ou 20 algumas necessidades needs que preencher o o topo de nossa pir mide de requisitos Da Perspectiva dos Propriet rios Controle de ilumina o residencial modific vel e flex vel a prova do futuro Como as tecnologias mudam eu gostaria que houvesse compatibilidade com novas tecnologias que possam emergir Atrativo discreto e ergon mico Independ ncia total e chaves program veis ou reconfigur veis para cada c modo da resid ncia Mass seguran a e despreocupa o Opera o intuitiva Eu quero ensinar minha m e tecnof bica O sistema com custo razo vel com chaves de baixo custo Corre o f cil e barata Configura o de chaves flex vel de um a sete bot es por chave Fora do alcance da vis o e observa o 100 confi vel Configura o de seguran a de f rias Habilidade de criar cenas como configura o de ilumina o para festas Nenhum incremento el trico ou de perigo de inc ndio na casa Habilidade de ap s uma falta de energia el trica restaurar a ilumina o Conseguir programar usando o meu PC Escurecer onde eu quiser Conseguir programar sem o meu PC Algu m mais Ir program lo para mim Seo sistema falhar eu ainda quero estar apto a ligar algumas luzes Interfaces para o meu sistema de seguran a residencial Interface com outros aparelhos HVAC udio video entre outros 78 Da Perspectiva
227. ou sistema faz ou n o faz Enfim o documento da Vis o representa a ess ncia do produto e deve ser defendido como se o sucesso do projeto dependesse disso Em algum ponto a quest o com raz o se transforma Mas quem desenvolve e mant m esse documento t o importante Quem gerencia as expectativas do clhente Quem negocia com a equipe de desenvolvimento o cliente o departamento de marketing o gerente de projeto e com os executivos da empresa que t m demonstrado tamanho interesse entusiasmado com o projeto agora que se aproxima o prazo final Em virtualmente todos os projetos de sucesso que estivemos envolvidos desde o projeto de ve culos de aventura que colocam borboletas na barriga de todos os visitantes at projetos de ventiladores de suporte de vida que sustentam dez vidas sem uma nica falha de software tinha um campe o N s podemos olhar para o passado desses projetos e apontar um indiv duo e nos casos de grandes projetos uma pequena equipe de pessoas os quais interpretam um papel maior que as suas pr prias vidas O campe o mant m a vis o do produto ou sistema ou aplica o na frente de suas mentes como se ela fosse a nica coisa mais importante de suas vidas Eles comem dormem e sonham sobre a vis o do projeto O Papel do Campe o do Produto O campe o do produto pode ter uma grande variedade de t tulos gerente de produtos gerente de projeto gerente de marketing gerente de engenharia g
228. ovo sistema que Ir atacar o problema s o Aumento de precis o dos pedidos de venda nos pontos de venda Aperfei oamento de relat rios gerenciais com os dados de venda FE finalmente alta lucratividade Uma vez descrita a declara o do problema pode ser divulgada entre os stakeholders para criticarem e tecerem coment rios Quando esse per odo de receber cr ticas e coment rios estiver finalizado e a declara o do problema consolidada a declara o do problema passar a ser uma miss o declarada a qual todos os membros da equipe de projeto ter o que ter em suas mentes para que todos trabalhem para atingir aos mesmos objetivos 3 Identificar Stakeholders e Usu rios A solu o efetiva de qualquer problema complexo quase sempre envolve a satisfa o das necessidades de diversos grupos de stakeholders Os stakeholders normalmente possuem v rias perspectivas sobre o problema e v rias necessidades que esperam que sejam atacadas pela solu o N s iremos definir um stakeholder como qualquer um que possa ser substancialmente afetado pela implementa o de um novo sistema on aplica o Muitos stakeholders s o usu rios do sistema e suas necessidades s o f ceis de identificar porque eles est o diretamente envolvidos com a defini o e uso do sistema Por m alguns stakeholders s o apenas usu rios indiretos do sistema ou s o afetados apenas pelos resultados de neg cio que o sistema influencia Esses stakeho
229. para virtualmente 100 qualquer tipo de aplica o onde conhecer as rea es Iniciais de usu rios seja um dos fatores chaves de sucesso Tipos de Storyboards Basicamente um storyboard pode ser qualquer coisa que a equipe quer que seja e a equipe deve se sentir livre para usar sua Imagina o para pensar num storyboard de aplica es espec ficas Storyboards podem ser categorizados em tr s tipos dependendo do modo de intera o com o usu rio passivo ativo ou Interativo Storyboards passivos contam uma est ria ao usu rio Podem ser consistidos de esbo os figuras screen shots apresenta es PowerPoint ou amostras de sa das Num storyboard passivo o analista interpreta o papel do sistema e simplesmente conduz o usu rio atrav s do storyboard com uma exposi o Quando voc fizer isto Isso acontece Storyboards ativos tentam fazer o usu rio ver um filme que n o foi produzido ainda Storyboards ativos s o animados ou automatizados talvez por uma ferramenta de apresenta o sequencial de slides ou de anima o ou at por um filme Storyboards ativos fornecem uma descri o automatizada sobre a maneira de como o sistema de comporta num cen rio normal de uso ou de opera o Storyboards interativos permitem que o usu rio experimente o sistema tanto de maneira real stica quanto pr tica Sua execu o necessita da participa o do usu rio Storyboards interativos podem ser simula es ma
230. parados para fornecer uma solu o para o problema No espa o da solu o n s focalizamos na defini o de uma solu o para o problema do usu rio este o mundo dos computadores programa o sistemas operacionais redes e dispositivos de processamento Aqui n s podemos aplicar diretamente todas as habilidades que n s aprendemos Caracter sticas do Sistema Inicialmente ser til declarar o que aprendemos no dom nio do problema e como pretendemos resolv lo atrav s da solu o Isso n o muito dif cil e deve consistir de itens como e O carro ter quadros de pot ncia e Gr ficos de an lise de defeitos fornecer um visual significativo para estimar o progresso e Entrada dos pedidos de vendas via Web e Ciclos de repeti o autom tica S o descri es simples na linguagem do usu rio as quais ser o utilizadas como r tulos para comunicar ao usu rio sobre como o nosso sistema ir atacar o problema Esses r tulos se tornar o parte da linguagem di ria e ser gasta muita energia para defini los debat los e prioriz los N s chamamos esta descri o de features caracter sticas do sistema que ser constru do Uma feature um servi o que o sistema fornece para atender um ou mais necessidades dos stakeholders Graficamente representamos as caracter sticas como a base para pir mide das necessidades Requisitos de Software Tendo estabelecido o conj
231. pelo menos at onde podemos prever revela o aumento em escala ou seja a eleva o da quantidade de trabalho com o passar do tempo podemos entender que o problema do desenvolvimento de software deve ser atacado por equipes de software bem estruturadas e treinadas Na disciplina de gerenciamento de requisitos em particular todos os membros da equipe estar o eventualmente envolvidas em atividades que auxiliem o gerenciamento de requisitos de projeto Essas equipes devem desenvolver as habilidades de requisitos para entender as necessidades dos usu rios para gerenciar o escopo da aplica o e para construir sistemas que atendam as necessidades desses usu rios equipe de requisitos deve trabalhar como uma equipe de futebol vencedora para enfrentar os desafios que o gerenciamento de requisitos imp em A fim de fazer isso o primeiro passo no processo de gerenciamento de requisitos assegurar que o desenvolvedor entenda o problema que o usu rio est tentando resolver N s iremos cobrir este t pico nos tr s pr ximos cap tulos Habilidade de Equipe 1 Analisando o Problema 22 Habilidade de Equipe 1 Analisando o Problema e Cap tulo 4 Os Cinco Passos da An lise do Problema e Cap tulo 5 Modelagem de Neg cio e Cap tulo 6 Engenharia de Sistemas Sistemas de Software Intensivo 23 Problema Equipes de desenvolvimento tendem a avan ar continuamente fornecendo solu es baseadas em entendime
232. plos documentos e naturalmente considerar v rios casos especiais Um documento pai define os requisitos do sistema como um todo incluindo hardware software pessoas e procedimentos e um outro define os requisitos apenas para a pe a de software Normalmente o primeiro documento chamado de especifica o dos requisitos do sistema enquanto que o segundo chamado de especifica o dos requisitos de software ou SRS para abreviar Um documento define as caracter sticas features do sistema em termos gerais e o outro define os requisitos em termos mais espec ficos Com frequ ncia o primeiro documento chamado documento da vis o o segundo chamado de especifica o dos requisitos de software Um documento define o conjunto total de requisitos para uma fam lia de produtos e o outro define os requisitos de apenas uma aplica o espec fica e para um release espec fico O primeiro documento normalmente chamado de documento dos requisitos da familia de produtos ou documento da Vis o da fam lia de produtos j o segundo chamado de especifica o de requisitos de software Um documento descreve os requisitos gerais de neg cio e ambiente de neg cio no qual o produto ir residir e o outro define o comportamento externo do sistema a ser constru do Normalmente o primeiro documento chamado de documento dos requisitos de neg cio ou documento dos requisitos de marketing j o segundo chamado
233. po Veja a Figura 22 5 DL gt gt gt gt gt gt gt gt gt gt gt gt gt Tempo Figura 22 5 Fases do ciclo de vida na abordagem iterativa 1 Na fase de concep o a equipe se concentra em entender o caso de neg cio do projeto o escopo do projeto e na viabilidade de uma implementa o A an lise do problema realizada o documento da Vis o criado e estimativas preliminares de cronograma e custos bem como os fatores de risco de projeto s o definidos 2 Na fase de elabora o os requisitos do sistema s o refinados uma arquitetura inicial execut vel estabelecida e um prot tipo de viabilidade inicial normalmente desenvolvido e demonstrado 3 Na fase de constru o o foco est na implementa o A maior parte do c digo desenvolvido aqui nesta fase e a arquitetura e o projeto totalmente desenvolvido 4 O beta teste normalmente ocorre nesta fase de transi o e os usu rios e pessoal de manuten o do sistema s o treinados O baseline testado da aplica o implantado para a comunidade de usu rios e implantado para uso Itera es Dentro de cada fase o projeto normalmente experimenta v rias itera es Figura 22 6 Uma itera o uma sequ ncia de atividades com um plano e crit rios de avalia o estabelecidos resultando em algum tipo de execut vel Cada itera o 7 constru da sobre a funcionalidade da itera o anterior assim o projeto desenv
234. primeira viagem caminhou para a outra extremidade da sala e sentou se pr ximo ao Sr Big a teoria diz que ser dificil para o Sr Big gritar com o Autor se eles estiver pr ximo ao Sr Big al m disso se ele golpear o Autor existe a chance de venc lo na justi a e recuperar os lucros de projeto Depois de uma breve discuss o o Autor notou que dentre os v rios problemas importantes que preocupam o projeto o problema da n o converg ncia dos requisitos estava causando atrasos e excedendo os custos O Sr Big disse D me um exemplo O Autor lhe deu um exemplo Os membros da equipe do cliente imediatamente come aram a argumentar entre si talvez demonstrando que este era o real problema O subcontratado sussurrou um pequeno sinal de al vio O Sr Big observou a equipe por um momento e ent o disse Muito engra ado D me mais um exemplo A equipe do Autor arrancou cinco impress es coloridas cada uma realizada com perfei o profissional do painel frontal proposto e disse n s apresentamos todas estas op es de projetos semanas atr s e n o conseguimos convergir para nenhum desses projetos e estamos exatamente no momento em que precisamos disso O Sr Big disse Isso n o pode ser t o dificil Equipe escolha um Os membros da equipe do cliente ent o brigaram entre si novamente O dia passou desse jeito N o houve converg ncia Havia pouca esperan a Na manh seguinte o Autor foi convid
235. produto A fim de fazer isso importante ouvir a contribui o de todos os stakeholders O workshop ser conduzido pelo que tem grande experi ncia como facilitador no gerenciamento de requisitos Como stakeholder podemos tamb m ter preconceitos ent o chamamos algu m de fora da equipe para nos assegurarmos que o workshop ser gerenciado livre de qualquer preconceito Os resultados deste workshop ser o disponibilizados imediatamente e ser o distribu dos para as equipes de desenvolvimento e marketing no dia seguinte Convidamos vossa senhoria a participar deste workshop como representante das necessidades de vossa equipe departamento cliente Se n o for poss vel a vossa participa o n s solicitamos que envie um membro de sua equipe que esteja autorizado a tomar decis es como representante de suas necessidades N s iniciaremos o desenvolvimento nos pr ximos dias se voc quiser ouvir contribui es para este projeto esteja aqui ou envie algu m que possa falar por voc Em outras palavras fale agora ou descanse em paz Em anexo a este memorando est uma breve descri o antecipada das caracter sticas do produto bem como algum material de leitura sobre o processo de workshop e brainstorming O workshop come ar exatamente s 8 30 horas e terminar at as 17 30 horas Este projeto e este workshop ser o executados de forma profissional para demonstrar isso n s fornecemos alguns materiais antecipada
236. produzir todos os requisitos a partir desse documento A vantagem da primeira abordagem que as mudan as nos requisitos pertencentes a todos os membros da fam lia podem ser realizadas em apenas um lugar No segundo caso voc poder precisar usar uma ferramenta de requisitos para gerenciar essas depend ncias sen o ser necess rio examinar manualmente cada membro espec fico do documento de requisitos toda vez que o documento pai for alterado Sobre os Requisitos Futuros Poucos esfor os de desenvolvimento t m o luxo de ter um conjunto de requisitos est veis ou estar apto a construir um sistema que satisfa a todos os requisitos conhecidos Durante qualquer processo de elucida o de requisitos surgem requisitos que n o s o apropriados para a constru o do pr ximo release Pode n o ser apropriado incluir tais requisitos numa especifica o de requisitos n o podemos nos permitir fazer qualquer confus o sobre quais requisitos ser o e quais n o ser o implementados Por outro lado n o apropriado descart los porque eles representam produtos de um trabalho de valor adicionado e queremos colher tais requisitos para futuros releases E o mais importante os projetistas de sistemas podem muito bem projetar o sistema de maneira diferente sabendo que certos tipos requisitos futuros t m grandes chances de serem considerados no pr ximo release A melhor coisa registrar ambos os tipos de requisitos em algum lugar
237. que a equipe de desenvolvimento pode entender as necessidades de stakeholders e usu rios de um novo sistema ou aplica o do mundo real Uma vez que na maioria das vezes sistemas s o constru dos para resolver problemas espec ficos tremos usar t cnicas de an lise de problemas para assegurar que entendemos o que o problema Mas devemos tamb m reconhecer que nem todas as aplica es s o desenvolvidas para resolver problemas alguns s o constru dos para ganhar vantagens sobre oportunidades que o mercado apresenta mesmo quando a exist ncia de um problema n o esteja clara Por exemplo aplica es nicas de software tais como SimCity e Myst provaram seu valor para aqueles que gostam de jogos de computador e desafios mentais ou para aqueles que apreciam modelagem e simula o ou para aqueles que simplesmente querem se divertir jogando em seus computadores Portanto ainda que seja dif cil dizer qual o problema que SimCity e Myst resolvem bem talvez o problema de n o existirem muitas coisas divertidas para fazer como o seu computador ou o problema de ter demasiado tempo livre sem ter o que fazer claro que os produtos fornecem real valor para um grande n mero de usu rios Nesse sentido problemas e oportunidades s o ambos os lados de uma mesma moeda seu problema minha oportunidade Isso apenas uma quest o de perspectiva Mas como muitos sistemas atendem a algum problema identific vel pod
238. que atendam as suas necessidades need e Uma caracter stica feature um servi o que o sistema fornece para atender um ou mais necessidades dos stakeholders e Um use case descreve uma sequ ncia de a es que quando executada pelo sistema produz resultados importantes para o usu rio ma das 6 Melhores Pr ticas da Engenharia de Software Gerenciamento de Requisitos justifica o foco no gerenciamento de requisitos Mas antes de explanar as v rias t cnicas e estrat gias para gerenciar requisitos necess rio fornecer algumas defini es e exemplos necess rio definir o que se entende por requisitos Defini es O que um Requisito Embora v rias defini es para requisitos de software tenham sido usadas durante anos a defini o dada por Dorfman e Thayer 1990 perfeitamente cab vel e Uma capacidade que o software que o usu rio precisa a fim de resolver um problema e atingir seu objetivo e Uma capacidade de software que deve ser atendida ou possu da por um sistema ou componentes do sistema para satisfazer um contrato padr o especifica o ou outros documentos formalmente impostos Esta defini o pode parecer um tanto vago mas por ora esta defini o ser o suficiente O que o Gerenciamento de Requisitos Requisitos definem as capacidades que o sistema deve apresentar Normalmente a adequa o ou n o do sistema ao conjunto de requisitos determina o sucesso ou o fracasso dos projet
239. que iremos ver variam desde a simples inexpressivas e extremamente simples tal como a t cnica de entrevista at s mais modestas e caras tal como a t cnica de prototipa o Embora nenhuma das t cnicas seja perfeita para todas as situa es a exposi o dessas v rias t cnicas ir fornecer um rico conjunto de habilidades a partir das quais a equipe poder escolher A cada projeto espec fico a equipe poder escolher entre as v rias t cnicas aquela que achar mais apropriada e aplic la de acordo com a experi ncia e conhecimentos obtidos anteriormente na elucida o de requisitos em outros projetos Desta forma a equipe ir desenvolver um conjunto de habilidades que poder o contribuir ativamente para aperfei oamento dos resultados 63 Cap tulo 7 Os Desafios da Elucida o de Requisitos Pontos chaves e elucida o de requisitos influenciada por tr s s ndromes end micas e A s ndrome Sim mas origina se da natureza humana e da incapacidade dos usu rios de perceberem o software da mesma forma que eles percebem os dispositivos de hardware e Procurar requisitos como procurar por Ru nas Desconhecidas quanto mais voc encontra mais voc conhece e s ndrome do Usu rio e o Desenvolvedor reflete a profunda diferen a entre os dois tornando dif cil comunica o os pr ximos cap tulos n s veremos uma variedade de t cnicas para elucidar requisitos do sistema a parti
240. queria ele est convencido de que expressou seus desejos claramente O desenvolvedor apenas n o entendeu Para complicar mais ainda em muitos projetos reais mais que dois indiv duos est o envolvidos Al m do cliente e o do desenvolvedor que podem naturalmente ter diferentes nomes e t tulos existem provavelmente o pessoal de marketing o pessoal de testes e garantia de qualidade gerentes de produtos gerente geral e uma variedade de stakeholders envolvidos que no seu dia a dia ser o afetados pelo desenvolvimento do novo sistema Todo esse pessoal fica frustrado com o problema de especificar uma pedra aceit vel principalmente porque normalmente n o h tempo suficiente no mundo atual t o competitivo onde as r pidas mudan as no mundo dos neg cios n o permitem gastar por exemplo 2 anos no projeto da pedra e no final ter que refaz lo tudo novamente Embora existam dificuldades suficientes ao lidamos com artefatos f sicos e tang veis como a pedra isso pode se complicar mais ainda Atualmente as organiza es de neg cio e ag ncias governamentais s o do tipo informa es intensivas de tal forma que mesmo que elas nominalmente estejam no neg cio de construir e vender pedras existe uma boa chance de que a pedra contenha um sistema computacional embutido Mesmo que isso n o ocorra existe uma boa chance de que o neg cio precise de sistemas elaborados para manter as informa es
241. quetes ou ser t o sofisticado quanto um c digo descart vel Um storyboards sofisticado constru do com c digos descart veis pode estar muito pr ximo a um prot tipo descart vel discutido no pr ximo cap tulo Como ilustra a Figura 12 1 estas tr s t cnicas de storyboarding oferecem um contnuum de possibilidades variando desde um exemplo das sa das at demonstra es interativas reais Screen shots Relat rios de Passivo Ativo Interativo Apresenta o de slides Prototipa o Regras de Anima o Demonstra es neg cio reais Apresenta es interativas Simula o Sa das Complexidade e custo Figura 122 1 Regras do brainstorming 101 De fato o limite entre storyboards sofisticados e prot tipos iniciais de um produto algo nebuloso A escolha da t cnica de storyboarding varia de acordo com a complexidade do sistema e dos riscos de enganos sobre o que o sistema precisa fazer Um sistema sem precedentes e movador que tenha uma defini o leve e confusa pode necessitar de m ltiplos storyboards partindo do passivo para o interativo conforme o entendimento da equipe sobre os aperfei oamentos do sistema O que os Storyboards Fazem A Branca de Neve e os Sete An es da Disney o primeiro filme animado ent o produzido usou storyboards e eram rotineiramente usados como parte integrante do processo criativo nos filmes e desenhos animados Virtualmente todos os filmes com caract
242. r produzir Quem ir avaliar e homologar o sistema quando ele for entregue e implantado Existem outros usu rios internos ou externos do sistema cujas necessidades devam ser atendidas Quem ir manter o sistema Existe algu m mais Em nosso exemplo da substitui o do sistema de pedidos o principal e o mais bvio dos usu rios s o os vendedores que entram com os pedidos de vendas Esses usu rios s o obviamente stakeholders uma vez que a sua produtividade conveni ncia conforto desempenho e satisfa o no trabalho s o afetados pelo sistema Quais outros stakeholders podem ser identificados Outros stakeholders o supervisor de pedidos de vendas por exemplo s o diretamente afetados pelo sistema mas acessam o sistema atrav s de diferentes relat rios e interfaces de usu rios Ainda outras pessoas o diretor financeiro da empresa por exemplo s o evidentemente stakeholders uma vez que o sistema pode ser afetar a produtividade qualidade e lucratividade da empresa Para n o esquecermos o diretor de sistemas de informa o e membros da equipe de desenvolvimento do sistema s o tamb m stakeholders uma vez que eles s o respons veis pelo desenvolvimento e manuten o do sistema Eles ter o que viver com os resultados assim como os usu rios A Tabela 4 3 sumariza os resultados da an lise de stakeholders e identifica usu rios e outros stakeholders do novo sistema de pedidos Tabela 4 3 Usu rios
243. r as prov veis caracter sticas novas de um sistema como fizemos no cap tulo 5 N o faremos nenhuma tentativa para descrever todas as circunst ncias sob as quais uma particular t cnica poder ser aplicada mas ao inv s disso nos concentraremos em fazer com que a equipe desenvolva habilidades para que possa aplicar essas t cnicas e inclu las em sua maleta de dicas e truques para pegar e usar em momentos apropriados do projeto 37 Cap tulo 5 Modelagem de Neg cio Pontos chaves e A modelagem de neg cio uma t cnica de an lise de problema apropriado especialmente para ambientes de IS TT e modelagem de neg cio usada para ajudar a definir sistemas e suas aplica es e Um modelo use case de neg cio que consiste de atores e use cases um modelo das fun es pretendidas do neg cio e Um modelo de objetos de neg cio descreve as entidades que fornecem a funcionalidade para realizar os use cases de neg cio e como essas entidades se interagem o contexto de um ambiente de tecnologia de sistemas informa o IS IT o primeiro problema a ser resolvido a sua vasta abrang ncia como descrevemos no Cap tulo 4 Neste ambiente a complexidade de neg cio abundante e normalmente precisamos entender algo sobre essa complexidade antes de tentar definir um problema espec fico importante a ser resolvido Esse ambiente possui n o apenas de um usu rio ou dois com suas interfaces computacionais mas de organi
244. r de seus usu rios e outros stakeholders Este processo extremamente simples Sente se com os futuros usu rios do sistema e com outros stakeholders e pergunte o que eles querem que o sistema fa a Ent o por que t o dificil Por que precisamos de tantas t cnicas Ali s por que precisamos desta habilidade de equipe afinal de contas A fim de apreciar por completo este particular problema deixe nos mostrar as tr s s ndromes que parecem complicar imensamente esta mat ria Obst culos da Elucida o A Sindrome do Sim Mas Um dos mais frustrantes impregnantes e sinistros problemas do desenvolvimento de aplica es o que n s conhecemos como a s ndrome do Sim Mas sendo observado nas rea es de usu rios para todas as pe as de software que desenvolvemos Qualquer que seja a raz o sempre observamos duas rea es imediatas distintas e separadas quando o usu rio v a implementa o do sistema pela primeira vez Uau que legal Podemos realmente fazer isso Fant stico parab ns e assim por diante Sim mas hummmmm como eu vejo isso Para que serve esse N o seria melhor se O que acontece se 2 2 r ros r E os N s usamos o termo usu rio genericamente neste contexto As t cnicas para elucidar requisitos do sistema se aplicam a todos os stakeholders sejam usu rios ou n o usu rios 64 As raizes da sindrome Sim Mas parece repousar profund
245. r detr s do problema 28 Atacando Causa RAIZ en a E an E E O E a a A e AE T Ra E A E E 29 Passo 3 Identificar Stakeholders e Usu rios rereeeeeereaneio 30 Passo 4 Definir a Fronteira da Solu o Sist mica eee 32 Passo 5 Identificar as restri es que ser o impostas solu o n 34 SUMAI ss si a SD RR a EO ii A R a 36 Vislumbrando o Futuro reter aa aeee erre nana aee cera nana aee rrenan aaa eee eree ana rrr ernes reenen rennt 36 CART ULO muen rot Dio TR are LEADER a a CARO AROS Ei o ana OR RO ua 38 MODELAGEM DE NEG CIO erre ret r aaa rr rear aaa aeee rear aaa eee e e aaa serenas 38 Prop sito da Modelagem de Neg cio eee eee aeee eee e eee eeeeaneeio 39 Usando T cnicas de Engenharia de Software para Modelar Neg cios 39 Escolhendo a Tecnica Coitada A CS Da a A N 39 nona dem de Mode oenn UNCAL Aana pd A aa 40 Modelssem delNcesciobsande UM Earias a a aa 40 Da Modelagem de Neg cio aos Modelos de Sistemas eee 42 Quando Usar a Modelagem de Neg cio reter eee erre terrena terrena cerrada 42 SUMAOS da A a a a a A E RR 43 VislumbDrando O FULUTO season pen dE ie pls La oa DRA ta E a oa 43 CAPI ULOG sa da RR 44 ENGENHARIA DE SISTEMAS DE SOFTWARE INTENSIVOS ereta 44 O que Engenharia de Sistemas eee ae terre a teor a aee eee n aee ereaneeeeenanerereanda 44 Princ pios Prasmaticos da Ensenhana de Sistemas mapas icon ca
246. ra vamos olhar o mapa que acabamos de construir Na figura 2 1 voc pode ver que fizemos uma transi o sutil por m importante em nossa forma de pensar N s caminhamos do dom nio do problema representado pela nuvem passamos pelas necessidades que descobrimos do usu rio at chegarmos na defini o de um sistema a qual constitui no dom nio da solu o representado pelas caracter sticas do sistema e pelos requisitos do software os quais ir o dirigir o projeto e a implementa o do novo sistema Mais ainda fizemos de tal forma que conseguimos assegurar que entendemos o problema e as necessidades do usu rio antes de antever ou definir a solu o Este mapa da mina junto com suas importantes diferen as ir o continuar a serem importantes durante o restante deste volume Dom nio do Problema Dom nio da Solu o Figura 2 1 Vis o global dos dom nios do problema solu o 16 Cap tulo 3 A Equipe de Software A programa o de computadores uma atividade de neg cio Weinberg 1971 Pontos chaves e O gerenciamento de requisitos afeta todos os membros da equipe embora de maneiras diferentes e O gerenciamento efetivo de requisitos somente poder ser realizado por uma equipe de software efetiva e S o necess rias seis habilidades de equipes para o gerenciamento de requisitos s pessoas optam pela profiss o de desenvolver software por raz es variadas Alguns l em a revista Popular Scienc
247. ra 17 3 A vers o 1 0 o nosso ponto de partida para o entendimento o que nos conta tudo que precisamos para conhecer o nosso projeto A vers o 2 0 define o que diferente nesse release Tomados em conjunto a vis o 1 0 e a vis o delta 2 0 definem a defini o completa do produto A Vis o Introdu o Ponto de partida Caracter sticas da vers o 1 0 gd o A Caracter sticas futuras E EEN Vis o 1 0 N PERON Vis o Novas caracteristicas Caracteristicas removidas T e Caracter sticas futuras Vis o Delta 2 0 Defini o completa do produto Figura 17 3 O Documento da Vis o Delta A duas vers es devem ser utilizadas em conjunto sempre que for necess ria a defini o completa do produto tanto para requisitos de regula o quanto de clientes por exemplo e bvio que 1sso Importante para os novos membros da equipe No entanto quando caracter sticas forem removidas voc ir ler caracter sticas que est o na vers o 1 0 mas que n o aparecem na vers o 2 0 Assim se necess rio siga essa trilha de auditoria sempre que voc precisar ressuscitar a defini o completa Se e quando isso se tornar complicado f cil reunir o conte do da vers o 1 0 e o Delta da vers o 2 0 num novo documento da Vis o 2 0 que represente um quadro do projeto compreensivo e completo Naturalmente n o precisamos ficar restritos sobre esta defini o ou ao que cada documento cont m Em v
248. ra o relacionamento entre uma das caracter sticas identificadas no documento da Vis o e um conjunto de requisitos associados Esse mapeamento e a habilidade de rastre los entre as v rias caracter sticas e requisitos forma a espinha dorsal de um conceito muito importante do gerenciamento de requisitos conhecidos como rastreabilidade um t pico que ser bem discutido posteriormente Tabela 23 1 Requisitos associados a uma caracter stica do documento da Vis o Documento da Vis o Requisitos de Software Caracter stica 63 O sistema de RS63 1 A informa o de tend ncia ser apresentada rastreamento de defeitos ir fornecer num relat rio contendo um histograma informando informa es de tend ncias para ajudar o o tempo no eixo x e o n mero de defeitos usu rio a avaliar o status do projeto encontrados no eixo y RS63 2 O usu rio pode entrar com o per odo da tend ncia na unidade dia semana ou m s RS63 3 Um exemplo do relat rio de tend ncia apresentado na Figura 1 em anexo O Dilema de Requisitos O que versus Como Como podemos ver os requisitos dizem aos desenvolvedores o que o seu sistema deve fazer e devem envolver assuntos relacionados s entradas sa das fun es e atributos do sistema al m dos atributos do ambiente do sistema Mas existe um monte de outras informa es que os requisitos n o deveriam conter Em particular devemos evitar estipular quaisquer detalhes de projeto ou de implement
249. ra um produto de software O Documento da Vis o Delta O desenvolvimento e gerenciamento do documento da Vis o podem representar papel chave para o sucesso ou fracasso de um projeto de software pois fornece um lugar comum para as atividades de stakeholders clientes usu rios gerentes de produto e gerentes de marketing Frequentemente at o gerente executivo da empresa estar envolvido no seu desenvolvimento e revis o Manter o documento da Vis o compreens vel e gerenci vel uma importante habilidade de equipe pois ir gerar grandes benef cios produtividade do projeto como um todo Para auxiliar nesse processo til manter o documento da Vis o t o curto e conciso quanto poss vel Isso n o dif cil principalmente nas primeiras releases do documento quando todos os itens do documento s o novidades para o projeto ou quando devem ser reiniciados num novo contexto da aplica o No entanto nos futuros releases voc pode descobrir que contraproducente repetir caracter sticas e outras informa es que n o tenham sido alteradas num contexto particular do projeto tais como perfil do usu rio e mercado alvo e j tenham sido incorporadas nos releases anteriores Documento da Vis o para o Release 1 0 No caso de um novo produto ou aplica o provavelmente todos os elementos do documento da Vis o devem ser desenvolvidos e elaborados Itens que estiverem fora do contexto do projeto podem ser removidos do
250. ramente com outras quest es ao inv s disso escreva tudo o mais r pido poss vel permita que o usu rio descarregue esse fluxo de pensamento em particular Siga formulando perguntas sobre as informa es que acabaram de ser fornecida Ent o depois que essa linha de pensamento tenha alcan ado o seu final l gico retorne a outras quest es da sua lista Depois de algumas entrevistas desse tipo o desenvolvedor analista ter obtido algum conhecimento do dom nio do problema e ter chegado ao entendimento tanto do problema a ser resolvido quanto das percep es do usu rio sobre as caracter sticas de uma solu o efetiva Al m disso o desenvolvedor pode sumarizar as principais necessidades needs do usu rio ou caracter sticas features do produto que foram definidos na entrevista Essas necessidades needs do usu rio vivem no topo de nossa pir mide de requisitos e servir o de guia para nos orientar em todas as tarefas seguintes Compilando os Dados de Necessidade Needs A sua an lise do problema ter identificado os principais stakeholders e usu rios que voc precisar para entrevistar e para obter o entendimento das necessidades needs dos stakeholders Normalmente n o precisamos fazer muitas entrevistas para obter um bom e s lido entendimento sobre o assunto 11 Needs do usu rio do HOLIS O Resumo do Analista 10 10 10 30 A ltima se o do formul rio de entrevista Resumo do Analista us
251. rapassar em 30 isso uma indica o de que o escopo do projeto pode estar mal definido e ajustes podem ser realizados Mesmo que o escopo n o seja bem gerenciado m ltiplas itera es foram desenvolvidas e executadas antes que chegasse o prazo final e pelo menos foram implantados Mesmo que falte alguma funcionalidade a release ir liberar algum valor ao usu rio se as caracter sticas tiverem sido selecionadas e priorizadas cuidadosamente permitindo que seu cliente atinja seus objetivos ao menos em parte at que voc continue com as pr ximas itera es E se a arquitetura for robusta e atender as quest es t cnicas sua equipe ter uma plataforma s lida onde funcionalidades adicionais poder o ser construidas O que fazer O que fazer Indep do m utilize a equipe deve fornecer ao menos um prot tipo de avalia o robusto a fim de obter feedback do cliente logo no in cio Uma das premissas desse volume que obter o Sim mas desde o in cio uma atividade poderosa e a melhor do processo de software e Quantas vezes voc tem para fazer isso e O cliente solicita mudan as em cada prot tipo e Estamos condenados independentemente do processo que seguimos Resposta ao menos uma vez sim e n o Sim clientes ir o exigir mudan as toda vez que ele ver um prot tipo N o voc n o est condenado A raz o que a quantidade de mudan as que ocorrem depois que o cliente tiver a oportunidade de
252. rar a defini o do sistema ou refin la at o n vel apropriado para dirigir o projeto e implementa o tal que toda a equipe conhe a exatamente qual tipo de sistema ser constru do e Finalmente na Habilidade de Equipe 6 Construindo o Sistema Correto cobrimos alguns aspectos mais t cnicos sobre garantia verifica o valida o teste e gerenciamento de mudan as de projeto mostramos como a rastreabilidade pode ser usada para ajudar a assegurar a qualidade resultante Membros da Equipe possuem Habilidades Distintas Uma das coisas mais interessantes sobre equipes que seus indiv duos t m diferentes habilidades Afinal de contas isso que faz de uma equipe uma equipe Walker Royce 1998 diz o seguinte Equilibrio e cobertura s o dois dos aspectos mais importantes para uma equipe de excel ncia Uma equipe de futebol preasa ter diversas habilidades assim como uma equipe de desenvolvimento de software Raramente uma equipe jogar um bom futebol se n o tiver uma boa cobertura ataque defesa e um bom t cnico Grandes equipes necessitam de cobertura nas v rias posi es chaves com jogadores adequados para cada posi o Mas mma equipe cheia de superstars cada um se esfor ando para marcar gols e competindo para ser o l der da equipe pode ser preocupante para o equil brio da equipe Jogadores adequados em cada posi o e somente alguns poucos l deres preocupados com a equipe normalmente vencem o jogo Na eq
253. requisitos O INCOSE definiu um conjunto b sico de 8 princ pios de engenharia de sistemas 1993 Conhecer o problema conhecer o cliente e conhecer o consumidor Usar crit rios efetivos com base nas necessidades para tomar decis es sist micas Estabelecer e gerenciar requisitos Identificar e avaliar alternativas de forma a convergir para um solu o Verificar e validar requisitos e performance da solu o Manter a integridade do sistema Usar um processo articulado e documentado Gerenciar frente a um plano 45 Esta lista identifica alguns princ pios pragm ticos da engenharia de sistemas No entanto a verdade que um subconjunto da disciplina de engenharia de sistemas fundamenta se num outro processo o da decomposi o sucessiva de sistemas complexos em sistemas mais simples A Composi o e Decomposi o de Sistemas Complexos Com este processo um problema complexo o sistema Figura 6 1 decomposto em problemas menores subsistemas Figura 6 2 Cada subsistema pode ser pensado projetado e manufaturado com sucesso e ent o integrado para produzir a solu o sist mica O ambiente do sistema Sistema Figura 6 1 Um sistema em seu ambiente A disciplina de engenharia que suporta a abordagem da decomposi o sist mica utiliza atributos da defini o anterior tal como o entendimento da caracter stica operacional manufatura teste entre outras Sistema Subsistema Su
254. rio processo iterativo Vamos fazer um exame mais minucioso Itera o de Requisitos e Projeto Na realidade as atividades de requisitos versus projeto devem ser iterativos A descoberta de requisitos sua defini o e decis es de projeto s o circulares O processo um continuo vai e vem onde os requisitos atuais nos fazem considerar a sele o de certas op es de projeto e as op es de projeto selecionadas podem iniciar novos requisitos Ocasionalmente a descoberta de uma nova tecnologia pode nos fazer abandonar v rias suposi es sobre o que fazem os requisitos n s podemos ter descoberto uma abordagem totalmente nova que dispensa a estrat gia antiga Vamos abandonar todo o m dulo cliente acesso a dados GUI e substitu lo por uma interface baseada em browser Essa uma excelente fonte e legitima de mudan a de requisitos Este processo como deveria ser tentar fazer de outra forma seria uma estupidez Por outro lado existe um s rio perigo nisso tudo pois se n o entendermos verdadeiramente as necessidades do cliente e o cliente n o estiver ativamente engajado no processo de requisitos e por que n o em alguns casos at entender as nossas atividades relacionadas ao projeto decis es erradas poder o ser tomadas Quando gerenciado apropriadamente esta reconsidera o continua de requisitos e projeto um processo verdadeiramente fant stico enquanto a tecnologia dirigir a nos
255. rir necessidades do usu rio Usu rios podem tocar sentir e interagir com o prot tipo do sistema de maneira que nenhuma das outras t cnicas pode fornecer De fato a prototipa o pode ser extremamente efetivo para atacar tanto a sindrome Sim mas Isso n o exatamente o que eu queria quanto a sindrome das Ru nas Desconhecidas Agora que eu vi eu tenho um outro requisito a adicionar Tipos de Prot tipos Prot tipos podem ser categorizados de v rias maneiras Por exemplo Davis 1995a categoriza os prot tipos como descart vel versus evolucion rio versus operacional vertical versus horizontal interface de usu rio versus algor tmico entre outras O tipo de prot tipo que voc escolhe depende do problema que voc est tentando resolver atrav s da constru o do prot tipo Por exemplo se o risco do seu projeto baseado principalmente na viabilidade da abordagem tecnol gica isso simplesmente nunca foi feito antes e voc n o est certo se a tecnologia aplicada pode atingir as metas de desempenho ou de rendimento voc pode querer desenvolver um prot tipo arquitetural que principalmente demonstre a viabilidade da tecnologia a ser usada Um prot tipo arquitetural pode ainda ser descart vel versus evolucion rio Descart vel implica que o prop sito do esfor o apenas para provar a viabilidade assim voc poder usar qualquer atalho t cnicas alternativas simula es ou qu
256. rnecer um sistema de contato para emerg ncias de algum tipo Analise do Problema Ao analisar o problema a equipe decidiu inicialmente desenvolver tr s declara es do problema um dos quais estabelece aparentemente o problema bvio sob a perspectiva da empresa 54 MS TST Descri o O problema do baixo crescimento apresentado na principal rea de atua o da empresa ilumina o profissional de teatros afeta a empresa seus empregados e seus acionistas devido ao desempenho inaceit vel e substancial falta de oportunidades de crescimento em rendimento e lucratividade Os benef cios desse novo produto e desse novo mercado em potencial para os produtos e servi os da empresa s o Revitaliza o da empresa e de seus empregados Eleva o da lealdade e conserva o dos distribuidores da empresa Alto rendimento e lucratividade Tend ncia de valoriza o das a es da empresa Ent o a equipe tamb m decidiu ver se podiam entender o problema a partir da perspectiva de um futuro cliente usu rio final e potenciais distribuidores construtores clientes da Lumenations Elementos Descri o O problema da falta de op es de escolha de produtos da funcionalidade limitada e alto custo dos sistemas de ilumina o de resid ncias afeta os propriet rios de sistemas residenciais de ltima gera o devido ao desempenho inaceit vel dos sistemas adquiridos ou com maior frequ ncia a decis
257. rogramador PC Servi os da Programador opcional Lumenations Figura 6 7 HOLIS com subsistemas e atores Note que n s acabamos de identificar cinco atores o propriet rio novamente mas que desta vez usa o PC para programar o HOLIS ao inv s de ligar e desligar l mpadas Este ator Propriet rio Programador possui neste papel diferentes necessidades para o sistema e assim um ator distinto do sistema N s iremos ver mais tarde os diversos comportamentos que o ator espera do HOLIS Os Subsistemas do HOLIS A partir da perspectiva da engenharia de sistema e de requisitos o problema torna se um pouco mais complexo Al m da necessidade de entender os requisitos do HOLIS o sistema n s iremos agora precisar tamb m entender os requisitos nicos para cada um dos tr s subsistemas N s podemos usar nosso paradigma de ator novamente no pr ximo n vel de decomposi o do sistema Ao se fazer isso surgem tr s novos diagramas de blocos Figuras 6 8 6 9 e 6 10 HOLIS 2000 a 0000 Propriet rio Chave de Unidade de Controle Controle Central Figura 6 8 Subsistema Chave de Controle com seus atores 58 Na Figura 6 8 quando vemos sob a perspectiva da Chave de Controle encontramos um outro ator Unidade de Controle Central UCC um outro subsistema Em outras palavras da perspectiva do subsistema Chave de Controle o UCC um ator e precisaremos entender mais tarde quais tipos de requisitos e use cases a C
258. rramentas leves e malucas storyboards e feltros se necess rio para atac lo m Li o 2 A tecnologia dif cil Pense duas vezes antes de voc iniciar um neg cio de terceiriza o de perif ricos m dicos 106 Cap tulo 13 Aplicando Use Cases Pontos chaves e Os use cases como storyboards identificam quem o que e como do comportamento do sistema e Use cases descrevem as intera es entre um usu rio e um sistema concentrando se no que o sistema faz para o usu rio e O modelo use case descreve a totalidade do comportamento funcional do sistema o Cap tulo 12 descrevemos o storyboarding e discutimos como voc pode usar storyboards para mostrar quem o que e como do comportamento do sistema e do usu rio Use cases s o uma outra t cnica para expressar este comportamento N s introduzimos brevemente esta t cnica no Cap tulo 2 e 5 onde usamos para nos ajudar a modelar o comportamento de um neg cio Neste cap tulo n s iremos desenvolver a t cnica use case descrevendo como podemos us los para entender o comportamento do sistema que estamos desenvolvendo em oposi o ao entendimento do comportamento do neg cio que ir utilizar o sistema Em outras palavras usaremos use cases como uma t cnica de elucida o para entender o comportamento necess rio da aplica o que iremos desenvolver para resolver o problema do usu rio Use cases s o uma t cnica t o importante para capturar e e
259. rte do baseline de caracteristicas o Impacto dessa mudan a deve ser avaliada antes de inclu la no baseline Se a equipe de projeto tiver realizado um bom trabalho de definir o baseline antes de come ar a suposi o deve ser a de que qualquer mudan a no baseline deve afetar os recursos o cronograma ou o conjunto de caracteristicas a serem liberadas na release Se os recursos s o fixos e o cronograma n o puder ser alterado a equipe de projeto deve engajar o cliente no processo de tomada de decis o que priorize a nova caracter stica em rela o a outras caracter sticas programadas para a release Se a nova caracter stica tiver uma prioridade cr tica ela deve por defini o ser inclu da na release e o cliente e a equipe de projeto devem em conjunto determinar quais caracter sticas ser o exclu das da release ou ao menos reduzidas em suas prioridades com a redu o associada das expectativas Se a caracter stica importante mas n o critica a equipe de projeto pode prosseguir com a implementa o da caracter stica na base de grandes esfor os deixando que o progresso dite se a caracter stica far ou n o parte da release Mudan a N o oficial Paradoxalmente o problema de mudan as iniciadas pelo cliente pode ser o mais f cil de tratar dentre os desafios do gerenciamento de requisitos O foco do problema externo podemos estabelecer certas salvaguardas e o impacto das mudan as podem ser avaliados e apresentad
260. s subcontratados entre outros Mais ainda use cases n o s o t o teis na identifica o de aspectos n o funcionais dos requisitos do sistema tais como requisitos de usabilidade confiabilidade performance entre outros N s iremos contar com outras t cnicas para atacar estes assuntos Depois que todos os use cases atores e objetos do sistema tiverem sido identificados o pr ximo passo promover o refinamento dos detalhes de comportamento funcional de cada use case Essas especifica es use case consistem de descri es textuais e gr ficas do use case escritos do ponto de vista do usu rio As especifica es use cases podem se entendidas como um reposit rio que descreve uma s rie de eventos relacionados que por sua vez podem ser usados para deduzir outros requisitos que ser o desenvolvidos mais tarde Assim uma 109 especifica o use case pode incluir o passo O t cnico de manuten o entra com o seu nome 16 caracteres no m ximo sobrenome entre outros Como os use cases definem as intera es usu rio sistema pode ser a hora apropriada de definir ao menos em conceito as telas displays pain is frontais entre outras coisas com as quais o usu rio interage Se um sistema de janelas utilizado para apresentar as informa es pode ser apropriado fazer uma descri o gr fica de alto n vel dos dados a serem exibidos os detalhes de projeto da interface gr fica formal GUI tais como defini o
261. s ajudemos a resolver Assim o nosso problema est em entender o seu problema dentro de sua cultura e sua linguagem para que seja poss vel construir o sistema que atenda a suas necessidades Como esse territ rio pode parecer nublado o dom nio do problema representado como uma nuvem cinza Isso foi feito propositadamente para nos lembrar e nos assegurar de que n s visualizamos claramente todos os casos dentro do espa o do problema Dentro do dom nio do problema usamos um conjunto de habilidades de equipe como o mapa e o compasso para entendermos o problema que ter que ser resolvido Enquanto 14 NS Features Requisitos de Software estivermos aqui precisaremos adquirir um entendimento do problema e as necessidades que devem ser atendidas para atacar esse problema Necessidades dos Stakeholders tamb m de nossa responsabilidade entender as necessidades dos usu rios e de outros stakeholders cujas vidas ser o afetadas pela nossa solu o Quando n s elucidarmos essas necessidades n s os colocaremos numa pequena pilha chamada Needs necessidades dos stakeholders a qual representamos como uma pir mide Caminhando em Dire o ao Dom nio da Solu o Felizmente a jornada atrav s do dom nio do problema n o necessariamente dif cil e os artefatos n o s o muitos No entanto mesmo com essa pequena quantidade de dados esse o trecho da jornada no qual n s devemos estar mais bem pre
262. s de serem implementados em software do que em hardware O mais importante que s o muito mais f ceis de serem mudados Assim na ind stria a intelig ncia antes existente nos componentes de hardware viabilizada atrav s da combina o de sistemas el tricos e eletr nicos sistemas mec nicos e sistemas qu mico f sicos encontram se hoje implementadas em componentes de software imersos dentro de microprocessadores ou subsistemas Quando as Gera es se Colidem os Anci es Encontram os Jovens Arrogantes Por d cadas engenheiros de sistemas ocuparam na ind stria os principais cargos de engenheiro de projeto s nior Marcado por ferimentos e testados em campo v rios desses engenheiros de sistemas seniores eram especialistas em disciplinas espec ficas tais como engenharia mec nica e eletr nica e muitos eram alguns dos melhores generalistas da equipe Eles eram testemunhas de grandes desastres e haviam conquistado muitas vit rias Agora velhos e experientes eles possuem incrivelmente bem o conhecimento espec fico do dom nio da aplica o r dios aeronaves refrigera o rob tica equipamentos de controle de materiais e sabem tamb m diferenciar facetas t cnicas econ micas e pol ticas envolvidas na tecnologia de implementa o Mas de repente uma nova gera o de indiv duos invadiu a sua rea Esses rec m chegados os programadores ou nos bons dias engenheiros de software relativamente
263. s de v rias partes da empresa trabalharem juntos com o objetivo comum de alcan ar o sucesso do projeto Neste cap tulo voc ir aprender a planejar e executar com sucesso um workshop de requisitos No final do cap tulo n s aplicaremos esta t cnica no nosso caso de estudos HOLIS Preparando o Workshop A prepara o apropriada do workshop cr tica para o seu sucesso A prepara o apropriada do workshop cr tica para o seu sucesso Vendendo o Conceito Primeiro pode ser necess rio vender o conceito dentro da empresa comunicando os benef cios da abordagem workshop aos futuros membros da equipe Este processo normalmente n o dificil mas comum encontrar resist ncias N o mais uma reuni o Provavelmente n o conseguiremos reunir todas essas pessoas cr ticas num nico dia Voc nunca ser atendido pelo nome do seu stakeholder favorito N o se desencoraje se voc acreditar eles vir o Assegurando a Prepara o dos Stakeholders Corretos Segundo a prepara o tamb m envolve a identifica o dos stakeholders que podem contribuir para o processo e cujas necessidades needs devem ser atendidas para assegurar o sucesso dos resultados Esses stakeholders j ter o sido identificados se a equipe executou o passo da an lise do problema mas agora tempo para uma ltima revis o para garantir que todos os stakeholders cr ticos foram identificados Log sticas Terceiro
264. s es Notamos tamb m que a hierarquia reflete o n vel de abstra o com o qual n s enxergamos o espa o do problema e o espa o da solu o N s ent o ampliamos a nossa vis o do processo de defini o utilizando como exemplo uma aplica o de software standalone e investimos algum tempo na defini o de seu Documento da Vis o crucial que todos os projetos mantenham o Documento da Vis o modificando o para atender s particularidades de uma aplica o de software da companhia N s reconhecemos que sem um campe o algu m que defenda os requisitos da aplica o e atenda s necessidades dos clientes e da equipe de desenvolvimento n o temos como garantir que decis es dificeis sejam tomadas Decis es dif ceis provavelmente ser o as de abandonar postergar ou relaxar requisitos por press es de cronograma Assim decidimos indicar um sacramentar algu m algu m que ficasse respons vel pelo Documento da Vis o e pelas caracter sticas que ele cont m Por sua vez o campe o e a equipe ir o delegar as decis es dif ceis para uma comiss o de controle de mudan as assegurando que as mudan as de requisitos sejam pensadas antes de serem aceitas Tendo uma estrat gia organizacional de gerenciamento de requisitos em m os e um campe o no leme estaremos mais bem preparados para prosseguir com o nosso trabalho Mas primeiro devemos dar uma olhada no problema de escopo o assunto da Habilidade de Equipe 4 147
265. s circunst ncias o nosso favorito a t cnica do workshop brainstorming 121 Habilidade de Equipe 3 Definindo o Sistema Cap tulo 16 Organizando as Informa es de Requisitos Cap tulo 17 O Documento da Vis o Cap tulo 18 O Campe o 122 A quantidade de informa es que devemos gerenciar aumenta rapidamente conforme nos movemos para baixo da pir mide Na Habilidade de Equipe 1 n s desenvolvemos as habilidades que fazem com que a equipe concentre se na an lise do problema Ao fazer isso n s conseguimos compreender totalmente o problema a ser resolvido antes que fossem investidos quaisquer esfor os s rios na solu o N s estivemos completamente concentrados no dom nio do problema Na Habilidade de Equipe 2 descrevemos um conjunto de t cnicas que a equipe pode usar para entender as necessidades do usu rio Essas necessidades do usu rio vivem no topo da nossa pir mide de requisitos indicando que s o essas as informa es que devemos entender inicialmente por serem as mais cr ticas e dirigirem tudo o que vier ap s esse entendimento Na Habilidade de Equipe 3 partimos do espa o do problema para chegar ao espa o da solu o sendo que o nosso foco se concentrar na defini o do sistema que ser constru do para atender as necessidades dos stakeholders Conforme nos movemos para baixo da pir mide veja Figura 1 a quantidade de informa es aumenta Por exemplo podem ser necess rias
266. s de codifica o ou processos de software que voc usar para criar o sistema Caso contr rio voc ter que evoluir um sistema que fundamentalmente falha em um ou mais desses aspetos Neste caso voc pode ter criado um prot tipo descart vel por acidente Ou pior a qualidade do sistema implantado estar para sempre comprometida pelo seu prot tipo de requisitos bem intencionado Avaliando os Resultados Depois que o prot tipo estiver constru do ele deve ser exercitado pelos usu rios num ambiente que simule tanto quanto poss vel o ambiente de produ o no qual o sistema final ser usado Dessa forma ambientes e outros fatores externos que afetam os requisitos do sistema tamb m se tornar o bvios Al m disso importante que existam v rios tipos de usu rios exercitem o prot tipo caso contr rio os resultados ser o preconceituosos Os resultados do processo de prototipa o dividem se em duas partes 1 Necessidades confusas tornam se melhor entendidas 2 Ao exercitar o prot tipo inevitavelmente elucida respostas Sim mas do usu rio assim necessidades anteriormente desconhecidas tornam se conhecidas Simplesmente por enxergarem um conjunto de comportamentos os usu rios passam a entender outros requisitos que devem ser Impostos ao sistema De qualquer forma a prototipa o virtualmente sempre produz resultados Assim voc deve normalmente prototipar qualquer aplica o nova ou inovadora O tr
267. s de um projeto significativamente complexo Existem v rios esfor os no sentido de organizar e formalizar processos tais como o SEI CMM Software Engineering Institute s Capability Maturity Model e os padr es de gerenciamento da qualidade ISO 9000 As vis es de Gerenciamento de Requisitos da SEI CMM e ISO 2000 ser o discutidas no Ap ndice D 12 Aplica o das T cnicas de Gerenciamento de Requisitos Tipos de Aplica es de Software No in cio sugeriu se que as aplica es de software podem ser categorizadas como e Sistemas de informa o e outras aplica es desenvolvidas para serem utilizadas dentro de uma empresa tais como Sistemas de Folha de Pagamento utilizados para calcular o sal rio l quido para o pr ximo m s Esta categoria a base para a ind stria de sistemas de informa o tecnologia de informa o ou IS TT Information system information technology e Software desenvolvido e vendido como produto comercial tal como o Processador de Textos utilizado para escrever este cap tulo Empresas que normalmente desenvolvem este tipo de software s o chamadas de fornecedores de software independentes ou ISV Independent software vendors e Software que s o executados em computadores embutidos em outros perif ricos m quinas ou sistemas complexos tais como aqueles que est o contidos nos avi es telefones celulares e em alguns autom veis de luxo Este tipo de software chamado de apli
268. s descobrimos o suficiente A Sindrome Usu rio e o Desenvolvedor T cnicas de elucida o de requisitos n o s o novas Desenvolvedores de aplica es t m as perseguido por mais de 40 anos para fazer um bom trabalho Ent o o que poderia explicar o fato de que entender as necessidades do usu rio permanece um de nossos maiores problemas Bem considerando o fato de que alguns poucos desenvolvedores de aplica o tiveram treinamento em t cnicas de elucida o 1sso talvez n o seja uma grande surpresa A terceira sindrome surge da lacuna de comunica o entre usu rios e desenvolvedores Chamamos esta sindrome de Usu rio e o Desenvolvedor Usu rios e desenvolvedores s o normalmente de mundos diferentes falando linguagens diferentes e tendo diferentes experi ncias motiva es e objetivos De certo modo n s devemos aprender a nos comunicar mais efetivamente com esses usu rios de outras tribos Num artigo sobre essa mat ria Laura Scharer 1981 descreve esta s ndrome e fornece algumas orienta es para ajudar a reduzir o problema Combinando suas palavras com as nossas experi ncias a Tabela 7 1 sumariza tanto as raz es para este problema quanto sugere algumas solu es A esperan a que com um melhor entendimento tanto da natureza desses problemas quanto das abordagens para mitig los desenvolvedores possam estar melhores preparados para os futuros trabalhos de interesse 66 Ta
269. s e atributos do sistema bem como de seu ambiente e Os requisitos devem excluir informa es relacionadas ao projeto tais como cronograma planos de projeto or amento e testes bem como informa es de projeto certas op es de projeto as quais por sua vez iniciam novos requisitos pelo qual um sistema desenvolvido as caracter sticas do sistema definidas nas Habilidades de Equipe anteriores foram deixadas propositalmente em alto n vel de abstra o para que e Pud ssemos entender melhor o aspecto e a forma do sistema atrav s de suas caracter sticas e de como elas atendem s necessidades do usu rio e Pud ssemos avaliar o sistema quanto completeza e consist ncia e sua adequa o em rela o ao seu ambiente e Pud ssemos usar essas informa es para determinar a viabilidade e gerenciar o escopo do sistema antes de fazer investimentos significativos Al m disso essa abstra o de alto n vel nos permite tomar decis es sobre requisitos excessivamente restritivos logo no In cio isto as pessoas t m a oportunidade de adicionar suas perspectivas e valor defini o do sistema antes de fecharem a implementa o do sistema Na Habilidade de Equipe 5 Refinando a Defini o do Sistema nossa discuss o muda para a elabora o detalhada das caracter sticas do sistema o suficiente para assegurar que as atividades de projeto e codifica o resultem num sistema que atendem plenamente as necessidades
270. s entre subsistemas e assegurar que o mecanismo de comunica o escolhido Ethernet Firewire porta serial ou single data line seja extens vel via mecanismos de software e n o de hardware Um ap s o outro essas mudan as afetaram os desafios do gerenciamento de requisitos de duas maneiras Cada uma dessas dimens es ir criar novos requisitos que o sistema hardware dever preencher a fim de satisfazer a solu o a ser constru da A maior parte do problema de requisitos se deslocou para a aplica o de software Felizmente para menos para a segunda maneira este o objetivo deste volume e n s esperamos prepar lo muito bem para este particular problema 50 Evitando o problema do sistema de chamin s Isso tudo bom ao menos na maioria das vezes Lidar com sistemas complexos requer abordagens n o triviais e o sistema de subsistemas um meio para este fim Certamente as alternativas s o piores n s poder amos chegar ao final com um sistema incrivelmente complexo e que ningu m conseguisse entender com comportamentos indeterminados e projeto baseado em funcionalidades compartilhadas particionamento pobre e c digos concorrentes que nunca ser o desatados A engenharia de sistemas parece ser a melhor alternativa Como isso afeta o gerenciamento de requisitos Quando feita a contagem final descobrimos que os requisitos de subsistemas s o muito mais numerosos do que os requisitos externos ou daque
271. s especialistas em engenharia de software e pesquisadores Felizmente a guerra de metodologias foi superada e a ind stria assentou 39 se sobre um padr o industrial a UML Unified Modeling Language para a modelagem de sistemas de software intensivos A Linguagem de Modelagem Unificada No final de 1997 uma linguagem gr fica para visualizar especificar construir e documentar os artefatos de um sistema intensivo de software foi adotado como um padr o industrial Booch Jacobson e Rumbaugh A UML fornece um conjunto de elementos de modelagem nota es relacionamentos e regras de uso que podem ser aplicados na atividade de desenvolvimento de software No entanto a UML pode tamb m ser aplicada para modelar sistemas e neg cios Um tutorial sobre UML est fora do escopo deste volume Para isso consulte o livro dos tr s amigos sobre a UML Booch Rumbaugh e Jacobson 1990 The Unified Modeling Language User Guide e Rumbaugh Booch e Jacobson 1998 The Unified Modeling Language Refrence Manual No entanto iremos usar alguns conceitos chaves da UML nesta se o e construir outros a partir desses conceitos nas se es subsequentes Modelagem de Neg cio Usando UML Uma das metas da modelagem de neg cio desenvolver um modelo de neg cio que possa ser usado para orientar o desenvolvimento de aplica es Os dois construtores chaves de modelagem que pode ser usado para este prop sito s o modelo nse case de neg
272. s para Elucida o de Requisitos A no o de use cases pode ser descrita sob a perspectiva do usu rio do sistema de forma muito simples Use cases s o descritos em linguagem natural S o f ceis de descrever e documentar Isto fornece um formato estruturado simples ao redor do qual a equipe de desenvolvimento e os usu rios podem juntos trabalhar para descrever o comportamento de um sistema existente ou para definir o comportamento de um novo sistema E claro cada usu rio individualmente ir naturalmente se concentrar nas capacidades do sistema que ser o necess rias para melhor fazer o seu trabalho Se al m disso o comportamento do sistema for totalmente explorado com todos os potenciais usu rios a equipe ter realizado um grande avan o em dire o aos objetivos de entender por completo o comportamento desejado do sistema No final do processo existir o muito poucas ruinas de funcionalidade desconhecidas Al m disso na medida em que o m todo use case explora as interfaces de usu rios diretamente feedbacks iniciais podem ser obtidos sobre este importante e vol til aspecto da especifica o e projeto do sistema No entanto devemos tamb m entender que os usu rios do sistema embora perten am a uma classe importante representam apenas uma das classes de stakeholders Podemos precisar aplicar outras t cnicas de elucida o para obter os requisitos de outros stakeholders tais como clientes n o usu rios gerente
273. sa habilidade de continuamente melhor atender as reais necessidades de nossos clientes Essa a ess ncia do que o gerenciamento efetivo e iterativo Mas quando gerenciado imapropriadamente ficaremos continuamente seguindo a cauda da tecnologia resultando num desastre N s nunca falamos que seria f cil 186 Uma Caracteriza o Avan ada de Requisitos A discuss o precedente sobre requisitos sugeriu que existiam v rios tipos de requisitos Especialmente n s achamos que seja til pensar em tr s tipos de requisitos como ilustra a Figura 23 3 e Requisitos funcionais de software e Requisitos n o funcionais de software e Restri es de Projeto Tipos de Requisitos Requisitos de Restri es de Software Projeto Requisitos Requisitos N o Funcionais Funcionais Figura 23 3 Tipos de Requisitos Requisitos Funcionais de Software Como seria de se esperar requisitos funcionais expressam o como se comporta o sistema Esses requisitos s o normalmente orientados a a o Quando o usu rio faz x o sistema far y Muitos produtos e aplica es concebidas para fazer algo til s o ricos em requisitos funcionais de software O software usado para implementar as principais funcionalidades Quando voc estiver definindo requisitos funcionais voc deve encontrar um bom equilibrio entre o qu o especifico e o qu o gen rico ou amb guo voc quer que seja esse requisito Por exempl
274. sas dn end cana Sa A da Aa a aaa da an 45 A Composi o e Decomposicao de Sistemas Complexos simsii n A A E A ira nada cuia na do assar isad as pa ati arado 46 Aloca o de Requisitos na Engenharia de Sistemas eeeeeereeereeeeeeers 47 SOBERE OS JOCENACOS Gute os pirata DD O a DOR ad aa era 48 UMARO SENOS A atas naa e a E E e A a A A 49 Quando as Gera es se Colidem os Anci es Encontram os Jovens Arrogantes si post ra a 49 Exitando o problema do sitema de Chanin Sonores a aa a NA E S aA A a DA EAT 51 Cuando Subsistemas Sao SubDCOnNHatos ass re e EA E E E E EE E E E a E E T 51 Faz ndo o Trabalho de Corretamente es es ii a u SS e np ep ii dd a aa a 51 O Caso de ESTUDO sas tibs iai dada doa ia bad Add doi da dar a Rd 54 Necessidades Preliminares do SUAR essea oras a tda lisa rc AEE CSA alle OAE AE A nr De Cr E a a AE EA AAAA 54 Analise o O Dic a ans a anda Da a aa do ao a a E a a 54 HOLIS O Sistema Atores e Stakeholders eterna tece eeeeereeeaneteteo 56 Ensenharia de Sistemas do HOLIS ayota aa a aaa ACTA da aa ORE nada AGA Da Ci SER RS A 57 Os subsistemas do HOMS srna a a a a a a a aa a a aa a a a a A 58 SUM RIO DA HABILIDADE DE EQUIPE 1 ssesessssesessosessosessoscseseoscseseoscseseoscseseoscseseoscsessoscseseoscseoscsessoscscsessoses 6l HABILIDADE DE EQUIPE Ziran A R AAEN NA 62 ENTENDENDO AS NECESSIDADES DOS USU RIOS e rrereeeeerrereeeeerereeanerers 62 CAPITULO a 64 Os DESAFIOS DA ELUC
275. sistema interage com o usu rio O elemento como representa o estado que o jogador ou o sistema assume durante a intera o Por exemplo n s fizemos um storyboard para um ve culo de entretenimento autom tico de passeio no parque QO quem representa o passageiro que passeia com o ve culo O o que representa o comportamento do ve culo quando v rios eventos s o fornecidos pelo passageiro O como fornece futuras descri es de como essa intera o acontecem eventos transi es de estados e descreve tanto o estado do passageiro 102 surpresa assustado quanto o estado do ve culo acelerando freando descarregando Ferramentas e T cnicas para o Storyboarding As ferramentas e t cnicas para o storyboarding podem ser t o variadas quanto a imagina o dos membros da equipe e dos usu rios do sistema A constru o de storyboarding passivos tem sido realizada com ferramentas t o simples quanto papel e l pis ou notas Post It Storyboarding passivos sofisticados podem ser constru dos com gerenciadores de apresenta o tais como o PowerPoint ou Harvard Business Graphics Storyboards interativos com usu rios ativos ou passivos t m sido constru dos com HyperCard SuperCard e com a utiliza o de v rios pacotes que permitem r pido desenvolvimento das telas de usu rios e relat rios de sa da Storyboards interativos podem ser constru dos com uma variedade de pacotes de software espec ficos para prototipa o
276. sistemas uma t cnica de an lise de problemas especialmente apropriada para desenvolvimento de sistemas embutidos e engenharia de sistemas nos ajuda a entender requisitos impostos aplica es de software que executam dentro da solu o sist mica e O flowdown de requisitos antes de tudo uma quest o de assegurar que todos os requisitos de sistema estar o cobertos por um subsistema ou pela colabora o de um conjunto de subsistemas e Atualmente o sistema deve ser otimizado para reduzir custos de software ao inv s de reduzir custos de hardware o Cap tulo 5 vimos a modelagem de neg cio uma t cnica de an lise de problemas para aplica es de sistemas de informa o IS IT A modelagem de neg cios nos ajuda a determinar quais aplica es devem ser constru das e onde devem ser executadas dentro do ambiente computacional da empresa e departamentos edif cios e constru es pol ticas e f sicas da empresa Em outras palavras essa an lise pode nos ajudar a determinar por que e onde uma aplica o dever existir Ao fazer isso naturalmente fizemos uma sutil mudan a do espa o do problema para uma vis o inicial do espa o da solu o onde a funcionalidade que resolve o problema ir existir em uma ou mais aplica es que atendem as necessidades finais do usu rio No neg cio de sistemas embutidos no entanto o dom nio do problema e o dom nio da solu o parecem totalmente diferentes Ao inv s de dep
277. sos clientes ir o ditar o projeto e nossos projetistas ir o ditar os requisitos Mas uma complica o sutil e ainda mais s ria fundamenta esta discuss o e camufla esse simples paradigma que apresentamos Retornando ao nosso exemplo de estudo de casos se a equipe toma uma decis o de projeto tal como a sele o de uma tecnologia PC para executar o subsistema UCC do HOLIS provavelmente traria algum impacto externo ao usu rio Por exemplo uma tela de 185 aviso ou de logon seria exibida em algum momento no mundo do usu rio Melhor ainda provavelmente n s iriamos querer tomar vantagens de algumas capacidades de entrada de dados do SO e essas bibliotecas de classe certamente iria exibir seu comportamento externos ao usu rio Nota para o t cnico dentro de voc Sim n s podemos escond lo mas isto est fora de quest o Dada as defini es fornecidas neste cap tulo a quest o Uma vez que o impacto de uma decis o de projeto causa comportamento externo vis vel ao usu rio esta mesma decis o a qual afeta claramente entradas e sa das do sistema agora se torna um requisito Podemos argumentar que a resposta correta Sim ou N o ou at isso n o realmente importante dependendo da interpreta o individual das defini es e an lises que fizemos at agora Mas 1sso acende um assunto muito importante dependendo do entendimento sobre o assunto torna se cr tico entender a natureza do pr p
278. specificar os requisitos do sistema que n s iremos desenvolv lo na Habilidade de Equipe 5 Refinando a Defini o do Sistema e Habilidade de Equipe 6 Construindo o Sistema Correto A t cnica use case parte integral do m todo da Engenharia de Software Orientado a Objetos como descrito no livro Object Oriented Software Engineering 4 Use Case Driven Approach Jacobson et al 1992 Este m todo de an lise e projeto de sistemas complexos dirigido por use case uma maneira de descrever o comportamento do sistema a partir da perspectiva de como os v rios usu rios interagem com o sistema para atingir seus objetivos Esta abordagem centrada no usu rio fornece a oportunidade para explorar o comportamento do sistema com o envolvimento do usu rio desde o In cio Al m disso como mencionamos anteriormente use cases servem como representa es UML para requisitos de um sistema Al m de capturar os requisitos do sistema os use cases desenvolvidos no processo de elucida o de requisitos ir o ser muito teis durante as atividades de an lise e projeto De fato o m todo use case importante durante todo o ciclo de vida do software como exemplo os use cases podem assumir um papel significativo durante o processo de testes Nos cap tulos seguintes iremos desenvolver a t cnica use case com maior profundidade por agora n s precisamos entender apenas sobre como aplicar use cases para capturar os requisitos iniciais do sistema
279. sportadora Gerente de Produ o Figura 4 5 Perspectiva do Sistema 33 A linha tracejada ilustra a fronteira do sistema para a solu o proposta O diagrama ilustra que a maior parte da solu o ir ser desenvolvida para um novo sistema de pedidos mas uma parte do c digo da solu o dever ser desenvolvida e implantada sob o sistema legado existente Passo 5 Identificar as restri es que ser o impostas solu o Restri es s o limita es sobre o grau de liberdade que temos em fornecer uma solu o Antes de gastar trilh es de d lares num esfor o bem intencionado que ir revolucionar o estado da arte de sistemas de pedidos n s devemos parar e considerar as restri es que ser o impostas solu o Definimos uma restri o como um limite sobre o grau de liberdade que temos em fornecer uma solu o Cada restri o tem o potencial para restringir severamente a nossa habilidade de produzir uma solu o da forma como estava prevista Assim cada restri o deve ser cuidadosamente considerada como parte de um processo de planejamento pois muitos podem at fazer com que reconsideremos a abordagem tecnol gica que previmos inicialmente Uma variedade de fontes de recursos deve ser considerada Isso inclui planejamento retorno de investimento or amento de pessoal e equipamentos assuntos ambientais sistemas operacionais banco de dados sistemas clientes e servidores assuntos t cnicos assuntos pol
280. st es permitir que o vendedor entenda totalmente o real problema do cliente tal que solu es efetivas possam ser sugeridas e determinadas de acordo com os seus m ritos espec ficos Este processo ilustra o valor das t cnicas de venda como um dos ingredientes da solu o completa para o real problema do cliente A Import ncia do Contexto da Solu o Depois que as quest es livres de contexto forem formuladas sugira solu es que possam ser exploradas Em nossa busca por descobrir requisitos pode tamb m ser apropriado fazer quest es sobre o dominio onde as solu es s o exploradas depois que as quest es livres de contexto tiverem sido realizadas e respondidas Afinal de contas a maioria de n s normalmente n o nos satisfazemos somente em entender o problema mas em fornecer solu es apropriadas para o problema a ser resolvido Esta adi o do contexto da solu o pode dar ao usu rio novas percep es e talvez at uma vis o diferente do problema E naturalmente nossos usu rios dependem de n s para ter o contexto caso contr rio eles teriam que nos ensinar todas as coisas que eles conhecem sobre o assunto Como um aux lio constru o desta habilidade dentro da equipe de desenvolvimento n s combinaremos essas t cnicas dentro da nossa entrevista livre de contexto gen rica uma entrevista estruturada que pode ser usada para elucidar solicita es de usu rios e stakeholders em muitos contextos da
281. stemas do HOLIS Agora que n s entendemos os atores externos do HOLIS permita nos fazer algumas considera es em n vel sist mico para ver como podemos particionar HOLIS em subsistemas Este processo pode ser bem dirigido pelos seguintes tipos de pensamentos da engenharia de sistemas Seria bom se n s pud ssemos ter software comuns tanto nos dispositivos de controle quanto no PC do propriet rio n s iremos pegar uma implementa o baseada no PC para ambos os elementos do sistema N s ainda n o estamos certos quanto flexibilidade que estamos precisando nas chaves soft remotas mas claro que ir o existir muitos deles e que alguns ir o estar distantes da unidade de controle principal e que n s provavelmente precisaremos de alguma comunica o inteligente entre eles e a unidade de controle Com este pensamento minimalista n s podemos surgir com uma nova perspectiva do sistema aquela em que o HOLIS o sistema seja composto de tr s subsistemas Chaves de Controle o dispositivo de chaveamento remoto program vel Unidade de Controle Central o sistema de controle de computador central e o Programador PC o sistema PC opcional que alguns propriet rios requisitaram Agora o diagrama de bloco apresentado na figura 6 7 57 L mpadas q O HOLIS 2000 QO 0000 L Propriet rio Au zE HR Recebedor de Chave de Unidade de Emerg ncias TBD Controle Controle Central Ps HOLIS 2000 Propriet rio P
282. strar o fato de que uma particular caracter stica deve ser removida no pr ximo release Conforme a equipe desenvolve seu trabalho atrav s do processo ela descobre que o documento cresce com o tempo Isso t o natural quanto definir um sistema que est em crescimento Infelizmente voc pode descobrir que com o tempo o documento torna se mais dif cil de se ler e entender Por que Porque o as informa es do documento s o mais antigas e cont m muitas informa es que n o mudaram desde o ltimo release Por exemplo as declara es do 138 posicionamento do produto e usu rios alvo provavelmente n o mudaram assim como as caracter sticas 25 50 implementadas na vers o 1 0 que vivem no documento da Vis o da vers o 2 0 Assim n s sugerimos o conceito de documento da Vis o Delta O documento da Vis o Delta concentra se somente em duas coisas o que mudou e quaisquer outras informa es que devam ser incluidas para definir o contexto Esta ltima informa o inclu da ou como um lembrete para a equipe da vis o do projeto ou porque novos membros da equipe necessitam do contexto para o seu entendimento O resultado um documento da Vis o Delta que agora tem como foco principal descrever o que novo e descrever o que mudou no release O foco apenas nas coisas que mudaram uma t cnica de aprendizagem que extremamente ben fica ao tratar com sistemas de informa es complexas Este modelo ilustrado na Figu
283. tas que podem ser claramente diferenciados Isto n s estabelecemos ou deixamos impl cito que e Requisitos precedem o projeto e Usu rios e clientes por estarem pr ximos das necessidades tomam as decis es sobre os requisitos e Os t cnicos tomam as decis es de projeto porque eles est o melhores preparados para escolher entre as v rias op es de projeto qual op o atende melhor s necessidades 7 Este um bom modelo e o ponto de partida correto para uma filosofia de gerenciamento de requisitos Davis 1993 chamou isso de o paradigma o que versus como onde o o que representa os requisitos ou o o que o sistema dever fazer e o como representa o projeto que ser implementado para atingir este objetivo N s contamos essa est ria dessa maneira por uma raz o melhor entender os requisitos antes de projet los e muitas restri es use a biblioteca de classes XYZ para acessar o banco de dados s o decis es de projeto importantes registrados nas propriedades dos requisitos de tal forma que podemos assegurar que os alcan amos as raz es contratuais ou talvez uma mais leg tima as raz es t cnicas Se n o pudermos fazer essa diferencia o de alguma forma o quadro deve ficar muito confuso e n o poderemos diferenciar os requisitos das informa es de projeto Al m disso n o saberiamos quem o respons vel por o que no processo de desenvolvimento No pior caso nos
284. ticos internos organiza o compra de software pol ticas e procedimentos da empresa escolha de ferramentas e linguagens pessoal e outras fontes de recursos al m de v rias outras considera es Essas restri es podem ser impostas antes mesmo que iniciemos qualquer atividade Nenhum novo hardware ou teremos que ir atr s e descobri los Para auxiliar nessa descoberta til conhecer o tipo de coisa que devemos procurar A Tabela 4 4 apresenta fontes potenciais de restri es de sistemas Responder quest es apresentadas nesta tabela ajudar a descobrir as principais restri es que ir o afetar nossa solu o Al m disso essa atividade poder provavelmente ajudar na identifica o da l gica para a restri o tanto para assegurar que voc entendeu a perspectiva da restri o quanto para voc reconhecer quando a restri o n o mais se aplica para a nossa solu o Quanto menos restrito melhor Uma vez que as restri es tenham sido identificadas algumas delas ir o se tornar requisitos para o novo sistema usar o sistema MRP desenvolvido pelo nosso fornecedor de sistema de conta corrente Outras restri es ir o afetar recursos planos de implementa o e planos de projeto responsabilidade do solucionador entender as potencias fontes de restri es para cada ambiente espec fico da aplica o e determinar o impacto de cada restri o sobre o potencial espa o da solu o 34 Tabel
285. timento entre as equipes de guias tur sticos e criam certos folclores no neg cio de turismo Numa esta o de ver o nosso amigo nos contou qual era a 65 pergunta mais est pida realizada por um turista est pido da qual ele mais gostava Bem hummmmm quantos ru nas desconhecidas existem De certa forma a busca por requisitos como uma busca por ru nas desconhecidas Quanto mais os encontramos mais os conhecemos Voc nunca sentir que encontrou todos e talvez voc nunca encontre De fato as equipes de desenvolvimento de software de todas as partes do mundo esfor am se continuamente em determinar quando finalizar a elucida o de requisitos isto determinar o momento em que eles ter o encontrado todos os requisitos essenciais ou ao menos encontrado o suficiente A fim de auxiliar a equipe a atacar esse problema n s fornecemos v rias t cnicas tanto no cap tulo Habilidade de Equipe 2 quanto nos posteriores Naturalmente como descrevemos no Cap tulo 1 muito importante gastar tempo em o analisar problema para identificar todos os stakeholders do sistema porque muitos desses stakeholders n o usu rios s o normalmente detentores de requisitos desconhecidos No entanto da mesma forma que o problema de encontrar todas as ru nas desconhecidas devemos adverti lo de que estamos numa miss o que pode nunca terminar Mas entendemos tamb m que em algum ponto estaremos aptos a dizer com seguran a N
286. to padr o especifica o ou outros documentos formalmente impostos Requisitos de software s o aquelas coisas que o software faz em nome do usu rio perif rico ou outro sistema O primeiro lugar a procurar por requisitos de software ao redor da fronteira do sistema por coisas que v o para dentro e para fora do sistema as intera es do sistema com seus usu rios Para fazer isso o mais f cil pensar que o sistema uma caixa preta e pensar nas coisas que voc gostaria de ter e definir a descri o completa do que a caixa preta faz Al m das entradas e sa das voc tamb m precisar pensar em outras caracter sticas do sistema tais como desempenho e outros tipos de comportamentos complexos bem como em outras maneiras de intera o do sistema com o seu ambiente Figura 23 1 Usando uma abordagem similar Davis 1999 determinou que n s precisamos de cinco classes principais de coisas para descrever o sistema totalmente 180 L Entradas do sistema n o apenas o conte do de entrada mas tamb m quando necess rio os detalhes dos perif ricos de entrada sua forma apar ncia e aspecto protocolo de entrada Como a maioria dos desenvolvedores sabe esta rea pode envolver detalhes significativos e pode estar sujeito volatilidade especialmente para GUI multim dia ou ambientes de Internet Sistema C gt Sa das Atributos do ambiente do sistema Fun es ai Y Atr
287. to anual atingiu aproximadamente 120 milh es de d lares e as vendas est o caindo A Lumenations uma empresa p blica e o baixo crescimento nas vendas n o pior ainda a falta de qualquer possibilidade razo vel de elevar o crescimento em vendas est afetando negativamente no valor da empresa e o humor de seus acionistas A ltima reuni o anual foi um tanto desconfort vel pois havia poucas novidades relatadas sobre a perspectiva de crescimento da empresa O valor de cada a o na ltima primavera havia chegado a 25 d lares devido a uma enorme quantidade de novos pedidos mas desde ent o vem vagarosamente caindo oscilando em torno de 15 d lares A ind stria de equipamentos para teatros como um todo tem poucos interessados por novos desenvolvimentos A ind stria encontra se madura e muito bem consolidada Uma vez que as a es da Lumenations est o na reserva e sua capitaliza o bastante modesta a sua venda n o uma op o da empresa O que necess rio um novo nicho de mercado n o t o distante do que a empresa faz melhor mas um que apresente substancial oportunidade de crescimento no rendimento e lucro Depois de executado um projeto de pesquisa de mercado e gasto muitos d lares para pagar consultores de mercado a empresa decidiu entrar num novo mercado Sistema de Automa o para Ilumina o de Resid ncias de ltima Gera o Este mercado aparentemente est crescendo de 25 a 35 ao ano Melhor ainda
288. to de como escrever o c digo nas pr ximas 48 horas ao inv s de preparar o lan amento para o mercado Hummm n o eu acho que isso n o uma boa id ia Voc pode construir utilizando a tecnologia que achar mais apropriada Gerente de Concordo Voc decide as caracter sticas e n s Desenvolvimento escolhemos a tecnologia essa a melhor combina o de nossas habilidades e responsabilidades Gerente de Produto Est combinado Esse di logo n o tem nada de mais apenas explana o senso comum mas incr vel o qu o frequente encontrar empresas que n o t m claro esta responsabilidade como no caso da empresa provedora de servi os on line De alguma forma o ambiente de fornecimento de software independente ISV simples O cliente externo e n s normalmente temos uma organiza o de marketing razoavelmente sofisticada a qual usamos para elucidar os requisitos e determinar quem o respons vel pelo equilibrio de todas as necessidades conflitantes Um cliente cujas necessidades n o s o atendidas simplesmente n o ser um cliente Embora isso n o seja uma boa coisa ao menos eles n o v o perder tempo blasfemando 144 O Campe o do Produto numa Empresa de IS IT Este n o o caso em empresas de IS IT N o existe departamento de marketing todos os seus clientes trabalham com voc e certamente se tornar o pregui osos depois que constatar que o release satisfaz seus desejos Onde encontrar nosso
289. to poss vel os 100 8 F cil de programar unidade de controle n o PC 88 Alto M dio Fornecer controlador dedicado 1 Facilidade de programar as esta es de controle 77 M dio M dio T o f cil quanto poss vel com o esfor o m dio 5 Configura o de aus ncias T Baixo M dio 13 Toda l mpada pode ser apagada 74 Baixo Baixo 9 Usar meu pr prio PC para programar 73 Alto M dio Apenas uma configura o suportada em na vers o 1 0 25 Interface UCC internacionalizado 24 M dio M dio Conforme combinamos com o distribuidor europeu 14 Caraeteristicas de entretenimento 66 Baixe Baixe N o aplic vel inclu da na 23 7 Ligar e desligar instant neo 44 Alto Alto Tornar o investimento inteligente Baseline obrigat rio v1 0 Todas as coisas acima desta linha devem ser inclu das ou iremos atrasar a release 20 Portas da garagem fechadas 66 Baixo Baixo Talvez tenha pouco impacto no software 2 Facilidade para instalar 50 M dio M dio N vel b sico de esfor o l1 Poder dirigir cortinas sombras bomba d gua e motores 44 Baixo Baixo Talvez tenha pouco impacto no software 22 Modo gradual aumento ou redu o da luminosidade 34 M dio Baixo Seria bom se tiv ssemos lentamente Opcional da v1 0 Implemente as caracter sticas acima o quanto voc puderem Cathy Caracter sticas Futuras As caracter sticas abaixo n o fazem parte do desenvolvimento corrente 3 Interface com o sistema de seguran a residencial 52 Alto Alto Poder amos ter ao menos uma interfac
290. tr rio poder haver desperd cio de recursos investidos na especifica o de requisitos e obten o de informa es de projeto que n o ser o implementados na confec o de scripts de teste de caracteristicas que estar o fora do escopo desse projeto na determina o incorreta do caminho cr tico de projeto entre outros N o podemos nos permitir investir quaisquer recursos em atividades que produzam sucata ou falharemos em otimizar os recursos investidos Em outras palavras o gerenciamento de requisitos ir reduzir o n mero de caracter sticas que ser desenvolvido na release inicial e desde que recursos s o extraordinariamente escassos n s n o podemos nos dar ao luxo de investir recursos adicionais em caracter sticas que n o ser o implementados no baseline corrente A Tabela 20 2 ilustra a adi o da informa o de esfor o nossa lista de caracter sticas 157 Tabela 20 2 Lista de caracter sticas com adi o do esfor o Caracter stica Prioridade Esfor o Caracter stica 1 Suporte a BD relacional externo Cr tica M dio Caracter stica 4 Interface para releases de novos SO Cr tica Alto Caracter stica 6 Importa o de dados externos por estilo Cr tica Baixo Caracter stica 3 Habilidade de clonar um projeto Importante Alto Caracter stica 2 Seguran a multiusu rio Importante Baixo Caracter stica 5 Assistente de novos projetos Importante Baixo Caracter stica 7 Implementar ferramenta de dicas til Baixo C
291. turalmente no contexto de nossos projetos de aplica es de software Se n s pudemos aplicar essas mesmas t cnicas para modelar neg cios poder amos falar a mesma linguagem em ambos os contextos Por exemplo uma coisa tal como o contracheque da folha de pagamento descrita no dom nio de neg cio pode relacionar se com uma coisa que aparece novamente no dom nio de software por exemplo o registro do contracheque da folha de pagamento Se n s tivermos sorte o suficiente para usar as mesmas t cnicas ou t cnicas muito similares tanto para a an lise de problemas quanto para o projeto de software ambas poderiam se beneficiar compartilhando os resultados produzidos pelas duas atividades Escolhendo a T cnica Correta Historicamente vimos que as t cnicas de modelagem que foram desenvolvidas e maturadas no dom nio do software inspiraram novas maneiras de visualizar uma organiza o Desde que as t cnicas de modelagem visual se tornaram comuns em projetos de novos softwares usar t cnicas similares no dom nio de neg cio tornou se natural Essa metodologia foi bem desenvolvida por Jacobson Ericsson e outros em 1994 Nos anos 80 e 90 houve uma r pida prolifera o tanto das t cnicas de modelagem de neg cio quanto de metodologias de desenvolvimento de software No entanto eles s o todas diferentes No centro dessas atividades estavam os v rios m todos e nota es orientadas a objetos desenvolvidos por diverso
292. ue sua equipe deve executar para liberar o produto de software final Alguns processos de software s o relativamente formais e outros s o informais mas sempre existe um processo mesmo que ele n o seja rigoroso ou documentado O processo de desenvolvimento de software da sua equipe define quem quem da equipe faz o que que atividade ser executada quando esta atividade executada em rela o a outras atividades e como os detalhes e passos na atividade normalmente a sua equipe atinge seus objetivos O processo de software tem um efeito material na habilidade da equipe desenvolver software no prazo e dentro do or amento Neste cap tulo n s veremos alguns dos aspectos de v rios tipos de processos de software ou seja fases dependentes do tempo e os principais tipos de atividades dessas fases e ent o analisamos como os v rios processos afetam os desafios do gerenciamento de escopo O Modelo Cascata Boehm 1988a disse que j nos anos 50 1950 a ind stria de software reconhecendo o custo de descobrir tardiamente defeitos dentro do ciclo de vida de software adotou um modelo l gico e sequencial o qual progredia a partir da fase de requisitos passando pelas fases de projeto codifica o e assim por 168 diante Isso foi o principal avan o obtido sobre os modelos anteriores de duas fases codificar e corrigir atrav s do qual programadores escreviam um c digo inicial e ent o o corrigia at que n o precisasse
293. uer particular release Inevitavelmente problemas inerentes comunica o devido ao esfor o envolvendo m ltiplas pessoas ir o exigir que um documento escrito seja produzido para que todas as partes possam concordar e consultar Documentos que definem o produto a ser constru do s o normalmente chamados de especifica o de requisitos A especifica o de requisitos de um sistema ou aplica o descreve o comportamento externo desse sistema Nota Por simplicidade e para refletir a conven o hist rica usamos o termo documento de forma gen rica nesta se o mas requisitos podem estar presentes num documento numa base de dados num modelo use case reposit rio de requisitos ou numa combina o desses elementos Como veremos nos pr ximos cap tulos um pacote de requisitos de software pode ser usado para conter esta informa o Mas os requisitos raramente podem ser definidos num nico documento monol tico por uma s rie de raz es O sistema pode ser muito complexo 125 As necessidades dos clientes s o documentadas antes da documenta o detalhada dos requisitos O sistema pode ser um membro de uma fam lia de produtos relacionados O sistema a ser constru do satisfaz a apenas um subconjunto de todos os requisitos identificados necess rio que as metas de marketing e de neg cio estejam separadas dos detalhes de requisitos do produto Em qualquer um dos casos voc precisar manter m lti
294. uipe de software n s esperamos que alguns jogadores tenham provado suas habilidades em trabalhar efetivamente com chentes que outros tenham habilidades de programa o de software e que outros tenham habilidades para Zestes Ainda outros jogadores da equipe ir o precisar ter a habilidade para projeto e arquitetura Muitas outras habilidades s o necess rias N s esperamos tamb m que a habilidade da equipe de requisitos em gerenciar requisitos afete v rios membros da equipe de diversas maneiras Assim de certa forma n s esperamos desenvolver todas as habilidades individuais da equipe para ajudar no gerenciamento efetivo de requisitos Al m disso tentaremos indicar onde podemos alocar cada membro da equipe com habilidade particular necess ria A Organiza o da Equipe de Software O desenvolvimento de software extremamente complexo e o dom nio no qual n s aplicamos nossas habilidades variam enormemente Assim n o parece razo vel que uma maneira espec fica de organizar uma equipe de software funcione para todos os casos e nem que seja a mais eficiente do que outras abordagens Apesar de tudo certos elementos comuns ocorrem na maioria das equipes de sucesso Assim achamos que seja mais importante estabelecer uma equipe hipot tica Por m ao inv s de inventarmos uma equipe ideal o que seria muito mais f cil e muito acad mico decidimos modelar nossa 19 equipe hipot tica considerando uma equipe de desenvolvimento de
295. uisitos em portugu s comum Minha casa deve ter tr s quartos e deve ter uma garagem grande o suficiente para acomodar dois carros e seis bicicletas Poder ser verificado ao longo deste volume que requisitos de um sistema de software em sua grande maioria podem ser escritos em portugu s comum Muitas das habilidades que a equipe precisar para se tornar um especialista a fim de vencer desafios pode tamb m ser descrito em termos pr ticos como conselhos de senso comum Por exemplo para um novato em constru o de casas o seguinte conselho poderia ser dado Assegure se de conversar com os agentes fiscais antes de cavar a funda o da casa e n o ap s preench lo com cimento construir paredes e levantar o teto Num projeto de desenvolvimento de software conselhos similares podem ser fornecidos Assegure se de fazer perguntas corretas assegure se de priorizar os requisitos e n o permita que clientes lhe digam que 100 dos requisitos s o cr ticos porque assim n o dar tempo para finaliz los antes de prazo previsto 10 Cap tulo 2 Introdu o ao Gerenciamento de Requisitos Pontos chaves e Um requisito uma capacidade que o sistema deve apresentar e Gerenciamento de requisitos um processo sistem tico de elucidar organizar e documentar requisitos de sistemas complexos e Nosso problema est em entender os problemas dos usu rios sua cultura sua linguagem e construir sistemas
296. umina o comercial A figura abaixo ilustra a organiza o da equipe de desenvolvimento e as associa es entre os membros da equipe N s visitaremos cada membro da equipe periodicamente no decorrer deste volume e veremos como eles aplicam suas habilidades para enfrentar os desafios de requisitos do sistema HOLIS Lumenations S A Divis o de Automa o para Ilumina o Residencial Organiza o da Equipe de Software Emily VP e GM Brooke Eric Diretor de Engenharia Diretor de Marketing Jack Michel Pete Cathy L der de QA Arquiteto Gerente de Gerente de Desenvolvimento de Produto Software L der de L der de L der de L der de Software Software Software 21 Sum rio dif cil para algu m racional ir contra a id ia de gerenciar e documentar requisitos de um sistema a fim de assegurar que os resultados ir o realmente atender o que o cliente deseja No entanto as pesquisas demonstram que como uma ind stria n s frequentemente realizamos um trabalho pobre A falta de retorno dos usu rios requisitos e especifica es incompletas e mudan as de requisitos e especifica es s o comumente as causas dos problemas citados nos projetos que falham em atender esses objetivos E n s sabemos que h um n mero significativo de projetos de software falham em atender esses objetivos Um pensamento comum entre desenvolvedores e clientes mesmo que n s n o estejamos seguros dos detalhes que queremos me
297. uncionalidade global do sistema Mas eu n o estaria criando um sistema arbitrariamente que n o esteja sendo dirigido pelos verdadeiros conceitos arquiteturais Verdade no sentido tecnico Mas separar conceitos entre equipes de projeto alinhado a log stica e especificar compet ncias mais importante Mas eu n o estaria criando interfaces artificiais e potencialmente um sistema de chamin s Sim faz sentido mas n s recomendamos que voc mantenha o mesmo c digo de interface em ambos os lados e desenvolvidos por uma nica equipe Caso contr rio as duas equipe realizar o trabalhos redundantes Voc ir sem d vida criar novos requisitos para o sistema incluindo interfaces que provavelmente n o seriam necess rias E sim importante ter consci ncia do problema da chamine e fazer tudo que puder para minimizar o acoplamento entre os sistemas e minimizar as quest es pol ticas que surgir o como resultado 53 O Caso de Estudo Enfim ap s uma breve introdu o engenharia de sistemas deixe nos aplicar o que aprendemos no sistema HOLIS nosso Sistema de Automa o de Ilumina o Residencial Neste momento n o gastaremos muito tempo tentando entender os requisitos do HOLIS N s faremos isso nos pr ximos cap tulos Nesse sentido a engenharia de sistemas prematura Por outro lado n s provavelmente entendemos o suficiente para tomar as primeiras decis es sobre o projeto do sistema com base em nossa e
298. unto de caracter sticas em comum acordo com o cliente n s partimos para definir os requisitos mais espec ficos necess rios para a solu o Se construirmos um sistema que atenda a esses requisitos podemos estar certos de que o sistema que desenvolvemos ir apresentar as caracter sticas que prometemos Uma vez 15 Controlar l mpada que cada uma dessas caracter sticas atenda a um ou mais necessidades dos stakeholders teremos atendido todas as necessidades diretamente na solu o Esses requisitos mais espec ficos s o os requisitos de software Representamos esses requisitos de software da mesma forma que fizemos para representar as caracter sticas Uma Introdu o aos Use Cases Um construtor chave ir nos ajudar no final de nossa jornada Este construtor chave o use case o qual usamos de v rias maneiras atrav s desde volume De forma simples um use case descreve uma segii ncia de a es executadas pelo sistema e que produz um resultado til para um usu rio Em outras palavras um use case descreve uma s rie de intera es usu rio sistema as quais ajudam o usu rio a executar alguma tarefa Representamos o use case como cone oval com o nome do use case Por exemplo se quisermos descrever um use case de acordo com a inten o do usu rio de simplesmente acender ou apagar uma l mpada n s podemos cham lo por exemplo de Controlar l mpada e o colocamos esse nome abaixo do cone oval Resumo Ago
299. uque assegurar que o retorno obtido no conhecimento dos requisitos fa a valer o Investimento realizado Isso porque queremos frequentemente prototipar ou ao menos implementar nossos primeiros prot tipos rapidamente utilizando t cnicas baratas e dispon veis Ao limitar o investimento n s maximizamos o retorno sobre o investimento de obter o entendimento dos requisitos 119 Sum rio Devido aos prot tipos de software demonstrarem uma parte da funcionalidade desejada de um novo sistema eles podem ser ferramentas efetivas para ajudar a refinar os requisitos reais do sistema Eles s o efetivos porque usu rios podem interagir com um prot tipo em seu ambiente o qual t o pr ximo ao mundo real quanto se puder chegar sem desenvolver o software de produ o Voc deve selecionar sua t cnica de prototipa o com base na probabilidade de um tipo de risco estar presente em seu sistema Sup e se que os prot tipos de requisitos sejam baratos e f ceis de desenvolver e que eles ajudem a eliminar grande parte dos riscos de requisitos de seu projeto Entre as v rias possibilidades de investimento voc deve investir somente o necess rio em seu prot tipo O uso de v rias t cnicas de prototipa o ou melhor o uso combinado de diversas de t cnicas de prototipa o tem se mostrado extremamente efetivo em auxiliar a equipe de projeto a desenvolver um melhor entendimento das reais necessidades de um sistema de software
300. uta a velocidade instant nea da aeronave 2 Requisitos de interface podem aparecer quando os subsistemas necessitarem se comunicar uns com os outros para atingir um resultado global Eles precisar o compartilhar dados fonte de energia ou um algoritmo computacional de uso comum Nesses casos a cria o de subsistemas tamb m propicia a cria o de interfaces entre subsistemas veja a Figura 6 4 Subsistema lt Subsistema A B Interface de A para B Figura 6 4 Interface entre dois subsistemas Mas existem mesmo requisitos derivados N s tratamos os requisitos derivados como qualquer outro requisito Eles n o parecem atender as defini es do Cap tulo 2 embora possa atenda defini es sobre restri es de projeto que iremos falar mais adiante importante reconhecer que esses requisitos embora cruciais para o sucesso do projeto s o derivados do processo de decomposi o do sistema Dessa forma decomposi es alternativas criam requisitos alternativos e esses requisitos n o s o cidad os de primeira classe no sentido de que eles n o refletem requisitos originados de nossos clientes No entanto a partir do ponto de vista de um fornecedor de um subsistema eles s o cidad os de primeira classes porque refletem requisitos impostos pelo cliente o desenvolvedor do sistema N o existe resposta m gica O como tratar esses requisitos baseado no papel da equipe de desenvolvimento no projeto na decomposi
301. utiva Reconhecemos tamb m que o modelo de neg cio que definimos possui construtores paralelos aos das aplica es de software e usamos esta semelhan a para reproduzir as fases de projeto de software N s iremos usar os use cases de neg cio que descobrimos para ajudar a definir os requisitos da aplica o Para a classe de aplica es de software a qual denominamos de sistemas embutidos usamos o processo de engenharia de sistemas como uma t cnica de an lise de problemas que nos ajuda a decompor sistemas complexos em subsistemas Este processo nos ajuda a entender onde as aplica es de software dever o estar e qual o seu principal prop sito Ao fazer isso aprendemos que complicamos o assunto de requisitos devido o surgimento de novos subsistemas os quais devemos entender os requisitos a serem impostos 61 Habilidade de Equipe 2 Entendendo as Necessidades dos Usu rios Cap tulo 7 Os Desafios da Elucida o de Requisitos Cap tulo 8 As Caracter sticas de um Produto ou Sistema Cap tulo 9 Entrevistando Cap tulo 10 O Workshop de Requisitos Cap tulo 11 Brainstorming e Redu o de Id ias Cap tulo 12 Storyboarding Cap tulo 13 Aplicando Use Cases Cap tulo 14 Role Playing Cap tulo 15 Prototipa o 62 O fator mais comum entre os desafios de projetos foi falta de informa es de usu rios Standish Group 1994 Problema Um estudo publicado pela Standish Group citou a Falta de i
302. vas e respeito m tuo s o normalmente os subprodutos do processo Ent o o workshop de requisitos e o brainstorming presencial s o sem d vida a nossa abordagem preferida Mas algumas vezes o brainstorming presencial n o poss vel Nessas situa es uma das alternativas o uso da Internet ou uma intranet para facilitar o processo de brainstorming criando se um grupo de discuss o Esta t cnica pode ser particularmente adaptada para aplica es avan adas de desenvolvimento onde s o necess rias pesquisas ou quando uma vis o de longo alcance cr tica o conceito for inicialmente confuso e uma grande variedade de informa es e significante n mero de usu rios e de outros stakeholders estiverem envolvidos Com esta t cnica o l der de projeto patrocina um servidor de lista ou p gina Web para registrar e comentar as caracter sticas do produto O registro de id ias e coment rios podem ser feitos tanto de forma an nima quanto pela cria o de autores com base nas constru es criadas pelo administrador Uma vantagem desta t cnica a persist ncia id ias e coment rios podem ser circulados por um longo per odo de tempo com total registro de todas as ramifica es de cada id ia Talvez a vantagem mais importante e nica deste processo esteja no fato de que id ias podem crescer e amadurecer com o passar do tempo O Caso de Estudos O Workshop de Requisitos do HOLIS 2000 Permita nos retornar ao nosso caso de estu
303. ver este livro foi tentar apresentar v rias t cnicas para construir o conjunto de habilidades de equipe Nenhuma t cnica funciona em todas as situa es nunca duas situa es ser o as mesmas Nos cap tulos anteriores focamos numa abordagem geral e filos fica da an lise de problemas que parece funcionar em v rios contextos de sistemas No entanto esse problema de sele o de t cnicas para aplicar se transformar em algo muito mais s rio nos pr ximos cap tulos onde definiremos a t cnica de modelagem de neg cio a t cnica de engenharia de sistemas e continuamos a definir uma variedade de t cnicas na Habilidade de Equipe 2 Entendendo as Necessidades do Usu rio onde apresentaremos uma grande variedade de t cnicas que podem ser usadas para entender as necessidades dos stakeholders e de usu rios com respeito ao sistema que voc ir construir No entanto n s pensamos que seja importante destacar que as t cnicas descritas neste livro da an lise do problema at brainstorming podem ser usadas em diferentes partes do processo de software e n o apenas na parte do processo onde n s escolhemos descrev las Por exemplo a equipe pode usar a an lise de problemas para definir um problema de sistema de pedidos ou resolver um problema t cnico dentro de sua implementa o Da mesma forma a equipe pode usar o brainstorming para determinar as prov veis causas ra zes num exerc cio de an lise de problemas ou determina
304. xperi ncia e em nosso entendimento do que sejam esses requisitos Em muitos casos n s n o nos comprometemos ainda com qualquer coisa de hardware ou software podemos retomar essas quest es posteriormente No processo iterativo que ser descrito posteriormente n s veremos a arquitetura de sistemas e requisitos de sistemas interativamente de tal forma que este n o uma hora ruim para come ar Necessidades Preliminares do Usu rio Deixe nos assumir que j definirmos e entendemos razoavelmente bem algumas das necessidades do usu rio do sistema HOLIS O HOLIS precisar suportar chaves soft chaves individualmente program veis usadas para ativar as caracter sticas de luminosidade nos diversos espa os da casa O propriet rio solicitou que houvesse algo para programar o HOLIS a partir de uma central remota de tal forma que ele pudesse simplesmente chamar quando precisasse ao inv s de ter que perder tempo em programar o HOLIS Outros futuros compradores solicitaram que o HOLIS pudesse ser programado a partir de seus computadores pessoais e que fosse fornecida a habilidade de fazer eles mesmos todas as instala es programa es e manuten es Outros ainda requisitaram que o sistema fornecesse um painel de controle simples um tipo de interface simples onde eles pudessem mudar no HOLIS a programa o configurar atividades de f rias entre outras sem ter que usar o PC O HOLIS precisa fo
305. za es unidades de neg cio departamentos fun es ampla rede de computadores intranet e extranet corporativa clientes usu rios recursos humanos sistemas MRP Material Requirement Planning estoque sistemas de gerenciamento entre outros Al m disso mesmo que estejamos concentrados numa aplica o espec fica que ser implementada devemos constantemente nos lembrar do contexto mais amplo no qual essa aplica o estar inserida Talvez isso possa ser realizado com maior sucesso fazendo se quest es corretas mas como qualquer t cnica existem mais coisas que podem ser feitas num contexto espec fico do que nos casos gen ricos No contexto de IS IT poderia ser til ter uma t cnica que possibilite determinar as respostas para as seguintes quest es Por que construir um sistema dessa maneira Onde deve ser alocado Como podemos determinar quais funcionalidades devem ser alocadas num particular sistema Quando devemos utilizar o processamento manual ou solu es de contorno Quando devemos considerar a reestrutura o da organiza o a fim de solucionar o problema Felizmente existe uma t cnica que se encaixa perfeitamente para resolver este problema e esta t cnica a 7modelagem de neg cio 38 Prop sito da Modelagem de Neg cio No contexto deste volume podemos pensar nos termos neg cio e modelagem de neg cio como algo t o amplo quanto poss vel Por exemplo o nosso neg

Gerenciamento de Requisitos de Software

Contents

Download Pdf Manuals

Related Search

Related Contents