GRA6432
Automação Comercial
Competências e Saberes da
Disciplina
Prof. Paulo Alipio Alves de Oliveira
2010
Objetivo Principal
• Na disciplina de Automação Comercial, o aluno terá
contato com ferramentas de desenvolvimento de banco
de dados e programas (dominará as técnicas para
desenvolvimento) e análise via desenvolvimento de
UML e estará apto a codificar e corrigir eventuais erros
de sintaxe e lógica estruturada, através de conceitos de
programação estruturada de sistemas e desenvolver,
através de análise de negócios, análise de processos e
análise de sistemas orientado ao objeto e todo o
planejamento técnico para desenvolver um sistema de
gestão empresarial modular com conexão à um banco
de dados e implementar todo o conhecimento adquirido
para implementação de programas.
2
Raciocínio Lógico e Conhecimento
3
Resultado Desejado
• Aliando conhecimento, experiência, didática, lógica
apurada, percepção para melhor solução dentre
muitas, metodologia, utilização de TI, dentre outros
atributos de um bom analista de sistemas, pode-se
conceber um bom planejamento e
desenvolvimento/criação de uma solução para uma
determinada necessidade/problema chegando-se a
um produto/serviço ideal. Esta será a principal
característica a ser proposta ao acadêmico para o
semestre: atribuição da melhor lógica amparada ao
seu conhecimento e informações.
4
Processos
• Porque não usamos?
–
–
–
–
Sentimento de perda de tempo
Falta de informação
Falta de uma política organizacional
Frases-chave:
• “Já está dando certo do jeito que está”
• “O usuário quer resultado logo”
• “Já dirijo à mais de 30 anos”
• Decidimos usar quando...
– Sentimento de “falta de direção”
– A manutenção de um sistema está saindo “cara” demais
5
Modelo cascata
• Primeiro processo
– Managing the development of large software
systems. W.W.Royce (1970)
– Modelo seqüencial de atividades
• Fortemente inspirado dos processos de
engenharia tradicionais
– “Engenharia de Computação”
– Necessidades  Projeto  Execução
• Atividades
– Análise  Projeto  Codificação  Teste  Manutenção
6
Managing the development of large
software systems. W.W.Royce
• Este modelo é muito simples de entender seu
funcionamento e uso. Royce (1970) caracteriza o
modelo cascata como um processo com a qual
cada fase deve ser terminada completamente antes
da fase seguinte começar. No fim de cada fase,
uma revisão ocorre para determinar se o projeto
está no trajeto correto, dizendo se o fluxo do
processo pode continuar ou não.
• Veja a figura:
7
Modelo Cascata - Royce
8
Modelo cascata
• Suposições
– Todos os requisitos são previamente conhecidos
– Requisitos não mudam
– Usuários sabem o que querem e só precisam ver o sistema quando este
estiver concluído
– Projetos podem ser feitos de maneira completamente abstrata
– Codificação sempre se adequa aos projetos (design)
– Manutenção é trivial
• Evolução
– Fonte
– Espiral
Análise
Testes
Codificação
Testes
Projeto
Projeto
Análise
Codificação
9
Surgiu então o Processo Unificado
• O que é o Processo Unificado (UP)?
– Metodologia de desenvolvimento de software iterativo e
incremental
– Procura estabelecer práticas que visem garantir a produção de
um software de alta qualidade, dentro de um cronograma e
orçamento possível.
• Principais práticas
–
–
–
–
–
–
Desenvolver iterativamente
Gerenciar Requisitos
Usar arquiteturas baseada em componentes
Modelar software visualmente
Verificar continuamente a qualidade do software
Controlar mudanças
10
Visão em espiral do UP
11
Visão Geral
12
Modelo Interativo e Incremental
• O modelo iterativo e incremental é um processo
cíclico de desenvolvimento para atender as
fraquezas do modelo cascata, o mais tradicional. O
modelo iterativo procede usando as lições
aprendidas por cada fase para modificar os
resultados da fase anterior.
• O desenvolvimento iterativo é também referenciado
como desenvolvimento incremental (Hurst, 2007).
13
Conceitos principais
• Componentes estáticos
–
–
–
–
–
Disciplinas
Fluxos
Papéis
Atividades
Artefatos
• Componentes dinâmicos
–
–
–
–
Ciclos
Fases
Iterações
Marcos
14
Conceitos-chave: Disciplina
• Disciplina
– Uma disciplina é um conjunto de atividades relacionadas
a uma “área de interesse” importante em todo o projeto.
– O fluxo de trabalho de uma disciplina é uma seqüência
semi-ordenada das atividades que são realizadas para
alcançar um determinado resultado.
• Tipos
– Relacionadas ao desenvolvimento
• Requisitos, análise e Design, implementação, implantação,...
– Relacionadas ao suporte
• Ger. de projeto, ger. de configuração e mudança, ambiente,...
15
Conceitos-Chave: Fluxo ou WBS
• Fluxo de Trabalho
– Uma simples enumeração de todos os papéis, atividades
e artefatos não constitui um processo;
– É necessária uma forma para descrever as seqüências
significativas das atividades que produzem algum
resultado importante e para mostrar as interações entre
os papéis.
– O fluxo de trabalho é uma seqüência das atividades que
produzem um resultado de valor observável.
16
Conceitos-Chave - Fluxo
17
Conceitos-Chave: Papel
• Define
– Comportamento e as responsabilidades de um indivíduo
ou de um conjunto de indivíduos que trabalham juntos
como uma equipe
• Papéis não são indivíduos
– Descrição do comportamento e das responsabilidades
que eles devem ter.
• Exemplos
– Analista de Sistemas, Designer de Negócio, Revisor de
Requisitos, Implementador, Arquiteto de Software,…
18
Conceitos-Chave: Atividade
• Uma atividade é uma unidade de trabalho que um
indivíduo, desempenhando o papel descrito, pode
ser chamado a realizar.
• Os papéis possuem atividades que definem o
trabalho que executam. Uma atividade é algo que
um papel faz e produz um resultado significativo no
contexto do projeto
• Exemplos
– Avaliar viabilidade do conceito arquitetural
– Estruturar modelo de implementação
“ Perceba que o verbo sempre está no infinitivo”
19
Conceitos-Chave: Artefato
• Um artefato é um produto de
trabalho do processo: os papéis
usam os artefatos para executar
atividades e produzem artefatos
ao executarem as atividades
• As atividades possuem artefatos
de entrada e saída
• Exemplo
Analista de Sistema/
Especificador de Requisitos
Domínio de Negócio e Especificação
de Casos de uso
20
Componentes dinâmicos
• UP é um processo baseado no modelo espiral
– Projeto dividido em ciclos
– Cada ciclo representa uma nova versão (release) do produto
– Cada ciclo possui 4 fases consecutivas
• Fases
– Iniciação ou Visão – definição do escopo
– Planejamento – análise e projeto
– Desenvolvimento ou Construção – desenvolvimento e
integração
– Transição ou Implementação/Instalação/Acompanhamento –
passagem ao “domínio público”
• O final das fases define os principais marcos do projeto
• Cada fase pode ser quebrada em iterações
– Cada iteração resulta em uma nova release (versão)
21
Fase de Iniciação ou Visão
• Objetivos
– Definir o caso de negócio do sistema
• Critério de sucesso, análise de risco,
planejamento de recursos e de tempo
(cronograma)
– Delimitar o escopo do projeto
• Saídas
–
–
–
–
Documento de visão do projeto
Caso de uso inicial (~ 20%)
Caso de negócio do sistema
Planejamento inicial (custo, cronograma,
processo,...)
– Possíveis protótipos (avaliação)
22
Marco da fase de incepção
• O fim da fase é um marco do projeto (milestone),
cujos critérios de avaliação são:
– Tomador de decisão (stakeholder) está de acordo com o
escopo e o custo e tempo estimados
– Requisitos bem compreendidos (a julgar pelo caso de uso
inicial)
– Custos e cronograma correspondem a realidade
– Avaliação dos protótipos desenvolvidos
• O projeto pode ser cancelado ou revisto se não
passar nos critérios desse marco
23
Fase da Planejamento/Elaboração
• Objetivos
– Analisar o domínio do problema
– Definir uma arquitetura de base
– Desenvolver o planejamento do projeto,
de forma a eliminar os maiores riscos
• Visão de um “oceano com um palmo
de profundidade”
• Saídas
–
–
–
–
Caso de uso (~80 %)
Arquitetura do sistema
Protótipo funcional da arquitetura
Planejamento mais detalhado, incluindo
as iterações
– Detalhamento do processo de
desenvolvimento
24
Tarefas na elaboração (1)
25
Tarefas no Planejamento Elaboração (2)
26
Marco da fase de elaboração
• Critérios de avaliação
– A visão do produto é estável?
– A arquitetura proposta é estável?
– O protótipo mostra que os riscos identificados foram
levados em conta e resolvidos?
– O plano para a fase de construção está bem detalhado?
– Os stakeholders concordam que o produto pode ser feito
no planejamento estipulado com a arquitetura proposta?
– Os custos investidos estão de acordo com o planejado?
27
Fase de Construção Desenvolvimento
• Objetivos
– Desenvolver os componentes e funcionalidades da
aplicação
– Integrar e testar os componentes
• Saídas
– O produto integrado e testado
– Manual do usuário
– Descrição da versão atual do produto
28
Marco da fase de construção
• Critérios de avaliação
– O produto está suficientemente estável e maduro para
ser colocado a disposição?
– Todos os stakeholders estão satisfeitos em colocar o
produto à disposição?
– Os custos investidos ainda estão de acordo com o
planejado?
• A fase de transição pode ser adiada se os critérios
falharem
29
Fase de transição
• Objetivos
– Realizar a transição do software aos usuários
• Inclui
–
–
–
–
–
Beta-testing
Treinamento dos usuários
Conversão das bases de dados funcionais
Execução paralela com o sistema que estará substituindo
Envio do produto ao marketing e vendas
30
Marco da fase Transição – Implementação –
Instalação - Acompanhamento
• Critérios de avaliação
– O usuário está satisfeito?
– As despesas reais com recursos são aceitáveis se
comparadas com as planejadas?
• Final
– Reiniciar um novo ciclo de vida com uma nova versão do
produto
– Manutenção total dos artefatos para terceiros que serão
responsáveis pela manutenção
– Comercialização do produto
31
Resumindo….
32
Artefatos
Documento
Iniciação
Elaboração
Construção
Transição
Análise de Domínio de Negócio
80%
13%
5%
2%
Arquitetura de Software
10%
70%
10%
10%
Camada de Dados
5%
45%
40%
10%
Especificação de Casos de Uso
50%
10%
30%
10%
Realização de Casos de Uso
0%
75%
20%
5%
Implementação
0-5%
30-40%
50-60%
0-5%
33