Projeto de desenvolvimento de software passo a passo

Objetivos

• Contextualizar An�lise e Projeto de software dentro de uma metodologia de desenvolvimento (um processo de desenvolvimento de software)

Um processo de desenvolvimento de software

• Uma linguagem de modelagem n�o � suficiente
• Precisamos tamb�m de um processo de desenvolvimento
  • Linguagem de modelagem + processo de desenvolvimento = m�todo (ou metodologia) de desenvolvimento
• O que � um processo de desenvolvimento?
  • Define quem faz o que, quando e como, para atingir um certo alvo
• Veremos os detalhes de processos concretos em outras disciplinas
  • Aqui, s� uma introdu��o
• As grandes fases de qualquer processo de desenvolvimento
  • Planejamento e elabora��o
    • Planejamento, defini��o de requisitos, constru��o de prot�tipos (opcional)
  • Constru��o do sistema (inclui codifica��o e testes)
  • Implanta��o (colocar em produ��o, treinar usu�rios, ...)

A Fase de Planejamento e Elabora��o

1. Criar relat�rio inicial de investiga��o (para construir o business case)
2. Levantar requisitos funcionais e n�o funcionais
3. Construir gloss�rio (ao longo da fase)
4. Definir modelo conceitual inicial (an�lise inicial)
5. Projetar arquitetura
6. Priorizar a funcionalidade e distribu�-la entre as itera��es

Detalhes sobre o levantamento de requisitos

• Requisitos s�o "cortes" no espa�o de solu��o
• Entendimento do que o usu�rio quer
• O resultado � uma promessa para o cliente
• N�o s� requisitos funcionais, mas tamb�m:
  • Facilidade de uso necess�ria
  • Quem utilizar� o produto
  • Hardware e software alvo para o produto
  • Qualidade/robustez
  • Desempenho
  • Seguran�a
  • Compatibilidade com outros produtos/vers�es e necessidades de migra��o
  • Necessidades de internacionaliza��o do produto
  • Suporte
  • Pre�o da solu��o
  • Documenta��o necess�ria
  • Uso de padr�es
  • Aspectos legais
  • Integra��o com outros produtos
  • Packaging
  • etc.
• N�o se fala "como" as coisas ser�o feitas
• "Use cases" descrevem cen�rios de funcionalidade desejada
  • Tamb�m chamados de "User Stories", pois � o usu�rio que decide o que deve ser feito

Detalhes sobre a fase de Constru��o

• Hoje, � considerado errado ter um processo que gere um "big bang!"
  • N�o se deve ter o software inteiro funcionando por inteiro no primeiro release
  • O risco � grande demais!
• Um processo de desenvolvimento deve ser:
  • Iterativo (ter v�rias itera��es no tempo)
  • Incremental (gerar novas vers�es incrementadas a cada release)
  • Uma itera��o dura entre 2 semanas e 2 meses
• Motivos:
  • Sempre tem algo para entregar para o cliente apressado (a �ltima itera��o)
  • Os requisitos mudam com tempo e um processo iterativo mant�m freq�entes contatos com o cliente o que ajuda a manter os requisitos sincronizados
  • Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo
  • Para evitar isso:

• O que � feito a cada itera��o?
  • An�lise (refinamento de requisitos, refinamento do modelo conceitual)
  • Projeto (refinamento do projeto arquitetural, projeto de baixo n�vel)
  • Implementa��o (codifica��o e testes)
  • Transi��o para produto (documenta��o, instala��o, ...)

Detalhes sobre a an�lise

• A an�lise gera um modelo para entender o dom�nio do problema
• An�lise tamb�m trata em alto n�vel de como uma solu��o poss�vel pode ser montada para atender aos requisitos
  • Acaba gerando uma especifica��o, mas sempre do ponto de vista do usu�rio e tratando apenas do dom�nio do problema
• N�o trata de detalhes de implementa��o
• Objetos tratados s�o sempre do dom�nio do problema (business objects)
• Muitos diagramas UML podem ser usados
  • O modelo � para o cliente e n�o para o programador
• Atividades t�picas durante a an�lise

1. Refinar use cases
2. Refinar modelo conceitual
3. Refinar gloss�rio
4. Definir diagramas de seq��ncia (opcional)
5. Definir contratos de opera��o (opcional)
6. Definir diagramas de estado (opcional)

Detalhes sobre o projeto (design)

• O projeto � uma extens�o do modelo de an�lise visando sua implementa��o num computador
• Novos objetos aparecem, mas n�o s�o do dom�nio do problema
• O resultado � para o programador ver, n�o o cliente
• Objetos da an�lise s�o (geralmente) mantidos e s�o embutidos numa infra-estrutura t�cnica
  • As classes t�cnicas ajudam os business objects a:
    • Serem persistentes
    • Se comunicarem
    • Se apresentarem na interface do usu�rio
    • Terem desempenho aceit�vel (usando caches ou threads, por exemplo)
• As atividades de projeto incluem:
  • Fase de refinamento da arquitetura (high-level design)
    • Defini��o de pacotes (m�dulos), interfaces entre pacotes
    • Decis�o sobre uso/cria��o de bibliotecas e/ou componentes
    • Falaremos disso em detalhes adiante
  • Fase de projeto detalhado (low-level design)
    • Atribui��o de responsabilidades entre os objetos
    • Constru��o de diagramas de classes
      • Pode incluir documenta��o javadoc (ideal)
    • Constru��o de diagramas de intera��o (opcional)
    • Levantamento de necessidades de concorr�ncia
    • Considera��es de tratamento de falhas
    • Detalhamento do formato de sa�da (interface com usu�rio, relat�rios, transa��es enviadas para outros sistemas, ...)
    • Defini��o do esquema do BD
    • Mapeamento de objetos para tabelas se o BD for relacional
  • Advert�ncia: se voc� usar Test-Driven Development, ent�o o design � feito bolando testes e escrevendo o software ao mesmo tempo
    • Neste caso, fazer diagramas ou Javadoc antes de codificar n�o funciona

Detalhes sobre a implementa��o

• Escrita do c�digo
• Relativamente simples se o projeto tiver sido bem feito
• Programadores devem normalmente seguir regras de codifica��o da empresa
• Atividades incluem code reviews
• N�o se deve chegar a esta fase cedo demais!
  • Mais cedo voc� agarra o teclado, mais vai demorar a terminar!
• Poucos novos diagramas nesta fase

Detalhes sobre os testes

• Inclui v�rias fases de testes
• Testes feitos pelo pr�prio programador durante a programa��o
  • Unit test: teste de classes individuais (ou de grupos de classes relacionadas)
  • Functional test: teste de fun��es inteiras (item de menu, p. ex.)
  • Component test: teste de componentes inteiros (exe, dll, ...) sem (ou com pouco) scaffolding
• Testes feitos por equipes independentes de teste
  • System test: testa a integra��o entre todos os componentes do produto
  • Alpha test: teste de produto inteiro dentro de casa
  • Beta test: teste de produto inteiro fora de casa
• Testes devem ser automatizados

intro programa

Como montar um projeto de desenvolvimento de software?

Quais as etapas do processo de desenvolvimento de software?

Quais são as 4 etapas do planejamento do projeto de software?

Quais são os 4 passos para o desenvolvimento de sistemas?