Todos os capítulos do livro Delphi 7 Internet e Banco de Dados em PDF (gratuito)
Olá nobres amigos,
Reunidos num só post, links de todos os capítulos em PDF.
Lembrando que não há suporte técnico.
Forte abraço e bons códigos.
Facunte iLife: A perfeição do imperfeito
Olá nobres amigos,
Reunidos num só post, links de todos os capítulos em PDF.
Lembrando que não há suporte técnico.
Forte abraço e bons códigos.
Código fonte do livro VB.Net Desenvolvendo uma Aplicação Comercial
Olá jovens,
Estou disponibilizando o código fonte do livro “VB.Net Desenvolvendo uma Aplicação Comercial”, de autoria de Alexandre Tarifa, Emerson Facunte e Marcus Garcia.
O livro foi publicado pela Editora Brasport (http://www.brasport.com.br)
Lembrando que não há nenhum tipo de suporte.
Baixe aqui o arquivo compactado.
Bons códigos.
Estou disponibilizando o código fonte do livro “VB.Net Desenvolvendo uma Aplicação Comercial”, de autoria de Alexandre Tarifa, Emerson Facunte e Marcus Garcia.
O livro foi publicado pela Editora Brasport (http://www.brasport.com.br)
Lembrando que não há nenhum tipo de suporte.
Baixe aqui o arquivo compactado.
Bons códigos.
Código fonte do livro C# Desenvolvendo uma Aplicação Comercial
Hey nobres mancebos,
Estou disponibilizando o código fonte do livro “C# Desenvolvendo uma Aplicação Comercial”, de autoria de Alexandre Tarifa, Emerson Facunte e Marcus Garcia.
O livro foi publicado pela Editora Brasport (http://www.brasport.com.br)
Lembrando que não há nenhum tipo de suporte.
Baixe aqui o arquivo compactado.
Bons códigos.
Estou disponibilizando o código fonte do livro “C# Desenvolvendo uma Aplicação Comercial”, de autoria de Alexandre Tarifa, Emerson Facunte e Marcus Garcia.
O livro foi publicado pela Editora Brasport (http://www.brasport.com.br)
Lembrando que não há nenhum tipo de suporte.
Baixe aqui o arquivo compactado.
Bons códigos.
Qualidade de Software - Convencendo o “Alto Escalão” - Parte II
Salve meus nobres!
Na primeira parte do artigo traçamos cenários comuns de desenvolvimento de soluções em empresas de diferentes portes.
Sinto-me incongruente neste cenário fatídico (trágico), porém estou de mãos atadas, lábios lacrados, costurados pela desunião de uma classe conhecida como: “OS CARAS DA INFORMÁTICA”.
No final da primeira parte do artigo, concluí com o seguinte pensamento:
Somos responsáveis pela mudança deste cenário. Não devemos culpar nossos diretores e gerentes. Nós permitimos isso!
Por que nós permitimos tal cenário?
Na primeira parte do artigo traçamos cenários comuns de desenvolvimento de soluções em empresas de diferentes portes.
Sinto-me incongruente neste cenário fatídico (trágico), porém estou de mãos atadas, lábios lacrados, costurados pela desunião de uma classe conhecida como: “OS CARAS DA INFORMÁTICA”.
No final da primeira parte do artigo, concluí com o seguinte pensamento:
Somos responsáveis pela mudança deste cenário. Não devemos culpar nossos diretores e gerentes. Nós permitimos isso!
Por que nós permitimos tal cenário?
- Medo de enfrentar o “boss”?
Certamente essa é uma das tarefas mais complicadas, que exige dose infinita de coragem. Mas se houver união, esta dose será dizimada entre os corajosos, porém uma força maior será formada. - Falta de iniciativa?
Vocês já perceberam quantas coisas perdemos por falta de iniciativa?
Quantas vezes nos questionamos sobre aquela “oportunidade única” que perdemos? - Ambiente hostil!
Este é um fator delicado, que exige um bom estudo estratégico antes de criar a tal coragem. Existem diversos níveis de hostilidade, desde a “teatral”, que apenas representa de maneira figurada, até a mais covarde que se apóia em técnicas desprezíveis como o assédio moral. Neste caso, você deverá denunciar a pessoa, ao invés de estudar estratégias. - Falta de argumentos
Opa! É aqui que entramos… Vamos enumerar alguns:
- Se há tempo para ficar corrigindo “bugs”, então há tempo para implantar processo de qualidade de software.
- Adotar uma metodologia enobrece e fortalece a qualidade do projeto
- Entrega no prazo
- Maior disponibilidade de tempo para novos projetos
- Maior integração entre as equipes
- Maior confiabilidade na equipe
- Melhoria no ambiente de trabalho
- Redução drástica de “bugs”.
- Redução do tempo para implantar novas funcionalidades
- Redução do tempo para encontrar qualquer tipo de inconsistência
Bem, com estes argumentos já é possível iniciar uma boa análise estratégica.
O espaço está aberto para discutirmos o assunto.
Follow me on Twitter: @facunte (http://www.twitter.com.br/facunte)
Qualidade de Software - Convencendo o “Alto Escalão” - Parte I
Nobres,
Vocês já conseguiram convencer seus gerentes e diretores a adotarem o modelo de qualidade de software em suas equipes?
Bem, esta é uma tarefa árdua e a batalha pode ser comparada com a histórica luta entre Davi e Golias.
Vejamos o cenário atual da maioria das empresas.
Empresa A
O cenário mais comum
Empresa B
Algumas empresas estão brincando neste nível
Vocês já conseguiram convencer seus gerentes e diretores a adotarem o modelo de qualidade de software em suas equipes?
Bem, esta é uma tarefa árdua e a batalha pode ser comparada com a histórica luta entre Davi e Golias.
Vejamos o cenário atual da maioria das empresas.
Empresa A
O cenário mais comum
- Gerente solicita desenvolvimento de uma “simples” rotina para cálculo de Folha de Pagamento.
Obs: Não há especificação de fórmulas, tão pouco as informações que farão parte do cálculo. - Desenvolvedor - neste cenário também pode ser chamado de Analista de Sistemas, Analista de Requisitos, Analista de Testes, Analista de Suporte, DBA e até mesmo “mágico” - levanta informações com gerente e/ou profissionais de RH e põe a mão-na-massa. Desenvolve a “simples” rotina, faz testes convencionais do tipo: informa valor, clica aqui, vê resultado e pronto!
- Gerente faz uma rápida avaliação na rotina desenvolvida e autoriza a implantação.
- O restante da epopéia (sim, isto pode ser considerado um poema épico, heróico) já é sabido: dezenas de erros serão observados, desde a análise dos requisitos até a fórmula criada.
- Gerente solicita revisão e correção dos erros.
O ciclo vicioso está formado. No momento em que “todos” os problemas apontados forem solucionados, novas requisições estarão numa imensa fila de espera. O “mega-desenvolvedor” tem trabalho para o resto de sua vida - um final dramático.
Empresa B
Algumas empresas estão brincando neste nível
- Gerente solicita desenvolvimento de uma rotina para cálculo de Folha de Pagamento. Agenda a reunião com todos os envolvidos no processo (analista de sistemas e RH) .
- Na reunião são apresentadas todas as informações para realização do cálculo. O analista pouco questiona, já que não é especialista em requisitos.
- Com base nas informações coletadas na reunião, o analista desenvolve a rotina, faz testes convencionais do tipo: informa valor, clica aqui, vê resultado e pronto!
- Gerente faz uma rápida avaliação na rotina desenvolvida, agenda nova reunião com os envolvidos e apresenta a solução.
- A rotina é implementada.
- A mesma epopéia: dezenas de erros serão observados, desde a análise dos requisitos até a fórmula criada.
Cenários diferentes, os mesmos problemas e todos nós reclamamos do processo.
Nos corredores ouvimos colegas dizerem:
- Você acredita que terei que alterar isso ou aquilo?
- Não aguento mais, eu sabia que aquilo estava correto, mas não sou o chefe aqui!
- As informações foram transmitidas pela metade, terei que refazer todo o processo.
- Isso não é justo. Trabalhei 6 meses neste projeto e os caras mudaram tudo!
Somos responsáveis pela mudança deste cenário. Não devemos culpar nossos diretores e gerentes. Nós permitimos isso!
A epopéia continua na Parte II.
Follow me on Twitter: @facunte (http://www.twitter.com.br/facunte)
Emerson Facunte, Senior Solutions Saraiva.COM, entusiasta Social Media, amante da boa música e games.
