Mudanças entre as edições de "Aula de apresentação do projeto"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
(Limpou toda a página)
 
Linha 1: Linha 1:
−
=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 [http://youtu.be/Js2vz8d8P_A (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.
 
−
 
−
{| border="1" cellpadding="2"
 
−
!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 [http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/waterfallmodel.html modelo Waterfall].
 
−
 
−
[[Arquivo:WaterfallModel.png|center|modelo Waterfall (FONTE: http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/waterfallmodel.html]]
 
−
 
−
=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[http://www.microtoolsinc.com/Howsrs.php],):
 
−
**Comunicação inicial com os clientes na forma de uma reunião: produto gerado -> [http://www.colegioweb.com.br/portugues/atas-de-reuniao.html ata da reunião] com os clientes (no caso, os professores);
 
−
**Definição inicial, planejamento([http://www.construx.com/File.ashx?cid=1190]) 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 [http://techwhirl.com/skills/tech-docs/writing-software-requirements-specs/ Documento de Especificação]. Ver um exemplo [http://www.atunes.org/wiki/index.php?title=Software_Requirements_Specification aqui].
 
−
*Projeto
 
−
*Implementação
 
−
*Integração, testes e apresentação
 
−
[[Arquivo:IFSC-PJI1Model.png|center|modelo IFSC Projeto Integrador 1 - engetelecom]]
 
−
 
−
==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 grupo=
 
−
 
−
==Critérios para a formação dos grupos==
 
−
* Os grupos serão de 4 alunos
 
−
* Grupos serão formados respeitando as turmas A e B de laboratório (4 grupos por turma)
 
−
* Na escolha dos grupos, os cabeças de grupo serão os 4 alunos com maior idade na turma, sendo os demais integrantes escolhidos por sorteio;
 
−
* Cada grupo 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 do grupo;
 
−
* 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
 
−
 
−
==Sobre as reuniões do grupo==
 
−
*As reuniões do grupo 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 do grupo serão publicadas na pasta compartilhada da equipe no google doc (google drive). O compartilhamento será entre os integrantes do grupo e os professores.  Os documentos de cada equipe deverão permanecer em sigilo em relação as demais equipes.
 
−
*[https://docs.google.com/document/d/19XSQdtATsCPAD_dpvgfRdZHHvtracENJz-OLzxBoVZk/edit Modelo de Ata de Reunião]
 
−
*[https://docs.google.com/document/d/1oNpqLxmV8I5LA52KkU0y0evVDcGNZQX7-q2T9sMkAcA/edit 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 os grupos 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).
 

Edição atual tal como às 19h19min de 11 de maio de 2012

Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=Aula_de_apresentação_do_projeto&oldid=43321”