Anda di halaman 1dari 6

O Processo de Desenvolvimento de Software

Objetivos

Contextualizar Anlise 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 no suficiente Precisamos tambm de um processo de desenvolvimento o Linguagem de modelagem + processo de desenvolvimento = mtodo (ou metodologia) de desenvolvimento O que um processo de desenvolvimento? o Define quem faz o que, quando e como, para atingir um certo alvo Veremos os detalhes de processos concretos em outras disciplinas o Aqui, s uma introduo As grandes fases de qualquer processo de desenvolvimento o Planejamento e elaborao Planejamento, definio de requisitos, construo de prottipos (opcional) o Construo do sistema (inclui codificao e testes) o Implantao (colocar em produo, treinar usurios, ...)

A Fase de Planejamento e Elaborao


1. 2. 3. 4. 5. 6. Criar relatrio inicial de investigao (para construir o business case) Levantar requisitos funcionais e no funcionais Construir glossrio (ao longo da fase) Definir modelo conceitual inicial (anlise inicial) Projetar arquitetura Priorizar a funcionalidade e distribu-la entre as iteraes

Detalhes sobre o levantamento de requisitos


Requisitos so "cortes" no espao de soluo Entendimento do que o usurio quer O resultado uma promessa para o cliente No s requisitos funcionais, mas tambm: o Facilidade de uso necessria o Quem utilizar o produto o Hardware e software alvo para o produto o Qualidade/robustez o Desempenho o Segurana

Compatibilidade com outros produtos/verses e necessidades de migrao o Necessidades de internacionalizao do produto o Suporte o Preo da soluo o Documentao necessria o Uso de padres o Aspectos legais o Integrao com outros produtos o Packaging o etc. No se fala "como" as coisas sero feitas "Use cases" descrevem cenrios de funcionalidade desejada o Tambm chamados de "User Stories", pois o usurio que decide o que deve ser feito

Detalhes sobre a fase de Construo

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

O que feito a cada iterao? o Anlise (refinamento de requisitos, refinamento do modelo conceitual) o Projeto (refinamento do projeto arquitetural, projeto de baixo nvel) o Implementao (codificao e testes) o Transio para produto (documentao, instalao, ...)

Detalhes sobre a anlise


A anlise gera um modelo para entender o domnio do problema Anlise tambm trata em alto nvel de como uma soluo possvel pode ser montada para atender aos requisitos o Acaba gerando uma especificao, mas sempre do ponto de vista do usurio e tratando apenas do domnio do problema No trata de detalhes de implementao Objetos tratados so sempre do domnio do problema (business objects) Muitos diagramas UML podem ser usados o O modelo para o cliente e no para o programador Atividades tpicas durante a anlise 1. 2. 3. 4. 5. 6. Refinar use cases Refinar modelo conceitual Refinar glossrio Definir diagramas de seqncia (opcional) Definir contratos de operao (opcional) Definir diagramas de estado (opcional)

Detalhes sobre o projeto (design)


O projeto uma extenso do modelo de anlise visando sua implementao num computador Novos objetos aparecem, mas no so do domnio do problema O resultado para o programador ver, no o cliente Objetos da anlise so (geralmente) mantidos e so embutidos numa infraestrutura tcnica

As classes tcnicas ajudam os business objects a: Serem persistentes Se comunicarem Se apresentarem na interface do usurio Terem desempenho aceitvel (usando caches ou threads, por exemplo) As atividades de projeto incluem: o Fase de refinamento da arquitetura (high-level design) Definio de pacotes (mdulos), interfaces entre pacotes Deciso sobre uso/criao de bibliotecas e/ou componentes Falaremos disso em detalhes adiante o Fase de projeto detalhado (low-level design) Atribuio de responsabilidades entre os objetos Construo de diagramas de classes Pode incluir documentao javadoc (ideal) Construo de diagramas de interao (opcional) Levantamento de necessidades de concorrncia Consideraes de tratamento de falhas Detalhamento do formato de sada (interface com usurio, relatrios, transaes enviadas para outros sistemas, ...) Definio do esquema do BD Mapeamento de objetos para tabelas se o BD for relacional o Advertncia: se voc usar Test-Driven Development, ento o design feito bolando testes e escrevendo o software ao mesmo tempo Neste caso, fazer diagramas ou Javadoc antes de codificar no funciona

Detalhes sobre a implementao


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

Detalhes sobre os testes


Inclui vrias fases de testes Testes feitos pelo prprio programador durante a programao o Unit test: teste de classes individuais (ou de grupos de classes relacionadas) o Functional test: teste de funes inteiras (item de menu, p. ex.) o Component test: teste de componentes inteiros (exe, dll, ...) sem (ou com pouco) scaffolding Testes feitos por equipes independentes de teste o System test: testa a integrao entre todos os componentes do produto o Alpha test: teste de produto inteiro dentro de casa o Beta test: teste de produto inteiro fora de casa

Testes devem ser automatizados

Anda mungkin juga menyukai