Você está na página 1de 75

Engenharia de Sistemas

PARA

LEIGOS

IBM EDIO LIMITADA

Cathleen Shamieh

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Publicado por Wiley Publishing, Inc. 111 River Street Hoboken, NJ 07030-5774 EUA www.wiley.com Copyright 2011 by Wiley Publishing, Inc., Indianapolis, Indiana EUA Publicado por Wiley Publishing, Inc., Indianapolis, Indiana EUA Nenhuma parte desta publicao pode ser reproduzida, armazenada em um sistema de recuperao ou transmitida de qualquer forma ou por qualquer meio eletrnico, mecnico, de fotocpia, gravao, digitalizao ou outro, exceto se permitido sob as Sees 107 ou 108 do 1976 United States Copyright Act, sem a aprovao prvia por escrito da Editora. Solicitaes de autorizao para a Editora devem ser enviadas para Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, EUA, (201) 748-6011, fax (201) 748-6008, ou online para http://www.wiley.com/go/permissions. Marcas comerciais: Wiley, o logotipo da Editora Wiley, Para Leigos, o logotipo do personagem da srie A Reference for the Rest of Us!, The Dummies Way, Dummies.com, Making Everything Easier, e imagens comerciais relacionadas so marcas comerciais ou marcas registradas da John Wiley & Sons, Inc. e/ou suas afiliadas nos Estados Unidos e em outros pases, e no podem ser usadas sem autorizao por escrito. Todas as outras marcas comerciais so de propriedade de seus respectivos proprietrios. A Wiley Publishing, Inc., no associada a nenhum produto ou fornecedor mencionado neste livro. LIMITE DE RESPONSABILIDADE/ISENO DE GARANTIA: A EDITORA E O AUTOR NO OFERECEM REPRESENTAES OU GARANTIAS DE QUALQUER NATUREZA COM RESPEITO PRECISO OU INTEGRIDADE DO CONTEDO DESTE TRABALHO E ESPECIFICAMENTE SE ISENTAM DE TODA E QUALQUER GARANTIA, INCLUINDO, SEM LIMITAO, GARANTIA DE ADEQUAO A UMA DETERMINADA FINALIDADE. NENHUMA GARANTIA PODE SER CRIADA OU CONCEDIDA POR MATERIAIS DE VENDA OU PROMOCIONAIS. AS RECOMENDAES E ESTRATGIAS AQUI CONTIDAS PODEM NO SER ADEQUADAS A TODAS AS SITUAES. ESTE LIVRO VENDIDO COM O ENTENDIMENTO DE QUE A EDITORA NO SE COMPROMETE A PRESTAR SERVIOS JURDICOS, CONTBEIS OU OUTROS SERVIOS PROFISSIONAIS. EM CASO DE NECESSIDADE DE ASSISTNCIA PROFISSIONAL, DEVE-SE PROCURAR OS SERVIOS DE UM PROFISSIONAL COMPETENTE. NEM A EDITORA NEM O AUTOR DEVEM SER RESPONSABILIZADOS POR PREJUZOS DECORRENTES DO USO DESTE MATERIAL. O FATO DE QUE UMA ORGANIZAO OU SITE SEJA MENCIONADO NESTE TRABALHO COMO CITAO E/OU FONTE POTENCIAL PARA INFORMAES ADICIONAIS NO SIGNIFICA QUE A EDITORA OU O AUTOR ENDOSSE AS INFORMAES QUE A ORGANIZAO OU SITE POSSA FORNECER OU AS RECOMENDAES QUE POSSA FAZER. ALM DISSO, OS LEITORES DEVEM LEVAR EM CONTA QUE OS SITES DA INTERNET APRESENTADOS NESTE LIVRO PODEM TER SIDO ALTERADOS OU DESATIVADOS APS A PUBLICAO DO PRESENTE MATERIAL.

Para informao geral sobre os nossos outros produtos e servios, entre em contato com o nosso Business Development Department nos Estados Unidos pelo telefone 317-572-3205. Para detalhes cobre como criar um livro Para Leigos personalizado para a sua empresa ou organizao, entre em contato com info@dummies.biz. Para informao sobre o licenciamento da marca Para Leigos para produtos servios, entre em contato com BrandedRights&Licenses@Wiley.com.
ISBN: 978-1-118-37062-9 Fabricado nos Estados Unidos da Amrica 10 9 8 7 6 5 4 3 2 1

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Agradecimentos da Editora
Temos muito orgulho deste livro e das pessoas que trabalharam nele. Para detalhes sobre como criar um livro Para Leigos para a sua empresa ou organizao, entre em contato com info@dummies.biz. Para detalhes sobre o licenciamento da marca Para Leigos para produtos servios, entre em contato com BrandedRights&Licenses@Wiley.com. Aqui esto algumas das pessoas que ajudaram a colocar este livro no mercado: Compras, Edio e Desenvolvimento de mdia Editora de projetos: Carrie A. Burchfield Gerente de edio: Rev Mengle Editora snior de compras: Katie Feltman Representante de desenvolvimento de negcios: Sue Blessing Especialista de projetos de publicao personalizada: Michael Sullivan Servios de redao Coordenadora snior de projetos: Kristie Rees Layout e artes grficas: Melanee Habig Revisora: Jessica Kramer

Publicao e edio, Srie Para Leigos de tecnologia Richard Swadley, Vice-Presidente e Editor executivo do grupo Andy Cummings, Vice-Presidente e Editor Mary Bednarek, Diretora Executiva, Compras Mary C. Corder, Diretora de Edio Publicao e edio, Srie Para Leigos de consumidores Diane Graves Steele, Vice-presidente e editora, Srie Para Leigos de consumidores Servios de redao Debbie Stailey, Diretora de servios de redao Desenvolvimento de negcios Lisa Coleman, Diretora, Desenvolvimento de novos mercados e marcas

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Viso geral do contedo


Introduo.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Captulo 1: Criao de produtos inteligentes.. . . . . . . . . 3 Captulo 2: Domando a fera com a Engenharia de Sistemas.. . . . . . . . . . . . . . . . . . . . . . 13 Captulo 3: Requisitos revolucionadores . . . . . . . . . . . . 23 Captulo 4: Abstrao do sistema de modelagem.. . . . 35 Captulo 5: Garantia da qualidade de primeira . . . . . . . 43 Captulo 6: Capacitao da colaborao e gerenciamento das mudanas por equipes grandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Captulo 7: Dez maneiras de ganhar com a Engenharia de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . 61

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Introduo
rodutos inteligentes so encontrados em qualquer lugar. Eles acompanham seus pacotes, controlam os sinais de trnsito, voam aeronaves e o orientam para o seu destino. Eles so o centro dos sistemas e servios que voc usa todos os dias dos smartphones aos carros inteligentes, sistemas mdicos, e sistemas aeroespaciais e de defesa. Produtos inteligentes, instrumentados e interconectados revolucionam a forma como as pessoas interagem e executam suas tarefas dirias. Com uma combinao de eletrnicos, softwares, sensores e outros hardwares, temos a tecnologia necessria para criar produtos multifuncionais personalizados. E, com a nossa imaginao ilimitada, temos o potencial de definir centenas de sistemas e servios inovadores personalizados voltados para o valor. O grande desafio ao criar produtos inteligentes a organizao: como podemos integrar com eficcia uma combinao complexa de tecnologias para criar um sistema de sistemas inteligentes que cumpram o que prometem e atinjam o seu potencial? A soluo est com a engenharia de sistemas. Engenharia de Sistemas Para Leigos, IBM Edio Limitada, explica o que a engenharia de sistemas e como ela pode ajud-lo a controlar a complexidade natural do desenvolvimento de produtos inteligentes conectados. Se quiser acelerar a colocao do produto no mercado, garantir a agilidade dos negcios e oferecer produtos inteligentes de alta qualidade e, ao mesmo tempo, reduzir os custos, Engenharia de Sistemas Para Leigos, IBM Edio Limitada, o livro para voc.

Como este livro est organizado


Os sete captulos deste livro tm por objetivo ajud-lo a entender o problema que a engenharia de sistemas tenta resolver e todas as etapas para resolv-lo. Eis aqui um resumo do seu contedo:

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Captulo 1 define os produtos inteligentes e explica porque eles justificam uma nova abordagem ao desenvolvimento de sistemas. Captulo 2 um resumo de alto nvel da engenharia de sistemas. Captulo 3 expe o papel fundamental que os requisitos desempenham no ciclo do desenvolvimento de sistemas. Captulo 4 mostra como os modelos podem aprimorar o seu entendimento da estrutura e do comportamento do sistema. Captulo 5 explica como verificar se voc construiu o sistema certo (validao) e construiu o sistema corretamente (verificao). Captulo 6 sugere formas de aprimorar a colaborao dos times de desenvolvimento. Captulo 7 fornece exemplos de algumas empresas reais que incorporaram a engenharia de sistemas nas suas principais prticas de negcios.

cones usados neste livro


LE

BRE-SE M

Ao ler este livro, voc ver vrios cones chamativos criados para destacar certa informao. Este cone destaca os conceitos principais que voc deveria memorizar.

A IC

Este cone exibido prximo s sugestes viveis que tm por objetivo facilitar, e muito, a sua vida. Estes so o oposto de uma dica. So sugestes que, quando ignoradas, certamente iro dificultar, e muito, a sua vida. Sei que voc no precisa saber de tudo o que sei, mas este cone d um pouco mais de detalhe sobre o que absolutamente necessrio, por isso voc pode pular se quiser.

O! IS V


COISA

TCNICA
S

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 1

Criao de produtos inteligentes


Neste captulo
Como lidar com a demanda de sistemas inteligentes interconectados Reconhecimento dos desafios na estrada para o sucesso Mudana de marcha para abranger um cenrio mais amplo

ense nisso: Ao dar r para sair de casa, o seu carro envia um sinal para a sua casa para armar o sistema de alarme e fechar a porta da garagem. O seu celular se sincroniza automaticamente com o sistema de comando de voz do seu carro e o sistema de posicionamento global (GPS) integrado analisa a situao do trfego ao vivo e sugere uma rota alternativa que gaste menos tempo para ir para o trabalho. O seu carro avisa que est na hora de trocar o leo, confere a sua agenda no seu smartphone, sugere horrios possveis para compromissos, e oferece para ligar para o seu posto de gasolina favorito. O carro at informa sobre a condio potencial de enchentes na sua volta do trabalho. possvel que um veculo que j foi conhecido como uma carruagem sem cavalo possa ser to inteligente e til? Claro que sim! Neste captulo, voc ir descobrir qual a fora motriz dos produtos inteligentes, como eles trabalham em conjunto, e porque voc deveria adotar novos processos de negcios no seu desenvolvimento.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

O que os produtos inteligentes tm de to inteligentes?


Os produtos inteligentes so a grande febre do momento. difcil imaginar a vida antes dos aparelhos eletrodomsticos de cozinha programveis, videogames interativos e celulares multitarefa que gravam vdeo, imprimem fotos, surfam a Internet e tocam msica. Uma aeronave pode achar o seu caminho evitando colises e contamos com drones inteligentes e outros sistemas de defesa de preciso para manter a nossa segurana. E por que estes e outros objetos inanimados podem realizar feitos to incrveis?

Entrega de valor com os sistemas inteligentes


Sistemas inteligentes movidos por software esto surgindo em todo o ecossistema: Sade: Software personalizado oferece uma acesso confivel e seguro s imagens mdicas complexas e relatrios atravs de dispositivos mveis, viabilizando que os profissionais mdicos revejam a informao do paciente fora do consultrio e acelerem os diagnsticos de emergncia. Servios pblicos: A comunicao bidirecional entre o fornecedor de energia e os consumidores atravs de uma grade inteligente facilita o controle inteligente do consumo de energia. Por exemplo, as lavadoras de roupas podem ser ligadas pela grade quando a energia mais barata, e certos aparelhos eletrodomsticos podem ser desligados durante os horrios de pico de consumo. Os carros inteligentes so outro exemplo nesta rea. Aparelhos inteligentes: Os aparelhos conectados da casa fornecem status atualizado do consumo de energia com interfaces intuitivas de usurio. O controle remoto destes aparelhos viabiliza que os consumidores atinjam o nvel de conforto desejado e reduzam o consumo de energia. Entretenimento: As TVs inteligentes fornecem acesso sem fio Internet, permitindo que os consumidores aluguem vdeos, faam compras, consultem a previso do tempo, estabeleam novas pginas personalizadas e faam download de aplicativos. Automotivo: Os sistemas anticoliso inteligentes integram uma tecnologia GPS diferencial, comunicao sem fio, e displays grficos a bordo para alertar o motorista sobre veculos prximos e at mesmo fazer uma manobra de emergncia.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 1: Criao de produtos inteligentes

Mistura de ingredientes tecnolgicos


Atualmente os produtos e servios inteligentes so o resultado da convergncia das tecnologias de manufatura, eletrnica e da informao. Os fabricantes de pensamento rpido perceberam que poderiam aproveitar os tremendos avanos dos microeletrnicos, software, dispositivos mecnicos, sensores e atuadores para criar produtos para impressionar os clientes e engolir os concorrentes. Por isso eles pegam um pouquinho disso, um pouquinho daquilo, misturam (com uma certa ajuda dos amigos engenheiros), e ta-r inventam produtos que at mesmo George Jetson acharia inovador!
LE
BRE-SE M

Os produtos inteligentes so de todos os formatos e tamanhos, mas em geral, podem ser caracterizados com trs adjetivos: Instrumentados: Dispositivos esportivos de produtos inteligentes, como cmeras, detectores de movimento, sensores de posio, receptores sem fio, som, calor e umidade leve, e campos magnticos que monitoram constantemente as operaes e farejam a vizinhana. Com o estabelecimento deste tipo de contexto, os produtos inteligentes podem se adaptar ao ambiente em tempo real. Interconectados: Quando dois ou mais produtos interagem entre si e compartilham informao, eles podem oferecer valor que vai alm da capacidade individual de cada produto. Conecte-os na Internet e no sistema de apoio ou outros sistemas de IT, e o cu o limite! Inteligentes: Com o uso de dados sensoriais, tendncias histricas e informao do perfil do usurio, os produtos bem projetados podem fazer previses, otimizar os resultados e personalizar a experincia do usurio.

Juntando tudo isso com software


No h dvida que o condutor mais importante da revoluo do produto inteligente o crescimento fenomenal da capacidade de processamento. Como o crebro por trs de cada produto inteligente, os microprocessadores integrados executam algoritmos, analisam dados, fazem clculos numricos complicados, e controlam todos os componentes mecnicos e eletrnicos de um produto inteligente.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Para fazer o trabalho, os microprocessadores executam milhares s vezes milhes de linhas de cdigos de software. Por exemplo, hoje em dia, os carros topo de linha contm dezenas de microprocessadores que executam provavelmente 100 milhes de linhas de cdigos com o objetivo expresso de oferecer 250 a 300 funes para os motoristas e passageiros. Com os fabricantes de semicondutores criando microprocessadores cada vez mais potentes, a oportunidade para os desenvolvedores de software criarem novas funes geniais est subindo como um foguete. E isto uma boa coisa porque muitos hardwares que diferenciam os produtos esto se transformando em commodities. Cada vez mais o software, e no os eletrnicos, que destaca um produto e determina quais produtos iro conquistar a fatia do mercado.

COISA

TCNICA
S

