Ola galera…
gostaria de saber se voces tem um link de um documento de um projeto de software para eu dar uma olhada por cima…
ja li tanto sobre requisitos, metodologias, padroes mas nao sei como escrever um…
gostaria de ter uma base analisando um projeto pronto…
alguem pode colocar um link ai?
Ricardo, qual seria o propósito desse documento? É para o cliente? Se for , pergunte a ele quais informações ele precisa.
Exatamente o que eu iria dizer.
Se não há objetivos, simplesmente não crie o documento. :lol:
seria um documento de analista para programado com copia para o cliente…
Documento do analista para o programador com cópia para o cliente não agrega nada, somente causa problemas. Documento é uma das piores formas de comunicação. Pelo visto, vocês trabalham da maneira tradicional da maioria das empresas. A maioria das pessoas aqui deste forum irá te recomendar trabalhar com a equipe bem junta (inclusive fisicamente), para não precisar desses “artefatos” e usar a comunicação face a face, que é muito mais eficiente. Uma lida sobre Agile/ XP / SCRUM te ajudará bastante nesse sentido.
pois eh man
entao vc acha que nao deviamos organizar isso na forma documentada?
entao como seria o jeito correto?
Bom dia Goboo,
acho que o Emerson Macedo quis dizer é:
Não é que você não precise documentar, o que você deve fazer é dar liberdade para seu programador ter acesso ao cliente, para conseguir as informações de forma rápida.
Você já deve ter ouvido falar de método agil certo ??
Então lá vc aprende que tratar com pessoas é melhor que documentos, mas isso não significa que você não deva documentar, o que deve fazer é estar proximo ao seu programador e fazer desenhos, em forma de rascunho.
Caso ele tenha dúvidas no desenvolvimento ele precisa ter acesso ao cliente/usuário.
Porém grandes alterações e mudanças de escopo devem sempre ser muito bem vindas e repriorizadas junto ao cliente.
para maiores informações recomendo os seguintes sites:
http://www.agilemanifesto.org/
sugarloafplop2005.icmc.usp.br/papers/9673.pdf
http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp
http://www.riehle.org/computer-science/research/2000/xp-2000.html
http://www.agileplanet.org/
http://www.improveit.com.br/xp/dissertacaoXP.pdf
http://www.agilealliance.com.br/
Espero ter ajudado.
abs,
ajudou sim
vou estudar XP outras metodologias de novo.
quando eu fiz o topico, meu intuito era aprender como
a coordenar um processo de desenvolvimento de software
mas antes tenho que entender como o processo tem que
ser organizado, depois disso pensarei em como faze-lo
obrigado galera
se nao for pedir muito, alguem ai tem um link sobre MVC
e arquiteturas para Desktop?
abs
[quote=gobbo]pois eh man
entao vc acha que nao deviamos organizar isso na forma documentada?
entao como seria o jeito correto?[/quote]
A cultura em lugares onde TUDO é documentado é a de procurar culpados por falhas no projeto, o que contrasta com a cultura em um ambiente ágil que é a de parceria e apoio. Se ERRAMOS (o analista, o programador e o usuário), tínhamos todo o direito de errar e na pŕoxima iteração melhoraremos.
Enquanto as empresas não entenderem isso, os projetos nunca utilizarão XP/SCRUM e continuarão um fracasso.
[quote=Taz][quote=gobbo]pois eh man
entao vc acha que nao deviamos organizar isso na forma documentada?
entao como seria o jeito correto?[/quote]
A cultura em lugares onde TUDO é documentado é a de procurar culpados por falhas no projeto, o que contrasta com a cultura em um ambiente ágil que é a de parceria e apoio. Se ERRAMOS (o analista, o programador e o usuário), tínhamos todo o direito de errar e na pŕoxima iteração melhoraremos.
Enquanto as empresas não entenderem isso, os projetos nunca utilizarão XP/SCRUM e continuarão um fracasso.[/quote]
Depois dessa, o tópico entrou no meu favoritos. 
O problema maior acontece quando essa mentalidade de papel está no cliente e não na equipe.
Estou num projeto onde tentei implementar um processo ágil com meu cliente. Por algumas semanas eu fui fazendo o desenvolvimento e participando de algumas reunioes sem maiores problemas, até que o cliente teve uma falha interna de comunicação entre as equipes envolvidas. Claro que o problema caiu sobre mim, já que toco o projeto sozinho, e agora tenho que entregar todos os documentos de casos de uso para eles.
Agora não sei onde foi o problema, se nao consegui me fazer entender para aplicar as práticas ágeis no cliente ou se a cultura dele está muita amarrada a papel e obrigue a entrega deste tipo de documentação!
"
[quote=gobbo]pois eh man
entao vc acha que nao deviamos organizar isso na forma documentada?
entao como seria o jeito correto?[/quote]
Na verdade eu posso ter me expressado mau ou você entendeu errado. O que eu quis dizer foi que você precisa ver se o documento é realmente necessário e que tipo de documentos são. Documentação é importante, mas apenas o que for preciso e nunca pra substituir a comunicação face a face.
A documentação em qq projeto de software tem um dilema interessante: geralmente O PRAZO TA COMENDO.
Ai vc quer fazer o que? Desenvolver ou manter a documentação atualizada?
Geralmente vc Desenvolve e ninguem percebe que a documentação ta defasada até que alguem queira “pq queira” que a documentação esteja em dia. No geral vc pode ter coisas como comentários no codigo que virem javadoc ou outra documentação genérica sobre o codigo + casos de teste de aceitação, funcionais ou unitarios, que sejam descritivos o suficiente para vc entender algumas coisas.
O Uso de uma WIKI é muito bom. Não custa nada colocar uns paragrafos sobre alguma funcionalidade que, no futuro, ninguem vai lembrar 100%. Sem falar que da wiki vc pode gerar um pdf e mandar pro cliente “parar de encher o saco”.
[quote=Emerson Macedo]Documento do analista para o programador com cópia para o cliente não agrega nada, somente causa problemas. Documento é uma das piores formas de comunicação. Pelo visto, vocês trabalham da maneira tradicional da maioria das empresas. A maioria das pessoas aqui deste forum irá te recomendar trabalhar com a equipe bem junta (inclusive fisicamente)
[/quote]
Infelizmente nas experiências profissionais que eu tive até hoje isso foi sempre difícil de acontecer, principalmente quando trabalhei em empresas médias/grandes e projetos mais complexos envolvendo um número maior de pessoas…
Abs
Sem falar que papel aceita tudo.
Não raro vc encontra documentos técnicos contraditórios. Ai se a empresa é burocrática ou isso é ignorado ou para-se tudo, se revisa a documentação, há briga, chega-se a uma terceira interpretação, atualiza-se os documentos e segue-se trabalhando com prazo ligeiramente menor.
A base de todo processo é o desenvolvimento iterativo. Faça uma lista do que tem que ser entregue. Geralmente colocamos o que é mais difícil no começo da lista até as coisas mais fáceis. Aí você a cada 2 semanas terá um release implementando um pedaço da lista (mas é implementando mesmo, analisado/codificado/integrado/testado).
Dá uma olhada em alguns posts no meu blog: http://blog.aspercom.com.br
Meuuu … fico de cara com alguns foruns ou melhor com alguns membros. Cria-se uma polêmica sobre o pedido do usuário quando o que ele precisa é de ajuda. Por que ao invés de questionar vocês não ajudam? Não interessa pra vocês se ele vai usar o documento para um cliente ou se vai ser só pra ele colocar num quadro em casa pra ficar admirando.
Só podem ajudar respondam, se não podem, fiquem quietos.
Amigo, você pode criar 2 modelos de documentação.
1 - Modelo Completo
http://bvsmodelo.bvsalud.org/download/projetos/DIR-GuiaElaboracaoPropostas-pt-20080611.pdf
2 - Modelo Simples
http://www.cordeiro.pro.br/aulas/engenharia/gerencia/plano.pdf