Gostaria que alguém pudesse disponibilizar os templates dos modelos de documentação de um sistema de médio porte. Pode estar em .doc mesmo. Pode ser qualquer tipo que vocês conseguirem, casos de uso, visão, especificação, caso de teste…
Os que achei no google, não me interessaram.
Ficaria muito grato, é simples, basta fazer o upload aqui no post mesmo!
OpenUp pelo que andei vendo é algo parecido com o RUP certo?
@Rodrigoy: Não acredito que haja algo mais importante (artefato ou atividades do processo). As atividades de cada processo geram artefatos…um tem ligação com o outro e para ter um processo de fato vc tem entradas, processamento e saídas (em linhas gerais) e nisso tudo os artefatos estão presentes…não existe grau de importancia na minha visão não.
[quote=richardpeder] @Rodrigoy: Não acredito que haja algo mais importante (artefato ou atividades do processo). As atividades de cada processo geram artefatos…um tem ligação com o outro e para ter um processo de fato vc tem entradas, processamento e saídas (em linhas gerais) e nisso tudo os artefatos estão presentes…não existe grau de importancia na minha visão não.[/quote]
Não necessariamente uma atividade TEM que gerar um artefato (é aquela história do conhecimento tácito, conhecimento explicíto e blá blá blá blá blá blá…). Se você senta com o cliente e conversa sob um determinado assunto do projeto, e sai dessa conversa com conhecimento do negócio, é essa ATIVIDADE que é importante. Se você junta sua equipe para conversar sobre arquitetura, e faz diversos rascunhos em papel usando rabiscos nem um pouco UML 2.0 compliant, é a dinâmica da equipe que é importante, esses rascunhos não são considerados artefatos.
Essa história de “recebo artefatos - executo a tarefa - cuspo artefatos” deve funcionar bem em cartório, linha de produção, banco… Essa visão mecanicista nunca funcionou para desenvolvimento de software. E vou além, essa não é a visão do UP.
Vou falar um pouco sobre isso na minha coluna, mas infelizmente estou escrevendo agora o que só vai ser publicado em janeiro.
Ou seja, se vc tem esse monte de papel rabiscado tá bom? Me perdoe Rodrigo, mas eu não sei trabalhar desta forma não. Um pouco de organização e sistemática não faz mal a ninguem. Vc ir lá, conversar com seu cliente, entender a atividade dele e passar isso em alguns documentos é muito mais organizado e fica mais facil de prosseguir com as coisas. eu sou adepto dos bons processo sim, mas, seguir a sistemática toda tb não é algo que vc precise fazer “religiosamente”, no entanto, se vc não documenta o que seu cliente quer como desenvolve o sistema? Com os rabiscos? Fala sério. :?
um software que atenda ao negócio (qualidade externa)
seja simples de manter e evoluir (qualidade interna)
que seja feito no menor custo possível.
É uma questão de custos… o que o cliente quer de fato é o software e não os documentos. O fato de usar rascunhos (veja, rascunhos, e não rabiscos como vc colocou) não tem relação alguma com organização ou maturidade do processo. Meu rascunho no papel A4 pode ser muito melhor para obter os RESULTADOS que listei acima do que usando ferramentas que custam milhares de dólares.
Tome cuidado com processos que PARECEM organizados com aqueles que SÃO organizados de fato. O que o cliente quer é o software e não os documentos que abstraem o que se espera do software. De fato, meus artefatos de requisitos são rascunhos de Domain Models, rascunhos de casos de uso, rascunhos de protótipos de tela, rascunhos de diagrama de atividades. Tudo em papel A4, desenhados junto com o cliente (e com isso, automaticamente aprovados por ele). Com esses “rabiscos” na mão, volto para casa e transformo isso em software funcionando, seguindo boas práticas de engenharia.
Dentro do processo não se pode gastar muita energia em levantar requisitos antecipadamente. Desenvolvimento de software é uma atividade de codificação.
Na próxima vez que encontro cliente, mostro o software permitindo que o cliente faça as alterações e ajustes necessários (e isso não tem relação com o fato de ter usado papel A4). Então pego mais papel A4 e mais modelagem…
Software funcionando é o melhor artefato para levantamento de requisitos.
e quando vc precisa dar manutenção olha no rabisco no A4? hehe eu entendi o q vc quis dizer tb ja fiz isso… e no cliente pouco me importa o software… é na mao mesmo de forma q eu entenda… e ainda mostro para ele é assim e talz… agora e o rabisco fica para mim… porem para a equipe eu tenho que usar um software ou no mesmo velho word passo exatamente como está no rabisco e mostro a equipe… o motivo é que com minha letra a equipe nao vai entender ou pode entender errado, e digitado e impresso é meio dificil hehhe… mais é isso ai o cliente que o software atendendo a sua necessidade… como vc implementou isso, é um problema seu… pq se amanha quando começar dar pau, ou precisa melhorar o sistema… é importante ter toda documentacao em maos… para ganhar tempo…
Trabalho a 5 anos na área e nunca vi um cliente querer só o sistema…geralmente, se vc fica responsável pela analise, ele vai querer os UC’s, Diagramas e demais documentos sim…e eles pagam por isso com certeza! Se ele compra seus testes pro sistema…ele vai querer os docs que usou pra testar, evidências dos testes realizados, as vezes até uma analise detalhada dos testes realizados e pelo modelo que vc está me dizendo vc faz a parte de analise tb, ou seja, a fase de analise fica sob sua resp então, neste modelo, não tem como fugir…se fosse só “controi e me entrega”, até poderia ser só entregar o codigo já que a analise vc não poe a mao.
Não sei em que empresa vc trabalha, mas nas que trabalhei nestes meus 5 anos na área JAMAIS vi vc só entregar o código fonte e fazer tudo em rascunho…acho isso um baita absurdo sem cabimento algum.
Não, não depende não… o mercado pede essas besteiras só por adaptação aos padrões. No geral, quem compra (compradores dos clientes) e quem vende (vendedores de fábricas) são mal preparados para a função. Eles acham que com a documentação vão garantir uma melhor qualidade interna do software, mas documentação não garante isso.
Nesses 13 anos na área eu nunca ví um cliente que quer um sistema… o que ele quer na verdade é resolver um problema de negócio… não somos pagos para fazer casos de uso, nem diagramas, nem código… nós somos pagos para resolver um problema de negócio…
Sim, eles jogam dinheiro fora com outras coisas também… como falei, é uma ilusão achar que casos de uso, diagramas e demais documentos colaboram para a qualidade interna do software. CMMI, MPS.BR, ISO não garantem que o cliente terá ROI com o projeto. O mercado está tendo que gastar alguns bilhões para aprender isso. Felizmente isso está mudando.
Cara, você está colocando um cenário da maneira que um cara entra numa fábrica de software e diz: - Quero requisitos, quero desenvolvimento… ahh… hoje eu quero testes também! É a mesma coisa que você chegar numa concessionária de carros e falar: -Hoje está calor… quero só o ar-condicionado do carro por favor…
Ai meu Deus… esses caras de fábrica teimam em separar o desenvolvimento de software entre design e construção. Não existe essa separação, desenvolvimento de software é 100% design. Até testar o software é design. NÃO EXISTE UMA FASE DE ANÁLISE. ALIÁS, NÃO EXISTEM FASES! Meus artefatos de análise são: o próprio código, meus TDDs, os comentários no código e talvez mais um documento de arquitetura. Se por alguma razão achei interessante modelar alguma coisa usando ferramenta (sim, eu uso ferramentas UML, mas sempre focando o código e não o modelo), trato de transformar logo em código.
Richard, trabalhei e presto consultoria em diversas empresas (inclusive, algumas eu ajudo a reduzir a concepção do software de algumas semanas para algumas horas). Eu trabalhei com software antes do mercado ficar maluco, e foi exatamente nesses últimos 5 anos que estamos tendo o ápice da maluquice. Não considere que as empresas que você trabalhou estão certas, pois a maioria delas estão erradas, não é o fato de não usar os rascunhos, mas sim “aonde” estão indo os esforços. Isso vai mudar e vai mudar MUITO em breve. O mercado não aguenta mais pagar o custo desse desenvolvimento pesado, cheio de etapas, cheio de documentos, cheio de pessoas, de departamentos.
Quero que o desenvolvimento de software volte para como era no ínicio dos anos 90 (só que com a tecnologia de hoje!). Nessa época era sentar a bunda na cadeira e fazer o desgraçado do software que resolve o problema do cliente. A última preocupação nessa época era o cronograma. Aí começaram as terceirizações que visavam “economizar”. Hoje um software não sai por menos de R$ 100K quando entra numa fábrica. Tudo é difícil, tudo é demorado, tudo precisa de um monte de coisa que de fato não precisamos.
Não vou bater boca com vc a respeito disso…é meu ponto de vista e a thread aqui vai estourar o banco de dados do GUJ e não vou mudar minha visão quanto a isto.
O desenvolvimento de software não vai voltar em como era nos anos 90…tudo isso que acredito, confio e estou dizendo é algo que vejo em grandes empresas e em muitas pequenas, ou seja, se vc quer desenvolver software como nos anos 90 pode ficar pra tras. Não adianta ficar defendendo “pq nos anos 90 era assim” como um revolucionário querendo que seja hj…as coisas mudam, as praticas mudam e não aceita-las é ser ultrapassado.
Pra mim, como lhe disse, essa sua concepção de desenvolvimento de software é absurda…é minha visão, minha opinião, não vou mudar.
[quote=richardpeder]
Pra mim, como lhe disse, essa sua concepção de desenvolvimento de software é absurda…é minha visão, minha opinião, não vou mudar.
ate mais…[/quote]
hum… não vai mudar pq? teimosia?
falando serio, não vou entrar na discussão de melhor ou pior.
mas se eu posso obter o mesmo resultado com menos burocracia/processo, porque eu usaria?
Ninguém aqui tá dizendo pra se usar todos os documentos/processos do CMMx nível 5 por exemplo não…criar documentos como Casos de Uso, Diagramas, etc auxilia o desenvolvimento…tudo bem que estou acostumado mais com esquema de FSW, no entanto, vejo isso como essencial e não consigo entender como uma pessoa desenvolve “uma solução de negócio” com rabiscos e rascunhos.
Me perdoem, mas isso é demais pra mim. Estou me retirando do tópico pq o assunto é absurdo demais para ser discutido. Estamos voltando a idade da pedra mesmo, não é possível.
Nesta comcepção do Rodrigo por ex, não existirá mais analistas, testadores, processos, nada…só o programador e o cliente do lado dizendo o que ele deve fazer?
Bom, daqui a 2 anos não vai reclamar dizendo que eu não avisei… as coisas estão mudando. Estou bem próximo do mercado para afirmar isso. Vou compartilhar aqui o que o Robert Martin vem falando a algum tempo: Ou as fábricas ficam ágeis ou elas morrem.
Essa concepção não é minha, tudo que falei aqui é fundamentado em literaturas (algumas dos anos 90, outras desse milênio), e qualquer desenvolvedor ágil concorda com a minha opinião.
Meu projeto está indo para o mercado até o final do ano. Quando isso acontecer vou fazer questão de mostrar o produto, os artefatos e o tamanho do sorriso dos stakeholders para você. Duvido que qualquer fábrica faria um trabalho melhor.
Não consigo ver um cenário mais maravilhoso do que esse que você pintou. É minha opinião sincera. E vou além, essa divisão do trabalho e especialização não é defendida por nenhuma metodologia. Nem mesmo pelo RUP.
Richard, pelo seu bem e pelo bem da sua carreira (seu bolso), peço que continue no tópico…
Se esse negócio de rascunho em papel de pão e código funciona pra vc, muito bom, mas eu não consigo enxergar isso como algo que de fato seja melhor do que onde tenhamos uma sistemática definida (não necessariamente burocrática) e a geração de alguns artefatos que auxiliem no desenvolvimento do negócio solicitado e documentação do que o cliente pediu/necessita baseado numa metodologia qualquer.
Não, não tem nenhum motivo pra eu continuar neste tópico visto que temos visões diferentes…vc defendeu a sua, eu defendi a minha, pronto.
Não tem mais o que discutir aqui. Espero que vc tenha sucesso neste seu projeto e nos demais em que vc venha a trabalhar.
Vejo como uma tendencia forte dos anos 90 a utilização de RUP, waterfall, documentação, ciclos de 2 anos de duração,etc…
Agora como tendencia forte dos anos 2000 são as metodologias ágeis, documentação apenas essencial, ciclos curtos, etc…
Já participei de projetos grandes em grandes multinacionais e cheguei em alguns projetos participar da apresentação do projeto para a presidência e na grande maioria das apresentações do projetos a maior parte da apresentação do projeto era mostrar resultados e melhorias.
Ficar agil? Concordo com vc, agilidade será a tendência dos próximos anos. Mas ficar “ágil” não significa anotar o que o cliente quer num papel A4, bota-lo do seu lado e sair programando…pelo amor de Deus, não quero mais discutir isso! Isso foi pra fechar a semana com chave de ouro! ?
Não é mais rápido bater fotos da lousa usada na reunião com o cliente e juntar com a gravação da conversa do que transcrever tudo com palavras que podem ser diferentes das que o cliente usou?
O cliente precisa homologar estes documentos para garantir que contém o que realmente falou ou basta vocês conferirem com a transcriçào das fitas, fotografias e filmes?
Como entram fotos, gravações e fitas no contexto do tipo CMM?
Qual a periodicidade que vocês conseguem nas reuniões com o cliente? Supondo que perdem pelo menos 2 dias na transcrição das conversas em documentos e na aprovação posterior deles, acho difícil haver reuniões semanais.