SoundBible.com

          Durante a apresentação da equipe no dia 07/05/2012, fomos questionados sobre a fonte e a legalidade dos novos sons utilizados em jogo. Para esclarecer melhor estas questões decidimos criar um post sobre este site e a origem de seus arquivos disponibilidades.

          Fonte do Post: http://soundbible.com/about.php 

Sobre o SoundBible.com

SoundBible.com disponibiliza milhares de efeitos sonoros gratuitos em arquivos de áudio. Estes sons podem ser utilizados em uma grande variedade de projetos, incluindo vídeos, filmes, jogos, apresentações de power point, e vários outros. SoundBible.com é uma excelente fonte de arquivos sonoros legalizados e gratuitos.

Por que estes arquivos são gratuitos ?

Por algumas razões na verdade.

·         Nossos projetos beneficiam professores, alunos, faculdades e outros. Estes não podem pagar por esses arquivos, por isso somos forçados a "doar" estes arquivos. 

·         A sessão de "Royalty Free Sounds" consiste em licenças Creative Commons e Public Domain works

·         Os proprietários do SoundBible.com foram ensinados a compartilhar pelos seus pais. Não foi isso que seu pais lhe ensinaram também? :D

·         Porque quando é de graça é melhor do que pagar taxas, correto?

Estes arquivos podem ser utilizados comercialmente?

Os "Royalty Free Sounds" podem ser utilizados em produtos pagos. Já os sons livres podem somente ser utilizados pela licença Creative Commons Attribution ou Public Domain License.

Identificação de artefatos

O Projeto de Software transforma os resultados da Análise de Requisitos em um conjunto de documentos capazes de ser interpretados diretamente pelo programador. É importante mapear todas as estruturas e funcionalidades dentro do contexto e das restrições da arquitetura, de forma a tornar possível a construção do software.

           Tudo o que compõe o projeto, sejam esses componentes parte da documentação ou do software, é um artefato. Sendo assim, devem ser identificados de modo padronizado, para que tanto a equipe responsável pela construção quanto a equipe responsável pela manutenção consiga localizar as informações quando forem necesárias.

            Segue abaixo a convenção utilizada para rotular os caminhos e artefatos na Estrutura de Diretórios do Produto.

<SEP>_<Identificação>_<Versão>.<EST>

<SEP>: Identifica o sistema: “P0rtal_Snake”.

<Identificação>: Texto para identificação do documento.

<Versão>: Identifica qual a versão do documento.

<EST>: Extensão do arquivo.

Exemplo: P0rtal_Snake_Requisitos_1_0.doc – Requisitos do P0rtal Snake versão 1.0

Controle de Configuração

Os procedimentos de mudança e alteração do software são semelhantes a um sistema de workflow, com passos definidos pela equipe visando agilidade e confiabilidade no processo. Ao serem encaminhadas alterações ao desenvolvedor ele irá avaliar qual o tipo de alteração:

Evolutiva : Trás a implementação de uma melhoria ou requisito novo no código fonte do projeto, como por exemplo a implementação de um novo sistema de pontos. É analisada a viabilidade de implementação, tempo necessário e se esta alteração encontra-se no planejamento e escopo do projeto. 
         Corretiva: Apresenta a correção de algum requisito ou funcionalidade, que acabou sendo implementada incorretamente e não foi detectado o problema no processo de inspeção e validação do software. É analisado como será implementada a correção do problema, definifo um prazo e executada a correção.
      Independente do tipo de alteração realizada, ao final do processo ela é encaminhada ao setor de inspeção, onde será validada e testada. Caso ocorra algum problema é retornado ao desenvolvedor a descrição do erro ocorrido.

Processo de alteração

         As alterações que o nosso cliente propôs e foram implementadas no projeto passaram por um processo padronizado de descrição, implementação, homologação e documentação do resultado.
         O processo é descrito na imagem abaixo: