quarta-feira, 27 de outubro de 2010
Escolha do Primeiro Incremento
- Itens a serem observados nessa fase:
* casos de uso
* diagramas de classes
* arquitetura inicial
* esquema de banco de dados
* tecnologias utilizadas
* etc.
quinta-feira, 14 de outubro de 2010
Apresentação Geral do AcordeOn
Projeto
Rede Social Colaborativa Musical – AcordeON
Objetivo
O sistema que será desenvolvido possui como objetivo o compartilhamento de letras, melodias e harmonias por meio de cifras, partituras e também arquivos em formato de áudio.
Meta
A meta é criar um ambiente virtual para criação, compartilhamento e divulgação musical, atuando como uma incubadora de músicas/compositores e proporcionando aos usuários do sistema a possibilidade de interação com outros compositores/fãs.
Público Alvo
O público alvo do projeto são pessoas do meio musical tal como músicos, cantores, compositores, arranjadores e afins, sejam eles amadores ou profissionais.
Escopo do Projeto
O sistema funcionará como uma rede social colaborativa onde cada usuário cadastrado poderá gerenciar seu perfil e torná-lo visível a todos os membros do AcordeON.
A principal funcionalidade do sistema será a possibilidade de compartilhar arquivos do gênero musical com outros usuários também já cadastrados. Estes arquivos poderão ser letras, cifras, partituras ou arquivos de áudio.
Compartilhar um arquivo significa que outros usuários poderão visualizá-lo ou alterá-lo, a depender de como o proprietário permitir. Este poderá escolher dentre alguns, todos ou nenhum de seus amigos como colaboradores, desta forma é possível que ele tenha acesso exclusivo aos arquivos que não deseja compartilhar.
Um membro do AcordeON somente poderá compartilhar um arquivo que postou com seus amigos e apenas poderá visualizar postagens de outros membros que forem seus amigos. Os comentários poderão ser feitos apenas por amigos e estarão sujeitos à moderação do autor da postagem.
Será permitido enviar mensagens a qualquer usuário cadastrado e criar de grupos para a reunião de pessoas com opiniões similares.
AcordeON não tem qualquer pretensão ou responsabilidade com relação aos direitos autorais, sendo de inteira responsabilidade dos usuários as medidas jurídicas para que os direitos sobre suas obras sejam preservados e exercidos.
quarta-feira, 13 de outubro de 2010
Requisitos Não-Funcionais
- Será desenvolvido em JAVA para web seguindo os padrões J2EE
- O banco de dados a ser utilizado será o MySql
- Possibilitará o acesso simultâneo de uma média 15 a 20 acessos inicialmente, expandindo-se ao decorrer do tempo
- Terá um tempo médio de resposta de 1 a 5 segundos para as principais funcionalidades.
- Interface Intuitiva e de fácil navegabilidade
- Os seguintes navegadores e suas versões superiores serão contemplados: Mozilla Firefox, Google Chrome e Internet Explorer 8
Requisitos Funcionais
· 1 – Gerenciar Arquivos
o Criar/Carregar arquivo
o Remover arquivo
o Editar arquivo
§ Editar Descrição de arquivo
§ Adicionar colaborador
§ Remover colaborador
· 2 – Gerenciar Amigos
o Adicionar Amigo
o Remover Amigo
o Buscar Amigo
o Listar amigos
o Aprovar solicitação de amigo
o Interagir com amigo
§ Comentar publicação
§ Mandar recado
· 3 – Gerenciar Perfil / Conta de usuário
o Cadastrar Conta de Usuário
o Remover Conta de Usuário
o Editar Conta de Usuário
§ Redefinir senha
§ Redefinir email
o Editar Perfil
· 4 – Gerenciar Comunidades
o Criar comunidade
o Editar comunidade
o Remover comunidade
o Excluir membro da comunidade
o Aprovar entrada de membro na comunidade
o Criar tópico
o Remover tópico
ESPECIFICAÇÃO DOS REQUISÍTOS
Podem ser entendidos como uma função, restrição ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do sistema.
Por serem atividades bases do processo de desenvolvimento de software as falhas cometidas nas atividades de definição e validação de requisitos irão originar documentos de requisitos inconsistentes afetando as etapas seguintes de projeto, implementação e testes e gerando produtos de softwares de baixa qualidade.
Segundo Macoratti As principais causas para o fracasso dos projetos de software são: especificação de requisitos mal formulada e alterações constantes nos requisitos. Para Standish, 37% dos problemas que ameaçam os projetos estão relacionados com os requisitos. Além disso, nem todos os requisitos são criados da mesma forma, sendo muitas vezes visíveis e incrementados ao longo do processo de desenvolvimento.
A Norma ISO / IEC 9126 define seis características de qualidade de software que devem ser avaliadas:
-Funcionalidade (finalidade do produto);
-Usabilidade (esforço para utilizar, aprender o produto);
-Confiabilidade (frequência de falhas, recuperabilidade);
-Eficiência (característica relacionada ao desempenho);
-Manutenibilidade (esforço necessário para modificar);
-Portabilidade (capacidade de transferir o produto para outros ambientes).
Por não ter um modelo padrão para gerenciar requisitos podemos defini-los e adaptá-los de acordo com as necessidades do sistema. No entanto para o AcordeON os requisitos serão categorizados como funcionais (comportamentais) ou não funcionais (todos os outros).
REFERÊNCIAS:
- [http://www.macoratti.net/07/12/net_fer.htm]
- [http://www.brunobraga.com.br/2009/02/12/requisitos-nao-funcionais]
- Utilizando UML e Padrões , Craig Larman, 2° ed., Editora Bookman.
- Material disponibilizado para a matéria de Engenharia de Software na Uneb no semestre 2010.1
terça-feira, 12 de outubro de 2010
Ciclo de Vida
O desenvolvimento de um software não é um processo simples e que por muitas vezes pode se tornar ainda mais complicado devido a falhas no gerenciamento do projeto e na especificação do produto, tendo dados incorretos como duração do projeto e custo esperado. Antigamente a grandes maioria dos projetos iniciados terminavam – quando terminavam - atrasados, custando mais do que orçado inicialmente e com as funcionalidades incorretas ou incompletas. Atualmente esse quadro melhorou, mas ainda continua com um grande número de projetos “problemáticos”, muito dessa melhora deve-se ao surgimento da engenharia de software.
A engenharia de software tem como objetivo melhorar a qualidade do software e aumentar a produtividade e satisfação profissional nesse meio. A engenharia de software faz uso da combinação de métodos para as fases de desenvolvimento e de ferramentas para automação desses métodos para assegurar a qualidade dos softwares. Um dos tópicos da engenharia de software está relacionado às fases de desenvolvimento de softwares e se chama ciclo de vida.
O ciclo de vida de um software pode ser definido como um conjunto de passos que descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum. As macro-fases no desenvolvimento de qualquer software são basicamente: levantamento de requisitos, análise, projeto, implementação e testes. E os principais ciclos de vida são: modelo clássico(em cascata), prototipação, evolucionário, incremental e espiral.
O modelo clássico segue um fluxo seqüencial e linear onde cada fase apenas começa ao final da fase anterior. O ciclo em cascata apenas deve ser utilizado quando os requisitos forem bem compreendidos, pois sua inflexibilidade por torná-lo bastante complicado.
O modelo de prototipação é um modelo incremental que se utiliza de protótipos para uma melhor avaliação e refinamento do software a ser desenvolvido, tornando-o mais fácil de ser adaptado às necessidades do usuário.
O modelo evolucionário consiste na especificação e desenvolvimento de uma versão inicial e a partir desta, realizar verificações e validações gerando versões intermediárias, através de protótipos, até chegar à versão final do sistema.
O modelo incremental trata-se de uma abordagem intermediária que combina as vantagens dos paradigmas em cascata e evolucionário, sendo identificadas as funções do sistema, estabelecendo incrementos e prioridades. Cada incremento pode utilizar-se de um paradigma de desenvolvimento diferente.
O modelo espiral é o mais realístico, sendo um modelo incremental que conta com análise de riscos e prototipagem. Suas principais fases são: planejamento, análise de riscos, desenvolvimento e avaliação. Essas etapas se repetem em círculos até que se chegue na versão final do software.
Para o desenvolvimento do acordeon foi escolhido como modelo base o ciclo de vida em espiral. Além disso, a adoção de boas práticas de outros ciclos de vida será utilizada à medida que forem necessárias, caso haja a necessidade. A escolha desse ciclo de vida ocorreu de forma unânime entre os componentes do grupo de desenvolvimento Versão Beta, pois este ciclo consiste de um modelo incremental e iterativo, que adota as boas práticas do modelo clássico (em cascata) e do modelo de prototipação. A falta de experiência dos componentes na especificação de sistemas grandes e o curto tempo para o desenvolvimento foram fatores considerados no momento da decisão, pois através das iterações e das versões que surjam ao decorrer do projeto, requisitos e vulnerabilidades do sistema poderão ser identificados/validados mais facilmente.
Por se tratar de um grupo de desenvolvimento pequeno que conta apenas com 4 desenvolvedores, foi decidido entre os membros do grupo que além do ciclo de vida em espiral, algumas técnicas de metodologias ágeis serão estudadas e caso venham a auxiliar no desenrolar do projeto também poderão vir a ser utilizadas.
Referências:
- http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-parte-1.html
- http://www.inf.ufpr.br/silvia/ES/SweES/SweESalunos.pdf
- Material disponibilizado para a matéria de Engenharia de Software na Uneb no semestre 2010.1sexta-feira, 8 de outubro de 2010
Planejamento para Sexta-Feira(15.10)
- Apresentação Geral: Leonardo Rodrigues
- Ciclo de Vida adotado: Henrique Vidal
- Requisitos Não - Funcionais: Vitor Santos
- Requisitos Funcionais: Jussi Barros
- Protótipos de Tela: Jussi e Leonardo.
- Dúvidas e Questionamentos: Todos.
quarta-feira, 6 de outubro de 2010
Escopo do Projeto
Informações Gerais
Versão Beta
Componentes:
Henrique Vidal Filho
Jussi Oliveira Barros
Leonardo Pereira Rodrigues
Vitor Santos da Silva
Tecnologia:
Java J2EE
Ferramentas:
Astah (UML)
NetBeans (IDE)
EMS MySQL (Banco de Dados)
Divisão dos Estudos Iniciais
Ciclo de Vida (para desenvolvimento)
Responsável: Henrique Vidal Filho
Protótipo de Interface (Acessibilidade)
Responsável: Leonardo Pereira Rodrigues
Gerência de Requisitos (Funcionais e Não-Funcionais)
Responsáveis: Jussi Oliveira Barros e Vítor Santos da Silva