Bom dia a todos.
Iniciarei um projeto na empresa onde trabalho e toda a arquitetura do sistema já foi escolhida, porém gostaria de desenvolver uma documento de especificação mostrando os principais pontos que nos fizeram escolher tal arquitetura.
O resumo deste documento pretendo apresentar para a gerencia e diretoria da empresa, no formato de slide.
Acredito que alguém já tenha desenvolvido alguma documentação disso e se puderem me ajudar com dicas/links ficaria muito grato.
Abs
up …
UML, não ajudaria?
andredecotia, obrigado por responder.
Vejo a UML como parte deste documento, você chegou a fazer alguma documentação neste sentido?
Cada empresa tem uma política, e o que é útil pra ela, em termos de documentação de arquitetura.
Se é apenas um modelo, pode seguir esse : http://www.cmcrossroads.com/bradapp/docs/sdd.html
Mas sugiro vc filtrar o que não é útil ou não faz sentido no tipo de sistema que vc quer especificar.
[]'s
reinaldob obrigado.
Vou ler a referência que me passou.
Realmente vou ter que ler algumas coisas e depois pegar o que mais se encaixa aqui, esta sera a minha primeira especificação, por isso estou querendo referências.
E desde quando gerente e diretor entende UML ? :lol:
A propósito,qual foi a arquitetura escolhida?
Não é permitido ficar dando up nos tópicos… os próximos serão deletados.
[]s
OK Luiz, isso não se repetirá.
Abs,
E desde quando gerente e diretor entende UML ? :lol:
A propósito,qual foi a arquitetura escolhida?[/quote]
UML puro não da pra ser apresentado pra diretoria, eu teria que utilizar uma outra linguagem mais simples com figuras.
A arquitetura escolhida foi: WebLogic + EJB 3.0 + JSF 2.0 (Oracle ADF) + JPA.
E desde quando gerente e diretor entende UML ? :lol:
A propósito,qual foi a arquitetura escolhida?[/quote]
UML puro não da pra ser apresentado pra diretoria, eu teria que utilizar uma outra linguagem mais simples com figuras.
A arquitetura escolhida foi: WebLogic + EJB 3.0 + JSF 2.0 (Oracle ADF) + JPA.[/quote]
Usa mapas mentais
Capitulo 9 deste livro pode te ajudar:
http://www.tar.hu/softarchpract/index.html
Na minha aula usei ADLs …
A documentação essencial de uma arquitetura é:
Contexto do Sistema - O sistema representado como uma caixa preta e seu “entorno” (os sistemas e usuários com os quais o mesmo interage)
Visão Geral da Arquitetura - Um ou mais diagramas informais (não use UML) que ilustram diferentes visões (no sentido de enfoques) do sistema. Pode-se enfatizar o ponto de vista de negócio (departamentos, fluxos de dados, usuários) e/ou o ponto de vista da TI corporativa (sistemas, servidores, datacenters, links de rede).
Modelo de Componentes - Um modelo UML dos componentes de software do sistema e suas interfaces. É um modelo inicialmente grosseiro que será refinado sucessivamente à medida que o projeto avança. Esse modelo começa em nível de subsistema e desce até o nível de especificação, se você realmente tiver cojones ou 1000 indianos trabalhando para você.
Modelo Operacional - Uma visão física (hardware, redes, distribuição) do sistema, podendo ser implementada com um ou mais diagramas de implantação (deployment diagrams) da UML. O foco aqui é descrever como os requisitos não funcionais são atendidos pela arquitetura. Se os usuários estão usando PC XTs conectados a um link WAN de 2kbps acessando uma máquina VAX conectada a uma unidade de fita é aí que você vai escrever seu testamento.
Documento de Decisões Arquiteturais - Um arquivo de texto onde você documenta e justifica decisões arquiteturalmente relevantes, como por exemplo tecnologias e componentes de terceiros utilizados, padrões utilizados, a estrutura de camadas da aplicação e a distribuição dos componentes nessas camadas e mais uma cacetada de informações, se você quiser.
Essa é a documentação by the book. By the IBM/Rational book.
Agora,se você já fez a bagaça e quer apenas documentar para garantir que ninguém amaldiçoe sua mãe no futuro, então a Visão Geral da Arquitetura e o Documento de Decisões Arquiteturais seria um bom começo.
OU ainda diga que vocês usam Scrum e não documente nada.
[quote=esmiralha]A documentação essencial de uma arquitetura é:
Contexto do Sistema - O sistema representado como uma caixa preta e seu “entorno” (os sistemas e usuários com os quais o mesmo interage)
Visão Geral da Arquitetura - Um ou mais diagramas informais (não use UML) que ilustram diferentes visões (no sentido de enfoques) do sistema. Pode-se enfatizar o ponto de vista de negócio (departamentos, fluxos de dados, usuários) e/ou o ponto de vista da TI corporativa (sistemas, servidores, datacenters, links de rede).
Modelo de Componentes - Um modelo UML dos componentes de software do sistema e suas interfaces. É um modelo inicialmente grosseiro que será refinado sucessivamente à medida que o projeto avança. Esse modelo começa em nível de subsistema e desce até o nível de especificação, se você realmente tiver cojones ou 1000 indianos trabalhando para você.
Modelo Operacional - Uma visão física (hardware, redes, distribuição) do sistema, podendo ser implementada com um ou mais diagramas de implantação (deployment diagrams) da UML. O foco aqui é descrever como os requisitos não funcionais são atendidos pela arquitetura. Se os usuários estão usando PC XTs conectados a um link WAN de 2kbps acessando uma máquina VAX conectada a uma unidade de fita é aí que você vai escrever seu testamento.
Documento de Decisões Arquiteturais - Um arquivo de texto onde você documenta e justifica decisões arquiteturalmente relevantes, como por exemplo tecnologias e componentes de terceiros utilizados, padrões utilizados, a estrutura de camadas da aplicação e a distribuição dos componentes nessas camadas e mais uma cacetada de informações, se você quiser.
Essa é a documentação by the book. By the IBM/Rational book.
Agora,se você já fez a bagaça e quer apenas documentar para garantir que ninguém amaldiçoe sua mãe no futuro, então a Visão Geral da Arquitetura e o Documento de Decisões Arquiteturais seria um bom começo.
OU ainda diga que vocês usam Scrum e não documente nada.[/quote]
Vlw esmiralha,
Bem os sistemas já existem, mas estão em .Net 1.0, teremos que migrá-los e tenho como idéia, iniciar a migração já com alguma documentação no mínimo decente, algo não tão exagerado, mas que não deixe requisitos importantes de lado e que mostrem o bom profissionalismo. E a idéia é que se “abandonar” o projeto alguém possa dar continuidade nele também.
Minha idéia é pegar o bom de cada idéia postada aqui e analisar o que melhor vai se encaixar no contexto do negócio da empresa.
Se você tiver acesso ao Microsoft Visio ou algo parecido poderia ser útil, já que no caso o UML seria algo mais técnico poderia usar um diagrama de deployment isso simplificaria bastante. Tenta fazer algo mais macro tipo : Quantos Servidores e quais, com quem eles se comunicam e depois poderia entrar em detalhe de acordo com cada “módulo” .
Oi LOGANJAVA,
Se entendi o que vc está precisando acho que vc poderia começar por algo como:
a) Introdução -> Fale sobre do que se trata o projeto, àreas envolvidas e etc…
b) O “problema” -> Fale sobre a situação atual do sistema.
c) A espectativa -> Fale sobre o que seria ideal para a organização.
c) A Solução -> Fale sobre a solução adotada para atingir as espectativas.
d) Arquitetura
…
Não esqueça de adicionar números (performance, despesas, ganhos e etc…), administradores gostam de números, vai dar uma noção maior do que se quer atingir.
Estes são apenas alguns pontos que vc, na minha opinião deveria colocar nos documentos. Já vi muitos documentos que são cheios de desenhos que não dizem nada de importante do ponto de vista estratégico. Vc não consegue saber do que se trata realmente a coisa toda. Qual a questão realmente abordada pelo projeto e por aí vai.
Na minha opinião apresentar UML para gerente vc vai correr o risco de deixa-los com sono; se for gerente da àrea de informatica tudo bem, desde que ele não seja leigo no assunto.
flws
O ponto do Fantomas é muito bom. Sempre leve em conta a audiência quando produzir qualquer documento.