Aula de Apresentação do Projeto
OBJETIVOS
Após esta aula o aluno deverá:
- conhecer a técnica Waterfalls a ser aplicada no desenvolvimento do projeto;
- estar ciente da equipe a qual ele pertencerá no desenvolvimento do projeto integrador;
- saber o papel do líder da equipe e da dinâmica de mudança de líder;
- estar ciente da proposta de projeto realizada pelos clientes (professores);
- estar ciente de como se dará a avaliação do projeto integrador;
- dar início a realização do projeto.
Modelo do ciclo de vida de software
Muitos modelos diferentes foram criados para representar o ciclo de vida do software. Embora estes modelos utilizam vários nomes para os processos do ciclo de vida, todos eles incluem de algum modo os seis processos: Engenharia de Requisitos; Projeto; Implementação; Integração e Teste; Entrega e Manutenção. Além disso, estes modelos geralmente enfatizam algum outro aspecto do desenvolvimento de software, tais como uma técnica de projeto particular (por exemplo, a prototipagem rápida (video sobre a prototipagem em papel), uma técnica de gestão (por exemplo, gestão de risco), ou um modelo para descrever um domínio limitado de desenvolvimento de software (por exemplo, software de tempo real).
Você pode se surpreender ao descobrir que de todos estes processos, a manutenção chega a 67% do custo do ciclo de vida de um software. Por isso, muitos desenvolvedores buscam usar abordagens de projeto que resultem em software que é mais fácil de manter.
- Engenharia de Requisitos
Durante este processo, os desenvolvedores e clientes se reúnem para discutir idéias para o novo produto de software. Os desenvolvedores usam uma variedade de técnicas, a fim de avaliar as reais necessidades do cliente. Uma dessas técnicas é prototipagem rápida em que um programa protótipo é construído que pode imitar a funcionalidade do software desejado. Usando este protótipo, os clientes podem entender melhor como o produto final irá se comportar e pode determinar se esse comportamento é o que eles realmente precisam. A menos que o processo de engenharia de requisitos é feito corretamente, o software resultante não será útil para o cliente, embora possa funcionar corretamente. O processo de engenharia de requisitos é concluída quando as especificações para o novo produto de software são escritos em um documento formal, chamado de documento de especificação de requisitos.
- Projeto
Durante este processo, os desenvolvedores decidem como irão construir o software para que ele atenda as especificações acordadas no documento de especificação de requisitos. Normalmente, o desenho do software passa por várias etapas em que se torna progressivamente mais detalhada. Esta abordagem de design é chamado de refinamento passo a passo, e permite os desenvolvedores gerenciar a complexidade do software, adiando decisões dos detalhes para mais tarde possível, a fim de se concentrar em outras questões importantes do projeto. Quando o projeto é completo, fica registrado no documento de especificação do projeto.
- Implementação/Programação
Durante este processo, as equipes de programadores escrevem o código real do software. O software é dividido em unidades separadas chamados módulos, a fim de lidar com a complexidade do processo de programação. As equipes não são apenas responsáveis pela codificação de seus módulos, mas também pela devida documentação do código e teste para garantir exatidão.
- Integração e Teste
Durante este processo, os módulos individuais do produto de software são combinados para formar o produto de software integrado. Uma vez que os módulos foram desenvolvidos separadamente, o teste é crucial no processo de integração. Mesmo com um bom projeto, incompatibilidades entre os módulos podem existir. Esses problemas precisam ser identificados e corrigidos para completar a integração.
- Entrega
Durante este processo, os programadores entregam o software completado para os clientes. Normalmente, os clientes irão realizar testes de aceitação do software para determinar se cumpre ou não as especificações acordadas no documento de especificação de requisitos. Uma vez que o software seja aceito, ele é instalado e utilizado pelo cliente.
- Manutenção
Durante este processo, o software passa por várias mudanças após seu lançamento inicial, a fim de corrigir bugs, adicionar novas funcionalidades, portar o software para novas plataformas, ou adaptar o software às novas tecnologias. Embora possa parecer que o software deve estar concluído após após seu lançamento inicial, isso está longe de ser verdade. Todos os produtos de software de sucesso evoluem com o tempo para atender às novas necessidades dos clientes.
- FONTE: http://courses.cs.vt.edu/csonline/SE/Lessons/LifeCycle/index.html (tradução)
O modelo em cascata (Waterfall)
O modelo em cascata é o clássico modelo de ciclo de vida do software. Este modelo foi aceito até o início de 1980, representa o ciclo de vida de software utilizando processos e produtos. Cada processo transforma um produto para produzir um novo produto como saída. Em seguida, o novo produto torna-se a entrada do processo seguinte. A tabela abaixo lista os processos e produtos do modelo cascata.
| Entrada de Produto | Processo | Saída de Produto |
|---|---|---|
| Comunicação dos Requisitos | Engenharia de Requisitos | Documento de Especificação de Requisitos |
| Documento de Especificação de Requisitos | Projeto | Documento de Especificação do Projeto |
| Documento de Especificação do Projeto | Implementação/Programação | Módulos de software executáveis |
| Módulos de software executáveis | Integração e Testes | Módulos integrados no produto |
| Módulos integrados no produto | Entrega | Produto de software entregue |
| Produto de software entregue | Manutenção | Requisitos alterados |
Para entender melhor estes processos e produtos, ver a animação do modelo Waterfall.
Sobre a metodologia de projeto a ser usada
A metodologia usada para desenvolvimento do sistema será uma adaptação do modelo clássico Waterfalls:
- Definição, planejamento e análise de requisitos (ver[1],):
- Comunicação inicial com os clientes na forma de uma reunião: produto gerado -> ata da reunião com os clientes (no caso, os professores);
- Definição inicial, planejamento([2]) e levantamento de recursos necessários: reunião com o grupo para uma primeira definição do sistema e um planejamento das fases do Waterfalls -> geração de um documento de planejamento das etapas (Gantt Chart na wiki). Divisão de funções para a primeira etapa;
- Análise de Requisitos: confecção do documento de análise de requisitos Documento de Especificação. Ver um exemplo aqui.
- Projeto
- Implementação
- Integração, testes e apresentação
Especificação de Requisitos
Benefícios de uma boa especificação
- Estabelece uma base para o acordo entre o cliente e o fornecedor do sistema;
- Reduz o esforço de desenvolvimento;
- Estabele uma base para determinação de custos e tempo de desenvolvimento (e cronograma);
- Facilita a adaptação do software para outros contextos;
- Base para refinamentos futuros: foco no produto;
O que deve conter um Documento de Especificação
- Funcionalidade: O QUE o sistema faz;
- Interfaces externas: como o sistema interage com usuários e sistemas externos;
- Aspectos de Desempenho: tempo de resposta, tempo de recuperação após uma falha;
- Atributos: portabilidade, segurança, facilidades de manutenção;
- Limitações: limitações de recursos, limitações impostas por padrões, linguagens a serem usadas, ambientes de operação;
Do trabalho em equipe
Critérios para a formação das equipes
- As equipes serão constituídas de 4 alunos
- As equipes respeitarão a divisão em turmas A e B de laboratório (4 equipes por turma)
- Na escolha das equipes, os cabeças de equipe serão os 4 alunos com maior idade na turma, sendo os demais integrantes escolhidos por sorteio;
- Cada equipe terá um líder aluno que compartilhará a liderança com um professor
- A liderança será alternada a cada fase do projeto:
- Análise e especificação do sistema
- Projeto
- Implementação/Programação
- Testes e Integração
Cabe ao líder
- Coodernar as reuniões e atividades da equipe;
- Tomar a decisão final nos encaminhamentos do trabalho;
- Delegar funções aos demais integrantes;
- Cobrar a execução das tarefas segundo o cronograma;
- Avaliar seus liderados;
- Garantir que os documentos da etapa estejam prontos na data prevista;
- Revisar documentos que devam ser alterados ao longo do ciclo de vida.
Divisão das equipes
- Turma B (quintas 7h30 as 9h20)
- Equipe 1: LETICIA SCHUELTER DE LIMA, MARIANA BEATRIZ GHIZONI, THIAGO HENRIQUE BONOTTO DA SILVA, ZILMAR DE SOUZA JUNIOR
- Equipe 2: MARCUS VINICIUS BUNN, TAMARA RAMOS ARRIGONI, WILLIAM MARCOS RIBEIRO
- Equipe 3: FABIO ESPINDOLA KOERICH, LEONARDO SCHUTZ, LUIZ GUSTAVO DE NARDI KELM FERREIRA, THAIANE VERBENA OLIVEIRA
- Equipe 4: LEONAN DA SILVA SARAIVA, NICOLE ACORDI DA SILVA, PRISCILA GOMES DOS SANTOS MARTINS, THIAGO WERNER
- Turma A (quintas 9h40 as 11h30)
- Equipe 5: ADILSON GOEDERT SIQUEIRA, FLAVIA DE OLIVEIRA BARBOSA, GUSTAVO CONSTANTE
- Equipe 6: BRUNO CARMINATTI DA SILVA, DOMENICA SOARES DA SILVA, JEAN MICHEL DE SOUZA SANT ANA, JOCELIO VIEIRA PAMPLONA
- Equipe 7: DANILO BEDAQUE, ERNANI RODRIGUES DE S.THIAGO, IGOR ALTHOFF VIDAL, RAMIREZ OLIVEIRA DA SILVA
- Equipe 8: ELTON FERREIRA BROERING, GUILHERME HUBERT, KATHARINE SCHAEFFER FERTIG, KRISTHINE SCHAEFFER FERTIG
OBS: Cada equipe tem um link na wiki, no qual pode registrar informações sobre o projeto que não sejam sigilosas. Basta que cada membro da equipe esteja cadastrado no portal de alunos do IF-SC. Depois pode acessar a wiki com o mesmo login e senha. Por questões de segurança o sistema aguarda 24 horas para permitir a edição de paginas pelos usuários novos, por isso não estranhem se não conseguirem editar no primeiro login.
Sobre as reuniões da equipe
- As reuniões da equipe deverão ser registradas na forma de ata conforme modelo;
- As reuniões poderão ser virtuais, através de Skype, Facebook, ou outra forma de comunicação.
- Todos os documentos da equipe serão publicadas na pasta compartilhada da equipe no google doc (google drive). O compartilhamento será entre seus integrantes e os professores. Os documentos de cada equipe deverão permanecer em sigilo em relação as demais equipes.
- Modelo de Ata de Reunião
- Modelo do Documento de Especificação de Requisitos
Do problema proposto
O problema a ser resolvido foi comunicado através de duas reuniões entre os clientes (professores Marcos Moecke e Eraldo Silveira e Silva) com as equipes de desenvolvimento do projeto na Turma B (Equipes 1 a 4) e Turma A (Equipes 5 a 8). A gravação dessas reuniões foi disponibilizado no google drive.
- É incentivada a troca de conhecimentos entre as equipes sobre técnicas, programação em App inventor e Scratch, mas as soluções adotadas por cada equipe deverá permanecer em sigilo.
- O prazo final para entrega do produto será: 05 de julho de 2012 (apresentação do produto) e 09 de julho de 2012 (teste do produto em uma situação real).