Planejamento e Gerenciamento Iterativo de ... -...

Planejamento e Gerenciamento Iterativo de

Projetos de Software

Hermano [email protected]

Planejamento e Gerenciamento Iterativo

2

Objetivos desta parte• Discutir uma metodologia de

desenvolvimento iterativa e incremental• Apresentar atividades de planejamento de

projetos de software na ótica de um processo iterativo e incremental

• Elucidar dúvidas comuns relacionadas aoplanejamento de projetos iterativos e incrementais ��

��

��


3

Agenda1. Introdução – Motivação e Conceitos

Básicos2. Considerando os Riscos3. Planejamento Iterativo – Planejando as

Fases e Iterações

Introdução

Motivação e Conceitos Básicos


5

Objetivos deste módulo• Apresentar a motivação para

planejamento e gerenciamento de projetos• Apresentar conceitos básicos• Apresentar as características de uma

metodologia iterativa


6

Preocupações do Gerente de TI• Melhorar a qualidade do desenvolvimento

de software• Principais riscos e incertezas no

desenvolvimento de sistemas


7

O que faz um gerente de projetos?

• Aloca recursos• Define prioridades• Coordena as interações com clientes e usuários• Procura manter a equipe de projeto focada na

meta do projeto• Resolve conflitos• Gerencia riscos• Estabelece um conjunto de práticas para

assegurar a qualidade dos artefatos do projeto


8

Qual é o objetivo do gerente de projetos?

��

��


9

Algumas estatísticas• 31% dos projetos são abortados• 53% dos projetos extrapolam o prazo em

mais de 50%• % de projetos que são finalizados dentro

do prazo e custo esperados

– em grandes empresas: 9%– em empresas medianas: 16%– em pequenas empresas: 28%

��


10

��

��

� �� !��

"��#�� $��%��

Conceitos Básicos


12

Parkinson’s effect• O trabalho se expande de modo a

preencher todo o tempo disponível para executá-lo

��&�� &�� '�� (��


13

Modelos de ciclo de vida de software

• Conjunto de fases, atividades, marcos e artefatos que guiam o desenvolvimento, operação e manutenção de um sistema

• Não existem modelos certos ou errados, apenas adequados ou não a uma determinada situação

"��


14

Modelos de ciclo de vida de software

• Força bruta, code and fix, nike-way• Cascata• Espiral• Iterativo• …


15

Modelo Cascata• Um dos mais antigos, e ainda um dos

mais usados!• Várias atividades executadas de forma

sistemática e seqüencial

��

��

!��!��"#�

��$�"#� ��

!��"#�


16

Modelo Cascata• Fixa pontos específicos para a entrega de

artefatos• É simples e fácil de aplicar, facilitando o

planejamento• Na prática, existe uma interação entre as

atividades e cada atividade pode levar a modificações nas anteriores– na maioria dos casos existe interação e

superposição!

• Pressupõe que os requisitos ficarão estáveis• Atrasa a redução de riscos


17

Desenvolvimento cascataatrasa a redução de riscos

Início daintegração

100%

Tempo

Pro

gres

so d

o pr

ojet

o(%

cod

ifica

do)

Deadlineoriginal

��%�&��'�$�!��(�)��*��


18

Modelo Iterativo• Aplicação do modelo cascata iterativamente• As iterações iniciais atacam os maiores riscos

��

�+�

!�

,-

!�

)��*+�,

��

�+�

!�

,-

!�

)��*+�-

��

�+�

!�

,-

!�

)��*+�.

/�0�1


19

Desenvolvimento iterativoantecipa a redução de riscos

100%

Tempo

Pro

gres

so d

o pr

ojet

o(%

cod

ifica

do)

��%�&��'�$�!��(�)��*��

Ciclo de vidatradicional

Ciclo de vidaiterativo


20

Modelo Iterativo• Testes e integração são realizados desde o

início, de forma contínua• Riscos críticos são resolvidos antes que

grandes investimentos sejam realizados• Permite feedback dos usuários desde cedo• Pequenos objetivos, foco em curto-prazo• Progresso é medido de forma mais concreta• Implementações parciais podem ser

implantadas2��3�� *+��

2��3�� *+��


21

Ator• Qualquer coisa que interage com o

sistema• Definem um papel particular• São sempre externos ao sistema• Exemplos:

– um usuário do sistema– outro sistema com o qual o sistema a

ser desenvolvido precisa se comunicar

.��


22

Caso de uso

– Seqüência de ações que incorpora uma funcionalidade específica do sistema, fornecendo um resultado de valor para algum ator.

– Forma específica de uso do sistema através da execução de alguma de suas funcionalidades.

– Conjunto de cenários que capturam requisitosfuncionais do sistema

– Mostram apenas o que o sistema faz, e não como– Capturam o comportamento pretendido para um

sistema, sem a necessidade de especificar como esse comportamento será implementado

.��/��


23

Um exemplo – casos de uso do Qualiti Internet Banking

Operadora do DOC

Operadora cartao de crédito

Realizar transferencia

Consultar cheques

Solici tar taloes de cheque

Desbloquear taloes de cheque

Efetuar Login

Alterar senha

Consultar saldo

Consultar extrato

Consultar Qualiti CardRealizar DOC

Efetuar pagamento do Qualiti Card

Cliente


24

Cenários

• Significa um caminho através de um caso de uso.

• Uma instância de um caso de uso• Exemplo (Sacar dinheiro):

– Saque com sucesso– Tentativa de saque MAS senha incorreta– Tentativa de saque MAS saldo insuficiente


25

Prioridade de casos de uso• Essencial para gerenciar os requisitos• Pode interferir no planejamento das

iterações• A prioridade pode ser:

– Essencial– Importante– Desejável ou Opcional

Uma Metodologia Iterativa e Incremental


27

Apenas a linguagem não basta!

+

++

+Metodologia de

desenvolvimento

Modelos, padrões e guias

Linguagempadrão

Ferramentasde apoio

Equipestreinadas


28

0�%��!��%��"#��!�%/�1�2��2��.�!�

0�%��!��%��"#��!�%/�1�2��2��.�!�

O que é uma metodologia?• Processo de desenvolvimento• Conjunto de métodos e práticas de

desenvolvimento (com orientações nas linguagens, paradigmas, tecnologias e ferramentas utilizadas)


29

Benefícios de uma metodologia• Qualidade de software• Produtividade no desenvolvimento, operação e

manutenção de software• Permitir ao profissional controle sobre o

desenvolvimento dentro de custos, prazos e níveis de qualidade desejados

• Permitir ao profissional estimar custos e prazoscom maior precisão

• Mas… os benefícios não virão de imediato!

2�� 3��2�� 3��


30

Características da metodologia• Inspirada no RUP (Rational Unified Process)

– Processo Unificado de desenvolvimento de software• Conjunto de atividades a serem realizadas para produzir ou

evoluir software– Baseado em boas práticas de desenvolvimento– Framework para processos

• Para usar o RUP é preciso instanciá-lo e definir padrões e guias específicos para a realidade de cada empresa/projeto

�� 4��5�6�� 4��5�6�


31

Características da metodologia• O desenvolvimento de sistemas

seguindo a metodologia é:– Iterativo e incremental– Guiado por casos de uso (use cases)– Baseado na arquitetura do sistema– Orientado a objetos


32

Iterativo e incremental

��

�+�

!�

,-

!�

)��*+�,

��

�+�

!�

,-

!�

)��*+�-

��

�+�

!�

,-

!�

)��*+�.

/�0�1


33

Iterativo e incremental• Em cada iteração:

– são identificados e especificados os casos de uso mais relevantes

– é feita a análise e projeto dos casos de uso, usando-se a arquitetura como guia

– são implementados componentes que realizam o que foi projetado

– verifica-se se os componentes satisfazem os casos de uso escolhidos

• A escolha dos casos de uso é baseada em uma análise dos riscos envolvidos no projeto

• Os casos de uso que apresentam os maiores riscos devem ser realizados primeiro, para resolver os riscos o quanto antes!


34

Guiado por casos de uso (use cases)

• Casos de uso são usados para especificar requisitos

• Durante a análise, projeto e implementação os casos de uso são “realizados”

• Durante os testes, verifica-se se o sistema realiza o que está descrito no Modelo de Casos de Uso

• Casos de uso são usados no planejamento e acompanhamento das iteraçõesRequisitos Testes Implantação

Casos de uso são usados durante todo o processo

Análise e Projeto

Implemen-tação


35