A flexibilidade inerente do software oferece inmeras oportunidades para o desenvolvimento de recursos e funes adicionais, permitindo que os fabricantes atualizem seus produtos de acordo com as expectativas de novidades por parte dos clientes. Por exemplo, os MP3 mais populares no so simples tocadores, eles armazenam bibliotecas de msica, transmitem vdeo, do suporte a mensagens, fornecem games e executam aplicativos de terceiros. Os melhores produtos podem ser facilmente atualizados para incluir funes para que acompanhem as mudanas do mercado.

Tornando-se viral com padres abertos


COISA
S

TCNICA
S

Em 2013, um nmero incrvel de 1,2 bilhes de dispositivos eletrnicos de consumo conectados estaro em 800 milhes de casas com acesso de banda larga. Se voc tem algumas boas ideias sobre como oferecer servios de valor agregado pela Internet, deve estar salivando com estes nmeros. Imagine se todos os dispositivos eletrnicos fossem criados no vcuo, com cada fabricante desenvolvendo a sua prpria forma de se conectar com a Internet e se comunicar com o mundo exterior. Poderia haver muito batepapo nas linhas, mas nenhuma delas seria til. Que perda de oportunidade! No se preocupe! Algumas pessoas realmente inteligentes com grandes vises do futuro tiveram a ideia de criar padres abertos, ou concordaram em maneiras para enviar mensagens dos dispositivos para provedores de servio. Quanto maior o nmero de empresas que usam os protocolos de comunicao definidos pelos padres abertos, maiores as oportunidades para

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 1: Criao de produtos inteligentes


todos ns. A populao est evoluindo rapidamente para uma Internet de coisas um ecossistema global de produtos e servios inteligentes e conectados.

Ateno aos clientes


Grande parte da populao mundial consiste em usurios experientes de produtos inteligentes.
COISA
S

TCNICA
S

Somente em 2010, cerca de 40 milhes de dispositivos de navegao pessoal foram vendidos no mundo e, em 2008, mais de 55 milhes de pessoas arrebataram iPods. Se voc viaja frequentemente, nem se preocupa com o tempo ruim durante um voo pelo pas porque sabe que o avio tem um equipamento inteligente que garante a segurana da sua viagem. Os usurios experientes conhecem muito bem a capacidade dos produtos inteligentes de hoje em dia e esto exigindo produtos mais inteligentes ainda. Os consumidores atualmente exigem produtos confiveis, interativos em tempo real e querem este produto agora! E se voc tiver sorte (e for inteligente) o suficiente para fazer a entrega na hora, no deve relaxar porque seus clientes j esperam um upgrade!

LE

BRE-SE M

Com a incorporao da capacidade de personalizao e de integrao nos designs, possvel criar produtos voltados para as necessidades individuais do usurio e adapt-los ao ambiente do usurio. Os clientes querem produtos que prometem facilitar e tornar suas vidas mais divertidas, no entanto, cada um deles tem uma forma nica de fazer as coisas, com um conjunto de valores distintos, implicncias e idiossincrasias. Os clientes querem produtos inteligentes to fceis de personalizar quanto baixar o aplicativo mais recente de smartphone!

Produtos Inteligentes no so ilhas


Voc pode perceber que no mais suficiente criar um produto independente, legal, cheio de recursos. Os produtos inteligentes de hoje devem ser inteligentes o suficiente para interagir com outros produtos inteligentes.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Vejamos um carro moderno, por exemplo (veja Figura 1-1). Um carro topo de linha tpico contm um conjunto de subsistemas de software sofisticados criados para tornar a experincia divertida, melhorar a segurana e otimizar a eficcia do combustvel: freios antitravamento, sistema anticoliso, controle de conforto, segurana e muito mais. O projeto e criao de um carro inteligente que na realidade um sistema de sistemas envolve a integrao complexa de componentes mecnicos, eltricos e eletrnicos, sem mencionar a execuo adequada de, aproximadamente, 100 milhes de linhas de cdigos. Para complicar ainda mais as coisas, os carros inteligentes interagem com diversos outros sistemas externos ao prprio carro. Os servios baseados em locais, sistemas de diagnstico de veculos e sistemas de recarga de carro hbrido/eltrico so apenas alguns dos muitos sistemas com os quais um carro pode interagir em um ecossistema automotivo maior. Parece complicado, no ? Mas mesmo! Mas tambm incrivelmente til. Por exemplo, se o sistema de segurana do seu carro projetado para interagir com centros de resposta de emergncia, ele pode fornecer detalhes do acidente para os socorristas baseado na coleta de dados dos sensores do carro. Os detalhes essenciais, como a fora do impacto, por exemplo, podem auxiliar o operador do servio de emergncia a determinar quais recursos de salvamento mais apropriados devem ser enviados.
Sistema de Sistemas
Sistemas de gerenciamento de frota e trfego Recarga do veculo por rede hbrida/eltrica inteligente Servios de emergncia, diagnstico de veculo, GPS/servios de localizao

Integrao da engenharia mecnica, eletrnica, software e eltrica Alarmes de segurana com auxlio do motorista

Viso panormica de 360 graus

Anticoliso preditiva

Controle do veculo hbrido e eltrico

Subsistema-intensivo em software Controle de cruzeiro


adaptativo

Navegao inteligente

Figura 1-1: Um carro inteligente um sistema de sistemas de um ecossistema maior.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 1: Criao de produtos inteligentes


BRE-SE M


O! IS V

Normalmente, os recursos mais valiosos de um produto inteligente no esto totalmente dentro do prprio produto mas so fornecidos com a interao com outros produtos ou servios do ecossistema. Da mesma forma como as pessoas, os produtos inteligentes precisam colaborar e compartilhar a informao! Poder compartilhar os dados no quer dizer que voc deveria! A privacidade, a segurana e os regulamentos (dentre outras coisas) podem ter um grande impacto no seu design!

LE

Identificao de desafios novos e empolgantes


O desenvolvimento de um produto inteligente de sucesso que oferea uma experincia personalizada para diversos tipos de clientes inconstantes e exigentes que queiram tudo para ontem , como dizer, um trabalho nada fcil. Voc pode ser um expert de renome na sua rea, tentando desesperadamente aceitar o fato de que nem a sua educao de elite nem a sua vasta experincia o preparou para os enormes desafios que voc enfrenta atualmente.
LE
BRE-SE M

Antes de escalar a montanha, para desenvolver produtos inteligentes de sucesso, voc precisa abordar as seguintes questes especficas: Domnio de mltiplas capacidades: Voc precisa ser especialista em diversas reas tcnicas, incluindo manufatura, eletrnicos, engenharia mecnica e engenharia de software. Embora a maioria das empresas seja forte em uma ou duas destas reas, esta especializao raramente encontrada sob um mesmo teto. Ser uma casa de software de categoria internacional: Se voc um fabricante de produtos que considera o software como um mal necessrio, melhor procurar um hipnotizador porque a maioria dos inteligentes dos produtos inteligentes so do software que ainda no se codifica a si mesmo (pelo menos, ainda no). Integrao do trabalho de desenvolvimento de hardware e de software: Com as funes voltadas para o software tomando o centro do palco, voc precisa fazer com que seus times de hardware e de software realmente trabalhem juntos e no apenas joguem os mdulos acabados para integrao e teste. Gerenciamento eficaz de times distribudos: Se os seus times de desenvolvimento esto localizados em cidades, fusos horrios e/ou

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

10

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


pases diferentes, tente facilitar os trabalhos em colaborao para garantir resultados eficientes, precisos e cooperativos. Interao com outros sistemas: Voc no deve lanar o nico produto do mercado que no consiga interagir com a Internet, sistemas de apoio de IT e outros sistemas interconectados. Os produtos independentes no so to inteligentes assim e muito provavelmente sero fracassos independentes. Conformidade garantida: Mesmo que o seu produto no esteja ligado diretamente aos padres regulatrios ou da indstria, ele pode interagir com um produto ou servio que esteja, por isso previna-se para que todos os outros garotos queiram jogar com voc. Mudana das prioridades do design: Priorize o seu design para capacidade de atualizao e no estabilidade do produto. Concentre-se nas prioridades de design certas. Para a rea aeroespacial pode ser a segurana, para a defesa pode ser a proteo, para os eletrnicos de consumo pode ser a capacidade de atualizao. Reduo do ciclo de vida do produto: Com a demanda de novos recursos causando a reduo da vida do servio at mesmo dos melhores produtos, o seu trabalho entrar no mercado na hora certa com o conjunto certo de recursos. Adaptao aos requisitos sempre diferentes: A mudana das necessidades do cliente, as condies dinmicas dos concorrentes e do mercado, e as metas corporativas repensadas so motivos vlidos para os pedidos irritantes de mudana. Se voc for inteligente, descubra como lucrar com a mudana.

Pesquisa dos perigos potenciais


A falha de abordar os desafios relacionados com a criao de um novo produto inteligente que seja uma bobagem pode deix-lo em maus lenis isso sem falar no prejuzo para a sua imagem e para os lucros. Os erros que possam parecer pequenos e fceis de corrigir em um produto independente normalmente so aumentados e distribudos atravs de um design de sistema interconectado. Um bug de software pode criar um caos quando no detectado no incio do processo de desenvolvimento, aumentando os custos e causando atrasos na programao. Com a quantidade de softwares nos dispositivos dobrando a cada dois anos, fcil entender porque 66% dos designs de software dos dispositivos ultrapassam o oramento, e porque 24% dos grandes projetos so cancelados devido a atrasos irrecuperveis da programao.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 1: Criao de produtos inteligentes


O! IS V

11

Se voc no puder desenvolver produtos complexos em um ciclo mais curto sem comprometer a qualidade, voc est fadado a perder a renda e manchar a sua marca. No entanto, os produtos inteligentes e interconectados normalmente tm centenas ou at milhares de requisitos exclusivos, sendo difcil imaginar ser possvel manter a qualidade e reduzir o ciclo de desenvolvimento. Se voc no estiver preparado para responder facilmente s novas demandas do mercado ou ameaas dos concorrentes, no se espante ao perder a fatia do mercado para organizaes mais ligeiras. Para muitas organizaes, somente chegar ao design inicial certo j um desafio: quase um tero de todos os dispositivos produzidos hoje em dia simplesmente falham na conformidade com as especificaes de performance ou funcionais. Voc pode apostar que estes dispositivos estaro fora das prateleiras muito rapidamente!

A IC

No porque voc tem um talento tcnico especial trabalhando no design do sistema que o sucesso garantido. Muitos sistemas falham devido a erros nas especificaes da interface do sub-sistema, fidelidade com os requisitos ou comunicaes do conhecimento principal e no de engenharia.

Reconhecimento da necessidade da mudana do paradigma


Depois de aceitar o fato de que para ter sucesso no mercado atual voc precisa mudar como o valor entregue com os seus produtos, voc pode iniciar a examinar novamente o planejamento, gerenciamento e processos de desenvolvimento do seu produto. E imediatamente voc ver a necessidade de mudar para se concentrar na inovao e na mudana com o software como a base para este diferenciador. Antigamente, quando o hardware mandava, o Design auxiliado por computador 3D (CAD) e o gerenciamento da Lista tcnica de materiais (BOM) eram tudo para o desenvolvimento de produto sequencial (veja Figura 1-2). O seu time de desenvolvimento de hardware usou um sistema CAD para desenhar o hardware para atender um conjunto de requisitos, enquanto que o time de software trabalhou com um conjunto de requisitos diferentes, porm relacionadas, para produzir o cdigo necessrio. O design CAD e o BOM foram entregues para a fbrica que calculou a forma mais rpida e mais barata de manufaturar o produto. Finalmente, os engenheiros de integrao e de teste (de outro departamento) carregaram o software e fizeram o teste geral do produto.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

12

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Planejamento

Anlise dos Requisitos


Requisitos

Design
Design CAD BOM

Desenvolvimento

Integrao e Teste

Implementao Operaes e Manuteno


Figura 1-2: Desenvolvimento de produto sequencial.

No mundo de hoje, este tipo de processo de desenvolvimento sequencial baseado em documentos simplesmente no d mais certo. Imagine tentar responder rapidamente aos eventos inesperados do mercado ou aos pedidos de novos recursos. Cada mudana exige voltar para o incio e refazer todo o processo sequencial. Sua empresa iria definhar num piscar de olhos!
BRE-SE M

Se a sua empresa depende de um sistema inteligente para sobreviver, preciso deixar de lado os processos antigos sequenciais baseados em documento e desenvolver todo um novo conjunto de processos centrais para o futuro.

LE

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 2

Domando a fera com a Engenharia de Sistemas


Neste captulo
Avaliao da engenharia de sistemas Ajuste da euforia do projeto com a realidade do mundo Modelagem do seu design

oc j pensou como a NASA conseguiu administrar com sucesso o desenvolvimento de um sistema to complexo como a da aeronave espacial Apollo? Como times to diferentes de engenheiros de projeto, programadores, fabricantes terceiros e outras pessoas conseguiram trabalhar juntos no primeiro voo tripulado para a lua? Bom, na realidade isto no poderia ter sido realizado sem a ajuda da engenharia de sistemas.

A engenharia de sistemas uma abordagem interdisciplinar da criao de sistemas maiores e complexos que atendam a um conjunto definido de requisitos de negcios e tcnicas. As indstrias aeroespacial e de defesa usam a engenharia de sistemas h muito tempo e muito do que elas aprenderam est sendo aplicado em outras indstrias. Com os sistemas de transporte, redes eltricas, e sistemas de telefonia e de rede tornando-se cada vez mais inteligentes, preciso mtodos dos voos espaciais para constru-los.
COISA
S

TCNICA
S

A engenharia de sistemas existe desde os anos 1940s, mas comeou a ganhar fora fora da NASA nos anos 1990s. Foi nessa poca que os fabricantes comearam a transformar os produtos ordinrios em sistemas inteligentes com a incorporao da tecnologia da informao passando a ser um ponto crucial no desenvolvimento de produtos. Somente recentemente o software passou a assumir um papel central.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

14

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Com a capacitao de funes sem limites nos produtos, o software passou a ter um papel central em todos os tipos de produtos, viabilizando muitos novos tipos de interconexes das peas e do produto com o mundo. O maior nmero de conexes aumentou exponencialmente a complexidade do sistema deixando as empresas sem alternativa, tendo que eliminar os silos de desenvolvimento e criar novas maneiras de gerenciar a complexidade. Neste captulo, voc saber exatamente o que a engenharia de sistemas, como ela pode ajud-lo a gerenciar a complexidade e a desenvolver produtos mais inteligentes e inovar at chegar no topo.

Engenharia de Sistemas
Se voc perguntar a cinco especialistas exatamente o que a engenharia de sistemas, vai receber provavelmente cinco talvez at seis respostas diferentes! O motivo que o termo engenharia de sistemas usado para vrias coisas diferentes e, em parte, porque o conceito de sistemas tem se modificado h dcadas, e por isso a engenharia de sistemas no teve escolha, e se modificou tambm! No se preocupe! Enquanto alguns doutores possam se preocupar com os detalhes e o escopo da engenharia de sistemas, a maioria dos especialistas concorda com a sua fundao. Nesta seo, veremos o que esta fundao e como constru-la.

LE

BRE-SE M

Enxergar a floresta e as rvores


A engenharia de sistemas uma prtica e um processo ao mesmo tempo (veja Figura 2-1): Como prtica, se preocupa com cenrio geral: como um sistema funciona e se comporta em geral, como ele faz a interface com os seus usurios e outros sistemas, como seus subsistemas interagem e como reunir vrias disciplinas de engenharia para um trabalho conjunto. Como processo, define uma abordagem estruturada slida para o desenvolvimento do sistema que possa ser aplicado ao sistema de sistemas ou dentro das disciplinas especficas da engenharia.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 2: Domando a fera com a Engenharia de Sistemas


