Desenvolvimento Apostila

FAT
Mrcia Ito Mind Technology
Metodologias de Anlise e Desenvolvimento de Sistemas

Curso de Especializao em Tecnologia de Anlise e Projeto de Sistemas Mrcia Ito http://www.mind-tech.com.br/users/ito ito@mind-tech.com.br
Esta apostila de autoria de Mrcia Ito. Nenhuma parte desta publicao poder ser reproduzida ou transmitida por qualquer modo ou meio, seja este eletrnico, fotogrfico, mecnico, ou outros, sem autorizao prvia e escrita da autora. Esta se reserva, por outro lado, o direito de alterar seu contedo e forma, sem qualquer aviso. Companhia, nomes e dados utilizados nos exemplos no so reais, com exceo quando indicados. Marcas: Todas as marcas e nomes dos produtos utilizados nesta apostila so marcas comerciais, marcas registradas ou nomes comerciais dos seus respectivos proprietrios. A autora no est associada comercialmente a nenhum produto ou fornecedor mencionado nesta apostila.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 1
FAT
Informaes Gerais
Nada lhe posso dar que j no exista em voc mesmo. No posso abrir-lhe outro mundo de imagens, alm daquele que h em sua prpria alma. Nada posso lhe dar a no ser a oportunidade, o impulso, a chave. Eu o ajudarei a tornar visvel o seu prprio mundo, e isso tudo. (Hermann Hesse)
Como professores podemos apresentar as solues para os problemas to logo so enunciados. No o fazemos de propsito, pois o importante no saber solues a respostas j dadas. Estas podem muito bem ser encontradas em livros e receiturios.
D um peixe a um homem faminto. Quando o peixe acabar e a fome voltar, ele retornar para pedir mais. Ensine o homem a pescar. Ele no voltar nunca mais.
Pessoas que sabem as solues j dadas so mendigos permanentes. Pessoas que aprendem a inventar solues novas so aquelas que abrem portas at ento fechadas e descobrem novas trilhas. A questo no saber uma soluo j dada, mas ser capaz de aprender maneiras novas de sobreviver. (Rubem Alves Filosofia Da Cincia 1987)
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 2
FAT
Objetivos
Esta disciplina tem como objetivo:
Aprender os conceitos de metodologia de desenvolvimento de software (MDS), o seu relacionamento com o processo de desenvolvimento de software (PDS) e modelos de qualidade. Aprender o UP (Processo Unificado) e o seu derivado comercial: o RUP. Conhecer as tcnicas existentes para o desenvolvimento de software e sua relao com a Metodologia Desenvolver o senso crtico e de anlise, atravs de debates e exposies.
Mrcia Ito M ind Technology
Bibliografia complementar
http://www.mind-tech.com.br/users/ito/maps/documentoApoio.html
UML and the Unified Process Jim Arlow, Ila Neustadt Addison Wesley 2003. The Unified Software Development Process - Ivar Jacobson, Grady Booch, James Rumbaugh - Addison Wesley - 1999. Engenharia de Software Roger S. Pressman McGraw-Hill Interame 2002 Engenharia de Software Ian Sommerville Prentice Hall Brasil 2003 The Rational Unified Process Made Easy: A practioners Guide to Rational Unified Process Per Kroll, Philippe Kruchten Addison Wesley 2003 Building J2EE Applications with the Rational Unified Process Peter Eeles Addison Wesley - 2002
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 3
FAT
Bibliografia complementar
Object-Oriented Programming with Java - David J. Barnes - Prentice Hall - 2000 Desenvolvendo Aplicaes Comerciais em Java com J2EE e UML Khawar Zaman e Cary E. Umrysh Ciencia Moderna 2003 UML for Java Programmers Robert C. Martin Prentice Hall 2003 Enterprise Java and UML Syed H. Rayhan, C. T. Arrington John Wiley Consumer - 2003
Metodologia de Ensino baseado no Ciclo da aprendizagem vivencial

Aplicao (Atingir alvos, mudar rumos)
Generalizao (Comparar vivncia X empresa)
Vivncia (Jogar)
Processamento (Analisar padres de desempenho)
Relato (Sentir)
Fonte: Gramigna, M.R.M.; Jogos de Empresa;1994
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 4
FAT
Ciclo da aprendizagem vivencial

Aplicao (Atingir alvos, mudar rumos)
Generalizao (Comparar vivncia X empresa)
Vivncia (Jogar)
Processamento (Analisar padres de desempenho)
Relato (Sentir)
Fonte: Gramigna, M.R.M.; Jogos de Empresa;1994
A aprendizagem vivencial um ciclo que ocorre quando uma pessoa se envolve com uma atividade, analisa a atividade criticamente, extrai algum insight til dessa anlise e aplica seus resultados. Este processo vivenciado espontaneamente na vida normal de qualquer pessoa. Este ciclo envolve um processo indutivo, partindo da simples observao, mais do que , de uma verdade apriorstica. O ciclo da aprendizagem vivencial passa pelas seguintes fases: VIVNCIA ( atividade ); RELATO ( compartilhar sentimentos, reaes e observaes com o grupo ); PROCESSAMENTO ( Anlise da experincia vivenciada ); GENERALIZAES ( Inferncia de princpios sobre o mundo real ); APLICAO (planejamento de comportamentos mais eficazes, e da utilizao dos novos conceitos no dia- a- dia de sua atividade profissional). Na etapa vivencial precisamos utilizar mais tcnicas de sensibilizao, dinmicas de grupos, simulaes, jogos ldicos, jogos de empresa, tcnicas experimentais ao ar livre, estudos de caso, enfim, todas as atividades ,que alm de trabalharem os conceitos, ou seja, o hemisfrio esquerdo do crebro, possam tambm trabalhar as experincias e o afeto das pessoas envolvidas, de forma a promover verdadeiras mudanas de comportamentos.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 5
FAT
Critrios de Avaliao
D = nota da participao das dinmicas D = (qtd de dinmicas que participou*10)/qtd de dinmicas R = nota de resenha de artigos R = nota da resenha/quantidade de resenhas Tr = trabalho dissertativo sobre um tema especfico Ap = nota da apresentao do trabalho M = Mdia M = D*0,1 + R*0,1 + Ap*0,2 + T*0,6 M < 7,0 Reprovado
Organizao
site da matria: http://www.mind-tech.com.br/users/ito/mds Lista: http://www.yahoogroups.com/mdsFatec-list
Lista com nome e e-mail de todos para cadastro
e-mail: ito@mind-tech.com.br
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 6
FAT
Evoluo do Software
impossvel para um homem aprender aquilo que ele acha que j sabe. Epteto
Um sistema no uma cabea. Um mvel no gente. Todos os processos e todos os aparelhos, resultaro inteis para as organizaes, se as cabeas dos indivduos que os empregam, no estiverem convenientemente organizados. E essas cabeas estaro organizadas, se estiverem organizadas devidamente, a mesma parte do corpo do chefe que os dirige. Assim como se podem escrever asneiras com uma mquina de escrever do ltimo modelo, tambm se podem fazer disparates com os sistemas e aparelhos mais perfeitos para ajud-lo a no faz-lo. Sistemas, processos, mveis, mquinas, elementos puramente auxiliares. O verdadeiro processo PENSAR. A mquina fundamental a INTELIGNCIA.
(Fernando Pessoa - 1926) ________________________________ _______________________ Pg. 7
________________________________ FAT/Mrcia Ito
FAT
Evoluo do Software
1950~meados da dcada de 60
Programar uma arte
Arteses habilidosos em solues de problemas atravs de algoritmos matemticos. Conheciam com mincias os princpios da cincia da computao Pouca habilidade em soluo de problemas no exatos.
Pouco mtodo formal

Descrio em textos (linguagem natural); Fluxograma; Expresses matemticas.
Evoluo do Software
Meados da dcada de 60~meados da dcada de 70
Em 1969 Criada a Disciplina de Engenharia de Software
Fritz Bauer (1969):
O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione corretamente em mquinas reais;
(IEEE Institute of Electrical and Electronics Engineering):

(1) Aplicao
de uma abordagem sistemtica, disciplinada, quantificvel para o desenvolvimento, operao e manuteno de um software; isto , a aplicao da engenharia ao software; (2) O estudo das abordagens do desenvolvimento de software.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 8
FAT
Evoluo do Software
Meados da dcada de 60~meados da dcada de 70
Em 1969 Criada a Disciplina de Engenharia de Software
Metodologia de desenvolvimento - Anlise estruturada:
Representao grfica dos requerimentos dos sistemas Preocupao com os fluxos de dados Prega a separao entre modelo lgico e fsico do sistema, mas no diz como faz-la
Evoluo do Software
Meados da dcada 70~final da dcada de 80
Sistemas distribudos Inteligncia embutida Hardware de baixo custo Metodologia de Desenvolvimento - Anlise essencial:
Encontrar o Modelo Essencial do Sistema Abandono da modelagem do sistema atual Particionamento por Eventos Incorporao da Modelagem de Dados no processo de especificao
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 9
FAT
Evoluo do Software
Final da dcada 80~at hoje
Orientao a Objetos
Metodologia de Desenvolvimento Orientado a Objetos Arquitetura por componentes Design Pattern Poltica de Padres Object Management Group (OMG):
CORBA UML
Evoluo do Software
Software Free Computao paralela Sistemas embarcados Programao em pequenos devices Inteligncia Artificial
Sistemas especialistas Redes neurais artificiais Data Mining
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 10
FAT
Evoluo do Software
Produtividade e Qualidade chega de mtodo!!
Processo de Desenvolvimento de Software UP/XP/ICONIX Modelos de Qualidade de Software CMM/ISO/SPICE Gerenciamento de Projetos PMBok Gerencia da Infraestrutura ITIL Governana em TI COBIT/Balanced Scorecard/6Sigma
Evoluo do Software
Futuro (?) - Consideraes
Inteligncia Artificial Distribuda Tecnologia de agentes
Linguagem de modelagem: proposta AUML Agent UML Comunicao
KQML FIPA-ACL
Metodologia Orientada a Agentes:

Tropos Gaia MaSE
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 11
FAT
Evoluo do Software
Futuro (?) - Consideraes
Poltica de padres
OMG-AWG
http://www.objs.com/isig/agents.html
FIPA
http://www.fipa.org
DARPA US Defense Advanced Research Projects Agency

CoABS Control of Agent-Based Systems
AgentLink
Projeto ESPRIT http://www.agentlink.org
CLIMATE
Cluster for Intelligent Mobile Agents for Telecomunications Environments http://www.fokus.gmd.de/research/cc/ecco/climate/climate.html
Modelos e o Desenvolvimento de Software

Procure entender um novo problema com aumento do seu conhecimento sobre ele, sem buscar referncias anteriores. Isaac Efraim
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 12
FAT
Definio de Modelo
Modelo a simplificao da realidade. O modelo reduz a complexidade pela decomposio da realidade em elementos fceis de entender. Diferentes aspectos definem um sistema, portanto, necessrio vrios modelos para representar cada um desses aspectos.
Definio de Modelo
Cada modelo mostra uma abstrao semanticamente bem encapsulada do sistema. Um modelo pode demonstrar:
Estrutura: organizao do sistema; Comportamento: dinmica do sistema.
Um modelo expresso atravs de uma linguagem:

linguagem de modelagem.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 13
FAT
Linguagem de Modelagem
A linguagem para a construo de modelos deve ter:
Elementos do modelo - conceitos e semntica fundamentais ao modelo Notao dos elementos - representao visual dos elementos do modelo Guidelines - guias de como e onde usar a linguagem.
Os modelos so os produtos gerados quando se segue um mtodo. Um modelo expresso atravs de uma linguagem de modelagem. Uma linguagem de modelagem possui uma notao (smbolos utilizados nos modelos) e um conjunto de regras. As regras so sintticas, semnticas e pragmticas. Notao dos elementos a sintaxe. A sintaxe define os smbolos e como eles se combinam entre si na linguagem. Podemos comparar a sintaxe com as palavras na linguagem natural, importante saber a ortografia correta das palavras e como podemos combin-las para formar uma frase. Elementos do modelo definem a semntica. A semntica define o significado de cada smbolo e como ele pode ser interpretado de modo isolado e quando combinado com os demais smbolos. No nosso exemplo, trata-se do significado das palavras dentro do contexto. Guidelines so um conjunto de regras pragmticas que definem a inteno dos smbolos dentro do modelo, tornando o modelo compreensvel por todos os que o analisam. Este corresponde na linguagem natural a um bom texto. Livros de estilos de redao ditam esse tipo de pragmatismo.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 14
FAT
Princpios da Modelagem
A escolha de quais modelos criar influncia na forma como o problema atacado e como a soluo encontrada. Todo modelo deve ser expresso em diferentes nveis de preciso. Os melhores modelos so aqueles que refletem a realidade. Nenhum modelo nico suficiente. Mesmo um sistema trivial melhor abordado atravs de um pequeno conjunto de modelos independentes.
A escolha dos modelos a serem criados tem profunda influncia sobre a maneira como um determinado problema atacado e como uma soluo definida. Em outras palavras, escolha bem os seus modelos. Os modelos corretos iluminaro de modo brilhante os problemas de desenvolvimento mais complicados, proporcionando concluses que simplesmente no seriam possveis de outra maneira; modelos inadequados causaro confuses, desviando a ateno para questes irrelevantes. Assim para uma boa modelagem existem algumas mximas: Cada modelo poder ser expresso em diferentes nveis de preciso; Os melhores modelos esto relacionados com a realidade; Nenhum modelo nico suficiente. Qualquer sistema no trivial ser melhor investigado por meio de um pequeno conjunto de modelos quase independentes.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 15
FAT
Benefcios da Modelagem na Engenharia de Software

Modelos comunicam a estrutura e o comportamento do aplicativo. Modelos permitem visualizar e controlar a arquitetura do aplicativo. Modelos permitem entender melhor o aplicativo que estamos construindo, expondo oportunidades de simplificao e reusabilidade. Modelos permitem gerenciar os riscos.
Em todas as disciplinas da engenharia, modelos so fundamentais. Quando se deseja construir algo, tais modelos (desenhos, esquemas, equaes) so projetados para descrever a aparncia e o comportamento do produto. O produto pode ser uma casa, uma mquina, um novo departamento de uma companhia, ou um software. H tempos, discute-se sobre a crise do software que baseada no fracasso dos projetos de software, pois estes no atendem s necessidades e os requisitos dos usurios, alm de exceder prazos e custos. Atualmente, alm destes fatores, outros prejudicam a produtividade, como as novas tecnologias (programao orientada a objetos, programao visual, ambiente cliente/servidor, etc.) e as exigncias no desenvolvimento de software (alinhamento estratgico, conectividade, tecnologia de informao, flexibilidade, etc.). Esses problemas no desenvolvimento de sistemas ocorrem porque os projetos iniciam a sua programao muito cedo, concentrando enormes esforos e tempo na codificao. Isto ocorre principalmente porque a maioria dos gerentes sente-se mais segura ao ver algum programando ("sensao" de produo) do que modelando de modo abstrato o sistema. Porm, medida que a indstria de software tem se deparado com sistemas complexos em ambientes distribudos, a necessidade de se modelar o software antes de implement-lo tem se tornado um ponto importante no desenvolvimento de sistemas.
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 16
FAT
Engenharia de Software
As crescentes demandas dos clientes e usurios, a maior complexidade da tecnologia disponvel e as exigncias de maior confiabilidade, menor custo e prazo e maior produtividade esto levando empresas e desenvolvedores a se convencerem que a abordagem artesanal no desenvolvimento e manuteno de software tem seus dias contados. tila Beloquim, 2003
Do que se trata a engenharia de software?
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 17
FAT
Engenharia de Software - Definio