Baseado na arquitetura do sistema

• A arquitetura é prototipada e definida logo nas primeiras iterações

• O desenvolvimento consiste em complementar a arquitetura– A arquitetura guia o projeto e implementação das

diversas partes do sistema• A arquitetura serve para organizar o

desenvolvimento, estruturar a solução e identificar oportunidades de reuso

• Os casos de uso dizem o que deve ser feito e aarquitetura descreve como


36

Orientada a objetos• Análise e Projeto em UML

– UML é uma linguagem usada para especificar, modelar e documentar os artefatos de um sistema

– É um padrão da OMG e têm se tornado o padrãoempresarial para modelagem OO

• Implementação em Java ou alguma outra linguagem de programação OO


37

Conceitos chave da metodologia

• Fases e Iterações• Fluxos de Atividades• Atividades• Artefatos• Modelos• Guias e Padrões• Responsáveis (papéis e perfis, não

pessoas)


38

.��"#� ��7��"#� .��"#� -��"#��7��3�7��8!��

��!��

��%��3��

9��3��3��4��7��

��!7��

Fases e iterações


39

Fases e iterações• O ciclo de vida de um sistema consiste de

quatro fases:

• As fases indicam a maturidade do sistema!

��

4� ��*+� ��(��*+� 4� ��*+� /�� *+�

'��

�� &�� *+� ��


40

0�� 5��

��"#��!��

4� ��*+� ��(��*+� 4� ��*+� /�� *+�

��"#��

��"#��

��"#��3�

��"#��3�

��"#��3�

��"#��"#�

��"#��"#�

Fases e iterações

• Cada fase é dividida em iterações


41

Fluxos de atividades• Agrupam atividades correlacionadas • Fluxos de atividades de suporte:

– Planejamento e gerenciamento– Gerência de configuração e mudanças

• Fluxos de atividades básicos:– Requisitos– Análise e projeto– Implementação– Testes– Distribuição


42

Fases, iterações e fluxos de atividades

Concepção Elaboração Construção Transição

IteraçãoPreliminar

Iter.#1

Iter.#2

Iter.#i

Iter.#i+1

Iter.#i+2

Iter.#n

Iter.#n+1

Requisitos.......................................

Análise e Projeto............................

Implementação...............................Testes.............................................Implantação...................................

Planejamento e Gerenciamento.....

Fluxos de Processo

Fluxos de Suporte

Fases

Iterações

Gerência de Configuração e Mudanças


43

Atividades• Unidade de trabalho• Composta de:

– Objetivos– Passos– Entradas e saídas– Responsável– Guias e padrões


44

Artefatos• Resultantes das atividades• Possuem modelos para

– indicar como devem ser feitos– padronizar os formatos dos documentos


45

Responsáveis

• Representam perfis ou papéis, nãopessoas

Gerente do projeto

Arquiteto

Analista

Programador

Testador

6 �

7��

0��

0��

8��


46

Fluxos de atividadesPlanejamento e Gerenciamento

ContratanteAprovarProjeto

IniciarProjeto Atestar Conclusão

do Projeto

Gerente deProjeto

IdentificarRiscos

DesenvolverPlano de Projeto

DesenvolverPlano de Iteração

Executar Plano deIteração

AvaliarIteração

ReavaliarRiscos

FinalizarProjeto

Arquiteto

Priorizarcasosde uso

DesenvolverEstudo deViabilidade

2. Considerando os Riscos


48

Objetivos desta parte• Introduzir conceitos básicos relacionados

ao gerenciamento de riscos• Discutir o levantamento, análise e

tratamento de riscos• Exercitar o planejamento de iterações de

acordo com os riscos do projeto


49

“Não se preocupe; eu vou pensar emalgo…”, Indiana Jones


50

Gerenciamento de riscos• Relaciona-se com a análise de aspectos

desconhecidos do projeto– são esses aspectos que podem fazer com

que o projeto fracasse!

• Risco– fator, elemento, acontecimento, qualquer

coisa que, se concretizada, pode interferir no sucesso do projeto


51

Gerenciamento de riscos

��%��"#� ��%��"#�

��

��!�� !��

��!�� !��


52

Identificação dos riscos• Para levantar os riscos podemos usar:

– o conhecimento do negócio– estudo de viabilidade, documento de requisitos e

plano do projeto– brainstormings– checklists

• Os riscos podem ser classificados de acordocom sua natureza em:– riscos de projeto– riscos do negócio– riscos técnicos


53

Riscos de projeto• Normalmente ameaçam o plano de projeto,

prejudicando o cronograma e/ou custo• Estão relacionados ao uso de recursos

– organizacionais• financiamento• ambiente de desenvolvimento• processo de desenvolvimento

– humanos• equipe• cliente/usuários

– tempo• cronograma• escopo


54

Riscos do negócio• Normalmente ameaçam a distribuição ou

implantação do produto, prejudicando o retorno do investimento

• Muitos são riscos indiretos


55

Riscos técnicos• Normalmente ameaçam a qualidade do

produto, prejudicando o tempo de conclusão do projeto

• São relacionados ao uso da tecnologianecessária para implementar o sistema


56

Análise dos riscos• Encontrados os riscos, é preciso decidir o

que fazer com eles…• Para tanto, vamos considerar a magnitude

ou prioridade do risco e criar a lista dos “10 mais”

'$��:��77�� ;��!��


57

Estratégias para tratar os riscos• Evitar

– reorganizar o projeto de modo que ele não sejaafetado pela concretização do risco

• Transferir– reorganizar o projeto de modo que outra

pessoa/instituição fique responsável pelo risco

• Aceitar– decidir conviver com o risco


58

Aceitando riscos– Determinar um Plano de contingência (Plano

B)– Estabelecer ações para mitigar ou atenuar o

risco• Muitas vezes, resume-se a uma melhor

investigação de algum ponto específico. Porexemplo:

8�� !��"#��!��3�� #� ��!�� !

8�� !��"#��!��3�� #� ��!�� !

6*+��!��!��!��"#� ��!��3��!��

6*+��!��!��!��"#� ��!��3��!��


59

Acompanhamento e controledos riscos

• Definir um responsável por cada risco ou pelogrupo de riscos do projeto– o “pessimista”

• Monitorar os indicadores– relatórios de status dos riscos

• Deixar o “caminho livre” para notícias ruins• Revisitar a lista de riscos periodicamente

– semanalmente– ao final de cada iteração

��$��<��3� ��!��3�� =��>

��$��<��3� ��!��3�� =��>

Os riscos no planejamentodas iterações


61

Riscos e casos de uso

• A realização dos casos de uso é usadapara eliminar riscos

• Para facilitar a visualização do relacionamento entre casos de uso e riscos, pode-se usar uma matriz de riscos


62

Matriz de Riscos

UC 3

�Risco Z

��Risco Y

�Risco X

UC 4UC 2UC 1


63

Riscos e iterações

?��?��

��!��"@��!��"@��

��"#��"#��

3. Planejamento Iterativo

Planejando as Fases e Iterações


65

Objetivos desta parte• Responder a perguntas comumente feitas durante o

planejamento de projetos iterativos– Como definir a quantidade e duração das iterações em cada

fase do projeto?– O quanto realizar de cada fluxo de atividades em cada

fase/iteração?• Apresentar padrões do ciclo de vida e estratégias para o

planejamento das atividades de projetos iterativos e incrementais

• Conhecer a estrutura de cronogramas iterativos e incrementais

• Discutir um exemplo de planejamento de projeto iterativoe incremental


66

Como definir a quantidade e duração das iterações?

• Iterar é bom, mas acrescenta certo overhead!– planejamento– avaliação– sincronização de atividades

• A agilidade para iterar depende basicamente de:– tamanho da equipe– experiência com o processo

• A complexidade e conhecimento do produtotambém pesam– padrões de ciclo de vida


67

Padrões de ciclo de vida• Ferramenta para auxiliar no planejamento

das fases• Dependem das características do projeto• Exemplos:

– Incremental– Entrega incremental– Evolucionário– Híbridos


68

Para começar, não esqueça!

.��"#�

��7��"#�

-��"#�

��7��3��

.��"#�

��

1��A7��B��C

��A��C


69

Ciclo de vida incremental• O domínio do problema é conhecido,

familiar• Os riscos estão bem entendidos e

razoavelmente controlados• A equipe é experiente

C E B B B B T T


70

Ciclo de vida evolucionário• O domínio do problema é novo ou

desconhecido• A equipe é inexperiente

C E E E E B T T


71

Entrega incremental– O domínio do problema é conhecido, familiar– Os requisitos e a arquitetura podem ser

estabilizados bem cedo, durante o desenvolvimento (não existe muita novidadeno sistema)

– A equipe é experiente– É preciso liberar Releases incrementais do

produtoC E B T T T T T


72

“Grande Projeto”– Um pequeno conjunto de funcionalidades vai

ser adicionado a um produto já estável– As novas funcionalidades são bem

conhecidas e entendidas– A equipe é experiente, tanto no domínio do

problema quanto no produto já existente

C E B T T


73

Estratégias Híbridas– Na prática, poucos projetos seguem apenas uma

dessas estratégias de ciclo de vida– A regra geral é:

• para sistemas onde existe alto risco associado ao negóciodo desenvolvimento:

• para sistemas complexos ou onde não se tem domínio do problema:

• para sistemas onde se espera maior complexidade/esforçona produção de código:

• para sistemas onde é preciso entregar o produto em umasérie de releases incrementais:

D�%�� .��"#�

D�%�� .��"#�

D�%�� 7��"#�

D�%�� -��"#�


74

Quantidade de iterações– Projetos simples: 3/4 iterações [0/1, 1, 1, 1]– Projetos típicos: 6 iterações [1, 2, 2, 1]– Projetos grandes: 10 iterações [2, 3, 3, 2]

– Resumindo…

�� .��,9��*:��

$��;��<��*:��

�� .��,9��*:��

$��;��<��*:��


75

Duração das iterações

• Normalmente variam de fase para fase, de acordo com as características do projeto– Iterações pequenas são típicas da Construção, com

pouca ou nenhuma atividade formal de análise e projeto

– Iterações grandes demandam marcos (milestones) intermediários

• O tamanho da equipe e sua experiência com o processo é um dos fatores determinantes


76

Duração das iterações• Alguns dados da Rational:

1 ano1001.000.000

6 meses45500.000

1 mês1550.000

1 semana510.000

Duração de 1 iteraçãoEquipeLinhas de

código


77

O quanto realizar de cada fluxo de atividades em cada fase/iteração?

• De maneira geral, em cada iteração um subconjunto do trabalho total é realizado– levantado/especificado– analisado e projetado– implementado– testado– preparado para a distribuição/distribuído

• Como escolher esse subconjunto?– conhecimento da equipe no domínio do problema e

arquitetura a ser adotada– necessidade de liberação de releases / deadline

restrito


78

Estratégias para as iterações• Larga e superficial

– Todo o domínio do problema é analisado, massem muitos detalhes

– Casos de uso: todos sãodefinidos e a maioria é detalhada

– Arquitetura: definidaamplamente – todas as interfaces, serviços, etc.

– Muito poucaimplementação até a Construção, onde fica o maior número de iterações

• Estreita e profunda– Um pedacinho do domínio

é analisdo em detalhes– Os casos de uso

relacionados com estepedacinho são detalhados

– A arquitetura necessáriapara suportar essepedacinho é definida

– Esse pedacinho é implementado, testado e possivelmente implantado

#'(��#'(��


79

Larga e superficial• Apropriada quando:

– o time é inexperiente no domínio do problemaou nas tecnologias que serão usadas

– a arquitetura é inédita, ou é um requisitochave para as funcionalidades do sistema

• Possíveis problemas:– analysis paralysis– falta de credibilidade e confiança da equipe– riscos técnicos não expostos devido a falta de

detalhes (visão apenas de alto nível)


80

Estreita e profunda• Apropriada quando:

– precisa-se de resultados muito rápido (para obtersuporte, provar viabilidade ou eliminar certos riscos)

– os requisitos estão continuamente evoluindo– o deadline é obrigatório– existe alta reusabilidade

• Possíveis problemas:– dificuldades de integração

• desenvolvimento de software integrado “verticalmente”, masincompatível “horizontalmente”

– muito retrabalho devido a falta de uma visão geral do problema


81

Estatégia híbrida• Na Concepção:

– larga e superficial para obter bom entendimento do escopo– estreita e profunda para verificar a viabilidade de alguma

tecnologia» construção de um protótipo

• Na Elaboração:– na maior parte do tempo, larga e superficial, para garantir que

a arquitetura cobre todas as necessidades– estreita e profunda em alguns pontos para atacar riscos

específicos• Na Construção:

– estreita e profunda, para implementar as funcionalidades do sistema, com alto grau de paralelismo e incrementalmente

• Na Transição:– completar o que falta, de acordo com o feedback do usuário e

bugs encontrados


82

Cronogramas iterativos e incrementais

• Bem mais complexos que os tradicionaiscronogramas em cascata

• Normalmente organizados por fases e iterações


83


• Concepção– Iteração 1

• atividade X• atividade Y• atividade Z

• Elaboração– Iteração 2– Iteração 3

• Construção– Iteração 4– Iteração 5– Iteração 6

• Transição– Iteração 7

• O cronograma não é feito todo de uma vez!

?�!7��B��4��3�>

?�!7��B��4��3�>


84


– Concepção• Iteração 1

– atividade A– atividade B– atividade C

– Elaboração• Iteração 2

– atividade D– atividade B– atividade E

• Iteração 3– Construção

• Iteração 4• Iteração 5• Iteração 6

– Transição• Iteração 7

– Devido a natureza do processo, váriasatividades vão ficarrepetidas

��3��#� ��!��!��!��!�

��

��3��#� ��!��!��!��!�

��


85

Características do projeto

• Prazo total: 16 semanas• Equipe de 5 pessoas, experiente no

domínio do problema• Equipe relativamente inexperiente no uso

da metodologia– Um dos objetivos do projeto é treinar os

desenvolvedores no uso da metodologia– Apoio de consultoria externa

• Estão previstos 2 releases do produto


86

Planejamento do projeto• Concepção

– Iteração preliminar de 2 semanas, larga e superficial, para“iniciar o projeto”

• Elaboração– 1 iteração, de 5 semanas, para eliminar os principais riscos– Estratégia híbrida: larga e superficial para modelar a

arquitetura e estreita e profunda para eliminar o risco de algunscenários

• Construção– 2 iterações de 2 semanas cada, estreitas e profundas, para

produzir a versao beta do sistema• Transição

– 1 iteração de 2 semanas para finalizar a primeira versão do sistema, com parte das funcionalidades previstas

– 1 iteração de 3 semanas para incorporar as funcionalidadesrestantes e lançar a versão completa do QIB


87

Conclusão – PlanejamentoIterativo

• Conheça os riscos• Planeje as fases

– duração e marcos (milestones)– quantidade de iterações

• Planeje a primeira iteração em detalhes– atividades, recursos, tempo, …

• Durante a execução da primeira iteração, planeje a segunda em detalhes

�� =�� =


88

Outros tópicos interessantes…• Estimativa de esforço

– Técnicas – vantagens e dificuldades• Pontos de casos de uso• Wideband Delphi

• Organização da Equipe– Características de um time vitorioso– Alocação da equipe nas fases

• Sincronização de atividades

• Atividades, artefatos e responsabilidades no Fluxo de P&G

• Implementação de processos iterativos e incrementais


89

Referências bibliográficas– The Unified Software Development Process. Ivar

Jacobson, Grady Booch e James Rumbaugh. Addison-Wesley, 1998.

– Software Project Management: A Unified Framework. Walker Royce. Addison-Wesley, 1998.

– Object-Oriented Project Management with UML. Murray Cantor. Wiley, 1998.

– Managing Risk: Methods for Software Systems Development. Elaine M. Hall. Addison-Wesley, 1998.

– Object Solutions: Managing the Object-OrientedProject (Addison-Wesley Object Technology Series). Grady Booch. Addison-Wesley, 1999.


90

Outras referências

– COCOMO 2: sunset.usc.edu/research/cocomosuite. Center for Software Engineering. Última visita em 8 de outubro de 2001.

– Software Engineering Economics. Barry Boehm. Prentice-Hall, 1981.

– The Deadline: A Novel About Project Management. Tom DeMarco. Dorset House, 1997.

– Applying Use Cases: A Practical Guide. Geri Schneider, Jason P. Winters, Ivar Jacobson. Addison-Wesley, 1998.

– Rational web site: www.rational.com.

Planejamento e Gerenciamento Iterativo de

Projetos de Software

Hermano [email protected]

Planejamento e Gerenciamento Iterativo de ... -...

Documents

Transcript of Planejamento e Gerenciamento Iterativo de ... -...