Engenharia de Sistemas Prtica

15

anlise de disciplinas, modelagem do sistema de sistemas

Sistema

Sistema

Sistema

Sistema
conceito, design, criao, operao

Engenharia de Sistemas Processo

Subsistema

Subsistema

Subsistema

Componente Eltrico

Componente de Software

Componente Mecnico

Componente de Software

Figura 2-1: A engenharia de sistemas uma prtica e um processo ao mesmo tempo.

No importa o tipo de anlise, a engenharia de sistemas a aplicao da disciplina ao processo de desenvolvimento do sistema. E esta disciplina tem dois sabores distintos: Disciplina tcnica garante a execuo rigorosa de um processo de desenvolvimento sensato, desde o conceito at a produo e a operao. Disciplina do gerenciamento organiza o trabalho tcnico em todo o ciclo de vida do sistema, incluindo a facilitao da colaborao, definio do fluxo de trabalho e implementao das ferramentas de desenvolvimento.

Alguns princpios de orientao a seguir


D

A IC

Com a unio da amplitude com a profundidade, a engenharia de sistemas tem por objetivo ajud-lo a administrar os detalhes de um trabalho complexo de desenvolvimento sem esquecer das metas gerais do projeto. Comece com a adeso ao seguinte conjunto de princpios de orientao:
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

16

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Fique focado no prmio. Defina o resultado desejado para um projeto desde o incio e no se afaste da sua meta, mesmo que a coisa fique louca. Envolva pessoas interessadas. Pea a opinio dos clientes, usurios, operadores, gerentes de nvel C e outras pessoas ao tomar as decises nas diferentes etapas do processo de desenvolvimento. Defina o problema antes de encontrar a soluo. Mantenha a mente aberta quanto aos meios para os fins, para examinar vrias alternativas e escolha a melhor soluo para o resultado desejado. Divida o problema em partes administrveis. Decomponha o sistema em subsistemas menores, e divida cada subsistema nos componentes de hardware ou software. Outro princpio o gerenciamento das interfaces destes pedaos para a garantia da integrao e entrega da capacidade emergente exigida. Espere para escolher a tecnologia especfica. Espere at estar bem adiantado no processo antes de selecionar os componentes fsicos para evitar o compromisso com uma tecnologia desatualizada ou desnecessria quando estiver pronto para implementar o design. Conecte os requisitos com o design. Confirme se voc pode justificar as decises de design conectando-as com as necessidades tcnicas e de negcios especficas. Teste logo, teste frequentemente. Aproveite os prottipos, simuladores, emuladores e qualquer outro mtodo para que todos envolvidos no projeto vejam logo o sistema. Confira se os testes provam o atendimento dos requisitos com a sua conexo.

Explorao do processo da engenharia de sistemas


Muito bem, voc tem fortes princpios orientadores, mas como coloc-los em ao? Bem, uma maneira de fazer isso desenvolver um processo consistente para a engenharia de sistemas que abranja estes princpios.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 2: Domando a fera com a Engenharia de Sistemas

17

Aproximadamente nos ltimos 20 anos, os especialistas de sistemas complexos desenvolveram e refinaram o conhecido Modelo V do processo de engenharia de sistemas (veja Figura 2-2). O Modelo V uma representao grfica de uma srie de etapas e procedimentos para o desenvolvimento de sistemas complexos.
Conceito das Operaes (ConOps) Especificao do Sistema
Validao do Sistema

Aceitao Testes

Verificao do Sistema

Projeto Detalhado

Desenvolvimento de Software/Hardware

Implementao

Figura 2-2: O Modelo V do processo de engenharia de sistemas.

Ao traar o V da esquerda para a direita, voc executa o processo de engenharia de sistemas em uma srie de etapas, assim: Conceito de Operaes (ConOps): Identificao e documentao das necessidades dos principais interessados, capacidade geral do sistema, funes e responsabilidades e medidas da performance para a validao do sistema no final do projeto. Especificao do Sistema: Detalhe dos requisitos verificveis do sistema que atendam s necessidades dos interessados definidas no ConOps. Design de Alto Nvel: Design de uma arquitetura de sistema de alto nvel que atenda os requisitos do sistema e preveja a manuteno, atualizaes e integrao com outros sistemas.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Inte

Verificao das Unidades/ Dispositivos

Unidade/ Dispositivo Testes

gra

eR

Design de Alto Nvel

eco

Verificao dos Subsistemas

Subsistema Testes

mp

osi

Sistema Testes

De fini

o eD eco mp osi

18

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Projeto Detalhado: Exame do design do sistema, desenvolvimento dos requisitos de componentes que do suporte compra de hardware dentro do oramento. Desenvolvimento de Software/Hardware: Seleo e procura da tecnologia apropriada, e desenvolvimento do hardware e software para o cumprimento das especificaes detalhadas do projeto. Teste de Unidade/Dispositivo: Teste de cada componente da implementao de hardware, verificao da funcionalidade de acordo com os requisitos dos componentes. Teste do Subsistema: Integrao dos componentes de hardware e de software em subsistemas. Teste e verificao de cada subsistema de acordo com os requisitos de alto nvel. Teste do Sistema: Integrao dos subsistemas e teste de todo o sistema de acordo com os requisitos do sistema. Confirmao de que todas as interfaces foram implementadas adequadamente e de que todos os requisitos e limites foram atendidos. Teste de Aceitao: Confirmao de que o sistema cumpre com os requisitos e atinge as metas desejadas. Durante o processo de engenharia de sistemas, criao e refinamento da documentao do sistema. Em cada etapa esquerda do V na Figura 2-2, crie os requisitos para a prxima etapa, bem como um plano para a verificao da implementao do atual nvel de decomposio. Por exemplo, durante a etapa de ConOps, voc cria um documento com os requisitos de alto nvel do sistema que conduz etapa de Especificao do Sistema, e cria o Plano de Validao do Sistema que conduz ao Teste de Aceitao. Em cada etapa direita do V, voc cria a documentao de suporte ao treinamento, uso, manuteno, instalao e teste do sistema.
A IC

Com a conexo de todas as etapas esquerda do V de todos os requisitos e referindo-se a estes requisitos durante o trabalho em direo direita do V, voc estar muito mais propenso a permanecer fiel sua misso original e manter a objetividade durante o processo. Estas conexes so conhecidas na engenharia de sistemas como rastreamento. O Captulo 3 abrange os requisitos e o rastreamento com detalhes.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 2: Domando a fera com a Engenharia de Sistemas

19

Gerenciamento da complexidade com modelos


Alguns modelos so teis, principalmente para um projeto de engenharia complexo. Se voc puder desenvolver mtodos relativamente baratos para o design, teste e verificao do sistema antes de produzi-lo, possvel economizar bastante tempo e dinheiro e at mesmo o seu trabalho! Uma maneira de fazer isso usar modelos para fazer o design e refinar o sistema durante o processo de desenvolvimento.
BRE-SE M

Com os modelos do sistema possvel capturar a complexidade em diversos nveis, incluindo o sistema de sistemas (tambm conhecido como ecossistema), sistema, subsistema e nveis de componentes. Com eles possvel explorar os detalhes de cada um destes nveis, conhecidos como nveis de abstrao, independentemente e ocultar ou expor os detalhes de acordo. Os modelos podem ter diferentes formatos. No nvel mais simples, pode ser apenas uma planilha usada para calcular alguma propriedade emprica do sistema. Por outro lado, pode ser uma simulao de computador interativa altamente complexa. Por exemplo, para entender como o sistema automotivo (traduo: carro) que voc est desenvolvendo capta e encaminha os dados do impacto em uma coliso para um sistema de resposta de emergncia. preciso explorar a informao sobre os sensores do carro e como o carro interage com o sistema externo, mas voc provavelmente no deve se distrair com detalhes externos, como o diagrama de fiao e colocao de componentes. O modelo certo pode mostrar o que necessrio sem detalhes extra. Os modelos podem proporcionar os seguintes benefcios: Permitir a concentrao na informao relevante para a presente questo, e garantir a consistncia do seu design. Captura da estrutura (arquitetura) e comportamento (funcionalidade) de um sistema, ilustrando o relacionamento e a interao dos elementos do sistema.

LE LE

BRE-SE M

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

20

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


possvel usar os modelos na previso do comportamento em diversos nveis de abstrao, permitindo a explorao de diferentes arquiteturas no incio do processo de desenvolvimento e a execuo de estudos de compensao para avaliar as opes de design que faam mais sentido. possvel desenvolver modelos executveis para a validao do design de acordo com os requisitos antes da construo do sistema. Os modelos permitem a visualizao dos detalhes de um sistema com diversas perspectivas (por exemplo, arquitetura, lgica, funo, dados fsicos, dados, e usurio), para a abordagem de questes especficas. possvel explorar modelos que ajudem a administrao do trabalho de desenvolvimento. A modelagem oferece uma tremenda visibilidade do sistema, proporcionando um ponto focal potente para a discusso e entendimento mtuo. Os modelos oferecem um espao para os pensamentos e critrios de decises, facilitando a colaborao entre voc e seu time de desenvolvimento. E, talvez o mais importante, o modelo do sistema fornece um ponto de sincronizao de diversas disciplinas de engenharia, e uma soluo para um dos problemas mais significantes para o desenvolvimento de sistemas inteligentes: como coordenar o hardware e o software.

Como falar o mesmo idioma


Da mesma forma como um arquiteto usa um conjunto de padres para representar elementos de um prdio em um desenho a ser interpretado por um mestre de obras, um time de desenvolvimento deve usar uma linguagem comum para representar os modelos de sistema que promovam a compreenso geral. Em 2001, o International Council on Systems Engineering (INCOSE), juntamente com o Object Management Group (OMG), iniciaram o desenvolvimento de uma linguagem de modelagem comum para as aplicaes de engenharia de sistemas e, em poucos anos, a Linguagem de Modelagem de Sistemas (SysML) nasceu. Criada como uma adaptao da Linguagem de Modelagem Unificada (UML) concentrada no software, a SysML o verdadeiro idioma padro para sistemas de modelagem e sistemas de sistemas.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 2: Domando a fera com a Engenharia de Sistemas


A SysML usa uma abordagem de diagrama simples para modelar os sistemas (to simples que algumas pessoas os chamam de pintura de caverna), onde a unidade bsica da estrutura um bloco pode ser usada para representar o hardware, software, instalaes, pessoal ou qualquer outro elemento de um sistema. Com uma srie de diagramas de estrutura em ninho, define-se a estrutura interna e o uso desejado de um elemento particular do sistema (por exemplo, um sistema de freio antitravamento). Ento, com uma srie separada de diagramas de comportamento em ninho, possvel mostrar como aquele elemento do sistema interage com outros elementos, e com os atores (usurios, sistemas externos ou o ambiente), para cumprir ou realizar o comportamento.

21

Alm da modelagem da estrutura (arquitetura) e do comportamento dinmico (funcionalidade) do sistema, a SysML tambm permite a modelagem dos requisitos e dos par-metros da performance. Por exemplo, em um sistema automotivo, possvel criar um diagrama de requisitos para especificar um limite, como parar a 105 kph em uma distncia de 55 m em uma superfcie limpa e seca e diagramas paramtricos para especificar as equaes que controlam o movimento do carro. E o melhor de tudo, possvel usar as novas ferramentas de software potentes pense como se fosse a construo de um simulador de um novo carro de corrida. Isto significa que voc pode fazer um test-drive para verificar a direo antes mesmo de constru-lo!
A IC

Com a definio e a organizao de modelos de construo, a SysML fora os engenheiros e arquitetos de sistemas a ser bastante claros e precisos ao projetar o sistema. Isto reduz a ambiguidade e leva a uma maior qualidade, ciclos de desenvolvimento mais curtos e custos reduzidos.

Uma boa imagem vale mil (ou um bilho) de palavras


A melhor maneira de entender a modelagem com a SysML olhar o diagrama da SysML. A Figura 2-3 mostra um diagrama do contexto simples de um carro moderno que tem um receptor integrado do Sistema de Posicionamento Global (GPS) e um controle remoto do sistema de controle de segurana residencial.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

22

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Motorista Carro Sistema de Posicionamento Global

Sistema de Vigilncia Residencial


Figura 2-3: Um simples diagrama do contexto de um carro.

Use o diagrama do contexto para definir os limites, ou contexto, do sistema. Neste caso, o sistema o carro, que interage com trs atores externos do sistema: o motorista, o sistema GPS e o sistema de segurana residencial. Um ator qualquer coisa com o qual o sistema interage, um usurio, outro sistema ou o ambiente. Use o diagrama do contexto para fornecer os detalhes do sistema sendo considerado.
BRE-SE M

Com a definio do sistema e dos seus atores, voc identifica os relacionamentos importantes e, com isso, os requisitos e interfaces. Ai ento tem incio o mapeamento das especificaes da interface e do fluxo de dados entre o sistema e os seus atores. Sem um diagrama do contexto, possvel deixar de ver um ator ou dois e cometer falhas quanto aos requisitos do sistema. Por exemplo, com a falha na definio do sistema de segurana residencial como um ator do ecossistema, o seu carro deixa de ser inteligente o suficiente para armar o sistema de alarme.

LE

O! IS V

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 3

Requisitos revolucionadores
Neste captulo
Reconhecimento dos benefcios da mudana Cobertura de todos os requisitos com a incluso de casos de utilizao Requisitos em cascata no processo de desenvolvimento Anlise do impacto da mudana Compreenso (do gerenciamento dos requisitos)

ntigamente os requisitos eram criados no incio de um projeto e o produto era projetado ao redor destes requisitos e, quando o departamento de marketing informava que o cliente queria fazer uma mudana (ou duas ou trs), voc batia o p, fazia cara feia e reclamava do processo de mudana dispendioso dos requisitos que exigia 57 assinaturas. Mas isso est mudando. Em um mercado voltil e competitivo cujo sucesso est atrelado a satisfazer cada vez mais os clientes, voc tem duas opes: mudar ou reclamar. Neste captulo, voc descobrir como projetar os requisitos do sistema j pensando nas mudanas para garantir que o design do sistema satisfaa estes requisitos.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

24

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Adoo da filosofia de mudana


Nesta nova era de produtos inteligentes, preciso responder rapidamente dinmica do mercado, como as mudanas das necessidades do cliente, novas ameaas de concorrncia ou o mais recente padro regulatrio. Os criadores de produtos tambm observaram durante os ltimos anos que os requisitos devem mudar com o melhor entendimento das necessidades durante o processo de desenvolvimento. Para o processo de desenvolvimento de sistema tradicional, a mudana o inimigo. E o que voc deve fazer? Criar um novo processo. A boa notcia que outras pessoas que passaram por isso estabeleceram um processo de projeto de requisitos totalmente novo. Mais do que simplesmente uma anlise e definio antecipada dos requisitos, a engenharia de requisitos define completamente o processo para o estabelecimento dos requisitos, atrelando-os aos testes, e facilitando a mudana.
D

A IC

Os requisitos funcionam melhor quando projetados com o pensamento na mudana. A filosofia da engenharia de requisitos que a mudana bemvinda. Na realidade, a mudana uma meta!

Compreenso do contexto
Antes de estabelecer um conjunto inicial de requisitos para um produto ou sistema inteligente, vale a pena pensar um pouco no problema que o seu produto est tentando resolver. Por exemplo, se a inteno criar um carro, essencial que voc entenda exatamente como e por quem ele ser usado. O carro ser para a cidade, estrada ou corrida? O mercado alvo consiste principalmente em motoristas mais velhos, homens jovens ou pais que no trabalham? O carro ter que enfrentar condies difceis, como frio extremo, rodovias com sal, calor extremo, terreno montanhoso ou alta altitude?
LE
BRE-SE M

