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:

Apresentação e entrega do produto adiadas

A data para entrega do produto com as alterações propostas pela equipe, bem como da documentação que o acompanha, foi adiada para 11 de junho, então teremos mais postagens sobre o trabalho nesse meio tempo.

No mesmo dia, postaremos o resultado final desses 3 meses e meio, passados desde o início do projeto.

Gerenciamento de Riscos do projeto

          Um conjunto de eventos pode ocorrer sob a forma de ameaças ou de oportunidades e, caso se concretizem, influenciam negativamente ou positivamente o projeto. Esses são os riscos e gerenciá-los inclui planeamento, identificação e análise de áreas de risco e o desenvolvimento de opções para lidar com eles e controlá-los.
          A equipe identificou alguns deles e propôs alternativas para controlá-los, reagir caso aconteçam ou eliminá-los.

1 - Desistência/Falecimento de integrantes da equipe de desenvolvimento -
Risco de média importância.
Caso ocorra desistência de algum integrante, haverá uma sobrecarga de atividades para os demais integrantes, que terão que ser novamente distribuídas.
Atraso no cumprimento das atividades, ou insatisfação em realizar as atividades previstas no projeto pode provocar esse risco.
Motivar a equipe e distribuir de tarefas e documentação da mesma afim de não concentrar as atividades pode evitar o problema.


2 - Perda de qualquer tipo de dados do projeto -
Risco de grande importância.
Pode haver perda de dados independente de haver um backup de segurança ou não, já que não há como prever um incêndio, enchente, roubo, entre outros fatores.
Caso ocorra a perda de dados primeiramente o backup será checado, caso esteja com problema ou não possa ser restaurado atividades terão que ser realizadas novamente.
Pode-se evitar tendo o máximo de cópias possível e mantendo elas atualizadas, armazenando cópias em pen drives, anexos em e-mail e nos computadores dos membros.

3 - Aceitação do software no mercado de entretenimento -
Risco de grande importância.
Pode haver uma não aceitação do software no mercado do software ocasionando perda de tempo e dinheiro já que todo o projeto terá que passar por uma reciclagem

Caso ocorra a não aceitação do software no mercado, o software terá que ser revisto e passar por devidos ajustes
Pode-se evitá-lo com versões betas que possibilitem ao cliente avaliar e fazer sugestões em diversas etapas do projeto.

Entrega da versão final

Está chegando a data para entrega do produto com as alterações (04 de junho), e das alterações.

Aguardem para a postagem do link para download da versão final entregue do jogo.