INCREMENTO II - DIVISÃO DOS MÓDULOS

Vitor
- Validações de campos do formulário (Incremeto I)
- Módulo de Recados (enviar recados/listar/excluir enviados) - Incremento II


Leonardo
- Tratamento de entradas duplicadas no banco de dados (Incremeto I)
- Módulo de Recados (responder/listar/excluir recados recebidos) - Incremento II


Jussi
- Construção de layout básico (Incremento I)
- Modulo de Amigos (solicitar/listar/excluir amigos) - Incremento II


Henrique
- Complementar a implementação de perfil (Incremento I)
- Módulo de Amigos (aceitar/buscar amigos) - Incremento II

Projeto - Incremento I

AcordeOn

PROJETO ARQUITETURAL

Diagrama de Classes - Fase Projeto

Em processo de amadurecimento...

Exemplo de Diagrama de Sequência

Detalhamento dos Casos de Uso - Incremento I

Clique aqui para visualizar o documento

Diagrama de Classes - Requisito 1(corrigido)

Abaixo segue diagrama de classes (DC). Esta versão do DC foi modificada após avaliação com o professor.

Detalhamento dos Métodos de Negócio

Clique aqui para acessar o documento

Projeto Arquitetural

A imagem a seguir representa o projeto arquitetural do AcordeON - Sistema colaborativo Musical. O modelo foi proposto a partir das tecnologias selecionadas para o desenvolvimento e da infraestrutura disposta inicialmente.

O modelo pode vir a sofre modificações ao decorrer das análises e desenvolvimento.

Definição de InfraEstrutura e Tecnologias

• InfraEstrutura
• Banco de dados MySql
  
• Servidor de Aplicação GlassFish V3

A infraestrura já foi decidida, faltando apenas a disponibilização de uma máquina servidora central que já está sendo providenciada. A estrutura será centralizada, onde todos os itens descritos acima estarão localizadas em uma única máquina.

• Tecnologias
  
• JSF 2.0
  
• Hibernate 3

As tecnologias foram definidas a partir do conhecimento prévio dos desenvolvedores e de testes básicos realizados para verificar a viabilidade das mesmas. Para estas definições foi considerada a facilidade de encontrar documentação e materiais de auxílio.

Diagrama de Classes do Requisito 1

Casos de Uso do Requisito 1

Requisito 1: Gerenciar Perfil/Conta de Usuário

CASOS DE USO

1 - Cadastrar conta de usuário
    Durante o cadastro de sua conta (criação de perfil), um usuário deve fornecer nome completo, cpf, data de nascimento, email com o qual a conta estará vinculada, cidade, estado, país, nome de usúário, senha e deve aceitar o termo de compromisso do AcordeOn. Uma pessoa poderá criar quantas contas quiser, contanto que já não tenha cadastrado um cpf semelhante.
  
2 - Remover conta de usuário
    Se uma pessoa já possui uma conta no AcordeOn, ela terá a possibilidade de remover esta conta, ou seja, ela naõ terá mais vínculo com seus amigos da rede e somente seus arquivos compartilhados permaneceram disponíveis para os colaboradores escolhidos.

3 - Editar conta de usuário
    Os usuários poderão alterar qualquer informação que forneceu do seu cadastro, com exceção de cpf.

4 - Editar perfil
    O usuário que já possuir uma conta cadastrada no AcordeOn automaticamente já possui um perfil padrão com informações básicas que foram coletadas no momento de cadastro. Ele poderá editar seu nome de exibição, descrição pessoal, áreas de interesse, estilos musicais de preferência e foto.

Slides da apresentação 15-10-2010

Apresentação do Sistema AcordeON

Escolha do Primeiro Incremento

Requisito escolhido: "Gerenciar Perfil/Conta de usuário"

- Itens a serem observados nessa fase:
* casos de uso
* diagramas de classes
* arquitetura inicial
* esquema de banco de dados
* tecnologias utilizadas
* etc.

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.

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

Atividade imprescindível para um processo de desenvolvimento de software, o levantamento de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e orçamento adequados tornando-se, cada vez mais, um fator decisivo para um projeto de software bem qualificado, que atinge ou até mesmo excede as expectativas dos clientes.
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

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.1

Planejamento para Sexta-Feira(15.10)

Na sexta feira, dia 15.10.10, haverá a apresentação do projeto. Sendo assim, a apresentação ficará organizada da seguinte forma:

- 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.

Escopo do Projeto

Rede social onde cada membro poderá compartilhar composições musicais (letras, cifras, partituras e/ou melodias) prontas ou incompletas, as quais poderão ser editadas ou complementadas por seus amigos, e visualizada por todos os membros do ambiente. Além disso, poderiam ser disponibilizadas versões beta das músicas para serem ouvidas no próprio domínio da rede.

Informações Gerais

Equipe:
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

Para sexta-feira dia 08/10, estudar base teórica sobre:

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