A compreenso do contexto essencial para o desenvolvimento de sistemas que alcancem as metas de marketing e de negcios. O contexto significa um conjunto de atores (por exemplo, usurios, outros sistemas e o ambiente) com o qual o sistema interage, e como as interaes do sistema com seus atores so realizadas.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 3: Requisitos revolucionadores

25

A Figura 3-1 mostra um diagrama do contexto para um carro com um sistema de navegao integrado e um sistema de controle de segurana de residncia voltado para uso em climas frios. Neste diagrama, o carro tratado como uma caixa preta que interage com os seguintes atores: o motorista, o sistema GPS e o sistema de segurana residencial e o clima frio. A definio do contexto ajuda a entender qual funcionalidade exigida do sistema e que tipo de trocas ocorrem entre o sistema e seus atores.

Motorista Carro

Ambiente de inverno

Sistema de Vigilncia Residencial

Sistema de Posicionamento Global

Figura 3-1: O contexto de um sistema delineia os limites e especifica as interfaces.

A compreenso do contexto tambm ajuda a garantir de que todos os requisitos, relacionamentos e interfaces necessrios sejam considerados antes do incio do processo de desenvolvimento. Por exemplo, a omisso do ator ambiente frio para o carro pode resultar na falha de especificar requisitos de um pacote para convenincia climtica com cabos de bateria pesados e um revestimento protetor do chassi. No mais alto nvel de abstrao, o seu sistema uma caixa preta que interage com um conjunto externo de atores. A caixa preta tem um conjunto de subsistemas interconectados (por exemplo, freios antitravamento, sistema de navegao, etc.) que compe o sistema. possvel decompor cada subsistema em um conjunto de componentes interconectados (e, talvez, subsistemas). Em cada nvel da decomposio (por exemplo, sistema, subsistema, componente) do seu sistema, o contexto muda.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

26

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Compare o diagrama do contexto do carro (veja Figura 3-1) com o diagrama do contexto do subsistema de navegao integrado do carro (veja Figura 3-2). No nvel do sistema, o carro a caixa preta que interage com atores externos. No nvel do subsistema, o subsistema de navegao a caixa preta que interage com diferentes conjuntos de atores: o motorista, o subsistema eltrico do carro e o sistema GPS.

Motorista

Subsistema de Navegao

Sistema de Posicionamento Global

Subsistema Eltrico
Figura 3-2: O contexto muda com a explorao dos diferentes nveis do sistema.
BRE-SE M

A compreenso do contexto delineia os limites do sistema e define as interfaces, estabelecendo a base para uma especificao precisa dos requisitos do sistema.

LE

Mergulho nos requisitos


Pense nos requisitos como trs amplas categorias ou nveis: Requisitos de origem. So os requisitos obtidos dos clientes ou interessados. Podem ser amplos e gerais, detalhados e especficos, abrangentes ou fragmentados ou mais provavelmente, um pouco de tudo. Como diz o ditado, os clientes no seguem nenhuma regra para oferecer os requisitos o que voc conseguir j lucro. Requisitos da misso ou dos negcios. So os requisitos que especificam o contexto operacional do sistema no o que o sistema faz, e sim o papel que ele tem no mundo. Para uma nova aeronave militar, pode descrever os tipos de misses a serem realizadas. Para um novo smartphone, os requisitos dos negcios podem descrever a operao da infraestrutura de comunicao da operadora do celular.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 3: Requisitos revolucionadores

27

Requisitos do sistema/subsistema. So os requisitos que definem o que o sistema deve fazer. Eles iniciam em um alto nvel do sistema e so analisados e decompostos para produzir os requisitos dos subsistemas de nvel mais baixo. Eles podem ser expressados com sentenas com o termo deve ou em formatos mais avanados como modelos e diagramas. Em cada nvel da abstrao, os requisitos definem o que um sistema deve fazer e como ele deve ser feito, mas no como deve ser implementado. Com os sistemas inteligentes tornando-se cada vez mais complexos, quase impossvel chegar aos requisitos do sistema certos no princpio. E nas reas como de eletrnicos de consumo, por exemplo, no qual a mudana mais importante do que a estabilidade, voc no deve congelar os requisitos no incio do processo de desenvolvimento.

Busca de mais informaes


Vale a pena obter a maior quantidade de informaes possvel para os requisitos da origem, do maior nmero possvel de interessados desde o incio do processo de engenharia dos requisitos. Voc deve iniciar com os clientes, claro, mas tambm deve obter informao sobre os padres regulatrios, da indstria e de segurana que governam o seu sistema, interfaces e troca de dados com outros sistemas (como por exemplo, o sistema GPS), e as limitaes dos negcios e de marketing.
BRE-SE M

O objetivo obter os requisitos que descrevam a capacidade e no as funes do sistema. (Por exemplo, o que o sistema deve fazer e no como deveria fazer.) Pergunte a um cliente que esteja descrevendo a funo, o que ele quer. Isto deve levar capacidade. Tambm importante especificar os requisitos funcionais e no-funcionais. Use os requisitos funcionais para descrever o que o sistema deve fazer, de acordo com certas informaes. Por exemplo, em um determinado ponto inicial e de destino, o seu sistema de navegao deve apresentar um mapa e exibir uma rota. Use os requisitos no funcionais para especificar os requisitos de performance ou de qualidade, ou para impor limites ao design. Inclua nestes requisitos coisas como velocidade, capacidade, confiabilidade, peso, uso e escalabilidade.

LE

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

28

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Para ter certeza que cobriu todos os ngulos, desenvolva casos de utilizao que descrevam todas as possibilidades de utilizao das funes do sistema. Por exemplo, a funo mapa da rota do seu sistema de navegao pode ser usado para encontrar o posto de gasolina mais prximo ou para mostrar os hotis na vizinhana do meu destino. Os casos de utilizao normalmente so compostos de sequncias de uma ou mais funes do sistema. Os casos de utilizao contam histrias concretas da utilizao do sistema e podem ser usados em trs nveis de requisitos origem, misso/negcios e sistema/ subsistema.

A IC

Com a captura da utilizao durante o desenvolvimento dos requisitos, mais provvel que voc projete um sistema que proporcione um valor real.

Satisfao e obteno de requisitos


Aps avaliar o contexto do sistema e definir um conjunto inicial de requisitos de alto nvel do sistema, use estes requisitos para chegar ao processo de design de alto nvel (veja Figura 3-3). Durante o processo de design so desenvolvidos os requisitos adicionais, como o Plano de Verificao do Sistema a ser atingido durante o teste do sistema, ou os limites do design arquitetnico que devem ser alcanados pelo projeto detalhado.

Mini van Especicao

Requisito: EcoFriendly

Requisito: Performance

Casos de utilizao Acelerar

Renado por

Requisito: Potncia Requisito: Emisses Requisito: Ecincia de combustvel Requisito: Frenagem Requisito: Acelerao
derivado Requ

atende padro de emisso ultra baixo

Caso de teste Acelerao mxima

Vericado por

Preenchido por
Potncia Subsistema

Figura 3-3: Processo do design de alto nvel.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 3: Requisitos revolucionadores


BRE-SE M

29

O exame do alcance do seu design atende os requisitos desenvolvidos no nvel de design anterior (mais alto) e trazem requisitos que devem ser usados pelo nvel do teste correspondente, bem como do nvel de design seguinte (mais baixo). Como voc pode ver, a definio de requisitos est expandindo, pois as linhas que diferenciam os requisitos do design esto cada vez mais tnues, e a conexo entre o teste e o design tornam-se crticas. O conjunto final de requisitos uma combinao dos requisitos iniciais do sistema de alto nvel com os requisitos obtidos durante o processo de design.

LE

Criao dos diagramas dos requisitos


Embora os requisitos antigos baseados em texto ainda sejam necessrios para grandes projetos com obrigaes contratuais, normalmente no so suficientes no mundo atual dos produtos inteligentes complexos, flexveis e focados no cliente. Felizmente, a Linguagem de Modelagem de Sistemas (SysML) amplamente adotada fornece uma base de trabalho para os requisitos de modelagem. Enquanto os grandes conjuntos de requisitos de texto ainda existem em um banco de dados, principalmente os enviados pelo cliente, existem agora novas formas melhores de visualizar e trabalhar com conjuntos de requisitos afins. A SysML permite a criao de modelos de requisitos hierrquicos que ilustram as dependncias, classificam os requisitos como originais ou derivados, e captam a lgica da opo do design. So dois os nveis de requisitos de sistema de alto nvel: EcoFriendly e Performance. (Veja Figura 3-3.) O requisito EcoFriendly tem um sub-requisito especfico que Emisses. O requisito Performance tem trs sub-requisitos, sendo um deles a Acelerao. O sub-requisito Acelerao mais refinado em casos de utilizao especficos. definido um plano de teste para acelerao mxima (um requisito que o processo deve atender). Finalmente, o sub-requisito Acelerao gera um requisito derivado para energia, atendido pelo subsistema Potncia. Os diagramas dos requisitos SysML permitem a fcil visualizao dos relacionamentos e a resposta de perguntas do tipo: Quais requisitos o subsistema Potncia atende? ou Qual pode ser o impacto da mudana

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

30

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


do requisito Tamanho da Carga? Quando os requisitos so tratados como parte integral da arquitetura do sistema, muito mais fcil visualizar o impacto das mudanas dos requisitos do seu sistema. E esta no uma das metas da engenharia de sistemas?

Direcionamento das decises do design com os requisitos


Com os requisitos em cascata no processo de design, a natureza de alguns deles podem levar a opes de design especficas. Por exemplo, ao projetar um sistema anticoliso de avio, o incio do processo pode apresentar trs opes de design, cada uma delas satisfazendo os requisitos funcionais para evitar a coliso: Sistema de radar de bordo Transponder Principalmente manual (comunicao com o controle de trfego areo) Cada opo de design tem o seu conjunto nico de componentes, requisitos de espao e custos, e envolve certo nvel de colaborao dos sistemas com seus atores (por exemplo, controle de trfego areo). Com a maior decomposio do design, possvel encontrar um requisito no funcional, como espao mximo da cabine de comando que limita as opes de design (o sistema de radar no cabe!). Os engenheiros de sistemas usam uma tcnica chamada estudo de compensao para avaliar as muitas opes de design que devem ser adotadas. basicamente a mesma coisa que todos fazem ao tomar uma deciso importante. Identificar os fatores importantes para a deciso, pontuar cada alternativa de cada fator, adicionar ajustes de ponderao e tomar a deciso. Os estudos de compensao normalmente exigem vastas pesquisas para a avaliao total das alternativas. O acompanhamento de todos os requisitos e como eles afetam as outras partes do sistema so um mal necessrio para a oferta de produtos de sucesso. As ferramentas de software prontas para uso ajudam a administrao dos requisitos do sistema.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 3: Requisitos revolucionadores


O! IS V

31

A omisso de um requisito pode causar problemas srios. Por exemplo, possvel projetar um porta-copos para automveis mais fenomenal do mundo, mas se ele ficar localizado embaixo do som do carro fazendo com que o seu caf latte grande bloqueie os controles porque voc esqueceu de levar em considerao o requisito de deixar um amplo espao livre no design, voc vai errar feio. Erros como esse podem sair muito caro.

Malabarismo com os requisitos e Designs


No exemplo de anticoliso para avies na seo anterior, vamos supor que voc selecionou a opo de design transponder do sistema. Esta opo semiautomtica envolve o monitoramento dos sinais do transponder do avio na rea por parte do controle de trfego areo. A opo de design dispara sub-requisitos de um design de subsistema de transponder e um plano de teste do subsistema. Voc j est bem adiantado no design do subsistema quando recebe um pedido de mudana de requisito. O novo requisito especifica que a aeronave deve evitar colises de modo independente. A sua opo de design no atende a este novo requisito, por isso preciso colocar este design de lado e trabalhar com uma opo alternativa, o sistema de radar. Certas mudanas podem produzir requisitos derivados de um design de subsistema que podem propagar-se at o design do sistema. Por exemplo, as restries de custo podem limitar a escolha de um componente do sistema que, por sua vez, limitam a funcionalidade do subsistema, afetando os requisitos originais. Antigamente (alguns anos atrs!) este processo de propagao da mudana consumia muitas horas ou at semanas, com os engenheiros rastreando e modificando os documentos e designs relevantes nos documentos em processador de texto, slides de apresentao e planilhas. A introduo de modelos no processo ajuda muito, conforme discutido no Captulo 4.
LE
BRE-SE M

Estabelea um processo formal para mudanas de requisitos e assim entender facilmente o impacto das mudanas no design do seu sistema.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

32

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Vinculao dos requisitos com os testes


Voc concluiu o design de um novo sistema de navegao de automvel super-sensvel. O prottipo j foi construdo e o time de testes informou que o sistema est funcionando muito bem. Na realidade, ele calcula a velocidade da rota entre dois pontos com tal velocidade (graas ao seu algoritmo brilhante), que deve acabar com a concorrncia. O seu chefe, todo orgulhoso, oferece o prottipo para o seu CEO usar durante um dia. O CEO fica impressionado at tentar encontrar o restaurante chins mais prximo e perder a pacincia esperando pela resposta. Voc tenta descobrir o que aconteceu e percebe que o seu algoritmo foi otimizado para clculos de rota de ponta-a-ponta mas no para encontrar locais dentro de uma certa distncia. E, embora o plano do teste do seu sistema tenha testado a funcionalidade do sistema, no testou todos os casos de utilizao (ou talvez algum tenha esquecido de criar este caso de utilizao).
BRE-SE M

Um componente principal do processo de engenharia de sistemas o estabelecimento de vnculos entre os requisitos e os testes. Tenha certeza de construir o sistema que voc planejou e no apenas um sistema que funcione. Em cada nvel da decomposio do sistema, com o ajuste e a derivao dos requisitos, voc cria e refina os planos de teste para confirmar que o sistema atende aos requisitos. Quando os requisitos mudam, os planos do teste tambm devem mudar. Normalmente, o ato de escrever um critrio para testes de um conjunto de requisitos ajuda a melhorar e a refinar os prprios requisitos.

LE

A IC

sempre bom avaliar os requisitos e confirmar que eles podem ser testados e at especificar no incio como eles devem ser testados.

No esquea de deixar um rastro


Para a garantia de que todos os requisitos sejam implementados adequadamente, preciso rastrear cada um deles durante o processo de desenvolvimento e de teste.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 3: Requisitos revolucionadores


LE
BRE-SE M

33

Rastreamento dos requisitos a capacidade de vincular cada requisito com trs itens relacionados: As necessidades dos interessados (requisitos da origem) que so atendidas Os elementos que implementam ou executam o sistema O caso de teste que o verifica O rastreamento ajuda a garantir a conformidade com os regulamentos e padres, evita o esquecimento de requisitos e mantm o foco nas metas gerais do projeto. Com o estabelecimento de vnculos de rastreamento completos, possvel avaliar exatamente o impacto da mudana de requisitos mais recente ou uma opo de design alternativa antes que a mudana seja feita.

Recompensa do seu trabalho to duro


