Projecto Feedback à 1ª Entrega

Apresentação em tema: "Projecto Feedback à 1ª Entrega"— Transcrição da apresentação:

1 Projecto Feedback à 1ª Entrega
ATSI 2007 Projecto Feedback à 1ª Entrega

2 O processo segundo Steven H. Spewak

3 Etapas do Processo segundo Steven H. Spewak
Iniciação: Clarificar o âmbito do projecto, a metodologia, as ferramentas a utilizar, a estrutura da organização e a equipa de projecto... Levantamento dos Processos de Negócio: Fazer um levantamento dos processos de negócio da Organização compreendidas no âmbito do projecto. Alinhamento Estratégico: Antever outras necessidades futuras das unidades organizacionais consequentes da visão estratégia preconizada pela Gestão de Topo da Organização... Tecnologias e Sistemas Correntes: Recensear os principais sistemas informáticos da Organização e as respectivas tecnologias de informação que os suportam... Arquitectura de Informação: Identificar e estruturar a informação que é necessária à concretização do negócio da Organização... Arquitectura de Aplicações: Definir o conjunto de sistemas que permite suportar de uma forma optimizada os processos de negócio, bem como promover uma gestão eficaz da informação, evitando-se assim a sua replicação e a incoerência... Arquitectura Tecnológica: Definir as plataforma tecnológicas necessárias para suportar os sistemas propostos na Arquitectura de Sistema... Plano de Migração e Implementação: Identificar as iniciativas necessárias à implementação do projecto, do âmbito tecnológico, do âmbito organizacional e humano e do âmbito da gestão e qualidade do projecto...

4 O processo e o projecto de ATSI
Iniciação Levantamento dos Processos de Negócio Alinhamento Estratégico Tecnologias e Sistemas Correntes Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica Plano de Migração e Implementação O relatório de projecto

5 O que deveria ter sido feito para a 1ª entrega...
Arquitectura Organizacional Orgânica dos sPOSI, distribuição territorial, contexto (com stakeholders), ... Representar como Diagramas UML (Use Cases, Classes, Objectos, ...), ou de outra forma qualquer equivalente... Arquitectura de Processos (1ª versão) Descrição dos processos, em texto de contexto... Descrição estruturada dos processos segundo template uniforme Descrição em diagrama BPMN ou diagramas de actividade UML

6 Recomendações para o resto do projecto

7 Formato do Relatório Usar um formato claro, independente do enunciado (sim, foi sugerido inicialmente usar-se fielmente o enunciado, mas parece que há quem siga isso demasiado à risca e nem sempre acaba por funcionar bem, criando resultados confusos...) Cada grupo pode escolher o formato que achar melhor se adapta ao seu relatório... MUITO IMPORTANTE: O relatório final não deve ser no entanto apenas um complemento ao enunciado, mas sim um ”deliverable” de projecto completo. Isto é, devem figurar no relatório TODOS os elementos importantes de descrição do problema e seu contexto, especialmente os objectivos e requisitos que já estejam no enunciado!!! O que não interessa ter no relatório final são as explicações complementares do enunciado sobre a metodologia, prazos de entrega, etc. O relatório deve ser escrito já pensando no momento final (altura em que o trabalho está terminado e entregue ao cliente) e não como documento intermédio com várias fases de entrega ao cliente (nesse caso seria importante ter então uma história do documento, uma descrição do planeamento do trabalho, etc.). Vejam assim as entregas intermédias como entregas internas dentro da empresa do consultor (entregas ao chefe...), e não como entregas ao cliente!

8 Proposta de Formato do Relatório
Uma possível estrutura recomendada pode ser: Resumo Executivo Metodologia Descrição do problema Objectivos de Negócio e Requisitos Arquitectura Organizacional Arquitectura de Processos Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica Arquitectura de Serviços (perspectiva SOA) Plano de implementação Glossário

9 Proposta de Formato do Relatório
Uma possível estrutura recomendada pode ser: Resumo Executivo Metodologia Descrição do problema Objectivos de Negócio e Requisitos Arquitectura Organizacional Arquitectura de Processos Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica Arquitectura de Serviços (perspectiva SOA) Plano de implementação Glossário 1 a 2 páginas de resumo... Descrição RESUMIDA em 3 a 4 páginas (mais ou menos como está no enunciado), com uma secção final descrevendo a restante estrutura do documento

10 Proposta de Formato do Relatório
Uma possível estrutura recomendada pode ser: Resumo Executivo Metodologia Descrição do problema Objectivos de Negócio e Requisitos Arquitectura Organizacional Arquitectura de Processos Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica Arquitectura de Serviços (perspectiva SOA) Plano de implementação Glossário Introdução textual descritiva caracterizando os sPOSI, o seu contexto, objectivos gerais de negócio, etc. Copiar o que interessar do enunciado! Não formalizar ou detalhar demais os requisitos, pois isso deve ser feito de forma estruturada em local próprio (neste caso já a seguir)!

11 Proposta de Formato do Relatório
Uma possível estrutura recomendada pode ser: Resumo Executivo Metodologia Descrição do problema Objectivos de Negócio e Requisitos Arquitectura Organizacional Arquitectura de Processos Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica Arquitectura de Serviços (perspectiva SOA) Plano de implementação Glossário Apresentar de forma estruturada objectivos de negócio e requisitos, apresentados em pontos próprios, com identificadores para cada elemento relevante, ... Termos ou expressões que necessitem de uma descrição clara para qualquer leitor do documento.

12 Proposta de Formato do Relatório
Uma possível estrutura recomendada pode ser: Resumo Executivo Metodologia Descrição do problema Objectivos de Negócio e Requisitos Arquitectura Organizacional Arquitectura de Processos Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica Arquitectura de Serviços (perspectiva SOA) Plano de implementação Glossário 1ª Entrega! 2ª Entrega (rever tudo o que foi feito anterior) 3ª Entrega (rever tudo o que foi feito anterior) Ir fazendo e revendo em cada entrega...

13 Formato do Relatório MUITO IMPORTANTE:
O RELATÓRIO TEM DE TER UM ÍNDICE DETALHADO!!! É impossível ler-se um documento destes sem um índice RELEVANTE... Com pontos (títulos, sub-títulos, etc..) numerados... ...

14 Sobre Identificadores
MUITO IMPORTANTE: Tudo o que seja um elemento relevante de informação no relatório, condicionante ou resultado de decisão (requisito, objectivo de negócio, unidade orgânica, entidade de informação, processo, sistema, etc.) DEVE TER UM IDENTIFICADOR próprio. É por isso importante definir um espaço de identificação para cada classe de elemento! Sempre que relevante, devem-se organizar índices desses elementos. Não deve ser prático organizar índices de requisitos, pois estes pela sua natureza são já de conteúdo/descrição curta (o que faria com que um índice fosse quase do mesmo tamanho do que a própria secção de descrição), mas já pode fazer sentido criar índices de: processos eventos de entrada e de saída entidades de informação aplicações serviços ...

15 Sobre rastreabilidade
É muito importante para a rastreabilidade que se façam no relatório referências cruzadas entre elementos, através dos seus identificadores. Concretamente, em cada ponto do relatório incluir sempre que relevante matrizes de relação: Arquitectura de Processos: objectivos/requisitos x processos (WHY) actores/unidades orgânicas x processos (WHERE, WHO) Arquitectura de Informação entidades x processos (WHAT) objectivos/requisitos x entidades Arquitectura de Aplicações processos x aplicações (HOW / WHO) entidades x aplicações Arquitectura de Serviços processos x serviços (HOW / WHO) entidades x serviços serviços x aplicações Arquitectura Tecnológica aplicações x tecnologia requisitos não funcionais x tecnologia

16 Sobre descrição dos processos
Utilizar templates simples!!! Uma tabela basta! Não utilizar templates em que a descrição do processo se reparte por várias tabelas. É muito pouco prático (sim, é verdade que há trabalhos recomendados de anos anteriores com templates dessas, mas o resultado disso é mesmo pouco prático!!!)

17 Sobre descrição dos processos
Não basta “despejar” as coisas para o papel. É preciso ter método também na sua apresentação, de modo a criar uma forma fácil, objectiva e agradável de apreensão pelo leitor. Formas ideais de apresentar um processo (de qualquer nível): Opção 1: Tudo em 1 página, com descrição em texto (curta), 1 quadro em cima descrevendo o processo e 1 o respectivo diagrama BPMN abaixo Opção 2: Tudo em 2 páginas, com descrição em texto (curta), com quadro descrevendo o processo em 1 página, e mais 1 página com o respectivo diagrama BPMN. Nota geral: Para além disto, criar diagramas gerais com processos de alto nível...

18 A eterna questão: Com que detalhe se devem representar os processos/actividades? Resposta: não é preciso detalhar uma actividade se a execução INTERNA da mesma não contiver nenhuma regra de negócio relevante ou pontos relevantes... sobre pontos relevantes 