Engenharia a aplicao de princpios matemticos e cientifcos s construes materiais, tcnica de construes. (Aurlio Buarque de Hollanda) Software so programas de sistemas, como sistemas operacionais, sistemas de banco de dados e programas de controle de telecomunicaes, alm dos programas aplicativos que executam as funes desejadas pelo usurio. (Edward Yourdon)
Software no apenas o programa do computador, mas tambm toda a documentao associada e os dados de configurao necessrios para fazer com que esses programas operem corretamente. Os engenheiros de software se ocupam em desenvolver produtos de software. Produtos de Software podem ser desenvolvidos para um cliente especfico ou para o mercado. Uma diferena importante entre os tipos de software que, nos produtos genricos, a organizao que desenvolve o software controla suas especificaes. Para os produtos personalizados, a especificao usualmente desenvolvida e controlada pela organizao que est comprando o software. Assim, a engenharia de software uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software, desde os estgios iniciais de especificao do sistema at a manuteno desse sistema, depois que ele entrou em produo. Nessa definio, h duas frases importantes:
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 18
FAT
Engenharia de Software - Definio

Fritz Bauer (1969):
O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione corretamente em mquinas reais;
(IEEE Institute of Electrical and Electronics Engineering):

Aplicao de uma abordagem sistemtica, disciplinada, quantificvel para o desenvolvimento, operao e manuteno de um software; isto , a aplicao da engenharia ao software; (2) O estudo das abordagens do desenvolvimento de software.
(1)
1. Disciplina da engenharia: os engenheiros fazem os produtos funcionarem. Eles aplicam teorias, mtodos e ferramentas nas situaes apropriadas, de modo seletivo; e sempre procuram descobrir solues para problemas, memso quando no existem teorias aplicveis e mtodos de apoio. Os engenheiros tambm reconhecem que precisam trabalhar de acordo com as restries organizacionais e financeiras e, assim procuram solues que estejam dentro dessas restries. 2. Todos os aspectos da produo de software: a engenharia de software no se dedica s aos pocessos tcnicos de desenvolvimento de software, mas tambm a atividades como o gerenciamento de projetos de software e o desenvolvimento de ferramentas, mtodos e teorias que dem apoio produo de software.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 19
FAT
Engenharia de Software - Elementos

Mtodos Ferramentas
Procedimentos
A engenharia de software abrange um cojunto de 3 elementos fundamentais mtodos, ferramentas e procedimentos que possibilita ao gerente o controle do processo de desenvolvimento de software e oferece ao profissional um base para a construo de software de alta qualidade produtivamente.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 20
FAT
Ferramentas
Recursos de software, utilizados para se proporcionar apoio automatizado ou semiautomatizados ao desenvolvimento de software. Aumentam e garantem a produtividade. Exemplos:
Editores de Texto Editores de Cronogramas CASEs Softwares para Gerenciamento de Configurao
As ferramentas proporcionam apoio automatizado ou semi-automatizado aos mtodos. Atualmente, existem ferramentas para sustentar cada um dos mtodos existentes. O acrnimo CASE significa computer-aided engineering e se refere a uma ampla gama de diferentes tipos de programas utilizados para apoiar as atividades de processo de software, como a anlise de requisitos, a modelagem de sistema, a depurao e os testes. Todos os mtodos atualmente so fornecidos com tecnologia CASE associada.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 21
FAT
Mtodo
Fornecem a tcnica para a construo do software. Definem
Padres; Notao; Critrios de qualidade.
O conjunto de tarefas que permitem usar o mtodo chamado metodologia de desenvolvimento de sistemas (MDS).
Os mtodos de engenharia de software so abordagens estruturadas para o desenvolvimento de software que incluem modelos de sistemas, notaes, regras, recomendaes de projetos e diretrizes de processos.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 22
FAT
Procedimento
Definem a sequncia em que:
os mtodos sero aplicados; produtos so entregue; controles que ajudam a assegurar a qualidade e coordenar mudanas; marcos de referncia que auxiliam a gerencia do projeto.
Os procedimentos evoluiram para os nossos processos de software.
Os procedimentos constituem o elo de ligao que mantm juntos os mtodos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software. Os procedimentos definem a sequencia em que os mtodos sero aplicados, os artefatos que se exige sejam entregues, os controles que ajudam a assegurar a qualidade e coordenar as mudanas, e os marcos de referncia que possibilitam ao gerentes de projeto avaliar o progresso.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 23
FAT
Paradigma da Engenharia de Software

Conjunto de passos que compreendem mtodos, ferramentas e procedimentos. A escolha do paradigma do software depende:
Natureza e aplicao do projeto Mtodos e ferramentas que sero utilizados Controles e artefatos que sero necessrios
Metodologia de desenvolvimento de sistemas Ciclo de vida dos Sistemas Processo de Desenvolvimento de Software
Em geral, os engenheiros de software adotam uma abordagem sistemtica e organizada em seu trabalho, uma vez que essa , com frequncia, a maneira mais eficaz de produzir software de alta qualidade. No entanto, a engenharia tem a ver, em grande parte, com a questo de selecionar o mtodo mais apropriado para um conjunto de circunstncias, e uma abordagem mais criativa e informal para o desenvolvimento pode ser eficaz em algumas circunstncias. O desenvolvimento informal particularmente apropriado para o desenvolvimento de sistemas de comrcio eletrnico, com base na Web, que requerem uma combinao de habiliddes de software e projetos grficos. Essa seleo de mtodos, ferramentas e procedimentos, muitas vezes so citadas como paradigmas da engenharia de software. Um paradigma de engenharia de software escolhido tendo como base a natureza do projeto e da aplicao, os mtodos e as ferramentas a serem usados, os controles dos produtos que precisam ser entregues.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 24
FAT
Metodologia de Desenvolvimento de Software

No carter, na conduta, no estilo, em todas as coias, a simplicidade a suprema virtude. Longfellow, Henry Wadsworth
O mtodo em engenharia de software nos diz como desenvolver tecnicamente um software. A metodologia, por sua vez, o tratado dos mtodos. Aplicando ao desenvolvimento de software temos que a metodologia o tratado dos mtodos em engenharia de software. Assim, poderiamos simplificar dizendo que a metodologia a receita que temos para desenvolver um software. Cada receita por sua vez implementa um mtodo, ento, temos uma metodologia para cada mtodo.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 25
FAT
Metodologia
Envolvem um conjunto de tarefas para: Planejamento e estimativa de projeto; Anlise de requisitos; Projeto
estrutura de dados, arquitetura algoritmo de processamento;
Codificao; Teste; Manuteno. Introduzem padres e uma notao grfica ou orientada linguagem em especial (ex.: DFD, MER, Use Case, etc..) Uso de Modelos no Desenvolvimento de Software
Todos os mtodos se baseiam na idia de desenvolver modelos de um sistema que possam ser representados graficamente e de utilizar esses modelos como uma especificao ou projeto de sistema. No existe a metodologia ideal, e diferentes mtodos tm reas de aplicao diversificadas. Por exemplo, os mtodos orientados a objetos, so com freqncia, apropriados para sistemas interativos, mas no para sistemas com severos requisitos de tempo real (ex.: controle de pouso de um avio).
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 26
FAT
Componentes da Metodologia
Fases, tarefas e passos para o uso da tcnica Tcnicas (mtodo) Ferramentas (automatizadas ou no) Artefatos Responsabilidades Pontos e mecanismos de controle Mtricas
Toda MDS deve basear-se em um conjunto de tcnicas e ferramentas compatveis, como a Anlise Essencial ou Orientao a Objetos. Cada tarefa e passo define o que deve ser feito, quando, como, por qu, por quem e como ser verificada a qualidade do que foi produzido. Os documentos produzidos devem ser guardados para facilitar manutenes, e devem ser atualizados tambm quando estas manutenes forem feitas. Assim, a necessidade destes documentos de serem facilmente mantidos torna o uso de ferramentas CASE extremamente importante.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 27
FAT
O que deve ter uma Metodologia de sucesso

Simples e objetiva Minimamente burocrtica Adaptada s idiossincrasias da organizao Automatizada (CASE) Dominada e apoiada pelos tcnicos (treinamento e experincia) Suportada pela Gerncia
A principal causa do fracasso de implantaes de MDS deve-se percepo por gerentes e desenvolvedores de que no est de acordo com a realidade da empresa, ou que as atividades prescritas no tm razo de ser, ou ainda que consomem muito tempo. Assim, o convencimento por todos os envolvidos dos benefcios da MDS, somado ao uso de uma MDS com as caractersticas acima fundamental para seu sucesso.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 28
FAT
Evoluo dos mtodos no desenvolvimento de sistemas