Nos sistemas grandes e complexos, o gerenciamento dos requisitos pode ser um pesadelo. Muitos times de desenvolvimento consistem em centenas e at milhares de arquitetos e engenheiros, e todos eles tocam os requisitos, seja para criar e editar ou simplesmente para rever e entender estes requisitos. O rastreamento normalmente atravessa quatro nveis de decomposio enquanto os requisitos dos interessados so percorridos em cascata at o design do componente e os requisitos de teste. Alm disso, estes nveis de decomposio normalmente atravessam as fronteiras da cadeia de suprimentos, tornando a vida ainda mais desafiadora. Um gerenciamento eficaz dos requisitos envolve muitas disciplinas de engenharia, incluindo o design do sistema, arquitetura, software, mecnica, eletricidade e engenharia do teste. As funes dos negcios, como o marketing e compras, tambm esto interessadas no gerenciamento dos requisitos.
D

A IC

As ferramentas de software podem ajudar no entendimento do processo de gerenciamento dos requisitos difceis. Estas ferramentas so projetadas para manter o histrico das auditorias, preservar todas as mudanas,

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

34

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


conduzir anlises de impacto, e automatizar o processo de gerenciamento da mudana. Elas tambm podem alertar sobre os requisitos ignorados, designs muito trabalhados e no conformidade. O gerenciamento dos requisitos muito difcil, mas com a ajuda das ferramentas certas possvel ter um grande retorno em termos de custo, agendamento e sucesso do projeto e manter a sanidade mental.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 4

Abstrao do sistema de modelagem


Neste captulo
Decomposio do sistema em nveis de abstrao Visualizao de como os elementos se encaixam Como o sistema deve se comportar Ajuste dos modelos do sistema com a iterao

ma frmula um tipo de modelo. Ela capta o relacionamento matemtico das variveis inseridas e o representa com uma estrutura matemtica que aplicada a diversos tipos de entradas. A visualizao da frmula ajuda o entendimento da relao dos elementos da estrutura. E, com o uso da frmula, possvel testar vrios tipos de possibilidades diferentes at encontrar a melhor frmula. Neste captulo, vamos explorar como possvel usar os modelos do sistema para administrar a complexidade, o relacionamento abstrato essencial do sistema e executar testes econmicos antes da construo do produto.

Arquitetura do sistema de modelagem


Os modelos de arquitetura viabilizam a captao da natureza esttica do sistema, incluindo a estrutura e o uso pretendido do sistema. Por exemplo, considere o modelo arquitetnico simplificado de um carro mostrado nas Figuras 4-1 e 4-2.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

36

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


O modelo da estrutura parcial da Figura 4-1 decompe o sistema em diversos nveis. No nvel superior, vemos o sistema geral: o carro. Um nvel abaixo, vemos dois dos muitos subsistemas de um carro: o sistema de freio antitravamento (ABS) e o chassi. O subsistema do chassi se decompe ainda mais em outro subsistema (o conjunto dos cubos), um componente mecnico (o pneu), e outros subsistemas e componentes no mostrados neste diagrama. O subsistema do conjunto dos cubos consiste em um componente eletrnico (sensor) e diversos componentes mecnicos no mostrados na figura. O subsistema ABS se decompe em um componente mecnico (rotor) e outro subsistema (o controlador antitravamento). O subsistema controlador antitravamento consiste em dois componentes eletrnicos: o detector de trao e o modulador do freio. As linhas pontilhadas que conectam o sensor do conjunto dos cubos com o controlador antitravamento mostram que os dois se relacionam, embora o sensor no seja um elemento do subsistema do controlador antitravamento.

Mini van Estrutura

Sistema de Freio Antitravamento (ABS)

Chassi

Rotor

Antitravamento Controlador

Conjunto dos Cubos

Pneu

Trao Detector

Freio Modulator

Sensor

Figura 4-1: Um modelo arquitetnico simplificado de um sistema de minivan.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 4: Abstrao do sistema de modelagem


BRE-SE M

37

Os modelos estruturais, como o modelo arquitetnico simplificado mostrado na Figura 4-1, captam a estrutura hierrquica da arquitetura do sistema e ilustram as conexes dos elementos do modelo. A Figura 4-2 mostra outra pea do modelo arquitetnico completo: uma viso interna de como as peas do subsistema do controlador antitravamento interagem entre elas e com o sensor do conjunto dos cubos. Neste caso, a sada do sensor conectada sada do detector de trao e a sada do detector de trao conectada sada do modulador do freio. Este diagrama simples ilustra as conexes para indicar o uso pretendido mas no especifica as condies nas quais as interaes acontecem. Os modelos de comportamento (discutidos na prxima seo) so usados para descrever a sequncia de eventos que devem acontecer para que as interaes ocorram (por exemplo, a leitura do sensor indica a perda de trao, e isso faz com que o detector de trao acione o modulador do freio).

LE

Sensor

Trao Detector

Freio Modulator
Controlador Antitravamento

Figura 4-2: Modelos arquitetnicos captam a informao de uso.

Os modelos estruturais como estes podem mostrar a arquitetura fsica, como no exemplo acima, ou podem ser usados para mostrar a arquitetura lgica. As arquiteturas lgicas so usadas cada vez mais no desenvolvimento de sistemas complexos porque permitem que os engenheiros calculem as interaes funcionais sem especificar uma estrutura fsica particular. Vejamos o carro da Figura 4-1. H algumas dcadas, os subsistemas de carros, como freios, motor e o rdio, eram completamente separados, e era apenas necessrio entender a arquitetura fsica para construir um carro. Pense agora na arquitetura lgica de um carro que tenha elementos como estes:

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

38

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Propulso, que ultrapassa as fronteiras fsicas dos freios, parte eltrica, motor e controles Gesto da Informao, que inclui toda a informao recebida, armazenada, enviada ou usada no carro Entretenimento, que pode ter componentes fsicos em comum com a propulso e a informao Segurana, que pode estar vinculada a muitos outros sistemas do carro como freios, gesto da informao e a interface de usurio do motorista Ao considerar a arquitetura lgica separadamente e, o ideal, antes da implementao fsica os engenheiros de sistemas podem adotar abordagens melhores e mais elegantes. Uma abordagem das arquiteturas lgica e fsica uma grande forma de administrar a complexidade dos novos produtos inteligentes integrados que no so mais projetados como o carro do seu av.

Comportamento do sistema de modelagem


Para entender como um sistema se comporta, preciso entender como os componentes da arquitetura (lgica e fsica) de um sistema interagem. Os modelos de comportamento do sistema captam a informao dinmica do sistema, como as transies de estado, aes que o sistema executa em resposta a eventos especficos, e interaes das peas que colaboram dentro de um sistema. Os modelos tambm captam o fluxo de dados e o controle das atividades, como por exemplo, como os dados de sada do sensor passam para as atividades ocorridas no controlador antitravamento de um carro, ou como o controle passa de uma pea para outra do sistema. A Figura 4-3 mostra um diagrama do estado simplificado que descreve os estados operacionais de um carro. Este carro permanece em um dos quatro estados desligado, marcha lenta, acelerando ou freando at que um evento especfico ocorra (por exemplo, frear) que faz com que o carro passe para outro estado. possvel mapear as conexes dos modelos de comportamento com os modelos estruturais para aplicar a consistncia atravs de um processo chamado alocao. Por exemplo, alocao da ao detectar perda de trao para o componente detector de trao do modelo estrutural do sistema, e alocao da ao fora do modulador do freio para o componente modulador do freio.
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 4: Abstrao do sistema de modelagem

39

Desligado

iniciar o motor

parar o motor

Dirigir Marcha lenta


acionar o acelerador quando a velocidade = 0 soltar o freio

Acelerando
frear

Freando

Figura 4-3: Modelo de comportamento mostrando as transies dos estados operacionais.

Nos sistemas complexos, preciso muitos modelos de pequenos comportamentos para representar toda a atividade ocorrida. Em muitos casos, uma atividade aciona uma ao em outra parte do sistema, por isso os modelos individuais so interconectados. Ao final da modelagem de toda a atividade, voc tem um modelo grande, complexo, uniforme e consistente do comportamento geral do sistema.
A IC

Com o uso da construo e da semntica da modelagem padro, como as fornecidas pela Systems Modeling Language (SysML), possvel usar ferramentas de software comercial para automatizar a execuo dos modelos de comportamento do sistema. As ferramentas podem traduzir automaticamente as construes de modelagem, como os diagramas de transio do estado, em sentenas com cdigo se-ento-executar. Desta forma, possvel simular o comportamento do sistema no software, viabilizando a execuo dos estudos e-se, ver as alternativas do design e realizar anlises de impacto antes da construo do sistema. Os estudos de compensao, que normalmente levam horas ou at dias, podem ser realizados em minutos desta forma.

Mapeamento dos modelos


Os padres da indstria, como a SysML, so a base para o entendimento comum da modelagem de sistemas em todos estes estgios. Os modelos
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

40

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


SysML so um conjunto de diagramas que representam a estrutura, comportamento, requisitos e limites quantitativos de um sistema. Os diagramas SysML vem em quatro tipos diferentes: Estrutura: Descreve que elementos arquitetnicos (lgico e fsico), conhecidos como blocos, esto contidos no sistema ou subsistema e como eles se conectam. Por exemplo, um subsistema de freio antitravamento contm um detector de trao e um modulador do freio. Comportamento: Descreve o comportamento do sistema ou subsistema, incluindo as transies de estado, sequncias de atividades, funes e interaes. (Por exemplo, detectar perda de trao aciona fora do modulador do freio.) Requisitos: Descreve os requisitos especficos do sistema ou do subsistema. (Por exemplo, fornecimento da distncia de parada especfica.) Paramtrico: Descreve os limites paramtricos do sistema ou subsistema. (Por exemplo, a equao da fora de frenagem uma equao paramtrica.)

Explorao dos quatro estgios da modelagem do sistema


Os sistemas so por natureza estruturas recursivas que consistem em diversos nveis comeando com o sistema geral no mais alto nvel, e so decompostos em subsistemas e, ento, em componentes. A melhor maneira de modelar um sistema completo usar um processo recursos de multietapas comeando de cima composto dos seguintes quatro estgios. Os estgios formam a palavra CURE, pense como a cura da complexidade: Contexto: Estabelece os limites do sistema, identifica as pessoas e os sistemas com os quais o sistema interage (tambm conhecidos como atores) e descreve as interfaces (como eles se comunicam com o sistema e o que eles trocam). Juntos, os elementos deste modelo contextual so conhecidos como a empresa significando o sistema e seu ambiente. Use o diagrama do bloco SysML para isso. Uso: Descreve todas as maneiras que os atores usam o sistema. Inclui quem ou o que usa o sistema, e quem ou o que o sistema usa. Isto realizado melhor com histrias especficas, passo-a-passo do tipo

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 4: Abstrao do sistema de modelagem

41

narrao do uso do sistema, como casos de utilizao, e ilustradas como diagramas de atividade SysML. Ajusta os requisitos do sistema, e os torna especficos e completos (no esquea, os requisitos de origem podem ignorar muita coisa importante). Os mesmos cenrios de utilizao tornam-se a base para os testes posteriores do sistema de acordo com a informao fornecida pela anlise de utilizao. Realizao: Define os modelos da estrutura (arquitetura) e comportamento (funo) que, juntos, descrevem como cada utilizao alcanada pelo sistema atravs da colaborao dos elementos da arquitetura do sistema. O comportamento exigido realizado (torna-se realidade) nos elementos do sistema. Isto muito diferente do processo de design tradicional que aloca os requisitos para os componentes fsicos e torce para que funcione com a utilizao real. Aqui, a utilizao definida especificamente e o design do sistema feito de acordo com as utilizaes especficas, e voc sabe que o sistema projetado para atender estes requisitos de utilizao. Execuo: Executa os modelos de comportamento para demonstrar que o design atende estes requisitos. Os modelos simples executveis, at mesmo os nveis mais altos de abstrao so uma forma excelente e econmica de descobrir os problemas complicados, m comunicao, ausncia de requisitos ou requisitos ambguos, e outras questes que atrapalham a programao desde o incio. Todos chegam a um acordo antes de qualquer coisa ser construda. Inicia no nvel mais alto da decomposio do design do sistema: o nvel do sistema (por exemplo, uma minivan). Aps estabelecer os modelos de contexto e utilizao, os modelos arquitetnicos e de comportamento de alto nvel so definidos de acordo com os requisitos do sistema. Ai ento, os modelos so executados para demonstrar que o sistema faz exatamente o que deveria fazer. Aps concluir o processo do nvel do sistema, o processo repetido no nvel de decomposio seguinte: o nvel do subsistema. Continue a examinar os nveis de decomposio, mudando o contexto ao passar para cada nvel do modelo, at alcanar o nvel mais baixo o nvel do componente onde a implementao fsica do design especificada (por exemplo, eletrnicos, software ou design mecnico). Em cada nvel, chegue horizontalmente ao V e execute a verificao e validao, usando o modelo como base. Use modelos executveis e outros tipos de simulaes matemticas e de design para realizar a

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

42

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


maior quantidade possvel de verificaes antes de chegar ao estgio da implementao.
BRE-SE M

O ponto sagrado aqui um modelo completo do sistema um tipo de verso virtual da realidade do sistema real. Isso ainda no possvel, mas com as ferramentas de modelagem cada vez melhores e aprendendo a se interconectar com as disciplinas de engenharia, estamos cada vez mais perto.

LE

Porque a modelagem est na moda


Pode parecer que a modelagem da arquitetura e do comportamento de um sistema complexo no vale a pena at lembrarmos como foi difcil o ltimo projeto, quando ningum do time de desenvolvimento assumiu a responsabilidade por ter ignorado um requisito essencial, e a reunio postmortem fez a Inquisio Espanhola parecer uma festa. Com a modelagem possvel captar todos os detalhes cabeludos do design do sistema de maneira organizada, permitindo a visualizao, entendimento e assimilao das complexidades da estrutura e do comportamento do sistema. Ela permite a explorao de opes diferentes de arquitetura e design, a execuo de estudos de compensao, e a avaliao do impacto das mudanas antes do incio da construo do sistema para a reduo dos riscos e dos custos de desenvolvimento do projeto. Modelos fornecem um contexto para a discusso das questes do sistema em diversos nveis. possvel usar modelos para explorar diversas vises de um sistema planejamento, requisitos, arquitetura, design, implementao, acionamento, comportamento, entrada de dados, sada de dados e mais para que voc e seus colegas possam analisar as grandes questes to facilmente quanto as pequenas questes do design. Com o uso das linguagens e tcnicas de modelagem padro da indstria, como SysML, possvel reduzir a ambiguidade e remover as barreiras da linguagem que possam existir entre os membros de diversos times de desenvolvimento e fornecer uma nica fonte mestre para o status e a documentao do desenvolvimento do projeto. Uma colaborao melhor e mais clara com documentos precisos proporciona maior eficcia, menores ciclos de desenvolvimento e, acima de tudo, maior qualidade.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 5

Garantia da qualidade de primeira


Neste captulo
Integrao da qualidade no processo de desenvolvimento de sistemas Iterao dos testes e do design Uso de modelos para revelar erros antecipadamente

ntigamente a garantia de qualidade era um processo realizado no final do ciclo de desenvolvimento como se a qualidade fosse um recurso tangvel que pudesse ser adicionada ao produto antes da entrega. E quando os defeitos eram descobertos, era preciso um grande trabalho para identificar e resolver a raiz do problema. No mundo de hoje onde os produtos inteligentes com softwares cada vez mais complexos, a qualidade passou a ser parte integral do processo de desenvolvimento de sistemas, trazendo a esperana da entrega de produtos sem defeitos e que demonstrem adequao para o objetivo. Neste captulo, veremos como a engenharia de sistemas ajuda a identificar as questes de qualidade com a validao e a verificao antecipadas no ciclo de desenvolvimento, para aumentar a possibilidade de que o projeto tenha sucesso.

Explorao dos nveis de teste