19 Pontos relevantes Control Point (Ponto de controlo): É um ponto de um processo em que se pretende medir indicadores de negócio. É importante para permitir aferir do alinhamento do processo com objectivos/requisitos (se e leitura do ponto for quantificável, o alinhamento também poderá ser desta forma quantificado). Break Point (Ponto de quebra): É quando um processo cruza diferentes unidades orgânicas. São importantes para detectar possíveis problemas da Arquitectura Empresarial. Ex.: uma actividade A antecede a actividade B e a A é da responsabilidade de alguém que reporta a X e a B é da responsabilidade de alguém que reporta a Y. Neste caso, se algo correr mal, há sempre o cenário potencial de A reportar a X que a culpa é de B, e B vai reportar a Y que a culpa é de A... no contexto de duas actividades executadas em contextos diferentes, uma mesma entidade é interpretada de forma incoerente. Critical Point (Ponto crítico): É um ponto de quebra inter-organizacional (que cruza a fronteira da organização).

20 Sobre a Arquitectura de Aplicações
Importante: Para propor esta arquitectura os grupos devem identificar no mercado produtos de referência (SAP, Navision, família de produtos ORACLE, SAS, Primavera, etc.) e propor uma solução com base nas funcionalidades dos mesmos. Apenas em casos extremos se deve propor aplicações novas a desenvolver. Os armazéns dos sPOSI têm actualmente SIs. Cada grupo é livre de considerar reutilizar esses SIs, ou deitá-los fora e usar outras soluções quaisquer...

21 Sobre Arquitectura Tecnológica
Novidade: Os sPOSI estão a ponderar obrigar todos os fornecedores a ter os seus produtos identificadores com RFID. Sugere-se aos grupos que considerem este requisito se assim o entenderem... Os sPOIS estão a ponderar automatizar os armazéns com prateleiras robotizadas. Não esquecer que os supermercados têm POS (onde são efectuadas as transacções das vendas), sistemas de etiquetagem (impressa ou digital – o Pingo Doce já tem umas coisas destas digitais...), equipamento de leitura de entrada e saída dos produtos dos armazens, etc.

22 Sobre Arquitectura de Serviços
...Segundo o paradigma “convencional”, os processos são suportados por aplicações. Entretanto a administração dos sPOSI tomou conhecimento de um novo paradigma emergente SOA, e está interessada em ter uma proposta alternativa... Esta arquitectura deve ser vista como uma proposta alternativa ao caminho anterior da solução de aplicações e tecnologia. Esta arquitectura deve por isso ser vista a dois passos: Mapeamento dos processos em serviços (obrigatório) Mapeamento dos serviços em aplicações e tecnologia (opcional, para os grupos que procurem alguma excelência no projecto)

23 Boas Práticas Evitar repetir informação no relatório! Cada coisa deve ser dita e apresentada apenas uma vez e apenas num sítio. Repetir coisas (requisitos, processos, etc.) é: Um desperdício de espaço e de atenção para quem tem de ler…) Uma fonte potencial de incoerência no resultado final (se tiverem de alterar algo, podem alterar apenas num lado e esquecer o outro…). Evitar por isso duplicar desnecessariamente informação no relatório (se o tiverem de fazer, tentem usar as funcionalidades do EA ou do editor de texto para fazer isso por referência e não por valor)

24 Poucos grupos se preocuparam com isto na 1ª entrega...
Boas Práticas O EA poderá não ser a ferramenta mais poderosa para fazer este tipo de trabalho, mas é a de aprendizagem mais rápida e fácil, e se for bem usada pode ser MUITO útil para gerir identificadores, diagramas e matrizes de relação de forma coerente!!! RASTREABILIDADE||| Poucos grupos se preocuparam com isto na 1ª entrega...

25 Exemplos da 1ª entrega

26 Exemplos da 1ª entrega... Template para descrever processos:
Grupo 14 Um exemplo interessante em geral: Grupo 3 (ver nota sobre requisitos versus actividades...) Exemplo interessante de levantamento de requisitos Grupo 5 (embora com uma apresentação algo “pesada”) Ênfase exagerado no processo ASI... Grupo 15 (extraordinário esforço...) Matriz relacional interessante (rastreabilidade) Grupo 6 (seria talvez mais relevante se em vez de ProcessosxObjectivos fossem duas matrizes de ObjectivosxRequisitos e de RequisitosxProcessos) Grupo 19

27 Questões?