Nem todas as coisas que importam podem ser contadas, e nem todas as coisas que podem ser contadas importam. Albert Einstein
Um mtodo em engenharia de software uma abordagem estruturada para o desenvolvimento de software, cujo objetivo facilitar a produo de software de alta qualidade, apresentando uma boa relao custo benefcio. Mtodos como anlise estruturada (DeMarco, 1978) e JSD (Jackson, 1983) foram inicialmente desenvolvidos na dcada de 1970. Esses mtodos procuravam identificar os componentes funcionais bsicos de um sistema, e os mtodos orientado a funes ainda so amplamente utilizados. Nas dcadas de 80 e 90, esses mtodos orientados a funes foram complementados por mtodos orientados a objetos, como aqueles propostos por Booch (1994) e Rumbaugh (Rumbaugh et al., 1991). Essas diferentes abordagens foram integradas em uma nica, construda segundo o UML.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 29
FAT
Desenvolvimento de Sistemas
Anlise Estruturada
Incio dos anos 70 - Modelar o sistema atual Representao grfica dos requisitos dos sistemas O importante o fluxo de dados
Anlise Essencial
No se faz a modelagem do sistema atual Decomposio por eventos Alm da modelagem do fluxo dos dados, a estrutura de armazenamento dos dados tambm importante (modelagem de dados)
A anlise estruturada foi o primeiro mtodo desenvolvido para o desenvolvimento de sistemas. Foi criado nos anos 70 e iniciava na modelagem da situao atual. Esta metodologia ao longo do tempo mostrouse ineficiente devido s suas limitaes: extremamente burocrticas particionamento do sistema subjetivo centrada em processos, tendo pouca preocupao com os dados incompatvel com as novas tecnologias: cliente-servidor e programao visual orientada a eventos. A anlise essencial surgiu na tentativa de suprir tais limitaes, introduzindo a modelagem de dados e o conceito de eventos. Porm novas limitaes transpareceram ao resolver os outros: uma lacuna entre os modelos de anlise e projeto baixo suporte reutilizao; no escalvel para grande sistemas; dificuldade na manuteno; difcil integrao com pacotes e sistemas legados.
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 30
FAT
Meados de 1970 ~ 1980s - As primeiras linguagens de modelagem para Orientao a Objetos. 1989 ~ 1994 - Guerra das Metodologias (Aproximadamente 50 tipos de mtodos) 1994 ~ 1995 - Alguns mtodos se destacam:
Booch OOSE OMT-2 Coad-Yourdon Fusion
A orientao a objetos surgiu com a linguagem Simula que implementou a noo de classe. A linguagem orientada a objetos somente comeou a ganhar destaque com a linguagem Smalltalk e posteriormente com a linguagem C++. medida que as linguagens orientadas a objetos se tornaram um sucesso, a necessidade de um mtodo que auxiliasse no desenvolvimento do software crescia. Assim entre 1989 a 1994 tivemos uma exploso de vrios tipos de metodologias. Os mais eficientes se destacaram dentre eles: Booch: Neste mtodo o sistema analisado atravs de vrias vises, em que cada uma delas representada por modelos e diagramas. O mtodo bastante extenso e os usurios sentiam dificuldade em utiliz-lo. O mtodo era composto por um processo de desenvolvimento iterativo e incremental. OMT (Object Modeling Technique): um mtodo desenvolvido na General Eletric por James Rumbaugh. um mtodo baseado em testes. O sistema descrito pelos seguintes modelos; objeto, funcional e o modelo dinmico. OOSE: Mtodo desenvolvido por Ivar Jacobson. A diferena com outros mtodos o seu foco em casos de uso e classificao de pessoas e equipamentos dependendo de seu papel no sistema. Coad-Yourdon: Este mtodo tambm conhecido como OOA/OOD e foi um dos primeiros mtodos utilizados na anlise e projeto de sistemas orientado a objetos. baseado num nico modelo o que torna o mtodo muito limitado. Fusion: Mtodo desenvolvido pela equipe da HP. considerada a fuso entre os mtodos anteriores a ele. Possui um grande nmero de diagramas.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 31
FAT
Outubro/1994 - Booch e Rumbaugh unidos.
Criar um mtodo unificado (Mtodo Booch + OMT-2).
Outubro de 1995 - esboo da verso 0.8 do Mtodo Unificado. Nesta mesma poca Jacobson integra o grupo. Reviso dos Objetivos, surge a UML.. Objetivos do Mtodo Unificado:
Modelar sistemas com a tcnica da Orientao a Objetos; Proporcionar uma utilizao em larga escala de hierarquia nos sistemas complexos e de misso crtica; Criar uma linguagem que possa ser compreendida por humanos e mquinas
Os esforos para a criao da UML se iniciaram oficialmente em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a unificao dos mtodos Booch e OMT. O esboo da verso 0.8 do Mtodo Unificado foi lanado em outubro de 1995. Mais ou menos na mesma poca, Jacobson se associou Rational e o escopo da UML foi expandido com a finalidade de incorporar o OOSE. Ao iniciar a unificao, foi estabelecido trs objetivos para o trabalho: 1. Fazer a modelagem de sistemas, do conceito ao artefato executvel, com a utilizao de tcnicas de orientao a objetos; 2. Incluir questes de escala, inerentes a sistemas complexos e de tarefas crticas; 3. Criar uma linguagem de modelagem a ser utilizada por seres humanos e por mquinas.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 32
FAT
Junho de 1996 - surge a verso 0.9 da UML. Durante o ano de 1996:
Consortium Partner; Sugestes da comunidade de Eng. de Software Contribuio dos membros do consrcio.
1997
Janeiro - UML verso 1.0 apresentada OMG Janeiro ~ Julho:
Contribuies adicionais UML; Semantic Task Force - Cris Krobyn e Ed Eykholt verso 1.1 da UML
Os esforos resultaram no lanamento dos documentos da verso 0.9 da UML em junho de 1996. Ao longo de 1996, foi solicitado e recebeu-se retornos da comunidade de engenharia de software geral. Nesse perodo tambm se tornou bem claro que muitas empresas de software consideravam a UML um recurso estratgico para seus negcios. Estabeleceu-se um consrcio de UML com vrias empresas que desejavam dedicar recursos com o propsito de trabalhar a favor de uma definio mais forte e completa da UML. Entre esses parceiros que contriburam para a definio da UML 1.0, encontravam-se Digital Equipment Corporation, HP, I-Logix, Intellicorp, IBM, ICON Computing, Microsoft, Oracle, Rational, Texas Instruments, MCI Systemhouse e Unisys. Tal colaborao resultou na UML 1.0, uma linguagem de modelagem bem definida, expressiva, poderosa e que poderia ser aplicada a uma grande variedade de tipos de problemas. A UML 1.0 foi oferecida para padronizao ao OMG (Object Management Group) em janeiro de 1997, em resposta solicitao do prprio OMG de propostas para linguagem-padro de modelagem. Entre janeiro e julho 1997, o grupo original de parceiros se expandiu, passando a incluir virtualmente todos os participantes e colaboradores da resposta inicial ao OMG, entre os quais se encontravam Andersen
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 33
FAT
1997
Setembro - UML verso 1.1 em votao pela OMG 14/11 - A verso 1.1 adotada como padro pela OMG. A manuteno da UML passa a ser feita pela OMG RTF (Revision Task Force) por Cris Kobryn
Vrias revises aps a sua submisso final foram feitas e futuras revises esto previstas.
Verso 1.2 - realizado em 1998 Verso 1.3 - realizado em 1999 Verso 1.4 realizado em 2002 Verso 2.0 realizado em abril/2004
Consulting, Ericsson, Object-Time Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software e Taskon. Um grupo de tarefas em semntica foi formado, liderado por Cris Kobryn da MCI System house e administrado por Ed Eykholt da Rational, com o propsito de formalizar a especificao da UML e de integrar a linguagem a outros esforos de padronizao. Uma verso revisada da UML (verso 1.1) foi oferecida para padronizao ao OMG em julho de 1997. Em setembro do mesmo ano, essa verso foi aceita pela ADTF (Analysis and Design Task Force) e pelo Architecture Board do OMG e, a seguir, submetida ao voto de todos os membros do OMG. A UML 1.1 foi adotada pelo OMG em 14 de novembro de 1997. A manuteno da UML foi ento assumida pela RTF (Revision Task Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lanou uma reviso editorial, a UML 1.2, em junho de 1998. No final do mesmo ano, a RTF lanou a UML 1.3. A verso 1.4 foi submetida em 2001. No se sabe se teremos uma verso 1.4.1 ou 1.5 em decorrncia a alteraes que podero ocorrer com a verso 1.4. Porm j se fala numa verso 2.0 para 2002.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 34
FAT
Processo de Desenvolvimento de Software

Nenhum vento sopra a favor de quem no sabe para onde ir. Sneca
A necessidade de produtividade, alm da metodologia (mtodo) foco no processo
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 35
FAT
Processos
Processo:
uma seqncia de passos executados para um determinado propsito (IEEE). Exemplo: o processo de desenvolvimento de software.
Processo de Software
um conjunto de atividades, mtodos, prticas e transformaes que profissionais de informtica utilizam para desenvolver e manter software e os produtos associados (CMM)
Um processo de software um conjunto de atividades e resultados associados que geram um produto de software. Essas atividades so, em sua maioria executadas por engenheiros de software. H quatro atividades de processo fundamentais e comuns a todos os processos de software. Essas atividades so: 1. Especificao do software: A funcionalidade do software e as restries em sua operao devem ser definidas; 2. Desenvolvimento do software: O software deve ser produzido de modo que atenda a suas especificaes; 3. Validao do software: O software tem de ser validado para garantir que ele faz o que cliente deseja; 4. Evoluo do software: O software deve evoluir para atender s necessidades mutveis do cliente. Diferentes processos de software organizam essas atividades de maneiras diversas e so descritos em diferentes nveis de detalhes. Os prazos das atividades variam, do mesmo modo que os resultados de cada atividade. Diferentes organizaes podem utilizar processos diferentes para produzir o mesmo tipo de produto. No entanto, alguns processos so mais adequados do que outros para alguns tipos de aplicao. Se um processo inadequado for utilizado isso provavelmente reduzir a qualidade do produto de software a ser desenvolvido.
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 36
FAT
Processo de Software
Mtodos, Tcnicas e Padres B A D C
PROCESSO
Pessoas com habilidades, treinamento e motivao Ferramentas e equipamento
Os processos de software so complexos e, como todos os processos intelectuais dependem do julgamento humano. Por causa da necessidade de utilizar o julgamento e a criatividade, tentativas de automatizar processos de software tm tido sucesso limitado. As ferramentas CASE podem apoiar algumas atividades de processo mas no existe a possibilidade, pelo menos nos prximos anos, de uma automao mais extensiva, na qual o software assuma o projeto criativo, liberando os engenheiros envolvidos no processo de software. Uma razo pela qual existe uma abordagem limitada para a automao de processo a imensa diversidade dos processos de software. No h um processo ideal, e diferentes organizaes desenvolveram abordagens interiamente diferentes para o desenvolvimento de software. Os processos evoluiram para explorar a acapacidade das pessoas em uma organizao, assim como as caractersticas especficas dos sistemas que esto sendo desenvolvidos. Por conseguinte, at dentro da mesma empresa pode haver muitos processos diferentes utilizados para o desenvolvimento de software.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 37
FAT
Processo de Software - Benefcios

Por que um processo?
Guia para desenvolvimento eficiente de software com qualidade Reduz riscos e aumenta a previsibilidade Promove viso e cultura comuns Institucionaliza prticas e mtodos Promove o aprendizado e melhoramento contnuo
A adoo de um processo adequado para o desenvolvimento do software permite que o produto final tenha a qualidade desejada.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 38
FAT
Modelo de Processo de Software

H quem passe pelo bosque e s veja lenha para a fogueira. Tolsti
Organizando as atividades de forma diferente em busca da produtividade. Um modelo de processo de software uma representao simplificada de um processo de software apresentada a partir de um ponto de vista especfico.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 39
FAT
Definio
Descrio simplificada de um processo de desenvolvimento de software Uma abstrao do processo real que est sendo descrito Definem as abordagens adotadas no desenvolvimento de software
Cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informaes parciais sobre o processo. apresentada, nesta apostila, os principais modelos de processos muito genricos (algumas vezes, chamados de paradigmas de processo) e fazemos isso a partir de uma perspectiva arquitetural. Em outras palavras, vmeos a estrutura do processo, mas no o detalhes das atividades especficas. Esses modelos genricos no so descries definitivas de processos de software. Em vez disso, so abstraes teis, que podem ser utilizadas para explicar diferentes abordagens do desenvolvimento de software.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 40
FAT
Modelo em Cascata
Definio de Requisitos Projeto de sistemas e de software Implementao e teste de unidade Integrao e teste do sistema Operao e Manuteno
Este o modelo mais simples de desenvolvimento de software, estabelecendo uma ordenao linear no que diz respeito realizao das diferentes etapas. Como mostra a figura, o ponto de partida do modelo uma etapa de Especificao o qual vai permitir uma clara definio dos requisitos de software, sendo que o resultado ser utilizado como referncia para as etapas posteriores de Projeto, Codificao, Validao e Manuteno. O modelo em cascata apresenta caractersticas interessantes, particularmente em razo da definio de um ordenamento linear das etapas de desenvolvimento. Primeiramente, como forma de identificar precisamente o fim de uma etapa de o incio da seguinte, um mecanismo de certificao (ou reviso) implementado ao final de cada etapa; isto feito normalmente atravs da aplicao de algum mtodo de validao ou verificao, cujo objetivo ser garantir de que a sada de uma dada etapa coerente com a sua entrada (a qual j a sada da etapa precedente). Isto significa que ao final de cada etapa realizada, deve existir um resultado (ou sada) a qual possa ser submetida atividade de certificao. Estas sadas, obtidas ao final de cada etapa, so vistas como produtos intermedirios e apresentam-se, normalmente, na forma de documentos (documento de especificao de requisitos, documento de projeto do sistema, etc..). Outra caracterstica importante deste modelo que as sadas de uma etapa so as entradas da seguinte, o que significa que uma vez definidas, elas no devem, em hiptese alguma ser modificadas.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 41
FAT
Desenvolvimento Evolucionrio
Atividades Concorrentes
Especificao Verso Inicial
Descrio do esboo
Desenvolvimento
Verses Intermedirias
Validao
Verso Final
O desenvolvimento evolucionrio tem como base a idia de desenvolver uma implementao inicial, expor o resultado ao comentrio do usurio e fazer o seu aprimoramento por meio de muitas verses, at que um sistema adequado tenha sido desenvolvido. Em vez de ter as atividades de especificao, desenvolvimento e validao em separado, todo esse trabalho realizado concorrentemente com um rpido retorno por meio dessas atividades. H dois tipos de desenvolvimento evolucionrio: 1. Desenvolvimento exploratrio, em que o objetivo do processo trabalhar com o cliente, a fim de explorar seus requisitos e entregar o sistema final. O desenvolvimento se inicia com as partes do sistema que so compreendidas. O sistema evolui com o acrscimo de novas caractersticas, medida que elas so propostas pelo cliente. 2. Fazer prottipos descartveis, em que o objetivo do desenvolvimento evolucionrio compreender os requisitos do cliente e, a partir disso, desenvolver uma melhor definio de requisitos do sistema. O prottipo se concentra em fazer experimentos com partes dos requisitos que estejam mal compreendidas.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 42
FAT
Modelo em Espiral
Determinar Objetivos, Alternativas, Restries Avaliar alternativas: Identificar e Resolver Riscos
Planejar Prximas Fases
Desenvolver e Verificar
Este modelo, proposto em 1988, sugere uma organizao das atividades em espiral, a qual composta de diversos ciclos. Cada ciclo na espiral inicia com a identificao dos objetivos e as diferentes alternativas para se atingir aqueles objetivos assim como as restries impostas. O prximo passo no ciclo a avaliao das diferentes alternativas com base nos objetivos fixados, o que vai permitir tambm definir incertezas e riscos de cada alternativa. No passo seguinte, o desenvolvimento de estratgias permitindo resolver ou eliminar as incertezas levantadas anteriormente, o que pode envolver atividades de prototipao, simulao, avaliao de desempenho, etc.. Finalmente, o software desenvolvido e o planejamento dos prximos passos realizado. A continuidade do processo de desenvolvimento definida como funo dos riscos remanescentes, como por exemplo, a deciso se os riscos relacionados ao desempenho ou interface so mais importantes do que aqueles relacionados ao desenvolvimento do programa. Com base nas decises tomadas, o prximo passo pode ser o desenvolvimento de um novo prottipo que elimine os riscos considerados. Por outro lado, caso os riscos de desenvolvimento de programa sejam considerados os mais importantes e se o prottipo obtido no passo corrente j resolve boa parte dos riscos ligados a desempenho e interface, ento o prximo passo pode ser simplesmente a evoluo segundo o modelo em cascata. Uma caracterstica importante deste modelo o fato de que cada ciclo encerrado por uma atividade de reviso, onde todos os produtos do ciclo so avaliados, incluindo o plano para o prximo passo (ou ciclo). O modelo se adequa principalmente a sistemas que representem um alto risco de investimento para o cliente.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 43
FAT
Desenvolvimento Formal de Sistemas

Definio dos requisitos Especificao Formal Transformao formal Integrao e testes de sistemas
O desenvolvimento formal de sistemas uma abordagem do desenvolvimento de software que tem algo em comum com o modelo em cascata, mas cujo processo de desenvolvimento tem como base a transformao matemtica formal (por exemplo: uma busca num banco de dados relacional lgebra relacional) de uma especificao de um sistema em um executvel.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 44
FAT
Modelo Iterativo
Este modelo tambm foi concebido com base numa das limitaes do modelo em cascata e combinar as vantagens deste modelo com as do modelo Prototipao. A idia principal deste modelo a de que um sistema deve ser desenvolvido de forma incremental, sendo que cada incremento vai adicionando ao sistema novas capacidades funcionais, at a obteno do sistema final, sendo que, a cada passo realizado, modificaes podem ser introduzidas. Uma vantagem desta abordagem a facilidade em testar o sistema, uma vez que a realizao de testes em cada nvel de desenvolvimento , sem dvida, mais fcil do que testar o sistema final. Alm disso, como na Prototipao, a obteno de um sistema, mesmo incompleto num dado nvel, pode oferecer ao cliente interessantes informaes que sirvam de subsdio para a melhor definio de futuros requisitos do sistema. No primeiro passo deste modelo uma implementao inicial do sistema obtida, na forma de um subconjunto da soluo do problema global. Este primeiro nvel de sistema deve contemplar os principais aspectos que sejam facilmente identificveis no que diz respeito ao problema a ser resolvido. Um aspecto importante deste modelo a criao de uma lista de controle de projeto, a qual deve apresentar todos os passos a serem realizados para a obteno do sistema final. Ela vai servir tambm para se medir, num dado nvel, o quo distante se est da ltima iterao. Cada iterao do modelo de Desenvolvimento Iterativo consiste em retirar um passo da lista de controle de projeto atravs da realizao de trs etapas: o projeto, a implementao e a anlise. O processo avana, sendo que a cada etapa de avaliao, um passo retirado da lista, at que a lista esteja completamente vazia. A lista de controle de projeto gerencia todo o desenvolvimento, definindo quais tarefas devem ser realizadas a cada iterao, sendo que as tarefas na lista podem representar, inclusive, redefinies de componentes j implementados, em razo de erros ou problemas detectados numa eventual etapa de anlise. ________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 45
FAT
Qualidade de Software
A verdade est l fora, algum sabe a URL? Annimo
O que qualidade de software? a qualidade do produto? A qualidade do seu processo?
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 46
FAT
Qualidade de Software
Qualidade de Software: As caractersticas de se ter demonstrada a obteno de um produto que est de acordo ou excede a concordncia sobre requisitos, como medido por critrias e medidas acordadas, e que produzido de acordo com um processo acordado (Rational Unified Process)
Qualidade: Caractersticas de se ter demonstrado o sucesso em desenvolver um produto que encontra ou excede acordo quanto aos requisitos, como mensurado com mtricas e critrios acordados, e produzido por um processo acordado (Rational Unified Process). Observa-se que, dentro desta definio, qualidade no somente estar de acordo com os requisitos, mas envolve tambm a identificao das mtricas e critrios e a implementao de um processo para assegurar que o produto resultante obteve o grau desejado de qualidade (e pode ser repetido e gerenciado). Em muitas organizaes, testes de software contabilizam 30% a 50% dos custos totais do desenvolvimento, e ainda assim so considerados como no bem-testados antes de ser entregue. Esta contradio enraizada em dois fatos claros: -Testar software muito difcil, as alternativas oferecidas por um sistema complexo so quase infinitas. -Testes so tpicamente realizados sem uma metodologia clara e sem a automao ou suporte de ferramentas requerido. Enquando a complexidade do software torna o teste completo uma meta impossvel, uma metodologia bem concebida e o uso de ferramentas modernas pode aumentar muito a produtividade e efetividade do teste de software.
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 47
FAT
Objetos da Qualidade
Qualidade de software inclui:
Qualidade de Processo refere-se s atividades, mtodos, prticas e tranformaes que profisionais de informtica utilizam para desenvolver e manter software e os produtos associados (CMM) Qualidade de Projeto refere-se ao correto emprego da metodologia definida e dos recursos disponibilizados na produo de software, objetivando:
Eficincia Eficcia Controle de Custos Cumprimento de Prazos
Qualidade de Produto seu controle visa garantir o atendimento s necessidades dos clientes e usurios Os critrios de avaliao
As principais caractersticas que determinam o grau de qualidade de um processo de software so a preciso de definio, documentao, usabilidade, aprimorabilidade, controlabilidade, mensurabilidade e a sua adaptabilidade a novas tecnologias. As principais caractersticas que determinam o grau de qualidade de um projeto de software so a correta especificao de requisitos, gerenciamento de requisitos (alteraes e impactos das mudanas), nvel de detalhamento adequado do modelo de software, facilidade de entendimento por parte de desenvolvedores, facilidade de alteraes, facilidade de inspees e walkthroughs e a existncia de pontos de verificao. As principais caractersticas que determinam o grau de qualidade de um produto final de software so a facilidade de instalao, utilizao, invisibilidade de comportamento, cobertura das necessidades funcionais que se pretende atender (escopo), exatido de resultados, tratamento apropriado de casos normais e excees e a facilidade de manuteno.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 48
FAT
Aumentando a qualidade do produto: Melhores Prticas

No espere por uma crise para descobrir o que importante em sua vida. Plato
O que fazer para aumentar a qualidade do produto?
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 49
FAT
Problemas no Desenvolvimento de Software

Sintomas Causas Melhores Prticas Desenvolvimento iterativo Gerenciar requisitos Arquitetura componetizada Verificao contnua da qualidade Necessidade no atendidas Requisitos insuficientes Requisitos expirados Mdulos no se integram Difcil manuteno Comunicao ambgua Arquitetura frgil Complexidade absurda
Descoberta tardia de falhas Inconsistncias no detectadas Gerenciar mudanas Baixa qualidade Baixa performance Testes pobres Avaliao subjetiva Modelagem visual (UML)
Coliso de desenvolvedores Desenvolvimento em Cascata Build-and-realease Mudanas no controladas

Fonte: SPMN (Software Program Manager Network)
Os problemas que afligem o desenvolvimento de software podem ser caracterizados a partir de uma srie de perspectivas diferentes, mas os gerentes responsveis pelo desenvolvimento de software concentram-se nas questes de primeiro plano: (1) as estimativas de prazo e de custo frequentemente so imprecisas; (2) a produtividade das pessoas da rea de software no tem acompanhado a demanda por seus servios; e (3) a qualidade de software s vezes menos que a adequada. Pouca coisa tem sido feita para melhorar a produtividade dos profissionais da rea de software. Alm disso, no dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software. Com poucos dados histricos como guia, as estimativas tm sido a olho, com resultados previsivelmente ruins. Sem nenhuma indicao sllida de produtividade, no podemos avaliar com preciso e eficcia de novas ferramentas, mtodos ou padres. A insatisfao do cliente com o sistema concludo ocorre frequentemente. A comunicao entre o cliente e o desenvolvedor de software muita fraca. A qualidade de software, nestas condies, suspeita. S recentemente comeamos a entender a importncia dos testes de software sistemticos e tecnicamente completos. A tarefa de manuteno de software devora a maioria de todos os recursos destinados ao software. A capacidade de manuteno de software no foi enfatizada como um critrio importante para a aceitao do software. Apresentamos primeiro as ms notcias. Passemos agora para as boas notcias. Cada um dos problemas descritos anteriormente pode ser corrigido. Uma abordagem de engenharia ao desenvolvimento de software aliada a uma contnua melhoria de tcnicas e ferramentas oferece a chave.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 50
FAT
Desenvolvimento: Cascata x Iterativo

Cascata (Waterfall)
Iterativo
Adaptado de Workshop Natura - NUP
As desvantagens do modelo cascata: No leva em considerao alteraes de requisitos Testes e integrao ocorrem somente ao final do processo, perdendo-se assim a oportunidade de detectar-se defeitos antes, a custos muito menores. A eliminao de riscos comea a ocorrer tardiamente Mede o progresso medindo produtos de trabalho que so pobres indicadores de tempo restante Implantaes somente ao final. Freqentemente resulta em grandes iteraes no planejadas. As vantagens do modelo iterativo: Os riscos so mitigados mais cedo, porque os elementos so integrados progressivamente Mudanas de requisitos e tticas so acomodadas mais fcil melhorar e refinar o produto, aumentando sua robustez. Testes e integraes so realizados muito mais cedo Organizaes podem aprender medida em que o ciclo de vida evolui A reusabilidade aumentada
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 51
FAT
O Ciclo de Vida Iterativo e a Reduo de Riscos

Risco Cascata
Risco Risco
Risco Iterativo
Tempo Tempo
O desenvolvimento iterativo produz a arquitetura primeiro, permitindo que a integrao ocorra como a atividade de verificao do projeto, e suas falhas so resolvidas o quanto antes. A integrao contnua substitui a grande integrao ao final do projeto. O desenvolvimento iterativo tambm prov viso muito melhor do projeto, porque as caractersticas do sistema que so inerentes arquitetura (performance, tolerncia a erros, manutenibilidade) so tangveis mais cedo no processo. Estes problemas podem ento ser corrigidos sem colocar custos e prazos em risco.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 52
FAT
Gerenciamento de Requisitos
O gerenciamento de requisitos um modelo sistemtico para encontrar, documentar, organizar e rastrear os requisitos variveis de um sistema. Um requisito uma condio ou uma capacidade com a qual o sistema deve estar de acordo. Nossa definio formal de gerenciamento de requisitos trata-se de um modelo sistemtico para: identificar, organizar e documentar os requisito do sistema, e estabelecer e manter acordo entre o cliente e a equipe do projeto nos requisitos variveis do sistema. Os principais itens para o gerenciamento eficiente de requisitos incluem manter uma declarao clara dos requisitos, juntamente com atributos aplicveis para cada tipo de requisito e rastreabilidade para outros requisitos e outros artefatos do projeto. A coleta de requisitos pode parecer uma tarefa bem precisa. Nos projetos reais, contudo, voc encontrar dificuldades porque: Nem sempre os requisitos so bvios e podem vir de vrias fontes. Nem sempre fcil expressar os requisitos claramente em palavras. Existem diversos tipos de requisitos em diferentes nveis de detalhe. O nmero de requisitos poder impossibilitar a gerncia se no for controlado.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 53
FAT
Problemas Relacionados ao No Gerenciamento de Requisitos

Uma minoria de projetos de software concluda no prazo e oramentos
Taxa de Sucesso: 16,2% Projetos com concluso tardia ou estouro de oramento: 52,7% Projetos cancelados: 31,7%
Causas principais:
Definio incorreta dos requisitos no incio do projeto Mau gerenciamento dos requisitos atravs do ciclo de vida (ou total ausncia de gerenciamento)
Fonte: www.standishgroup.com
Os requisitos esto relacionados uns com os outros, e tambm com o produto liberado do processo de engenharia do software. Os requisitos tm propriedades exclusivas ou valores de propriedade. Por exemplo, eles no so igualmente importantes nem igualmente fceis de cumprir. H vrias partes interessadas, o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de diferentes funes.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 54
FAT
Benefcios do Gerenciamento de Requisitos

Melhor controle de projetos complexos Melhor qualidade e satisfao do cliente Custos e atrasos reduzidos aliado ao modelo iterativo Melhoria na comunicao Servem como uma base contratual entre a equipe desenvolvedora e os seus clientes
O controle do projeto aumenta medida que as alteraes de requisitos so analisados quanto ao impacto e avaliados com critrios na realo custobenefcio. O sistema construdo de acordo com as necessidades e requisitos reais perfeitamente compreendidos aumentando assim a qualidade e satisfao do cliente. Aliar o gerenciamento de requisitos ao modelo iterativo diminuem custos e atrasos na medida que reduzem erros no incio do desenvolvimento, o impacto de erros ao longo do desenvolvimento. Melhora a comunicao entre os desenvolvedores e dos desenvolvedores e os clientes: Assegura a documentao clara e no ambgua dos requisitos Facilita o envolvimento de usurios, permitindo que eles entendam que a aplicao est sendo construda de fato para atender as suas necessidades
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 55
FAT
Arquitetura Baseada em Componentes
Celular
PC em Rede Captao Pedidos
Empenho Estoque Separao PDA
Funcionalidades Funcionalidades Unificadas Unificadas
Banco 4 Cadastro Pessoas Banco 1 Banco 3 Administrao Materiais
Integrao Integrao Facilitada Facilitada
Faturamento Promoes
Rastreamento Pedidos
Parceiros B2B
Navegador Internet
Evoluo Facilitada! Evoluo Facilitada!
Fonte: Workshop Natura - NUP
O desenvolvimento centrado na arquitetura. O processo enfatiza basear o desenvolvimento na arquitetura prvia do software. Tendo uma arquitetura robusta permite o desenvolvimento paralelo, diminui o retrabalho e aumenta a probabilidade de reutilizao de componentes e facilita a manuteno.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 56
FAT
Benefcios da Arquitetura Baseada em Componentes

Flexvel a Mudanas:
Adaptvel a mudanas de requisitos. Melhora a extensibilidade. Permite reutilizao. Encapsula dependncias de sistema.
Baseada em Componentes:
Reutiliza ou customiza componentes. Componentes podem ser adquiridos comercialmente. Evolui software existente de forma incremental.
A arquitetura de software o aspecto que d o mais alto retorno de investimento com respeito qualidade, prazos e custos. parte de projeto e refere-se a decises de como o sistema ser construdo. Arquitetura no o projeto completo, o nvel mais alto de abstrao. Em outras palavras, os elementos que tem efeitos de longa durao sobre as qualidades do sistema, particularmente sua capacidade de evoluir. A arquitetura talvez o aspecto mais importante que pode ser usado para controlar o desenvolvimento iterativo. A propriedade mais importante de uma arquitetura a flexibilidade mudanas. Tcnicas principais so abstrao, encapsulamento e anlise e projeto orientados a objetos. O resultado aplicaes mais manutveis e extensveis.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 57
FAT
Verificao Contnua da Qualidade

A qualidade deve ser verificada ao longo de todo o processo:
O processo deve seguir as normas estabelecidas. Os artefatos devem estar de acordo com o padro estabelecido. Todas as iteraes devem ser testadas. Todos os artefatos devem ter a qualidade verificada.
A qualidade do produto (software) deve ser verificada durante todo o desenvolvimento:

Planejamento e Execuo de Testes com base em modelos Teste atravs de cenrios garante que todos os requisitos sero adequadamente implementados Identificao antecipada de erros Teste em cada iterao
A qualidade adicionado a cada atividade realizada dentro do processo e so utilizadas critrios e mtricas objetivas. O gerenciamento dos riscos est embutido no decorrer do processo, de tal forma que os riscos para o sucesso do projeto so identificados e solucionados precocemente no processo de desenvolvimento, quando h tempo para reagir. Aliado ao ciclo de vida iterativo, permite que desenvolvedores identifiquem componentes progressivamente e possam optar por desenvolv-los ou compr-los no mercado. O uso de componentes permite reutilizao em larga escala, a diviso do trabalho entre indivduos ou equipes diversas e a organizao dos planos de testes em funo dos componentes, facilitando a identificao de defeitos.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 58
FAT
Gerenciamento de Mudana
Objetivo
Controlar o ciclo de vida do software
Garantir
rea segura para o desenvolvedor Desenvolvimento paralelo Integrao acontece de forma automtica Versionamento de artefatos (qualquer tipo de documento)
Gerenciamento de Solicitaes de Mudana - abrange a infra-estrutura organizacional necessria para avaliar o custo e programar o impacto de uma mudana solicitada sobre o produto existente. O Gerenciamento de Solicitaes de Mudana envolve o trabalho da Equipe de Reviso de Mudana ou do Comit de Controle de Mudana.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 59
FAT
Modelagem Visual
Estabelece uma linguagem nica e padro Fcil entendimento (estrutura e comportamento) Evita ambigidades Define objetivamente os requisitos e as solues
As atividades enfatizam a criao e manuteno de modelos. Esse tipo de foco minimiza o tempo associado gerao e manuteno de documentos e reala o contedo relevante de informaes. Modelos, principalmente aqueles utilizados na UML, so uma representao semntica muito rica do sistema durante o seu desenvolvimento. A UML uma linguagem padro para a elaborao da estrutura de projetos de software. A UML poder ser empregada para visualizao, a especificao, a construo e a documentao de artefatos que faam uso de sistemas complexo de software. A UML adequada para a modelagem de sistemas, cuja abrangncia poder incluir sistemas de informao corporativos a serem distribudos a aplicaes baseadas em Web e at sistemas complexos embutidos de tempo real. uma linguagem muito expressiva, abrangendo todas as vises necessrias ao desenvolvimento e implantao desses sistemas. Apesar de sua expressividade, no difcil compreender e usar a UML. Aprender a aplicar a UML de maneira efetiva tem incio com a formao de um modelo conceitual da linguagem, o que pressupe o entendimento de trs principais elementos: os blocos bsicos de construo da UML, as regras que determinam como esses blocos de construo devero ser combinados e alguns mecanismos bsicos que aplicam a toda linguagem. A UML apenas uma linguagem e, portanto, somente uma parte de um mtodo para o desenvolvimento de software. A UML independente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrada na arquitetura, iterativa e incremental.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 60
FAT
Processos de Desenvolvimento de Software

No basta possuir um intelecto vigoroso; o primeiro requisito aplic-lo corretamente. Ren Descartes
Aplicando a qualidade nos processos de desenvolvimento de software.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 61
FAT
Tipos de Processos
Um processo de software pode ser
Preditivo
Rgido Burocrtico No leva caractersticas especficas de cada projeto em considerao
Adaptativo
Adaptado s necessidades de cada projeto Adaptvel s caractersticas da equipe de projeto Conceito de framework gil
O processo adaptativo visto como um framework, ou seja, um conjunto de recursos utilizado para se construir o processo para um projeto especfico. Os recursos so selecionados e adaptados para se construir o produto objetivo.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 62
FAT
Descrio de Processo
Processos devem ser descritos, e sua descrio deve estar ao alcance de todas as pessoas envolvidas na organizao Descries tradicionais: manuais impressos Descries modernas: sites disponveis na intranet da organizao descrio on-line Vantagens da descrio on-line:
Todas as vantagens de documentos eletrnicos Templates de documentos disponveis para download Possibilidade de se criar links entre documentos e descries no processo (exemplo, tarefas de cronograma e descries de atividades)
No adianta ter um processo que se encontra na cabea de seu idealizador. Para ser usada deve ser divulgada e modificada de acordo com o decorrer dos projetos.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 63
FAT

Extreme Programming (XP)
Possui um nico artefato Utiliza CRC artefato secundrio
Feature Driven Developmente (FDD)

Possui 4 artefatos
Lista de caractersticas Diagrama de Classe Mapas de Sequncias Cdigos
Uso de cores no diagrama de classe
Extreme Programming (XP) Pioneiro no moderno movimento chamado Peso Leve, contm apenas um nico artefato principal (o prprio cdigo). Em XP so utilizados, para capturar os requisitos do sistema, cartes CRC (Classe, Responsabilidade e Colaborao), que so os artefatos secundrios deste processo. Outra caracterstica interessante (e inovadora) deste processo a prtica de se trabalhar em grupos de duas pessoas na codificao e nos testes dos programas. Feature Driven Development (FDD) Utilizando-se de quatro artefatos (Lista de Caractersticas, Diagrama de Classes, Mapas de Seqncia e Cdigo), o FDD enfoca iteraes que duram duas semanas para mostrar resultados tangveis. Dentre suas contribuies destaca-se o seu Diagrama de Classes, do qual permite o uso de cores para destacar tipos diferentes de classes.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 64
FAT

Joint Application Design (JAD)
Baseada na coleta de requisitos dos usurios Concentrado nas atividades de Anlise e Projeto Difcil reunio de todos os usurios
Object-Oriented Software Process (OOSP)

Coleo de processos padres coleo de tcnicas gerais, aes e/ou tarefas. Possui duas fases: Inicial e Entrega
Joint Application Design (JAD) um mtodo baseado na coleta de requisitos de usurios por meio de entrevistas e observaes. Seu ponto forte est concentrado nas atividades de Anlise e de Projeto. Aps a coleta dos requisitos, renem-se novamente com os usurios com o intuito destes, alm de eliminarem conflitos entre os requisitos, chegarem a um acordo comum sobre o que ser o sistema. Uma das vantagens deste processo a rapidez em que se chega na definio do sistema. Como desvantagem, destaca a dificuldade de reunir todos os usurios envolvidos com o processo. Object-Oriented Software Process (OOSP) Processo de Software Orientado a Objeto. Compreende uma coleo de Processos Padres. Um Processo Padro uma coleo de tcnicas gerais, aes, e/ou tarefas (atividades) que so freqentemente executadas. Em OOSP os esforos se concentram em duas fases de Processo: Inicial e Entrega.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 65
FAT

Open Process
Desenvolvido por um consrcio de pessoas e organizaes Suporta a UML e similar ao Processo Unificado
Rapid Application Development (RAD)

Semelhante prototipao Refinamentos sucessivos
Unified Process (UP)

Desenvolvido a partir do Objectory Process de Ivar Jacobson Foi submetido OMG em Maio de 2000
Open Process Processo de Desenvolvimento de Software desenvolvido por um consrcio formado por um grupo de pessoas e organizaes com a inteno de aumentar o uso da Orientao a Objeto. O Open Process um Processo de Software que foi projetado para auxiliar organizaes no uso de tecnologias de objetos e componentes, embora possa ser facilmente aplicado em outras tecnologias de desenvolvimento de software. Similar ao Unified Process, o Open Process foi inicialmente criado por uma fuso de mtodos: MOSES, SOMA, Firesmith, Syntjesis, BOM e OORAM. Este processo suporta a notao UML, a notao OML (Object Modeling Language) e qualquer outra notao Orientada a Objeto e pode ser configurado de diferentes formas. um processo que possui forte suporte para a modelagem de negcio, projeto, gerenciamento, captura de requisitos e a tradicional Anlise & Projeto da Orientao a Objeto. Rapid Application Development (RAD) um mtodo de desenvolvimento de sistema que pode produzir software de alta qualidade. um processo iterativo similar a Prototipao, em que requisitos, projeto e o prprio sistema so desenvolvidos com refinamentos seqenciais. RAD enfatiza velocidade de desenvolvimento. Com RAD, aumenta-se e estende-se a verso inicial por diversas iteraes at que seja alcanado o grau desejado para o produto, geralmente produzindo componentes funcionais do sistema final. Com RAD, usurios so intensamente envolvidos no processo de desenvolvimento, atravs de sesses de JAD. Ferramentas ICASE so ento rapidamente utilizadas para estruturar os requisitos e desenvolver prottipos que sero revisados pelos usurios, tambm, em sesses de JAD. As principais vantagens do RAD so o envolvimento dos usurios no processo de Desenvolvimento e a reduo do custo do desenvolvimento. Assim como no JAD, como desvantagem, destaca a dificuldade de reunir todos os usurios envolvidos com o processo.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 66
FAT
Conhecendo um Processo de Desenvolvimento de Sofware: UP

Um dos maiores desafios das organizaes de software justamente aplicar em seus processos de desenvolvimento os novos conceitos de engenharia de software Ian Sommerville, 2003
Depois da linguagem unificada para modelos, cria-se o processo unificado!!
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 67
FAT
Evoluo do Processo Objectory Ivar Ferramenta Jacobson
Processo Processo
Mtodo
Mtodo
Mtodo
Arquitetura Agosto 1985
Arquitetura Fevereiro 1986
Arquitetura Novembro 1988
Arquitetura Setembro 1989
A demanda por sistemas complexos faz com que seja necessrio a utilizao de mtodos de desenvolvimento. E atendendo a esta necessidade que Ivar Jacobson criou em 1985 o Processo Objectory. A idia por trs do Objectory a criao de um Processo Unificado que suportar as atividades do desenvolvimento de software atravs do ciclo de vida do sistema. O processo ter todas as fases de desenvolvimento, desde o modelo da empresa, anlise, projeto, implementao, teste, configurao e instalao manuteno. No desenvolvimento das tcnicas do Objectory iniciou-se com a arquitetura, depois os mtodos, processos e finalmente as ferramentas. As bases tcnicas do Objectory foi formulada em 1985. Desde que foi desenvolvida as idias bsicas continuam as mesmas, ou seja, o conceito de casos de uso so descritas como essenciais ao processo. A primeira verso coerente do processo surgiu em fevereiro de 1986 e foi apresentado na OOPSLA87. A descrio dos processos foram completadas em Novembro de 1988. A partir deste momento, Jacobson, iniciou seu trabalho em desenvolver uma ferramenta que suportasse o processo, o qual surgiu em Setembro de 1989, o OrySE (Objectory Support Environment).
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 68
FAT
1993 Processo Objectory verso 3.3 Outubro de 1995 Jacobson une-se a Booch e Rumbaugh no desenvolvimento do Mtodo Unificado reviso dos objetivos:
Mtodo unificado Linguagem Unificada
Dezembro de 1998 Modelo do Processo Unificado (Unified Process Model) verso 5.0 Maio de 2000
UPM submetido a OMG RUP 2000 e IBM SI Method UPM customizado
Desde a publicao at 1993, o Objectory foi utilizado em aproximadamente 20 projetos e a verso corrente nesta poca era a 3.3. Em outubro de 1995 a Rational Rose que pertencia a Grady Booch e James Rumbaugh, adquirem a Objectory e Ivar Jacobson une-se ao grupo. Nesta mesma poca decidem que inicialmente iriam desenvolver uma linguagem unificada e posteriormente o mtodo unificado. Assim em dezembro de 1998, Ivar Jacobson, principalmente desenvolve o modelo do Processo Unificado na sua verso 5.0. O Processo unificado (UPM) totalmente baseado no Objectory. A UPM se baise em 3 princpios: Dirigido por caso de uso Centrado na arquitetura Iterao com incremento Em maio de 2000 a UPM foi submetida aprovao da OMG, como ela semelhante ao CORBA, ou seja, precisa ser implementada a Rational Rose customizou a UPM para o seu ambiente e hoje temos o Rational Unified Process (RUP). A IBM tambm customizou a UPM e criou o IBM SI Method.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 69
FAT
Objetivo
Permitir o desenvolvimento de sistemas de alta qualidade
usabilidade custos prazos
Utilizar as melhores prticas no desenvolvimento de sistemas Permitir o gerenciamento adequado na organizao do desenvolvimento
O processo unificado foi modelado especialmente para suportar a UML e desenvolver sistemas com qualidade e tcnicas de orientao a objetos. O objetivo do processo unificado permitir a produo de um software de qualidade que preencha as necessidades do usurio dentro de prazos e custos definidos previamente. O processo unificado utiliza-se das melhores prticas no desenvolvimento de software necessrias para dimensionar de forma adequada ao tipo de projeto e organizao. No lado do gerenciamento, o processo unificado permite uma disciplina no modo como as tarefas e responsabilidades so realizadas na organizao do desenvolvimento de software.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 70
FAT
Caractersticas
Processo iterativo
encontrar a soluo atravs de refinamentos sucessivos flexibilidade mudanas estratgicas
Fonte: Rational Software Corporation; Rational Unified Process Version 2002.05.20; Copyright 1987 2002; 2002.
Caractersticas
Centrado na arquitetura do software
desenvolvimento paralelo reutilizao de componentes
Baseado em Casos de Uso

entender como o software ser utilizado
Processo customizvel Controle de qualidade Gerenciamento de riscos
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 71
FAT
Caractersticas
Foco em modelos
minimiza o tempo na gerao e controle de documentos evidencia o contedo de informao vrias vises do sistema
Tcnicas de Orientao a Objetos

UML
Estrutura
A estrutura do UP formada por uma matriz de duas dimenses:
Dimenso relacionada ao contedo: descreve os recursos utilizados durante o ciclo de vida
Disciplinas Macroatividades Atividades
Dimenso relacionada ao tempo: descreve a estrutura do ciclo de vida (aspectos dinmicos)

Fases Iteraes
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 72
FAT
Estrutura
Tempo
Contedo
Adaptado de Rational Software Corporation; Rational Unified Process Version 2002.05.20; Copyright 1987 2002; 2002.
O UP executa uma srie de ciclos que compem a vida de um sistema. Cada ciclo conclui com um lanamento de produto aos clientes. Cada ciclo consiste em quatro fases: iniciao, elaborao, construo, e transio. Cada fase subdividida em iteraes. Cada ciclo resulta em um lanamento novo do sistema e cada lanamento um produto pronto para ser entregue. Este produto inclui os requisitos, os casos de uso, os requisitos no funcionais e os casos de teste. Inclui, tambm, a arquitetura e os modelos visuais - artefatos modelados com a UML. De fato, inclui todos os elementos que habilitam os usurios, analistas, designers, implementadores, testadores e gerentes especificarem, projetarem, implementarem, testarem, e usarem um sistema. Alm disso, so estes elementos que permitem o uso e a modificao do sistema de gerao a gerao.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 73
FAT
A dimenso dinmica do UP
Impossvel significa somente que voc ainda no encontrou a soluo. Annimo
Os aspectos do UP em funo do tempo Fases, Marcos e Iteraes e o ciclo de vida iterativo em detalhes
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 74
FAT
Dimenso Dinmica
Organizado em fases, marcos e iteraes.
Tempo
Fases
marco
Iteraes
Fase perodo entre dois grandes milestones do processo na qual um determinado conjunto de objetivos devem ser alcanados, artefatos so finalizados e decises estratgicas so tomadas para que se possa ir para a prxima fase. Passamos para a prxima fase somente se os objetivos foram alcanados de forma satisfatria. O UP possui 4 fases: Iniciao estabelece o modelo do negcio para o projeto Elaborao estabelece o plano do projeto e sua arquitetura Construo implementao do sistema; Transio fornece o sistema aos seus usurios finais. A iniciao e elaborao esto relacionados com as atividades de engenharia do desenvolvimento, enquanto que a construo e a transio com a produo. Os marcos so pontos de deciso estratgica planejados. Ao final de cada marco deve-se avaliar os resultados e os objetivos alcanados. Para a avaliao dos resultados e objetivos utiliza-se checklists. Uma iterao deve ter como resultado um produto executvel de valor observvel, portanto verificvel.Os critrios de avaliao do produto devem ser estabelecidos quanto a iterao planejada Iteraes devem possuir horizonte de tempo fixo (time box). O Time Boxing fixa a data de trmino do projeto ou de uma atividade do projeto, e no seu contedo. Caso se verifique que o escopo inicial no ser atingido, negocia-se a reduo do escopo, e no o adiamento do prazo. O planejamento das iteraes feito tomando-se como base as funcionalidades requeridas (casos de uso) a serem implementadas na iterao. As fases determinam o que resolver em suas iteraes quais funcionalidades implementar. Iteraes podem ser vistas como pequenos projetos independentes utilizando modelo cascata. ________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 75
FAT
Iteraes
Fases e Marcos do UP
Iniciao Elaborao Construo Transio
Marco: Objetivos do ciclo de vida Marco: Arquitetura do ciclo de vida
Marco: Capacidade operacional inicial Marco: Lanamento do Produto
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 76
FAT
A iniciao tem como objetivo entender o problema e assegurar que existe soluo possvel e vivel Os resultados que devem ser obtidos ao final da fase: Escopo do produto definido Requisitos crticos identificados Viso preliminar de pelo menos uma arquitetura candidata Estimativas iniciais de esforo e custo Estimativa de riscos Ambiente de suporte para o projeto preparado O objetivo do marco garantir que o objetivo do ciclo de vida foi definido (o que construir) Se a verificao deste Marco Principal falhar, deve-se repensar o projeto como um todo, ou mesmo em abort-lo pode significar que a construo do produto no vivel, seja pela complexidade do problema, seja pelos altos custos estimados
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 77
FAT
O objetivo da fase de elaborao definir a arquitetura para prover uma base para os esforos de projeto e implementao da fase construo Resultados que devem ser obtidos ao final da fase: Base da arquitetura definida Funcionalidades de significao arquitetnica implementadas Riscos de significao arquitetnica resolvidos A viso operacional e a arquitetura definitiva devem estar definidas ao final desta fase. Seus riscos devem estar claramente identificados. Os componentes da arquitetura podem ser distribuidos entre desenvolvedores ou equipes de desenvolvedores. As estimativas de custos e prazos devem ser de alta credibilidade, permitindo que se assumam comprometimentos. O objetivo do marco garantir que a arquitetura do produto foi definida (como construir) Se a verificao deste Marco Principal falhar, deve-se repensar o projeto como um todo, ou mesmo em abort-lo os riscos tcnicos no foram resolvidos, e provavelmente se materializaram em problemas reais
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 78
FAT
O objetivo da fase de construo identificar os requisitos restantes e concluir a implementao do sistema sobre a linha de arquitetura definida na fase Elaborao Resultados que devem ser obtidos ao final da fase: Requisitos totalmente detalhados e identificados Projeto concludo Produto implementado fisicamente Verses preliminares (alfa,beta, etc.) avaliadas pelo cliente/usurios Produtos perifricos (documentao tcnica, manuais de usurio, materiais de treinamento) criados No decorrer do processo e de suas iteraes, novos requisitos podem surgir, e necessidades de detalhamentos maiores de requisitos previamente identificados tambm. Ao final desta fase, os requisitos devem estar totalmente identificados e planejados, pois so base para o planejamento de testes sobre o produto implementado, objetivo tambm desta fase. Falhas de testes podem provocar ajustes ao produto ou detalhamento maior de requisitos. O detalhamento final da arquitetura pode ocorrer nesta fase tambm. O objetivo do marco garantir que todas as funcionalidades requeridas foram implementadas Se a verificao deste Marco Principal falhar, deve-se planejar mais uma iterao se o projeto chegou a esta fase, no podem haver riscos tcnicos significativos envolvidos e os custos realizados at o momento no mais justificam abortar-se o projeto
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 79
FAT
O objetivo da transio assegurar que o software est disponvel para a comunidade de usurios Resultados que devem ser obtidos ao final da fase: Produto afinado (pequenos ajustes em funo de feed-back de usurios realizados) Software totalmente testado contra os requisitos e aprovado Implantado no ambiente operacional Bases de dados operacionais criadas, dados migrados Usurios capacitados para utilizar o software As atividades de afinao so decorrentes de testes do produto em ambiente real, o que ocorre nesta fase. Mas as principais atividades referem-se a instalao do produto no ambiente de produo. A homologao pelos usurios marca o final do ciclo de vida do processo. O objetivo do marco garantir que o produto foi entregue e aceito pelos clientes/usurios Se a verificao deste Marco Principal falhar, deve-se planejar mais uma iterao para resolver os problemas que causaram esta falha
________________________________ FAT/Mrcia Ito ________________________________ _______________________ Pg. 80
FAT
Fases e Iteraes no UP
As fases determinam a nfase da aplicao de disciplinas por iterao:
Iteraes de iniciao: maior nfase em modelagem de processos de negcios e requisitos Iteraes de elaborao: maior nfase em anlise e projeto Iteraes de construo: maior nfase em implementao e testes Iteraes de transio: maior nfase em implantao Disciplinas de suporte podem ser vistas com a mesma nfase ao longo de todo o projeto
O planejamento e avaliao das iteraes feito na disciplina Gerenciamento de Projeto
Iteraes X Fases no UP
As fases determinam os tipos de funcionalidades que devem ser selecionadas para as iteraes, de acordo com os riscos tcnicos envolvidos Iniciao: funcionalidades que contm riscos relativos ao domnio do problema Elaborao: funcionalidades que contm riscos relativos arquitetura Construo: demais funcionalidades, que no devem conter riscos significativos Transio: refinamentos e produtos acessrios, necessrios para a disponibilizao do software comunidade de usurios
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 81
FAT
A Dimenso Esttica do UP (Contedo)

Nenhuma obra criativa veio luz sem o jogo ldico da fantasia. A dvida que temos para com o jogo da imaginao incalculvel. Carl Jung
Os conceitos-chave dos elementos que o UP utiliza ao longo do processo e as relaes entre eles
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 82
FAT
Dimenso Esttica
Organizado em disciplinas.
Disciplinas so grupos de atividades que formam um fluxo e produzem um resultado de valor observvel Agrupadas pelas suas caractersticas No UP temos apenas as caractersticas de Engenharia:
Requisitos Anlise e Design Implementao Teste

As disciplinas correspondem s fases dos processos que adotam o ciclo de vida tradicional; no UP elas so visitadas a cada iterao
________________________________ FAT/Mrcia Ito
Contedo
________________________________
_______________________ Pg. 83
FAT
Disciplina
Cada disciplina detalhada atravs de um fluxo de trabalho
Fluxo de Trabalho
Conjuntos de atividades frequentemente executadas em conjunto (macroatividade):
Altamente relacionadas Executada por um grupo de pessoas Produz um resultado intermedirio coerente So as unidades bsicas para o planejamento das iteraes (tarefas a serem includas em cronograma)
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 84
FAT
Detalhamento da Macroatividade
Artefato de sada Atividade
Papel Artefato de entrada

Atividade unidades de trabalho que um indivduo deve executar quando desempenha um papel no processo, criam ou atualizam artefatos e podem durar de poucas horas a poucos dias Papis so definies de comportamento e responsabilidade de indivduos, ou conjuntos de indivduos trabalhando em time Comportamento: conjunto de atividades executadas Responsabilidade: relativas a artefatos Papis no so indivduos: Um indivduo pode executar mais de um papel, o que significa que este est assumindo mais de um conjunto de comportamentos e responsabilidades definidos no processo A quantidade de papis que um indivduo assume inversamente proporcional ao nmero de indivduos que compe a equipe de projeto Embora normalmente exista uma correspondncia, papis no devem ser vistos como cargos em uma organizao Artefato qualquer coisa produzida, modificada ou utilizada por uma atividade sendo sua entrada e/ou saidas. Tipos de artefatos: Documentos, Modelos, Elementos de Modelos, Cdigo Fonte, Executveis Normalmente esto sujeitos a controle de configurao e mudanas e podem ser compostos por outros artefatos So criados em um determinado ponto do ciclo de vida, e podem evoluir no decorrer do projeto.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 85
FAT
Templates
Padres para artefatos tipo documentos Produzidos com ferramentas de escritrio
Editores de textos Planilhas eletrnicas Editores de cronogramas
Exemplos: Arquivos .dot (Microsoft Word) ou .xlt (Microsoft Excel) Por definio, outros tipos de artefatos no possuem templates associados
Relao Entre os Elementos do UP

Um papel responsvel por um ou mais artefatos Um artefato de responsabilidade de um nico papel Um papel executa uma ou mais atividades Uma atividade executada por um nico papel Um artefato entrada para uma ou mais atividades Um artefato criado por uma nica atividade Um artefato modificado por uma ou mais atividades
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 86
FAT
Relao Entre os Elementos do UP

Uma macroatividade agrupa uma ou mais atividades Uma atividade agrupada em uma ou mais macroatividades Uma disciplina agrupa um conjunto de macroatividades e atividades estas so propriedades da disciplina Papis e artefatos no so propriedade de disciplinas
Um papel pode executar atividades de disciplinas distintas Artefatos podem ser utilizados ou modificados por atividades de disciplinas distintas, embora sejam criados por uma nica atividade de uma disciplina em particular, o que permite sua classificao por disciplina
Estrutura do UP
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 87
FAT
RUP: O UP Comercial
Os analfabetos do sculo XXI no sero os que no sabem ler e escrever, mas os que no sabem aprender, desaprender e reaprender. Alvin Toffler, autor de Future Shock
O processo desenvolvido pela Rational IBM.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 88
FAT
Rational Unified Process - RUP

O Rational Unified Process uma implementao refinada do UP, comercialmente disponvel na forma de um conjunto de pginas em HTML. Ela foi elaborada para utilizar como ferramenta de apoio a Suite da Rational.
Existem uma serie de variantes comerciais do UP. Se pensar em termos de objetos, a UP uma classe de um processo de desenvolvimento de software e as variantes comerciais so subclasses da classe UP. Isso significa que as variantes possuem as mesmas caractersticas que o UP, modificam algumas (polimorfismo) e acrescentam algumas. A variante mais famosa o RUP. Como o RUP e o UP so muito semelhantes, podemos dizer que o UP o processo aberto enquanto que o RUP comercial e fortemente relacionado com os produtos da Rational Corporation. Tanto o RUP quanto o UP implementam disciplinas, papis e atividades, porm, a representao diferente entre eles. No entanto, h pouca diferena na implementao das disciplinas.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 89
FAT
Estrutura do RUP
As diferenas entre o UP e o RUP: Quanto ao objetivo e s caractersticas no existe diferena. A Dimenso Dinmica a mesma, porm na dimenso esttica acrescentam-se elementos. Alm das disciplinas do UP, acrescentam-se as disciplinas de suporte e outras que complementam as disciplinas de engenharia.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 90
FAT
Quanto a Disciplina
O conteudo das disciplinas temos que o fluxo de atividade, macroatividades e atividades encontram-se mais refinados. E alguns casos desenvolver o artefato e realizar a atividade facilitado utilizando as ferramentas da Rational. Alm de atividades, papis e responsabilidades descreve: Conceitos: textos que contm definies, idias importantes Guias: Tcnicas, regras para se executar atividades ou construir artefatos Mentores de ferramentas: normas e padres para uso de ferramentas Roadmaps: guias para utilizao do framework do processo para resolver problemas especficos ou adapt-lo a projetos com caractersticas definidas
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 91
FAT
Fluxo de Atividade das disciplinas do RUP

No se pode conhecer as partes sem conhecer o todo, nem conhecer o todo sem conhecer as partes. Pascal
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 92
FAT
Modelagem de Negcio
A modelagem de negcio ajuda a entender a estrutura e a dinmica da organizao na qual o sistema ser implantado. Permite entender os problemas correntes na organizao e identificar melhorias em potencial. Ter certeza que clientes, usurios finais e desenvolvedores tenham uma linguagem em comum para compreender a organizao. Facilita a derivao dos requisitos do sistema necessrias para apoiar a organizao. A fim de que tudo isto seja possvel, as atividades na modelagem de negcio descrevem como desenvolver a viso da nova organizao e baseada nesta viso definir os processos, responsabilidades e papis em modelo de casos de uso e objeto do negcio.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 93
FAT
Requisitos
Apesar de muitas definies de requisitos de software terem sido utilizados ao longo dos anos, a de Dorfman and Thayer (1990) se destaca: A capacidade do software de resolver um problema de forma objetiva para o usurio. A capacidade do software que um sistema ou um componente do sistema deve ter para satisfazer um contrato, padro, especificao ou outra documentao formal. Assim o gerenciamento de requisitos um processo sistemtico de elucidar, organizar e documentar os requisitos de sistemas complexos. Para maiores informaes recomendamos a seguinte bibliografia: Managing Software Requirements A Unified Approach - Dean Leffingwell e Don Widrig - Addison-Wesley - 2000
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 94
FAT
Anlise e Projeto
O objetivo da anlise e projeto modelar o software. As atividades principais atividades so: Desenvolver o modelo do projeto baseado nos requisitos: A entrada principal para esta atividade o modelo de requisitos. Este modelo inclui o diagrama de classe, sequencia, colaborao estado e componente. Definir e desenvolver uma arquitetura robusta para o sistema: Prticas mostram que um bom caminho para desenvolver o software definir a arquitetura para o seu sistema primeiro e depois detalhar o modelo e implementar baseada nesta arquitetura. O projeto da arquitetura deve refletir tanto os requisitos do sistema quanto a arquitetura existente da organizao. Adaptar o projeto para o ambiente de implementao: O projeto no deve somente refletir os requisitos, tambm deve refletir o ambiente da organizao. Por exemplo, num ambiente que no existe infra estrutura de rede e nem pretende ter no adianta projetar um sistema cliente/servidor. Finalizar o projeto da interface com o usurio: Embora a prototipao da interface do usurio sej uma importante atividade no workflow de requisitos, o projeto da interface termina na anlise e projeto. O objetivo do prottipo da interface na fase anterior, entender os requisitos para o software e comunicar o seu entendimento sobre estes requisitos.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 95
FAT
Implementao
O objetivo da implementao escrever e iniciar o teste do software. Para tanto necessrio documentar o cdigo. Esta atividade possui uma certa resistncia por parte do programador de se realizar, mas a lio nesta hora simples: pense primeiro e depois execute. Depois desse passo necessrio escrever o cdigo, se no pudermos reutilizar algum. Enfim devemos testar o cdigo, existem vrias forma de testar, que so definidas no prximo workflow. Enfim necessrio integrar o trabalho feito pelas equipes de desenvolvimento, o ideal em intervalos regulares, pois podemos verificar se tudo est executando conforme o desejado. O resultado final da integrao se bem feito deve resultar no sistema.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 96
FAT
Teste
Em muitas organizaes, o teste do software equivale de 30% a 50% do custo de desenvolvimento do software. Muitas pessoas acreditam que o software no foi bem testado antes da sua entrega. Esta contradio acontece por dois fatos. Primeiro, testar o software muito difcil. As diferentes formas que um programa pode se comportar so inquantificveis. Segundo, testes so realizados sem uma metodologia clara e sem ferramentas de suporte ou automatizadas. Enquanto a complexidade do software faz com que um teste completa seja impossvel o mercado exige uma produtividade e um teste efetivo.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 97
FAT
Implantao
O objetivo principal da implantao ter certeza que o sistema ser implantado com sucesso. Assim ele descreve as atividades associadas de tal forma a ter certeza de que o produto est disponvel aos usurios finais. A implantao descreve 3 modos de implantao, instalao no cliente, comercializao e acessar software pela internet. Em cada instncia, h uma nfase no teste do produto no local de desenvolvimento, seguido por um beta teste antes do produto ser finalmente entregue para o cliente.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 98
FAT
Gerenciamento de Configurao
O objetivo principal do gerenciamento de configurao controlar a mudanas e manter a integridade dos artefatos do projeto. Assim o gerenciamento de configurao envolve: Identificar os itens de configurao; Restringir as mudanas para estes itens; Auditar as mudanas feitas pelos itens; Definir e controlar as configuraes delas.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 99
FAT
Gerenciamento de Projetos
O gerenciamento de projeto de software a arte de balancear objetivos, gerenciamento de risco e outras limitaes para o desenvolvimento do produto. O objetivo do gerenciamento de projetos no RUP de facilitar a tarefa de gerenciar. No uma receita de bolo de sucesso, mas apresenta uma abordagem para gerenciar o projeto que auxiliaro nesta rdua tarefa. Os objetivos do gerenciamento de projetos so: Providenciar um esqueleto para gerenciar extensiva os projetos de software; Providenciar um guideline prtico para planejar, recrutar, executar e monitorar os projetos; Providenciar um esqueleto para o gerenciamento de risco; No objetivo do RUP, cobrir os pontos a seguir: Gerenciamento de pessoas: contratar, capacitar e treinar; Gerenciamento de custos: definir, alocar, etc.; Gerenciamento de contrato com fornecedores e clientes; O fluxo de trabalho foca em: Gerenciamento de risco; Planejar a iteratividade do projeto, atravs do ciclo de vida do projeto; Monitorar o progresso iterativo do projeto, suas mtricas.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 100
FAT
Ambiente
Seu principal foco so em atividades necessrias para configurar o processo para o projeto. Descreve as atividades de requisitos necessrias para desenvolver os guidelines de suporte ao projeto. O objetivo destas atividades providenciar organizao de desenvolvimento do software um ambiente de desenvolvimento - ambos em processos e ferramentas - que ir apoiar a equipe.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 101
FAT
Caso de Desenvolvimento
... a reflexo tica obriga-nos a procurar, entre as vrias solues possveis, quais so aquelas que correspndemno s a critrios de eficincia e de eficcia, ao equil~ibrio entre custos e benefcios, mas sobreturo a exigncias de prioridade, eqidade, moralidade... G. Berlinguer
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 102
FAT
Adaptando o UP para o projeto

Para utilizar o UP necessrio customiz-lo para a organizao e para cada projeto (caso de desenvolvimento). O processo de customizao envolve a definio e incorporao:
padres da casa; templates de documentos ferramentas: compiladores, CASE, configurao e verso, etc.. banco de dados modificaes no ciclo de vida dos projetos
O UP fornece as diretrizes para o desenvolvimento de um sistema orientado a objetos e considera que cada organizao deve implement-la da forma que melhor se adapte realidade da empresa. muito semelhante ao CMM, a forma de implementao fica por conta da organizao. Da mesma forma, o UP, tambm considera que cada projeto um projeto e assim uma adaptao do processo para cada projeto tambm necessrio. Esta adaptao documentada no artefato, caso de desenvolvimento.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 103
FAT
Passos para a elaborao do caso de desenvolvimento

Analisar o Projeto e a Organizao Definir Escopo Decidir como executar cada disciplina Adaptar artefatos por disciplina Modificar disciplinas e atividades Escolher modelo de ciclo de vida Identificar os envolvidos Mapear papis para Cargos Documentar o Caso de Desenvolvimento
O resultado dos passos acima so documentados no Caso de Desenvolvimento.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 104
FAT
Implantao de um Processo de Desenvolvimento de Software

A verdadeira viagem da descoberta consiste no em buscar novas paisagens, mas em ter olhos novos. Marcel Proust
Passos para a implantao de um PDS

Levantamento da situao atual da empresa:
Anlise da situao atual identificando as principais necessidades da empresa para a implantao do processo de desenvolvimento de software. Definio de pessoas responsveis para a adaptao do processo unificado na empresa. Planejamento da implantao do processo de desenvolvimento de software na empresa, onde sero definidos responsabilidades, papis e atividades.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 105
FAT

Treinamento nas tcnicas:
O objetivo principal deste primeiro treinamento padronizar os conhecimentos das pessoas chaves responsveis pelo desenvolvimento de software. Como existem expectativas e objetivos diferentes entre os vrios atores, os cursos tero mdulos diferenciados para os gestores e a equipe operacional de desenvolvimento.

Customizao do Processo para a empresa:
Os membros da equipe de processo da empresa iro adaptar realidade da empresa ao processo definindo:
as fases, tarefas, passos para o desenvolvimento de software; ferramentas; artefatos produto das fases de desenvolvimento; pontos e mecanismos de controle; mtricas; papis e responsabilidades.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 106
FAT

Homologao do processo customizado (desenvolvimento de um projeto piloto):
A equipe de processo da empresa iro validar o processo customizado, desenvolvendo um projeto piloto. O projeto piloto ser desenvolvido utilizando o processo definido na etapa anterior. A equipe de processo deve definir o projeto piloto e anotar os ajustes que o processo ir sofrer. Ao optar por utilizar uma ferramenta CASE e uma linguagem que a equipe no conhea, a equipe precisa receber treinamento da ferramenta/linguagem antes de iniciar o projeto piloto.

Ajustes no processo unificado customizado;
Com a lista de ajustes ao processo, analisar o impacto e definir as alteraes necessrias ao processo unificado customizado.
Processo de Disseminao na empresa

Planejar e realizar uma gesto de mudana com as equipes de desenvolvimento Planejar e realizar o capacitao das equipes de desenvolvimento. Aplicao e acompanhamento do processo em projetos iniciais
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 107
FAT

Foco na melhoria do processo
Desenvolver e manter o processo padro da organizao Desenvolver e manter diretrizes e critrios de adaptao do processo da organizao Realizar projetos pilotos para novas tecnologias Divulgar as atividade de melhoria e desenvolvimento do processo
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 108
FAT
Anexos
A gente pensa porque as coisas no vo bem alguma coisa incomoda. Quando tudo vai bem, a gente no pensa, mas simplesmente goza e usufrui... (Rubem Alves)
O professor, para ajudar o estudante de forma efetiva, e sem atrapalhar sua iniciativa individual, deve levantar as mesmas perguntas e indicar os mesmos passos, uma vez atrs da outra. Assim, em problemas inumerveis temos de levantar a questo: o que desconhecido? Podemos variar as palavras e perguntar a mesma coisa de formas diferentes: o que necessrio e exigido? O que que voc quer encontrar? O que que voc deve procurar? O objetivo destas perguntas fazer com que o estudante focalize a sua ateno no desconhecido (G. Polya, How to Sove it - 1957)
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 109
FAT
S mais um passo ( Antoine Saint-Exupry ) Guillorme pilotava sobre a cordilheira quando seu pequeno monomotor sofreu uma pane, caindo sobre a montanha de neves eternas. Embora no tivesse se ferido gravemente, suas pernas apresentaram profundos cortes e srios ferimentos. Com muito esforo, sentindo fortes dores, ele abandonou a cabine do avio destroado. Ao constatar a extenso dos ferimentos, compreendeu que no teria como sair dali sozinho. Perscrutou o horizonte em todas as direes e s viu solido gelada. Conhecedor da regio, aps rpida anlise, entendeu que seu fim estava prximo, principalmente em razo dos srios ferimentos que sofrera nas pernas. Por um instante sentiu-se tomado de pnico e pela dor de saber que chegava ao fim de seus dias. Pensou na famlia que no tornaria a ver, nos amigos, nas tantas coisas que ainda pretendia realizar e na impotncia de no ter a quem pedir socorro. Depois, j mais conformado, ps-se a pensar sobre as medidas a tomar. No havia nada a fazer no sentido de sobrevivncia, portanto o mais sensato seria deitar-se na neve e esperar que o torpor causado pelo frio tomasse conta de seu corpo, permitindo-lhe ser envolvido, sem dor, pelo manto da morte. Deitado sobre a neve, Guillorme dirigiu o pensamento a seus filhos, que ele no veria crescer e esposa, de quem tanto gostava. Aquele homem de esprito forte, batalhador, lutava consigo mesmo para resignar-se situao. "Meu consolo - pensava ele - saber que eles no ficaro desamparados; meu seguro de vida tem cobertura suficiente para proporcionar-lhes subsistncia por muito tempo. Menos mal! Felizmente tive o bom senso de estar preparado para uma situao destas; to logo seja liberado meu atestado de bito, a companhia de seguros...". Neste instante, Guillorme teve um sobressalto; sua aplice rezava que o seguro s seria pago mediante a apresentao do atestado de bito. Ora, naquele lugar inacessvel, seu corpo jamais seria encontrado; ele seria dado por desaparecido. No haveria, pois, atestado de bito. Passar-se-iam anos de privaes para sua famlia, antes que ele fosse oficialmente considerado morto. Apavorado com essa idia, ele pensou: "A primeira tempestade de neve que cair soterrar meu corpo; nunca iro me achar. Preciso caminhar at um lugar onde meu corpo possa ser encontrado". As dores que sentia eram cruciantes, mas sua determinao era maior. Ele sabia que, ao p da cordilheira, havia um povoado cujos moradores costumavam aventurar-se at certa altura da montanha, para caar.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 110
FAT
A distncia era longa - vrios quilmetros -, mas ele precisava realizar a ltima proeza de sua vida: chegar at onde seu corpo pudesse ser encontrado por um caador. Reunindo todas as foras que ainda lhe restavam, obrigou-se a ficar em p. Foi preciso um esforo hercleo para no cair. Consciente da distncia que teria de percorrer e sabedor de que no podia permanecer naquele local, apesar de seu estado lastimvel, Guillorme estabeleceu a meta de dar um passo. Jogou um passo a frente e disse: "S um passo!". Com extrema dificuldade empurrava a outra perna e repetiu: "S mais um passo!", e de novo: "S mais um passo!". Concentrando toda a sua energia apenas no prximo passo e estabelecendo um forte condicionamento positivo - atravs do comando "s mais um passo" ele caminhou quilmetros pela neve. No se permitia pensar na distncia que ainda faltava percorrer, ou em sua dificuldade para se locomover; concentrava-se apenas no espao a ser vencido pelo passo seguinte. Assim caminhou o dia todo. A tarde j ia avanada quando seus olhos, turvos pela dor e pelo cansao, vislumbraram alguns vultos sua frente; firmou o olhar e percebeu que se tratava de pessoas que olhavam estupefatas, para ele. "Agora eu j posso morrer", pensou, e deixou-se escorregar para o nada. Dias depois, j no hospital, abriu os olhos e a primeira imagem que viu foi a da esposa, a seu lado. Guillorme teve alguns dedos de um dos ps amputados, que foram congelados pela neve. Passou algum tempo hospitalizado, at readquirir foras, mas continuou vivo ainda por muito tempo. Ao narrar esse episdio acontecido com seu amigo, Saint-Exupry relata a determinao desse homem valente e ressalta o fato de que foi a fixao da meta em curtssimo prazo ("s mais um passo") que lhe proporcionou fora e nimo bastante para vencer a dura prova pela qual passava. Tivesse ele pensado na enorme distncia a ser percorrida, na situao fsica precria em que se encontrava, e muito provavelmente no teria encontrado foras para alcanar o objetivo a que se determinou no alto da montanha. Esse exemplo deixa bem clara a importncia da estipulao de metas bem definidas; em curto prazo (s mais um passo); em mdio prazo (chegar ao p da montanha); em longo prazo (ter seu corpo localizado), para a realizao de qualquer objetivo proposto. Se uma emergncia obrig-lo a fazer mudanas nos planos, os ajustes tambm podero ser feitos com pequenos passos complementares. Mas para tanto necessrio saber para onde voc quer ir.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 111
FAT
Assemblia na carpintaria (autor desconhecido) Contam que na carpintaria houve uma vez uma estranha assemblia. Foi uma reunio das ferramentas para acertar suas diferenas. O martelo exerceu a presidncia, mas os participantes lhe notificaram que teria que renunciar. A causa? Fazia demasiado barulho e, alm do mais, passava todo o tempo golpeando. O martelo aceitou sua culpa, mas pediu que tambm fosse expulso o parafuso, dizendo que ele dava muitas voltas para conseguir algo. Diante do ataque, o parafuso concordou, mas por sua vez, pediu a expulso da lixa. Dizia que ela era muito spera no tratamento com os demais. A lixa acatou, com a condio de que se expulsasse a trena, que sempre media os outros segundo a sua medida, como se fora a nica perfeita. Nesse momento entrou o carpinteiro, juntou o material e iniciou o seu trabalho. Utilizou o martelo, a lixa, a trena e o parafuso. Finalmente, a rstica madeira se converteu num fino mvel. Quando a carpintaria ficou novamente s, a assemblia reativou a discusso. Foi ento que o serrote tomou a palavra e disse: - Senhores, ficou demonstrado que temos defeitos, mas o carpinteiro trabalha com nossas qualidades, com nossos pontos valiosos. Assim, no pensemos em nossos pontos fracos, e concentremo-nos em nossos pontos fortes. A assemblia entendeu que o martelo era forte, o parafuso unia e dava fora, a lixa era especial para limar e afinar asperezas e a trena era precisa e exata. Sentiram-se ento como uma equipe capaz de produzir mveis de qualidade. Sentiram alegria pela oportunidade de trabalhar juntos. Ocorre o mesmo com os seres humanos. Quando uma pessoa busca defeitos em outra, a situao torna-se tensa e negativa. Ao contrrio, quando se busca com sinceridade os pontos fortes dos outros, florescem as melhores conquistas humanas. fcil encontrar defeitos. Qualquer um pode faz-lo. Mas encontrar qualidades e enxergar atributos, isto para os sbios.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 112
FAT
Burrice informatizada "O potencial do computador para acabar com os entraves da burocracia est por ser explorado, e seus limites so desconhecidos"
Ao chegar ao aeroporto de Quito, j faz tempo, aps mostrar o passaporte, um policial uniformizado me pede 80 sucres. Depois da trapalhada para conseguir os sucres, avano para outro soldado com o mesmo uniforme, em uma mesa igualzinha. Este decreta: 80 sucres (deve ser para o outro ministrio). Assim a burocracia por todas as partes. Alis, por que to complicado cobrar a taxa de aeroporto? Quando estava tomando posse como diretor da Capes, fui ver como tramitavam os pedidos de bolsa de estudo. Olhando um formulrio, lembreime de que havia visto outro parecido na sala ao lado. Perguntei por que um segundo com a mesma funo. Coa a cabea o chefe e admite: ", realmente no serve para nada". Assim a burocracia. Ou pede o que no precisa ou tudo feito para facilitar a vida de quem opera e no de quem precisa de seus servios. A burrice impera, a inteligncia passou longe. No sei se ainda h um papel chamado "requerimento". Algum quer um documento oficial e paga por ele. Qual a razo de declarar por escrito que quer o tal documento? Entra a informtica para salvar o mundo da burocracia cretina. O computador, essa mquina fabulosamente rpida e verstil, posto a servio de todos os procedimentos administrativos. Tudo ser informatizado. Fui renovar minha carteira de habilitao. Atendimento impecvel, mooilas gentis e competentes, tudo informatizado. Mas, enquanto esperava o curso dos acontecimentos, comecei a perceber que havia sido informatizada a mesma burrice de sempre. Passou-se metade do servio para o computador, mas no desapareceu a abundncia de papeis inteis, duplicando, triplicando informaes, em grande parte, tambm inteis. At h pouco tempo, o dono de faculdade que quisesse saber do MEC o andamento de algum pedido seu tinha de pagar a impresso da pgina que daria a informao. Mas pagamento, s depositando 25 centavos no longnquo Banco do Brasil. Para consertar, preciso repensar da estaca zero a burocracia do papel. Se no for assim, simplesmente somamos burocracia do papel mais uma etapa informtica.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 113
FAT
A Gol fez tudo certo. Cronometrei o tempo para emitir uma passagem, carto de embarque e etiqueta de bagagem a partir de um aviso de pagamento, o chamado PTA: menos de dois minutos. Na companhia ao lado, foram trs a quatro para tirar a passagem e mais dois em outro balco para o check-in (alm do tempo em uma segunda fila). Baniram-se a burrice, o papel e a espera, todos inteis. Se, antes de informatizar, algum no perguntar "para que serve esse papel (ou a informao nele contida), e o que acontece se for eliminado?", o computador passa a ser um mero gerenciador de uma papelada imbecil. O potencial do computador para acabar com os entraves da burocracia est por ser explorado, e seus limites so desconhecidos. No caso do Detran, todos os papis poderiam ser dispensados, a fila eliminada (pela marcao do atendimento por telefone ou pela internet), o pronturio iria para a clnica pela internet e o pagamento seria por carto de crdito ou cheque. Na verdade, tudo, menos os exames de sade e de habilidade ao volante, poderia ser feito pela internet (quem no a tem usaria a do despachante). Mas no temos o monoplio da burrice. Nos hospitais americanos, a capacidade de diagnstico e tratamento est pelo menos trs dcadas frente da informatizao. Como os mtodos de armazenamento de dados so medievais (at na mo e em guardanapo se fazem anotaes), a informao no pode ser recuperada e tem de ser coletada mltiplas vezes (a um custo extorsivo para o paciente). Do ponto de vista de segurana, no h mais razo para guardar papel. Empresas de Wall Street que foram pulverizadas em 11 de setembro retomaram suas operaes financeiras menos de duas horas depois, graas a backups em dois Estados diferentes. Portanto, a soluo para lidar com a burocracia no o computador, mas a inteligncia, o pragmatismo e a coragem para fazer o certo e no o de sempre. O computador vem depois, para informatizar o necessrio e no o suprfluo. Claudio de Moura Castro economista (claudiomc@attglobal.net) Fonte: Revista Veja 17/04/2002
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 114
FAT
Quem no escreve bem... perde o trem! Certa vez, um apressado gerente de uma grande empresa precisava ir ao Rio de Janeiro para tratar de alguns negcios urgentes. Como tivesse muito medo de viajar de avio, deixou o seguinte bilhete para a sua recmcontratada secretria: Maria: devo ir ao Rio amanh sem falta. Quero que voc me rezerve, um lugar, noite, no trem das 8 para o Rio. Sabe o leitor o que aconteceu? O gerente simplesmente, perdeu o trem! Por qu? Bem, acontece que Maria, a nova secretria, ao ler o bilhete, franziu a testa e, com uma cara desanimada e cheia de dvidas, ficou pensando, pensando... at que finalmente, decidiu: foi, noite, estao ferroviria e reservou um lugar, para o dia seguinte, no trem das 8h. da manh. Cumprida a tarefa, Maria foi para casa, com um sorriso nos lbios e muita alegria na alma, contente por ter resolvido bem o primeiro problema em seu novo tabalho. Mas... a sua alegria ia durar pouco! Ao chegar ao emprego, no dia seguinte, a dedicada secretria teve a estranha impresso de estar vendo um fantasma diante de si: l estava o gerente, tranqilo, fumando o seu perfumado cachimbo e assinando papis, em meio a lentas e gostosas baforadas. Passado o primeiro susto, a perplexa Maria balbuciou: - O senhor... ainda por aqui? - Ento, o que que voc acha? Onde que eu deveria estar? resmungou maquinalmente o gerente, enquanto, sem levantar a cabea, continuava assinando papis e cachimbando. - Mas... mas... o senhor no ia para o Rio hoje? - Ia, no... eu vou para o Rio hoje. Hoje noite, no mesmo? No lhe pedi, ontem, para comprar uma passagem no trem das 8 de hoje noite? Pois ento... continuou o gerente, falando entre os dentes, mordendo o cachimbo, com a cabea enfiada nos papis. Atnita, a secretria, como fulminada por um raio, desabou na cadeira, diante de sua mesa de trabalho. Depois, pouco a pouco, foi recobrando os sentidos e recuparndo as cores do rosto, ao mesmo tempo que ia disfaando o mal estar, arrumando papis e limpando caprichosamente a mesa com um pano mido. - Ento, Maria, tudo certo com o trem das 8, hoje noite, no mesmo? insistiu o gerente, mordendo o cachimbo. - Oi? retrucou a secretria, aparentemente calma. - Estou perguntando a voc: tudo certo com o trem do Rio? retomou o j intrigado gerente, levantando a cabea e encarando a enigmtica moa. - Oi?
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 115
FAT
- Oi, oi, oi, que mania de oi essa! Voc no pode responder direito, como gente? Afinal, cad a passagem? gritou o agora irritado gerente, que j no mais cachimbava. - Passagem? Mas... que passagem? O senho s pediu para reservar um lugar... Ah! J ia esquecendo: olhe, o senhor no leve a mal, por favor, mas... reservar se escreve com s e no com z... explicou Maria, com um ar de professora, sorrindo e piscando muito os olhos. - Escute aqui, moa: no preciso de suas lies! Sei muito bem como as palavras se escrevem! Seus comentrios so perfeitamente dispensveis. Alis... essa histria de reservar com s ou com z no me refresca nada, agora! O que eu quero simplesmente a minha passagem para o Rio, poxa! Pode ser? - No, infelizmente, no pode ser, porque... reservar um lugar uma coisa e comprar uma passagem j outra bem diferente... Foi ento que o gerente esmurrou a mesa e berrou a plenos pulmes: - Cheeeeeeeega, pelo amor de Deus! Isso j est virando uma palhaada! Olhe aqui, mocinha: ontem, eu deixei um bilhete, pedindo para voc me comprar uma passagem para o Rio, no trem das 8, de hoje noite! Foi s isso que eu pedi. T claro? Mais claro do que isso da... impossvel!! Impertubvel, retrucou a valente secretria: -No, seu gerente, no est claro! O senhor est completamente enganado! No foi nada disso que o senhor escreveu a! Leia, por favor! Olhe aqui: o senhor me pede para reservar... reservar com s, o senhor sabe, n? Ento, continuando: o senhor me pede para reservar um lugar, noite... olhe aqui, seu gerente, veja bem, o senhor at sublinhou, grifou duas vezes as palavras reserve e noite, certo? Bom, continuando: o senhor me pede, aqui no bilhete, para reservar, noite, um lugar no trem das 8 para o Rio, t? E como o senhor deveria viajar no dia seguinte, ento eu fiz exatamente, veja bem, exatamente o que o senhor mandou: fui noite, e pedi uma reserva, para o dia seguinte, no trem das 8 da manh para o Rio. Era s o senhor chegar hoje l, na Estao, um pouquinho antes das 8, comprar a passagem, entrar no trem, pegar o seu lugarzinho bem gostoso, no meio do vago, lado da janela e... pronto! Fechava os olhos, dava uma boa cochilada e... de repente... o senhor acordava de cara para aquela lindeza de paisagem, o Corcovado, as praias... a, aquilo bom demais! De p, boquiaberto, plido, o gerente deixou o cachimbo cair sobre os papis espalhados na mesa.
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 116
FAT
- Eh, espere a, que cara essa, seu gerente? O que que o senhor tem? No est passando bem? Quer que eu chame um mdico? - Mdico... coisa nenhuma! Voc vai comprar essa passagem agora, j, no trem das 8 da noite para o Rio! J, ouviu? Antes que eu faa um estrago por aqui! Mais que depressa, a secretria saltou sobre o telefone e ligou para a estao. Esforo intil: o trem da noite estava lotado. Desta vez, foi o gerente que desabou na cadeira, a cabea entre as mos, chorando convulsivamente e lamentando-se: - Meu Deus do cu, que mal que eu fiz pra sofrer assim? Onde foi que eu errei? Me explique, Maria, por favor, eu lhe suplico: ser que eu escrevo to mal assim? Meu bilhete est to claro, to simples... eu s pedi uma passagem no trem das 8 pra o Rio e veja o que voc me aprontou! Agora, eu vou perder um dos nossos melhores clientes l no Rio! O que que vou fazer, voc pode me explicar? Eu no entendo, francamente, eu no entendo: todo mundo na firma j est cansado de saber que eu no gosto de viajar de avio, que eu s viajo de trem noturno, que sempre me reservam uma cabina com leito, que eu adoro viajar em cabina com leito... poxa, mas onde foi que eu errei? Cautelosa, a secretria aproximou-se do gerente, devagarinho, e, pouco a pouco, com jeito, comeou a afagar a sua cabea, enquanto explicava maternalmente: - Mas ser que era preciso dizer mais alguma coisa? Estava tudo to claro, to bvio na minha cabea... ser que a sua cabea assim to diferente da minha, que voc no capaz de entender uma idia to simples? - Bem, j que o senhor perguntou, ento eu explico: olhe, seu gerente, as nossas cabeas so muito diferentes sim, claro! Alis, no existem duas cabeas iguais nesse mundo: o senhor tem certas idias na sua cabea, eu tenho outras, o vizinho da sala ao lado j tem outras bem diferentes, e assim por diante. Se a pessoa no explicar direito o que ela quer, ningum vai adivinhar, porque os pensamentos no esto grudados na testa da gente, eles esto dentro da nossa cabea e ns temos de saber colocar para fora essas idias. O senhor, por exemplo, queria que eu comprasse uma passagem, para o Rio de Janeiro, no trem das 8 da noite, cabina com leito, no mesmo? Mas acontece que o senhor no conseguiu passar essa idia para a minha cabea, porque, pelo seu bilhete, eu entendi outra coisa, completamente diferente da que o senhor tinha na cabea. Quer ver? Vamos comear por este trecho: (...) me rezerve, um lugar, noite (...) Bem, o senhor j sabe que reservar com s, mas deixe pra l, no isso que importa agora. H erros mais graves aqui. Em primeiro lugar, se o senhor queria que eu comprasse uma passagem, o certo, ento era escrever: compre uma passagem ou providencie uma passagem!
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 117
FAT
Segundo problema: O senhor no fala em cabina com leito, mas em lugar; ora lugar uma palavra que pode significar muita coisa, ao mesmo tempo: pode ser uma poltrona de 1. ou de 2. Classe, no meio ou na ponta do vago, do lado da janela ou do corredor, e pode ser at uma cabina com leito! Terceira falha, e esta de sintaxe... - De sinta... de sintaxe? E eu vou l me lembrar das regras dessa maldita anlise lgica? - No, seu gerente, sintaxe no trata s de anlise lgica... sintaxe a parte da gramtica que cuida da ordem e das relaes das palavras na frase, das relaes entre as frases, perodos. Estou falando bonito, no ? que eu ando estudando seriamente a lngua portuguesa, com um professor muito inteligente (e muito simptico tambm!)... alis, obrigao minha saber corretametne o portugus, seno pra que serve a secretria? Ah, sim, como ia dizendo, a sintaxe do seu recado est bem ruim: Se o senhor observar bem o trecho ... me reserve, um lugar, noite... acho que o senhor no aguenta mais, no? bem, como eu dizia, se o senhor observar bem esse trecho, vai ver que a ordem das palavras e, principalmente, a posio das vrgulas do um duplo sentido frase. O senhor duvida? Ento veja bem: como h uma primeira virgula, separando a forma verbal reserve do objeto direto lugar, e como h uma segunda vrgula logo depois de lugar, o leitor do bilhete pode juntar reserve com noite e pensar que, em vez de reservar um lugar noturno, o senhor, como autor do bilhete mandou reservar noite um lugar... entendeu, seu gerente? Xi... parece que o senhor no est entendendo nada, ou, ento, no gostou da minha explicao, no mesmo? Pode at ser que eu tenha sido meio confusa, mas... vou fzer um esqueminha aqui no papel, pra ficar mais claro o que expliquei... Diante do gerente ainda em prantos, a zelosa secretria traou algumas linhas, escreveu algo e depois exibiu o seguinte esquema: 1 Reservar um lugar noite (= lugar noturno) 2 Reservar noite um lugar - Entendeu agora, seu gerente? A frase tem dois sentidos. Minha cabea foi pelo segundo sentido: por isto que eu fui noite, estao, para reservar o lugar para o senhor. Ah, e uma ltima falha ainda, para terminar. Me diga uma coisa, seu gerente! Se o seu trem era o das 8 da noite, por que que o senhor no escreveu logo: trem das 20 h? O senhor no acha que muita confuso poderia ter sido evitada? Portanto, concluindo: com um bilhete assim, com tantas falhas de sintaxe, de pontuao, de vocabulrio, e at de ortografia, eu nunca ia poder adivinhar as idias que o senhor tinha na cabea! Enxugando as lgrimas e assoando ruidosamente o nariz, o gerente encarou a secretria com um ar quase infantil e perguntou, com a maior inocncia:
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 118
FAT
- Mas, ento, Maria como que eu deveria ter escrito esse bilhete, afinal? - Ora, muito simples. O senhor podia ter escrito assim... ih! Espere um pouquinho... eu queria comentar um pequeno problema. o seguinte: quando a gente escreve 10 horas, 20 horas, etc., preciso colocar a abreviatura correta da palavra horas, isto : h, como manda a gramtica certo? Bom, agora vou mostrar como que acho que o senhor deveria ter escrito o bilhete: Maria: compre, para mim, uma passagem, em cabina com leito, no trem das 20h de amanh (4. feira), para o Rio de Janeiro. Este um bilhete claro. A, eu faria exatamente o que o senhor estava querendo. - s isso, Maria? Terminou a lio? - Quem sou eu pra ensinar pro senhor! Mas j que o senhor perguntou, eu preciso ser bem honesta: no terminou ainda no! Falta s uma coisinha... agora, eu s digo se o senhor no ficar bravo... - O que , Maria, o que que est faltando ainda, poxa? - Bom, eu achei, seu gerente, eu achei que o bilhete estava um pouco seco. Da prxima vez, se o senhor quiser me deixar bem contente, o senhor poderia colocar um por favor ou um muito obrigada, sabe, alguma palavrinha assim, s para me agradar. A gente faz o servio com mais boa vontade. Quer ver como ficaria mais bonito? Veja, seu gerente: Maria: por favor, providencie, para mim, uma passagem, em cabina com leito, no trem das 20 h de amanh (4. feira), para o Rio de Janeiro. Muito obrigado. - , tudo muito bonito, muito claro... mas, agora, no adianta mais nada... eu j perdi o trem e, pior ainda, perdi o cliente... murmurou o gerente, enfiando novamente a cabea entre as mos. -Como no adianta nada? Adianta, sim senhor! O senhor perdeu o trem, perdeu o cliente, porm... porm... aprendeu uma boa lio. Como dizia o meu pai, l no interior onde a gente morava: Quem no escreve bem... perde o trem! proclamou a vitoriosa Maria. Izidoro Blikstein (Fonte: Tcnicas de Comunicao Escrita 2000)
________________________________ FAT/Mrcia Ito
________________________________
_______________________ Pg. 119

Desenvolvimento Apostila

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Desenvolvimento Apostila

Caricato da

Copyright:

Formati disponibili

FAT

Mrcia Ito Mind Technology

Metodologias de Anlise e Desenvolvimento de Sistemas

________________________________ FAT/Mrcia Ito

Mrcia Ito M ind Technology

________________________________ FAT/Mrcia Ito

Mrcia Ito Mind Technology

Metodologia de Ensino baseado no Ciclo da aprendizagem vivencial

Generalizao (Comparar vivncia X empresa)

Processamento (Analisar padres de desempenho)

________________________________ FAT/Mrcia Ito

Ciclo da aprendizagem vivencial

Generalizao (Comparar vivncia X empresa)

Processamento (Analisar padres de desempenho)

________________________________ FAT/Mrcia Ito

Mrcia Ito M ind Technology

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito

Pouco mtodo formal

Mrcia Ito M ind Technology

(IEEE Institute of Electrical and Electronics Engineering):

________________________________ FAT/Mrcia Ito

Mrcia Ito M ind Technology

________________________________ FAT/Mrcia Ito

Mrcia Ito M ind Technology

________________________________ FAT/Mrcia Ito

Mrcia Ito M ind Technology

Metodologia Orientada a Agentes:

________________________________ FAT/Mrcia Ito

DARPA US Defense Advanced Research Projects Agency

Mrcia Ito M ind Technology

Modelos e o Desenvolvimento de Software

________________________________ FAT/Mrcia Ito

Mrcia Ito M ind Technology

Um modelo expresso atravs de uma linguagem:

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito

Benefcios da Modelagem na Engenharia de Software

Do que se trata a engenharia de software?

________________________________ FAT/Mrcia Ito

Engenharia de Software - Definio

________________________________ FAT/Mrcia Ito

Engenharia de Software - Definio

(IEEE Institute of Electrical and Electronics Engineering):

________________________________ FAT/Mrcia Ito

Engenharia de Software - Elementos

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito

Os procedimentos evoluiram para os nossos processos de software.

________________________________ FAT/Mrcia Ito

Paradigma da Engenharia de Software

________________________________ FAT/Mrcia Ito

Metodologia de Desenvolvimento de Software

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito

O que deve ter uma Metodologia de sucesso

________________________________ FAT/Mrcia Ito

Evoluo dos mtodos no desenvolvimento de sistemas

________________________________ FAT/Mrcia Ito

________________________________ FAT/Mrcia Ito