Ao projetar um produto inteligente com vrios subsistemas e milhares (ou milhes) de linhas de cdigo, voc pode pensar como possvel verificar e validar todo o sistema. Onde comear? Como ter certeza de que todas as peas do quebra-cabea se encaixam e tambm funcionam adequadamente para oferecer a funcionalidade do produto que os interessados (e acionistas) buscam? Bem, na realidade, o processo de qualidade comea no incio do design do sistema.
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

44

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Os sistemas grandes e complexos so decompostos em diversos nveis, incluindo o nvel do sistema, um ou mais nveis do subsistema e, finalmente, o nvel do componente.
BRE-SE M

Embora possa parecer intuitivo esperar at que o sistema esteja pronto para fazer os testes, a boa prtica de engenharia de sistemas inclui tcnicas mais sofisticadas para que o sistema tenha qualidade durante a sua construo. Durante a construo, cada componente do sistema (hardware ou software) testado independentemente e depois integrado com outros para formar o subsistema. A seguir, o subsistema testado independentemente e depois integrado com outros para formar o sistema, e o sistema testado. Por ltimo, todo o sistema testado juntamente com o ambiente operacional (contexto) para verificar se todo o conjunto faz o que deve fazer no ambiente real. Alm de testar o sistema durante a sua construo, possvel verificar e validar os modelos e simulaes do sistema para descobrir os problemas no incio antes que qualquer placa do circuito seja montada ou soldada. possvel at verificar as atividades durante a etapa inicial de obteno de requisitos para conferir se a interpretao da necessidade do cliente est correta.

LE

Teste da unidade
O teste do nvel mais inferior do sistema est intimamente ligado implementao do seu design. Cada componente de hardware ou software testado, os defeitos so corrigidos e a implementao refeita. Quanto ao software, isto pode envolver diversos ciclos iterativos de codificao, testes e recodificao at o software estar completamente depurado. Aps abordar todos os defeitos conhecidos, hora de verificar se o componente atende aos requisitos alocados. Lembra quando voc desenvolveu o design detalhado do sistema? Bom, parte da fase do design detalhado envolveu a definio dos requisitos especficos para os componentes e a criao de um Plano de Verificao da Unidade. Agora, os casos de teste so definidos no Plano de Verificao da Unidade para verificar se o componente atende aos requisitos alocados. Quando os defeitos so descobertos, volte para a implementao para corrigi-los. Aps o exame detalhado dos componentes, eles podem ser integrados em conjuntos ou subsistemas de nvel superior.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 5: Garantia da qualidade de primeira


BRE-SE M

45

Certifique-se de que o seu Plano de Verificao da Unidade documenta detalhadamente os casos e os resultados de testes especficos de cada componente e que uma matriz de rastreamento seja usada para vincular os testes aos requisitos especficos que foram verificados. Com isso, quando todos os testes so aprovados, o sistema atende a todos os requisitos.

LE

Integrao e verificao do subsistema


Os componentes de hardware e de software completamente verificados esto prontos para a integrao com os mdulos ou subsistemas. Se as interfaces foram testadas primeiro, isto no deve ter problemas.
BRE-SE M

O objetivo desta etapa de testes garantir que todas as interfaces entre os componentes e os conjuntos tenham sido implementadas adequadamente e que todos os requisitos e limites do subsistema tenham sido atendidos. Dependendo do grau de complexidade do subsistema, pode ser necessrio desenvolver uma plano de integrao que defina a ordem para a integrao dos componentes e sub-conjuntos de nvel mais inferior. Se possvel, planeje a integrao para que as peas que devem trabalhar em conjunto tambm estejam prontas para a integrao. Em cada etapa da integrao, compare a funcionalidade do subconjunto com o conjunto de requisitos apropriados, usando o Plano de Verificao de Subsistema definido na fase do design.

LE

O! IS V

Cuidado para no ignorar os testes realizados para verificar os requisitos no nvel do componente, pois muitos requisitos abrangem como cascata diversos nveis da decomposio do sistema. Por exemplo, quando um requisito do sistema especifica que uma tela de display deve ficar em branco quando um usurio pressiona um boto, preciso verificar se o componente da tela pode ficar em branco (teste de nvel de componente), e preciso verificar tambm se com o apertar do boto a tela fica em branco (teste de nvel de subsistema).

Teste do sistema
Com a iterao progressiva, possvel integrar, testar e verificar os subsistemas at chegar ao nvel do sistema (veja Figura 5-1). Cada iterao envolve um teste cuidadoso e detalhado com ateno especial

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

46

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


para as interfaces e a verificao de que os requisitos apropriados foram atendidos. No nvel mais alto, so realizados testes para verificar se o sistema em geral atende aos requisitos do sistema de nvel alto definidos no incio da fase do design. Repetindo, os testes so baseados no plano de verificao definido em paralelo com os requisitos do sistema.
A IC

importante documentar os resultados de cada caso de teste e anotar quaisquer respostas inesperadas ou outras anomalias. No entanto, resista tentao de corrigir um defeito recm-descoberto para evitar a perda do controle da configurao. Ao invs disso, documente o problema, analise a causa e defina um plano de ao para resolver o problema dentro do contexto de um processo sistemtico.
componentes integralmente testados subsubsistemas

Integrao
subsistemas vericados subsistemas

Vericao dos

sistema vericado

Figura 5-1: Integrao e verificao so um processo iterativo.

Quando tudo corre bem, o resultado um sistema verificado que pode ser apresentado para os interessados. possvel provar que todos os requisitos do sistema foram atendidos, confirmando que o sistema foi construdo corretamente.

Teste de aceitao do sistema


s construir que os interessados aparecem. Esta filosofia pode no ser muito verdadeira. O sistema pode ser perfeitamente projetado e

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 5: Garantia da qualidade de primeira


implementado, atender a todos os requisitos e e muito mais mas, se no atender ao uso pretendido, est fadado a ser um fracasso.

47

Vejamos, por exemplo, o caso de um sistema de controle de sinais luminosos de trnsito bem projetado. Habilmente projetado para controlar a sequncia dos sinais luminosos de trnsito de uma grande cidade, este sistema pode falhar em atender o uso pretendido reduzir o congestionamento com a agilizao do fluxo do trfego se ningum se preocupou em estudar os padres tpicos do trfego da cidade e em transform-los em um mapa da sequncia de tempo para os requisitos do sistema.
LE
BRE-SE M

O objetivo do teste de aceitao do sistema confirmar se o sistema atende ao objetivo pretendido. Na fase conceitual do projeto so identificadas as necessidades principais do interessado, a capacidade geral do sistema, cenrios de utilizao (CONOPS e casos de utilizao) e medidas de performance para validao do sistema. Voc definiu um Plano de Validao do Sistema e, se foi inteligente, o guardou em um cofre e no permitiu que ningum o alterasse para acomodar objetivos indesejados como reduzir a qualidade para economizar muito pouco. O Plano de Validao do Sistema a base slida com a qual voc deve provar que o sistema atinge os objetivos pretendidos. Realize uma validao do sistema com usurios reais e mea a performance de acordo com o plano, incluindo at mesmo a satisfao do cliente. A validao pode exigir a coleta de dados antes, durante e depois da implementao do sistema. Aps documentar cuidadosamente a performance do sistema, rena-se com os interessados, analise todos os dados e avalie o sucesso do projeto. Quando um problema observado no sistema durante os testes, normalmente h uma falha no sistema que pode ser corrigida com uma modificao do sistema. Observe que o problema pode ser outra coisa. Quando o plano de verificao ou o procedimento de teste est errado ou desatualizado o teste pode falhar sem significar falha do sistema. Por outro lado, um requisito errado, ambguo ou incompleto (principalmente um requisito de interface), podendo ser a fonte do problema mais um motivo para a concentrao em obter requisitos e planos de testes corretos desde o incio do processo.

LE

BRE-SE M

Quando os testes de verificao indicam um problema, retroceda e confira os requisitos e design, faa os ajustes necessrios e repita os testes.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

48

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


Por exemplo, suponhamos que voc esteja projetando um limpador de para-brisas com sensor de chuva (RSW). O objetivo do RSW limpar o para-brisas automaticamente ao detectar gotas de chuva na parte externa do para-brisas. A arquitetura de alto nvel do sistema RSW inclui um sensor ptico com um alcance operacional especfico conectado na superfcie interior do para-brisas, uma unidade de controle eletrnico e um software. O design exige que o sensor e o software interajam para identificar a presena de gua e ativar o limpador de para-brisas. Os testes dos componentes individuais indicam que o sistema RSW funciona de acordo com o projeto dentro da faixa operacional do sensor. Ai ento so integrados o RSW, o para-brisas e outros subsistemas em um carro. No entanto, o teste da operao do RSW com todo o sistema, falha. Aps uma extensa anlise da causa do problema, a fonte do problema descoberta: as caractersticas fsicas do para-brisas (mais especificamente, o ndice e a espessura pticos) so incompatveis com a faixa operacional do sensor. Voc conclui que no definiu um requisito para as caractersticas fsicas do para-brisas que garantisse a compatibilidade com o sistema RSW. Neste caso, preciso voltar para a fase do design, adicionar o requisito e redesenhar o para-brisas. O que causou esta confuso foi uma suposio no expressada e no examinada, um clssico bicho-papo para os engenheiros de sistemas. A hiptese foi que o sensor funcionaria com qualquer tipo de material do para-brisas. Se voc tivesse expressado esta hiptese, algum poderia ter dito: No com qualquer material! e identificado o requisito que estava faltando. Esta experincia dolorosa um grande exemplo da importncia de testes frequentes e desde o incio.

Testes frequentes desde o incio


mais barato consertar um defeito descoberto no incio. Como podemos ver na Figura 5-2, o conserto dos defeitos descobertos aps o lanamento do produto podem custar at 100 vezes mais do que o conserto dos defeitos descobertos durante o processo dos requisitos. Mas isto apenas um exemplo. Com a adeso estrita ao processo de testes, possvel reduzir drasticamente o custo do conserto dos defeitos.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 5: Garantia da qualidade de primeira

49

$7.600/defeito
Aps o lanamento do produto

$960/defeito
Durante a fase de testes/CQ

$240/defeito $80/defeito
Durante a fase dos requisitos Durante o design e a fase de implementao

Figura 5-2: O custo da correo dos defeitos aumenta drasticamente com a progresso do processo de desenvolvimento.

O grande problema so as . . . Interfaces


Um dos grandes problemas do desenvolvimento e testes de grandes sistemas complexos que as peas desenvolvidas independentemente nem sempre funcionam em conjunto de acordo com o planejado. Voc est frito se esperar at que todas as peas estejam prontas para realizar a integrao e o teste, e encontrar problemas na integrao porque provavelmente j ultrapassou toda a sua programao e oramento.
O! IS V

Este provavelmente o principal fator que causa atrasos na programao e estouro de custos: descoberta tardia de problemas com a integrao no processo de desenvolvimento. um grande fator de risco para o sucesso do programa. E o que voc pode fazer? Os engenheiros de sistemas elaboraram duas abordagens principais para minimizar este risco: Verificar as interfaces e interaes dos principais subsistemas e componentes no incio com a substituio de alguns (ou at todos) subsistemas e componentes por modelos e simulaes Integrar as peas gradativamente (ou por iterao) e ver como elas funcionam, e no esperar at que tudo esteja pronto para iniciar a integrao e encontrar os problemas
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

50

D

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


A IC

A primeira abordagem, a modelagem do sistema (veja Captulo 4), pode ser de grande ajuda. Os modelos de utilizao, expressados como diagramas de atividades e diagramas de sequncias, ajudam a identificar quais peas do sistema falam entre si e quais interfaces so necessrias entre elas. Com este conhecimento, possvel fazer com que as peas falem entre si para uma integrao antecipada reduzindo a simulao e emulao necessrias. Ao forar os times dos subsistemas a trabalharem em conjunto assim que possvel podemos identificar as questes logo no incio do processo do design quando mais fcil e mais econmico corrigi-los. Com os modelos tambm possvel testar o seu entendimento das interaes dos subsistemas antes que sejam construdos com a execuo de modelos e a confirmao de que o que voc pensou realmente vai acontecer. A transformao do pensamento em diagrama de execuo pode revelar discrepncias em uma etapa onde seja mais simples e mais barato consertar os problemas. Com modelos que simulam a operao dos componentes que ainda no foram construdos, possvel testar as interfaces muito antes de vincular todas as peas de ao e circuitos do sistema. Pense em um simulador de voo, por exemplo, que permite que os engenheiros testem os aspectos da operao de uma aeronave antes mesmo que ela decole. A segunda abordagem a incorporao da maior quantidade possvel de integrao e testes (iterao) progressivos no ciclo do desenvolvimento. Os engenheiros de software usam ciclos de desenvolvimento iterativos h dcadas. claro que mais fcil usar a iterao no desenvolvimento de software do que, por exemplo, na construo de componentes eletrnicos ou da fuselagem (porque normalmente o hardware exige um prazo de entrega mais longo), mas as mesmas ideias podem ser aplicadas. Os ciclos de iterao antecipados podem identificar as peas de alto risco do produto com a integrao de uma combinao de prottipos ou hardware de simulao com o software recm-desenvolvido. Com todas estas criaes preliminares do sistema, porm executveis, possvel resolver os problemas de integrao, aperfeioar as interfaces, e confirmar as opes do estudo de compensao. Alguns engenheiros de sistemas com pensamento moderno sugerem que a integrao deve ser tentada antes dos testes dos componentes individuais, como parte do subsistema integrado. Embora possa parecer um contra-senso, na realidade, isso identifica antecipadamente os riscos antes de esperar a integrao do sistema para que as coisas quebrem.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 6

Capacitao da colaborao e gerenciamento das mudanas por equipes grandes


Neste captulo
Em busca de um ponto comum para interaes humanas eficazes Automao dos processos do trabalho Vinculao das ferramentas e dos dados do ciclo de vida

quipes pequenas e mais ntimas de desenvolvimento de produto sabem realmente como trabalhar em conjunto com eficcia: eles compartilham a informao essencial, usam as mesmas ferramentas de desenvolvimento e compartilham a mudana de um requisito, descoberta de um defeito ou at fazem uma festa! Multiplique o tamanho da equipe por, vejamos, 100, atribua uma lista de desejos de aproximadamente 700 requisitos, informe que eles tm seis meses para construir o produto e diga adeus ao seu trabalho (e todos os convites para festas). Como possvel capturar a mgica que existe nos pequenos times de desenvolvimento e adapt-la para grandes times de desenvolvimento? Este captulo mostra como.

Facebook
Temos muito o que aprender com a explorao deste site de rede social de tanto sucesso, o Facebook. Lanado em 2004 quando a maioria dos donos de computadores j tinha uma conta de e-mail, o Facebook decolou
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

52

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


imediatamente e, no incio de 2011, se orgulhava de ter 600 milhes de usurios. E por que o Facebook to popular? Os fundadores do Facebook descobriram uma maneira de desenvolver uma plataforma em tempo real fcil de usar para relacionamento social organizada ao redor de interaes sociais tpicas com amigos, parentes, e outras pessoas com interesses semelhantes. Esta plataforma proporciona uma interface fcil de usar para compartilhar novidades, fotos, curtir, no curtir, status de relacionamento e outras informaes. Ao invs de forar a comunicao das pessoas em um formato tecnolgico como o e-mail, por exemplo, o Facebook usa a tecnologia como uma plataforma para dar suporte a uma comunicao voltada para as pessoas. Agora, imagine a aplicao da mudana de paradigma do Facebook no mundo da engenharia de sistemas. Imagine uma plataforma baseada na tecnologia que capitaliza a maneira como as equipes de desenvolvimento, engenheiros e interessados interagem. Como o Facebook, esta plataforma aproveitaria a conexo com a Internet para unir as pessoas tornando uma equipe grande e dispersa to eficaz quanto uma equipe pequena que estivesse trabalhando em uma mesma sala.

Como todos podem chegar a um acordo


Uma engenharia brilhante no suficiente para criar um produto inteligente que venha a ter sucesso no mercado. As pesquisas mostram que um tero de todos os dispositivos produzidos no cumprem os requisitos de performance ou da funcionalidade e que 24 porcento de todos os projetos so cancelados devido aos atrasos irrecuperveis. Muitas vezes o motivo para uma falha to catastrfica do sistema no est relacionado com o design da engenharia do sistema, e sim com as falhas do conhecimento ou da comunicao. Por isso, no de se estranhar que os trabalhos de desenvolvimento de sistemas sofram com a m comunicao. A maioria das grandes equipes de desenvolvimento est espalhada pelas cidades, empresas e pases. As barreiras do idioma e da cultura dificultam e comunicao, e o fuso horrio normalmente atrapalha a colaborao. At mesmo para os funcionrios de uma mesma empresa, os silos organizacionais podem impedir a comunicao, reduzir a produtividade e propagar o jogo da acusao.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 6: Capacitao da colaborao e gerenciamento das mudanas por equipes grandes


A m comunicao pode causar muitos problemas, como: Falta de clareza das metas do sistema Mltiplas interpretaes dos requisitos do sistema Requisitos incompletos ou ignorados Perda de tempo com a obteno manual de informao de mltiplas fontes Equipes que trabalham com documentos desatualizados Diferenas ou redundncias das responsabilidades Para aumentar ainda mais estes problemas, as equipes de desenvolvimento esto sendo muito pressionados para aumentar a produtividade mesmo com o aumento da complexidade do sistema. E para completar, os produtos inteligentes com enormes quantidades de software exigem mais documentaes e a curva de aprendizado dos novos membros da equipe muito acentuada.
BRE-SE M

53

A melhor maneira de superar a dificuldade da comunicao natural de uma equipe grande proporcionar uma fundao comum para o desenvolvimento, estabelecimento e a manuteno de um idioma comum para a comunicao nesta fundao.

LE

Estabelecimento da fundao
Muitos dos sistemas inteligentes de hoje contm diversos subsistemas de vrias fontes e milhes de linhas de cdigo desenvolvidos pela equipe de engenharia de diversas empresas, pases e culturas. Pense em uma aeronave moderna a fuselagem construda em um pas por uma empresa, o motor por outra, os avinicos por terceiros, e o software de integrao por outra! Para simplificar os processos de desenvolvimento e de testes, essencial oferecer uma plataforma unificada para o desenvolvimento dos sistemas. O uso de uma plataforma de desenvolvimento comum elimina as barreiras das equipes, e permite que os engenheiros trabalhem em conjunto durante o ciclo do desenvolvimento. Uma plataforma unificada facilita a integrao do trabalho e do compartilhamento do conhecimento das equipes distribudas, reduzindo o tempo precioso do ciclo do desenvolvimento. Com a reduo da m comunicao e a simplificao dos fluxos de trabalho, podemos esperar uma melhora substancial da qualidade e uma maior satisfao da equipe. Alm disso, os

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

54

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


engenheiros podem compartilhar o status do projeto com todos da equipe com quadros de gerenciamento, para que os gerentes de desenvolvimento mantenham o projeto na linha.

Como falar o mesmo idioma


No existe nada melhor para unir diversas equipes de desenvolvimentos com vrias culturas e disciplinas de engenharia do que adotar um design voltado para modelagem baseado em um idioma comum independente do domnio. Ao fornecer uma referncia visual para o design do sistema a modelagem elimina as barreiras do idioma e facilita para que todos da equipe de desenvolvimento entendam o sistema e compartilhem do conhecimento das funes. E uma compreenso compartilhada se traduz diretamente em uma melhor produtividade, pois os engenheiros no perdem mais tempo resolvendo mal-entendidos e com o retrabalho do projeto. A Linguagem de Modelagem de Sistemas (SysML) est emergindo como o padro aceito para o desenvolvimento dos sistemas voltados para a modelagem. Ela d suporte a todas as fases do desenvolvimento do sistema, incluindo a especificao dos requisitos, anlise e design do sistema, verificao e validao dos sistemas que consistem no hardware, software, dados, pessoal, e at mesmo locais. Ela tambm tem a vantagem de ser completamente compatvel com a Linguagem de Modelagem Unificada (UML) que facilita a passagem dos modelos do ponto de vista do sistema para o software. So muitas as ferramentas de software disponveis comercialmente que do suporte ao desenvolvimento com a SysML, e cada uma delas tem o seu prprio ambiente de desenvolvimento. Para facilitar a colaborao eficaz, os times devem padronizar uma plataforma de trabalho comum com as ferramentas mais eficazes disponveis no mercado.

Alm do e-mail e do compartilhamento dos documentos


O estabelecimento de uma plataforma de desenvolvimento comum um passo gigantesco na direo certa para um trabalho de equipe eficaz mas isso

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 6: Capacitao da colaborao e gerenciamento das mudanas por equipes grandes

55

no suficiente. Quando um membro da equipe de desenvolvimento faz uma mudana (por exemplo, de um modelo do requisito ou do sistema), e isso no comunicado imediatamente para o resto da equipe, o resultado o caos.

Acompanhamento das mudanas


Durante a engenharia de um sistema, a informao essencial sempre muda de acordo com o projeto. A engenharia de sistemas envolve (dentre outras coisas) o design iterativo e os processos de teste: Desenho do sistema, desenvolvimento dos modelos, teste dos modelos, repetio dos desenhos para a correo dos defeitos, e assim por diante. Por isso, os modelos, resultados dos testes e as outras informaes so sempre atualizados. Os requisitos tambm podem mudar, pois o mercado e os negcios precisam evoluir. Tradicionalmente, as grandes equipes de engenharia contam com a documentao em texto como a fonte de toda a informao do projeto. Os arquivos cheios de documentos dos requisitos, documentos de arquitetura de alto nvel, documentos do design, e outros documentos normalmente servem como a fundao de todo o conhecimento do sistema. Mas os documentos so limitados pois simplesmente registram a informao e no permitem uma fcil mudana a informao. Voc no deve contar exclusivamente com a documentao pois ela se torna obsoleta antes mesmo de ser aprovada!
LE
BRE-SE M

As equipes de desenvolvimento de sistemas precisam de um mecanismo consistente e flexvel para obter a informao essencial e facilitar a atualizao, sem perder a integridade.

Comunicao das mudanas


O mtodo tradicional para a criao de algumas dezenas de documentos essenciais e a troca de informao por e-mail no funcionam bem nos ambientes de desenvolvimento complexos de hoje em dia. Com as centenas ou at mesmo milhares de requisitos dos sistemas complexos, a troca de e-mails apenas cria caos e confuso.
BRE-SE M

As equipes de desenvolvimento de sistemas precisam de um veculo que facilite a troca eficaz entre os membros da equipe. Uma plataforma robusta para o compartilhamento da informao a nica maneira de evitar problemas que podem ser causados quando diversas verses dos documentos essenciais so espalhadas por todos os lugares.

LE

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

56

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Escolha do que deve ser compartilhado


Se voc tivesse que sentar e fazer uma lista dos diferentes tipos de informaes essenciais que devem ser administradas para o desenvolvimento de um sistema complexo, provavelmente nunca chegaria ao fim. Por isso, ao escolher qual informao deve ser compartilhada com todos da equipe de desenvolvimento, cuidado para evitar colocar na lista todas as peas dos dados que descrevem o sistema.
BRE-SE M

O objetivo facilitar o compartilhamento e a colaborao dos membros de uma equipe de desenvolvimento de sistemas, e no sobrecarregar a equipe com informaes suprfluas. Faa uma lista com a informao mnima que deve ser compartilhada para facilitar a colaborao, como por exemplo: Prioridades do desenvolvimento Aprovaes do projeto Agendas Funes e responsabilidades dos funcionrios Requisitos Alterao de pedidos Modelos conceituais Casos de utilizao Planos de teste Defeitos Assuntos essenciais Dados de rastreamento Informao do oramento Informao de aquisies

LE

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 6: Capacitao da colaborao e gerenciamento das mudanas por equipes grandes

57

Maneiras de facilitar o compartilhamento


No realista esperar que cada uma das potenciais centenas de empresas que participam do processo de desenvolvimento de produto usem exatamente o mesmo conjunto de ferramentas do mesmo fornecedor. Por isso, preciso haver uma forma para que todos da equipe virtual possam compartilhar os dados de desenvolvimento sem importar que equipe ou parceiro que os criou.
A IC

Uma colaborao eficaz inicia com uma plataforma no qual o processo de desenvolvimento geral pode ser administrado e controlado. Com esta plataforma, os interessados e engenheiros processam e produzem dados que so compartilhados, analisados e relatados com eficincia durante o ciclo de desenvolvimento dos sistemas. As ferramentas de automao e de federao que aproveitam a tecnologia para simplificar a comunicao e a automao dos fluxos de trabalho, so o prximo grande desenvolvimento da colaborao.
Repositrio

Requisitos

Sistema de Publicao

Requisitos

Dados

Modelos
Motorista Carro Sistema de Posicionamento Global

Modelos

Testes

Modelos

Sistema de Vigilncia Residencial

Resultados do testes

Figura 6-1: Um repositrio virtual da informao do design pode ajudar a aumentar a colaborao.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

58

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Criao de um repositrio virtual de informao ao vivo


As pessoas precisam ter acesso em tempo real informao atualizada do projeto localizada em qualquer local e em qualquer formato de dados. Tradicionalmente os engenheiros de sistemas gastam bastante tempo para acompanhar a informao e garantir que todos estejam trabalhando com os mesmos documentos.
A IC

Com a organizao da informao essencial em um repositrio virtual cria-se uma fonte nica de conhecimento dos aspectos essenciais do processo de desenvolvimento, para a automatizao do processo do compartilhamento da informao. Um repositrio virtual no existe fisicamente, os dados so obtidos quando necessrio dos locais em todo o mundo, de acordo com a necessidade. Por exemplo, os dados da engenharia mecnica podem ser obtidos de um repositrio de dados fsicos administrados pelo time de engenharia mecnica de Seattle, enquanto que os dados de engenharia eltrica podem ser obtidos de um banco de dados de engenharia eltrica de Tquio. Ningum precisa saber (ou se importar) com o local onde os dados fsicos esto localizados desde que eles possam ser obtidos quando necessrios. A Figura 6-1 mostra um modelo conceitual deste repositrio virtual e como ele pode ser usado. Um gerente de processo dos negcios atua como o crebro da operao, administrando a execuo das atividades de desenvolvimento. Ele pode acessar os dados de acordo com o que necessrio (e quem precisa) com os padres abertos. Ao invs de passar documentos de textos dos gerentes de produto para os arquitetos, engenheiros de design, engenheiros de teste e assim por diante, todos os envolvidos no processo de desenvolvimento podem acessar os dados necessrios de forma transparente. Um repositrio virtual como esse uma fonte nica de informaes atualizadas que todos podem acessar de qualquer lugar. Alm disso, ele permite a troca de informao e de ideias, e a captura das decises e processos mentais quase como se estivessem trabalhando no mesmo local.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 6: Capacitao da colaborao e gerenciamento das mudanas por equipes grandes

59

Por que um repositrio virtual?


Por que um repositrio virtual e no um real? Bem, na realidade, so muitos os motivos porque isso uma melhor ideia do que enfiar tudo em um banco de dados. Primeiro, a definio de um banco de dados universal que possa armazenar tudo o desejado ou necessrio seria um trabalho gigantesco! Segundo, seria preciso dar suporte as ferramentas de todos os fornecedores que existam atualmente ou que venham a existir no futuro. E terceiro, um banco de dados macio acessado de todo o planeta teria uma boa performance para certas coisas e seria um desastre para outras, isso sem mencionar as atualizaes para novas verses, pontos nicos de falhas (da rede ou do hardware), e muitos outros desafios de um nico armazenamento fsico dos dados. Virtual definitivamente melhor distribudo, otimizado para os dados e performance de cada ferramenta, com atualizao simples e fcil conexo com terceiros. Aviso: Uma soluo que coloca tudo em um s local pode prend-lo a uma soluo proprietria e a um fornecedor, limitando a sua opo como consumidor!

Simplificao da integrao da ferramenta


Embora o compartilhamento dos recursos e ativos com um repositrio virtual parea ser excelente a princpio, na realidade, isso no fcil. As ferramentas internas, projetos de fonte aberta e diversos fornecedores podem criar barreiras com os formatos de dados incompatveis e outros fatores. Nos ltimos anos, os fornecedores de ferramentas populares de desenvolvimento de ciclos de sistemas, como os tipos de ferramentas relacionadas na Tabela 6-1, passaram a definir maneiras para facilitar a integrao das ferramentas de ciclo dos sistemas. Com a criao de uma comunidade conhecida como Open Services for Lifecycle Collaboration (OSLC), estas empresas se dedicam promoo de novas formas de colaborao atravs da eliminao das barreiras das ferramentas. Inspirada pela arquitetura da Internet, a OSLC especifica um conjunto de padres ligeiramente agrupados, formatos de recursos comuns, e servios criados para facilitar o compartilhamento dos recursos do sistema. A OSLC facilita o uso conjunto das ferramentas de qualquer fornecedor, e simplifica o compartilhamento dos dados do ciclo do sistema, como os requisitos, solicitaes de alterao, casos de teste e defeitos.
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

60

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Tabela 6-1 Principais ferramentas da engenharia de sistemas


Tipo de ferramenta Gerenciamento e rastreamento dos requisitos Desenvolvimento de sistemas baseados em modelagem Gerenciamento da mudana e da configurao Gerao automatizada da documentao Engenharia integrada de sistemas e de software Principais capacidades Rastreamento completo ao vivo dos requisitos da origem, misso, e sistema/subsistema Requisitos do sistema, funcionalidade do sistema, realizao, estudos de compensao, execuo e validao Gerenciamento da colaborao, mudana, repositrio compartilhado e configurao Gerao de documentos de requisitos, design e especificao Desenvolvimento integrado do fluxo descendente dos requisitos e modelos

Automao da produo dos documentos


At mesmo em um modelo de desenvolvimento de modelagem a documentao e os relatrios so necessrios para as obrigaes contratuais, conformidade, revises tcnicas e administrao do projeto. A documentao normalmente envolve trabalho fsico, como a execuo de um diagrama de uma ferramenta de modelagem, a captura de tela e a colagem no documento. Alm disso, os engenheiros gastam bastante tempo na coleta da informao de diversas fontes, para a obteno, resumo e reformulao da informao mais recente para a produo de um relatrio personalizado.
D

A IC

As ferramentas de automao de documentos podem simplificar a produo de relatrios personalizados, garantindo a consistncia da informao em cada relatrio. As ferramentas de automao permitem o acesso ao repositrio central da informao, identificao e seleo da informao necessria, e pedido de relatrio. Alm de simples, este processo tambm facilita a reutilizao e a consistncia da informao. Alm disso, possvel consolidar a informao essencial de diversas fontes at mesmo produtos de diversos fornecedores em um nico relatrio. Certamente isto economiza tempo com a produo dos documentos, mas a grande vantagem quando alguma coisa muda. s fazer as mudanas necessrias dos requisitos e modelos, apertar um boto, e pronto os documentos esto revisados.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 7

Dez maneiras de ganhar com a Engenharia de Sistemas


Neste captulo
Correo das falhas do design no incio do processo de desenvolvimento Desenvolvimento de modelos de negcios flexveis Controle do software integrado complexo Melhoria do gerenciamento dos requisitos Reutilizao do cdigo para acelerar o lanamento dos produtos Uso de ferramentas de colaborao Lanamento de solues complexas no mercado dentro do prazo Uso de uma plataforma de desenvolvimento integrada Teste logo, teste frequentemente Compartilhamento dos requisitos para maior eficcia

engenharia de sistemas oferece uma vantagem competitiva necessria para o sucesso no desenvolvimento de produtos inteligentes que ofeream um valor tangvel para os clientes (e para o resultado final). A engenharia de sistemas como parte do processos de negcios centrais aumenta a probabilidade da produo de produtos que as pessoas realmente queiram, com menos defeitos caros, e maior capacidade de responder dinmica do mercado. Neste captulo, veremos dez exemplos de empresas que adotaram as melhores prticas da engenharia de sistemas e que obtiveram resultados reais e mensurveis.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

62

Engenharia de Sistemas Para Leigos, IBM Edio Limitada

Correo das falhas do design antes que se tornem viral


A

O! IS V

Um dos grandes desafios da engenharia de produtos inteligentes identificar os defeitos no incio do processo de desenvolvimento. A maioria dos defeitos surge durante o processo de design, mas s identificada na fase de testes, ou at mesmo depois do produto entrar na fase de produo. Nos produtos caros de produo em massa, a no descoberta das falhas de design pode custar muito caro, e nos produtos de defesa produzidos em massa, os defeitos no detectados tambm podem ser perigosos. Para complicar ainda mais as coisas, a maioria dos sistemas de defesa composta de mltiplos subsistemas complexos projetados e construdos por diversos subcontratados aprovados. Como subcontratada do Departamento de Defesa dos Estados Unidos, a Brockwell Technologies de Huntsville, Alabama, cria aplicativos de sistemas integrados de armamento em tempo real e executa diagnsticos integrados de veculos militares. O desenvolvimento de sistemas de armamentos interconectados apresenta um desafio nico: como fazer modificaes em um sistema sem afetar os outros sistemas. Para reduzir a possibilidade de introduo de defeitos com a interao dos subsistemas, a Brockwell Technologies incorporou um design e testes do sistema baseados em modelagem nos seus processos de negcios. Com a modelagem da estrutura e do comportamento do sistema, os engenheiros da Brockwell criam prottipos de sistemas complexos e virtualizam o seu funcionamento. Com a tcnica de modelagem preditiva os engenheiros podem identificar as falhas do design no incio do processo de desenvolvimento antes que os sistemas sejam produzidos em massa. O investimento da Brockwell na engenharia de sistemas vantajoso tanto para o Departamento de Defesa quanto para a Brockwell: A Brockwell melhorou a confiabilidade e a segurana dos seus sistemas de armamentos e reduziu em 40 porcento o tempo para a colocao do produto no mercado.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 7: Dez maneiras de ganhar com a Engenharia de Sistemas

63

Engenharia de um modelo de negcios flexvel


Se estiver planejando iniciar um novo negcio ou entrar para um novo mercado, a coisa mais inteligente a ser feita desenvolver uma infraestrutura de negcios flexvel projetada para ser um exemplo para a engenharia de sistemas. E foi exatamente isso que uma empresa de Atlanta fez quando entrou no mercado quente da telemtica h alguns anos. A empresa viu uma oportunidade de passar frente dos veteranos do setor com o estabelecimento de uma infraestrutura de negcios que permitisse a adaptao rpida aos relacionamentos de negcios e modelos de entrega de servio. Com uma estrutura de trabalho flexvel do processo criada com uma tecnologia aberta, a empresa concluiu que poderia entrar em novas oportunidades de servio antes que as provedoras de telemticas existentes com a sua tecnologia prpria e modelos rgidos de negcios pudessem reagir. A empresa projetou todos os processos centrais dos negcios incluindo os da linha de frente, de retaguarda, e as operaes com um objetivo em mente: o lanamento rpido de novos servios. Alm disso, para simplificar o desenvolvimento dos novos servios, a empresa instalou uma plataforma comum de desenvolvimento de sistemas e um conjunto de ferramentas de colaborao. A infraestrutura de desenvolvimento de sistemas da empresa permitiu o gerenciamento do trabalho dos produtos e das entregas, armazenagem das entregas em um repositrio central, a colaborao das equipes espalhadas pelo mundo, manuteno do controle da verso e rpida comunicao das atualizaes. Com a combinao dos sistemas abertos, processos flexveis e colaborao aprimorada, a empresa consegue lanar novos produtos no mercado em menos de 30 dias. Com o ponto focal das telemticas mudando da prpria tecnologia para servios inovadores que usam de forma diferente os dados do veculo, a empresa realmente fica bem mais posicionada para ganhar a competio.

Controle do software integrado complexo


As empresas inteligentes sabem que, quando o produto apenas parte de uma soluo de sistema de sistemas maior, a garantia da qualidade

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

64

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


consistente do produto de suma importncia. Afinal de contas, ningum quer que a sua empresa seja conhecida como o elo fraco do sistema. Mas, com o crescimento do tamanho e da complexidade dos softwares integrados, fica cada vez mais difcil garantir a qualidade. Durante muito tempo, o desenvolvimento manual de software foi o ganha-po de uma provedora de servio de tecnologia alem especializada em medio e controle da engenharia de tecnologia e processo. Mas quando decidiu desenvolver um software integrado complexo para sistemas que gerenciam e controlam de forma remota sistemas fotovoltaicos, a empresa descobriu que teria que adotar um novo ambiente de software. Com quatro objetivos especficos em mente reduzir os defeitos do produto, melhorar o rastreamento, aumentar a reutilizao dos mdulos de software, e garantir um produto com qualidade consistente a empresa selecionou uma plataforma que usa o desenvolvimento de modelos na engenharia de sistemas em tempo real e integrada. O novo sistema permite que a empresa identifique e conserte os problemas no incio com os testes de modelos durante a fase de design garantindo um software com alta qualidade e consistente. Como bnus, a empresa agora pode criar mdulos de cdigo fonte e subsistemas reutilizveis, dando para a empresa uma vantagem sobre a concorrncia.

Melhora da eficincia com requisitos consistentes


Para criar o produto certo e construir o produto certo preciso conhecer profundamente as necessidades do cliente e dos interessados, e definir cuidadosamente os requisitos do sistema ao redor destas necessidades. Sem um gerenciamento eficaz dos requisitos, muito fcil perder de vista os objetivos e os seus clientes. Com centenas de desenvolvedores espalhados pelo mundo usando diferentes ferramentas de gerenciamento de requisitos, uma empresa australiana estava tendo dificuldades com a ineficincia do desenvolvimento e o rastreamento inadequado dos requisitos. A gerncia estava cada vez mais preocupada por no poder testar os requisitos de forma uniforme, pois cada equipe de desenvolvimento tinha seus prprios mtodos de gerenciar os requisitos. E o pior de tudo era que a falta de consistncia aumentava a possibilidade de

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 7: Dez maneiras de ganhar com a Engenharia de Sistemas


erros e tinha o potencial de prejudicar o relacionamento da empresa com o seu maior cliente, a Fora de Defesa Australiana.

65

A organizao implementou uma soluo unificada para o gerenciamento dos requisitos projetada para dar suporte anlise dos requisitos em toda a empresa. Com o acesso universal ao repositrio centralizado de requisitos, a soluo elimina a confuso, o retrabalho caro e a duplicao do trabalho. E o mais importante, a soluo facilita o rastreamento total dos requisitos garantindo que o produto lanado atenda s necessidades do cliente.

Aproveitamento do cdigo reutilizvel para acelerar o lanamento do produto


Se o seu portflio tem uma linha de produtos com recursos bsicos semelhantes, provavelmente muitos cdigos de software similares podem ser aproveitados. As empresas inteligentes estruturam seus cdigos em mdulos reutilizveis para acelerar o desenvolvimento dos produtos futuros. E foi exatamente isso que a Oc N.V. tinha em mente quando decidiu produzir a impressora de folhas soltas mais rpida do mundo. Lder do mercado de tecnologia e servios de gerenciamento de documentos digitais, a Oc desenvolve aplicativos de software avanados que entregam documentos e dados atravs de redes internas e da Internet para dispositivos de impresso e arquivos locais e em todo o mundo. Normalmente, a Oc codifica cada nova impressora do zero, mas quando assumiu a enorme tarefa de coordenar os cdigos de 17 processadores distribudos na nova impressora, a empresa decidiu examinar novamente seus processos de desenvolvimento. A Oc utilizou ferramentas de desenvolvimento voltadas para modelos para decompor o sistema da impressora em subsistemas menores e projetados mais facilmente. Com isso, os desenvolvedores puderam fazer a modelagem de um conjunto de mquinas de estado finito simultneas que foram codificadas em um conjunto de mdulos reutilizveis para diversos ambientes de destino. Agora, sempre que uma mudana necessria, a Oc simplesmente atualiza os modelos e gera novamente o cdigo reduzindo o tempo de resposta para as solicitaes de mudana.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

66
COISA
S

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


TCNICA
S

Atualmente, mais de 50 porcento dos cdigos de software da empresa so reutilizveis, e isso traz uma enorme melhora na eficincia e na qualidade. Na realidade, a Oc at lanou um prottipo opervel de uma nova impressora em apenas dois meses seis meses antes do previsto.

Simplificao do desenvolvimento com as ferramentas de colaborao


As empresas que desenvolvem produtos complexos, inteligentes e altamente instrumentados sabem que o sucesso depende tanto do gerenciamento do trabalho tcnico quanto excelncia da engenharia. Sem uma disciplina a nvel do sistema para coordenar os trabalhos de diversos grupos de engenharia, os produtos complexos esto fadados a se tornar famosos fracassos. Quando a General Motors (GM) resolveu criar o Chevy Volt, trabalhou intensamente em estabelecer as melhores prticas para a engenharia de sistemas. A GM examinou as prticas de desenvolvimento e as prticas de gerenciamento do trabalho tcnico visando melhorar as duas. Tradicionalmente, os engenheiros de sistemas da GM gastam grande parte do seu tempo conferindo as cargas de trabalho dos desenvolvedores e garantir que todos tenham a mesma verso dos requisitos e dos outros documentos. Para liberar os engenheiros para que pudessem se concentrar na funcionalidade e na qualidade, a GM decidiu utilizar uma ferramenta comercial para coordenar os times de desenvolvimento e gerenciar uma nica verso dos requisitos e de outros documentos. A GM ento implementou prticas de desenvolvimento de sistemas baseadas em modelagem para ajudar o gerenciamento da complexidade (o Volt executa aproximadamente 10 milhes de linhas de cdigos). Os desenvolvedores da GM usaram modelos para visualizar as interaes dos sistemas integrados e executar simulaes para testar os modelos. A combinao das ferramentas de colaborao com o desenvolvimento de sistemas baseados em modelagem valeu a pena: A GM concluiu o desenvolvimento do Volt em apenas 29 meses um recorde para a GM, que normalmente desenvolve um novo carro em at cinco anos ou mais.

Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

Captulo 7: Dez maneiras de ganhar com a Engenharia de Sistemas

67

Entrega de solues complexas no mercado dentro do prazo


Para ter sucesso no mundo ultra-competitivo de hoje, as empresas que desenvolvem sistemas complexos extremamente grandes sabem que precisam ser espertos ao focar o processo de desenvolvimento nos requisitos. A capacidade de capturar e de gerenciar os requisitos pode fazer a diferena entre ganhar ou perder um grande contrato. Uma empresa de defesa queria reduzir os riscos do lanamento de solues de sistema de sistemas complexas de muitos milhes de dlares no mercado dentro do prazo. A empresa teve uma ideia inovadora: reunir o gerenciamento dos requisitos e a estrutura de trabalho da arquitetura da empresa de forma a permitir que a empresa lanasse os sistemas complexos baseados em requisitos dentro do prazo. A empresa baseou sua soluo nos produtos disponveis comercialmente para o gerenciamento dos requisitos e o planejamento da arquitetura do sistema. Agora, a empresa pode definir as solues tecnolgicas, mas tambm as solues operacionais, tcnicas, de treinamento e de sistemas durante todo o ciclo. Com isso, ela lana sistemas grandes, complexos e de alta qualidade no mercado mais rpido do que nunca. Alm disso, quando os requisitos do cliente mudam, a empresa pode mostrar o impacto das mudanas bem rapidamente.

Melhora da produtividade com uma plataforma de desenvolvimento integrada


As empresas que desenvolvem sistemas essenciais para a segurana normalmente precisam demonstrar que o seu processo de desenvolvimento est em conformidade com os padres de segurana nacionais e internacionais. Quando o ambiente de desenvolvimento fragmentado, fica difcil demonstrar esta conformidade. Com um conjunto diverso de ferramentas de desenvolvimento e de times de desenvolvimento em dois grandes locais, foi necessrio outra empresa australiana para fazer algumas mudanas para garantir o sucesso dos projetos futuros. Ela oferece solues de sinalizao e controle ferrovirio essenciais para a segurana em todo o mundo, e seus clientes exigem compatibilidade com verses anteriores do equipamento ferrovirio.
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.

68

Engenharia de Sistemas Para Leigos, IBM Edio Limitada


A empresa precisava de um ambiente de desenvolvimento integrado que promovesse a conformidade com padres de segurana e confiabilidade global. A empresa implementou uma soluo uniforme de gerenciamento dos requisitos e da configurao que atenderam aos requisitos do cliente e tambm viabilizaram a colaborao total das equipes de desenvolvimento em diversos locais.

Teste logo, teste frequentemente


A entrega de um prottipo ou de um modelo executvel para as mos dos interessados no incio tem um valor incrvel. O feedback do conceito no incio do processo evita problemas mais tarde.
LE
BRE-SE M

A execuo de testes simples o mais cedo possvel tambm til durante os testes finais. O acesso desde o incio para as equipes de testes, mesmo quando eles sabem que o produto ainda no est pronto ou apenas um prottipo, tambm ajuda a melhorar os planos e procedimentos dos testes do mesmo modo que ajuda os designers verificarem suas ideias.

Compartilhamento dos requisitos para a economia de tempo e dinheiro


Normalmente as grandes organizaes de desenvolvimento tm duas ou mais equipes localizadas em reas diferentes que trabalham em verses paralelas com requisitos compartilhados. Poderia-se economizar muito tempo e dinheiro se essas equipes tivessem um mecanismo para o compartilhamento dos requisitos. Uma empresa de Michigan uma fornecedora global lder de sistemas eletrnicos mveis e de transporte. Um dos objetivos da empresa era melhorar a comunicao das equipes de desenvolvimento globais para que eles pudessem ser mais produtivos durante o trabalho nas verses paralelas com os requisitos compartilhados. A implementao de uma ferramenta de gerenciamento de requisitos facilita o compartilhamento dos requisitos pelos desenvolvedores da empresa. Eles podem importar os requisitos de um repositrio para que possam ser reutilizados em um novo projeto, evitando a duplicao desnecessria do trabalho, economizando tempo e reduzindo os custos do desenvolvimento. A ferramenta de gerenciamento dos requisitos promove a consistncia e aprimora a colaborao, permitindo que a empresa entregue produtos de maior qualidade em menos tempo.
Estes materiais so 2012 John Wiley & Sons, Inc. Qualquer disseminao, distribuio ou uso no autorizado estritamente proibido.