2) Método iRON

Construção de
Software Orientado ao Negócio
A solução proposta pelo método iRON
integração de Requisitos Orientados a Negócio
Eduardo José Ribeiro de Castro, MSc
Agenda
1) Contextualização
●
Causas de fracasso em projetos de software
●
Importância dos requisitos
●
Processo de construção de software
●
Qualidade de software
2) Método iRON
●
Análise do negócio
●
Engenharia de requisitos
●
Princípios norteadores
●
Estrutura do método
3) Estudo de caso
●
Visão geral do emprego do iRon
4) Debates e análise de casos
Agenda
1) Contextualização
●
Causas de fracasso em projetos de software
●
Importância dos requisitos
●
Processo de construção de software
●
Qualidade de software
2) Método iRON
●
Análise do negócio
●
Engenharia de requisitos
●
Princípios norteadores
●
Estrutura do método
3) Estudo de caso
●
Visão geral do emprego do iRon
4) Debates e análise de casos
Porque os projetos falham ?
Porque os projetos falham ?
● Ausência dos elementos básicos
● Pouco entendimento das necessidades dos
clientes
○
○
Problema de comunicação
Ausência de especialista na função
Ausência dos componentes básicos
O que dá e o que não dá certo
Por que os projetos falham ?
Referência: ATALLA, FABIANO. Por que os Projetos de TI Fracassam?
http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1532
Por que os projetos falham ?
Referência: ATALLA, FABIANO. Por que os Projetos de TI Fracassam?
http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1532
Produtividade
Por que os projetos falham ?
● Ausência dos elementos básicos
● Pouco entendimento das necessidades
dos clientes
○ Problema de comunicação
○ Ausência de especialista na função
Ausência dos componentes básicos
O que dá e o que não dá certo
Elementos da Comunicação
A importância da Comunicação
O problema da Comunicação
Mundos diferentes
CLIENTES
Dominam o problema (sua
necessidade)
TÉCNICOS
Dominam a solução técnica
Conhecem as regras do negócio Sabem como colocar em programas as
regras de negócio
Tem necessidades que evoluem Preferem congelar as expectativas e
constantemente
celebrar atas ou documentar requisições
Usam o linguajar de negócio
Usam o linguajar da tecnologia
Não entendem de modelos
técnicos
Não dominam modelos de negócio
(preferem se especializar em modelos e
ferramentas da informática)
Vai ficar melhor do que eu esperava!
GASPARETTO, Wagner. Toda relação humana é uma negociação – saiba negociar!
Por que os projetos falham ?
● Ausência dos elementos básicos
● Pouco entendimento das necessidades
dos clientes
○ Problema de comunicação
○ Ausência de especialista na função
Por que continuam falhando ?
Fonte: Standish Group. http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html
Projetos persistentes em projeto
Fonte: PMI - Chapter São Paulo - eNews - http://www.pmisp.org.br/enews/edicao1106/artigo_01.asp
Por que continuam falhando ?
Por que?
Falta de processo de Engenharia de Requisitos?
Falta de especialistas na comunicação?
Falta de um método focado no negócio?
Por que continuam falhando ?
• A tendência natural das organizações que trabalham sem
um processo de ER tem sido identificar os requisitos
rapidamente de maneira informal e iniciar a codificação.
• Este é o processo “codifica-remenda” até a produção de
uma versão com qualidade adequada ou o cancelamento
do projeto.
• Estes projetos freqüentemente estouram o prazo e o
orçamento.
• É importante lembrar que o esforço e o custo do
retrabalho são maiores do que os investimentos em ER,
buscando desenvolver o projeto certo da primeira vez.
Por que continuam falhando ?
Por que?
Falta de processo de Engenharia de Requisitos?
Falta de especialistas na comunicação?
Falta de um método focado no negócio?
Por que continuam falhando ?
A especialização em Engenharia de Requisitos
Engenheiro
de
Requisitos
Analista de
Sistemas
Progra
madores
Projetista
de
Sistemas
Adaptado de: RUP- Por que iterar? http://www.funpar.ufpr.br:8080/rup/process/workflow/manageme/co_phase.htm
Por que continuam falhando ?
Por que?
Falta de processo de Engenharia de Requisitos?
Falta de especialistas na comunicação?
Falta de um método focado no negócio?
Resposta: solução sistêmica
Agenda
1) Contextualização
●
Causas de fracasso em projetos de software
●
Importância dos requisitos
●
Processo de construção de software
●
Qualidade de software
2) Método iRON
●
Análise do negócio
●
Engenharia de requisitos
●
Princípios norteadores
●
Estrutura do método
3) Estudo de caso
●
Visão geral do emprego do iRon
4) Debates e análise de casos
Agenda
2) Método iRON
● Análise do negócio
●
Engenharia de requisitos
●
Princípios norteadores
●
Estrutura do método
2) O método iRON – Análise do Negócio
2) O método iRON – Análise do Negócio
"A primeira regra de qualquer tecnologia
utilizada nos negócios é que a automação
aplicada a um processo eficiente
aumentará a eficiencia.
A segunda é que a automação aplicada a
um processo ineficiente aumentará a
ineficiência.”
(Bill Gates)
2) O método iRON – Análise do Negócio
Segundo o BABOK 2.0, a Análise de Negócio é
definida como:
• Conjunto de tarefas e técnicas utilizadas
para o trabalho como um elo de ligação entre
as partes interessadas (stakeholders) para
entender a estrutura, as políticas e as
operações de uma organização bem como os
problemas envolvidos, e recomendar
soluções que permitam que esta possa
alcançar seus objetivos.
2) O método iRON – Análise do Negócio
Sistemas de Informação
É
um
conjunto
de
componentes
interrelacionados que coletam, manipulam
e disseminam dados e informação,
proporcionando
um
mecanismos
de
feedback para atender a um objetivo.
Stairs e Reynolds(2002)
2) O método iRON – Análise do Negócio
• A analise do negócio de um Sistema de
Informação deve ser realizada buscando
identificar os elementos que a compõem e
as tarefas e as regras dos processos
utilizados para transformação dos dados em
informação
• Essa análise do processo nos permite
compreender o negócio, identificar os
problemas e propor soluções.
2) O método iRON – Análise do Negócio
SISTEMA DE INFORMAÇÃO – S.I.
PROCESSO
DADOS
INFORMAÇÃO
Automação
2) O método iRON – Análise do Negócio
SISTEMA DE INFORMAÇÃO – S.I.
PROCESSO
DADOS
Descrição do
Processo
Mapeamento do
Processo
Análise do
Problema
Proposta de
Solução
Automação
INFORMAÇÃO
Agenda
2) Método iRON
●
Análise do negócio
● Engenharia de requisitos
●
Princípios norteadores
●
Estrutura do método
2) O método iRON – Engenharia de Requisitos
• A ER é uma sub-área da Engenharia de Software que
estuda o processo de produção e gerência dos requisitos
que o software deverá atender.
• O objetivo da ER é fornecer métodos, procedimentos e
ferramentas que forneçam suporte adequado às tarefas de
produção e gerência dos requisitos do sistema.
• Foi estabelecida como disciplina independente em 1993
2) O método iRON – Engenharia de Requisitos
Importância dos Requisitos
• Uma compreensão completa do problema e a definição
dos requisitos do software e sua especificação
minuciosa é fundamental para o processo de
desenvolvimento obter um software com alta qualidade.
• Não importa quão bem projetado ou codificado está um
programa, se ele for mal analisado e especificado
desapontará o usuário e trará aborrecimentos ao
desenvolvedor.
2) O método iRON – Engenharia de Requisitos
Importância dos Requisitos
• Requisitos mal definidos, ou que não atendam as
expectativas dos clientes, exigem reparos durante o
desenvolvimento do software.
• A manutenção do projeto de software eleva
drasticamente seus custos, podendo levá-lo ao
fracasso.
2) O método iRON – Engenharia de Requisitos
Importância dos Requisitos
2) O método iRON – Engenharia de Requisitos
O que é um REQUISITO ?
“Podemos
conceituar
requisitos
como
sendo uma ação a ser executada por um
sistema, possuindo características e condições
próprias e que devem ser atendidas conforme as
necessidades de negócio do usuário.”
Carlos Vazquez - FATTO
2) O método iRON – Engenharia de Requisitos
2) O método iRON – Engenharia de Requisitos
Dois tipos de DOCUMENTO de REQUISITOS
Clientes
Definição
dos Requisitos
•Lista do que o Cliente espera que
o sistema faça;
•Compreensível ao Cliente;
•Consenso entre Cliente e
Analista;
Técnicos
Especificação
dos Requisitos
•Redefine os requisitos em termos
técnicos;
•Compreensível para o Projetista
•Consenso entre Analista e
Desenvolvedor
•Envolve Modelagem
Agenda
2) Método iRON
●
Análise do negócio
●
Engenharia de requisitos
● Princípios norteadores
●
Estrutura do método
2) O método iRON – Princípios Norteadores
Princípios:
Negócio
orienta o
Software
Software
automatiza
Processo
Requisitos
a partir de
Tarefas
Protótipo
define e valida
Requisitos
Rastreabilidade
para controle de
Mudança
Apoio a:
• organização de dados
• métrica de software
• teste de software
2) O método iRON – Princípios Norteadores
Software automatiza as tarefas de
um processos de negócio
2) O método iRON – Princípios Norteadores
Conjunto de
Tarefas
Processo de
Negócio
(BPM)
Define
Automação
Conjunto de
Requisitos
Software
LP
BD
2) O método iRON – Princípios Norteadores
Proposta
de
Solução
Análise
do
Negócio
Descrição
do
Processo
Mapeamento
do
Processo
Identificação
do
Problema
Viabilidade
Análise do
Problema
Definição e Controle
dos
Requisitos
Definição
dos
Objetivos
Produção e
Gerência
de
Requisitos
Funcionalidades
e
Recursos
Engenharia
de
Requisitos
2) O método iRON – Princípios Norteadores
O RUP – Rational Unified Process é um processo iterativo e adaptativo
de desenvolvimento, organizado e consistente.
iRON
2) O método iRON – Princípios Norteadores
Com relação as Metodologias ágeis, o iRON também pode participar
das etapas iniciais de levantamento de requisitos.
iRON
Anex
Agenda
2) Método iRON
●
Análise do negócio
●
Engenharia de requisitos
●
Princípios norteadores
● Estrutura do método
2) O método iRON – Estrutura do Método
• Com base nos conceitos de
• Engenharia de Software (IEEE), de
• Qualidade de Software (ISO 9126),
• Gestão de Processo de Negócio (BPM),
• Análise de Negócio (BABOK)
• Engenharia de Requisitos (IEEE)
• foi construído o método.
• com disciplina e seu conjunto de atividades e
artefatos
• necessários
a
documentação
das
funcionalidades de um software solicitado pelo
usuário.
2) O método iRON – Estrutura do Método
Resolvendo problemas: processo de análise (1)
Fonte: PFLEEGER, Engenharia de Software
2) O método iRON – Estrutura do Método
Resolvendo problemas: processo de síntese (2)
Fonte: PFLEEGER, Engenharia de Software
2) O método iRON – Estrutura do Método
Método iRON
integração de
Requisitos
Orientado ao
Negócio
Construção de software orientado ao negócio.
2) O método iRON – Estrutura do Método
Fases
Disciplinas
Elicitação
Análise
Documentação Validação
Análise do
Negócio
Proposta de
Solução
Definição
dos
Requisitos
Prototipação
Teste
Gerência de
Requisitos
Disciplinas de Apoio
Gerência de
Projeto
Administração
de Dados
Métrica de
Software
2) O método iRON – Estrutura do Método
VISÃO
SISTÊMICA
Pontos de Automação
Inicio
Fim
Processo de Negócio
Preocupação com a solução
ESTRATÉGICA
Integração de
Requisitos
Orientado ao
Negócio
iRON
Qualidade de Software
2) O método iRON – Estrutura do Método
Artefatos:
• Documento de Análise de Negócio – DAN
• Descrição e mapeamento do processo
• Definição do problema e proposta de solução
• Documento de Definição de Requisitos – DDR
•
•
•
•
•
•
• Requisitos de software
• Rastreabilidade
• Prototipação
Documento de Modelagem de Requisitos – DMR
Documento de Modelagem de Dados - DMD
Documento de Especificação de Requisitos – DER
Documento de Teste de Software – DTS
Documento de Métrica de Software - DMS
Plano de Gerencia de Requisitos – PGR
2) O método iRON – Estrutura do Método
Requisitos do Software:
• Funcionais (ações)
•
Ex.: O sistema deve gerar extrato bancário
• Dados (atributos)
•
Ex.: O sistema deve gerar extrato bancário contendo
nome, hora, data, saldo e movimentação
• Regras de Negócio (condição)
•
Ex.: Quando o sistema gerar o extrato bancário o sistema
deve apresentar a movimentação dos 5 último dias
• Não Funcionais (Norma ISO 9126 - Qualidade)
•
Ex.: Quando o sistema gerar o extrato bancário o sistema
deve imprimir o extrato em até 5 segundos
Agenda
1) Contextualização
●
Causas de fracasso em projetos de software
●
Importância dos requisitos
●
Processo de construção de software
●
Qualidade de software
2) Método iRON
●
Análise do negócio
●
Engenharia de requisitos
●
Princípios norteadores
●
Estrutura do método
3) Estudo de caso
●
Visão geral do emprego do iRon
4) Debates e análise de casos
3) Estudo de Caso
Fases
VISÃO
SISTÊMICA
Disciplinas
Pontos de Automação
In
ici
o
Análise
Documentação
Validação
Análise do
Negócio
Fi
m
Processo de Negócio
Elicitação
Proposta de
Solução
Definição dos
Requisitos
Preocupação com a solução
ESTRATÉGICA
Integração de
Requisitos
Orientado ao
Negócio
Prototipação
Melhoria do Sistema
Teste
Gerência de
Requisitos
iRO
N
Disciplinas de Apoio
Gerência de
Projeto
Identificador
Requisito Funcional
RF01
RF02
RF03
RF04
RF05
RF06
O sistema deve permitir incluir usuário
O sistema deve incluir autor
O deve incluir
O sistema deve permitir alterar usuário
O sistema deve permitir excluir usuário
O sistema deve permitir incluir premio
Análise
do
Negócio
Descrição
do
Processo
Mapeamento
do
Processo
Identificação
do
Problema
Viabilidade
Proposta
de
Solução
Análise do
Problema
Definição
dos
Objetivos
Funcionalidades
e
Recursos
Definição e Controle
dos
Requisitos
Produção e
Gerência
de
Requisitos
Engenharia
de
Requisitos
Requisito
dados
RD01
RD02
RD03
RD01
RD04
RD05
de
Regra
Negócio
RNG01
RNG02
RNG01
RNG03
RNG08
de
Administração de
Dados
Métrica de
Software
3) Estudo de Caso – Análise do Negócio
• Visão Geral do uso do método
1. Analise de Negócio
2. Mapeamento do processo
3. Analise de Requisitos
4. Rastreabilidade
5. Prototipação
6. Modelagem de Requisitos
7. Modelagem de Dados
8. Métrica de Software
3) Estudo de Caso – Análise do Negócio
“A Editora ABC trabalha com diversos autores que escrevem livros
para ela publicar. Alguns autores escrevem apenas um livro, enquanto
outros escrevem muitos. Além disso, alguns livros são escritos por
diversos autores. Mensalmente é enviado às livrarias um catálogo com
o nome dos livros lançados e seus respectivos autores. Esse catálogo
é organizado por assunto para facilitar a divulgação.
Informações sobre a cota de compra de cada livraria são modificadas
a cada três meses, de acordo com a média de compra no trimestre
solicitada pela livraria. Uma carta é enviada à livraria anunciando a
nova cota em cada assunto e os descontos especiais que lhe serão
concedidos para comprar em quantidades maiores.
Aos autores dos dez livros mais vendidos no ano, a Editora ABC
oferece prêmios. A festa de premiação é anunciada com dez dias de
antecedência, por meio de publicação em jornal dos dez livros mais
vendidos, com seus respectivos autores.”
3) Estudo de Caso – Mapeamento do Processo
Subprocesso
Gerar
Catálogo
3) Estudo de Caso – Definição dos Requisitos
Sub-Processo Gerar Catálogo (Requisitos Funcionais)
RF01 – O Sistema deve cadastrar autor (RD01)
RF02 – O sistema deve cadastrar livro (RD02) (RNG01)
RF03 – O sistema deve cadastrar as livrarias (RD03)
RF15 - O sistema deve registrar publicação (RD14)
RF04 – O sistema deve gerar catalogo de lançamento de livros (RD04) (RNG02) (RNG03)
Sub-Processo Gerar Catálogo (Requisitos de Dados)
RD01 – O sistema deve cadastrar autor contendo nome, endereço, telefone (RF01)
RD02 – O sistema deve cadastrar livro contendo o nome do livro, assunto e seu(s) respectivo(s)
autor(es) (RF02)
RD03 – O sistema deve cadastrar livraria contendo nome da livraria, endereço, telefone e cota
(RF03)
RD04 – O sistema deve gerar catalogo contendo nome do livro, assunto, data publicação, e autor
(RF04)
RD15 - O sistema deve registrar publicação contendo nome do livro, data de publicação, assunto e
seu(s) respectivo(s) autor(es) (RF15)
Sub-Processo Gerar Catálogo (Regra de Negócio)
RNG01 – Quando o livro for cadastrado o sistema deve permitir cadastrar um ou mais autores
(RF02)
RNG02 – Quando o catalogo de lançamento do livro for gerado o sistema deve organizar por
assunto (RF03)
RNG03 – Quando o catalogo de lançamento do livro for gerado o sistema deve verificar se o
período é de 30 dias (RF03)
3) Estudo de Caso - Rastreabilidade
Req. Complementares
Req. Funcional
RD01 RD02 RD03 RD04
RF01
RF02
RF03
RF04
RF15
X
RD14
X
X
X
X
Req. Complementares
Req. Funcional
RNG01 RNG 02
RF02
RF04
X
X
RNG 03
X
3) Estudo de Caso - Rastreabilidade
Rastreabilidade Bidirecional
DAN
Problema Solucao
DDR
Requisito
Funcional
Requisitos de Regra de
Dados
Negocio
Prototipo
Modelagem
Formulario Caso de Uso Tabelas
Lógica
Especificação
de Requisitos Código
Teste
Caso de
Teste
3) Estudo de Caso - Prototipação
3) Estudo de Caso – Modelagem de Requisitos
3) Estudo de Caso – Modelagem de Requisitos
3) Estudo de Caso – Modelagem de Requisitos
3) Estudo de Caso – Modelagem de Dados
Identificador
Requisito Funcional
Requisito
Regra de
Complementar
Negócio
RNG01
RF01
O sistema deve permitir cadastrar usuário
RD01
RF02
O sistema deve cadastrar autor
RD02
RF03
O sistema deve cadastrar livro
RD03
RF04
O sistema deve cadastrar Livraria
RD04
DER criado após a análise de alguns requisitos funcionais
RNG02
3) Estudo de Caso – Modelagem de Dados
Identificador:
RD01 – O sistema deve cadastrar o usuário pelos seguintes atributos.
Nome
O S E Descrição
Nome usuário
x
x Atributo que representa o nome completo do usuário
Requisitos Funcional
RF01 / RFXX
Exemplo
Pedro Silva Motta.
Tipo
A
Login
x
x
Atributo que representa o login do usuário. Este atributo é utilizado para efetuar o login no sistema.
PedroSM
A
Senha
x
x
Atributo que representa a senha do usuário. Este atributo é utilizado para efetuar o login no sistema.
12345678
A
Data de cadastramento
x
Atributo que representa a data do cadastramento do usuário a ser identificado pelo sistema
17/11/2002
D
Status
x x
Atributo que representa o status do usuário.
I ou A
--
CPF
x
x
Atributo que representa o número do cadastro da pessoa física do usuário.
021.058.194-08
N
x
Atributo que representa o número do registro geral do usuário.
1.487.599
N
Atributo que representa a unidade da federação de expedição do RG do usuário.
DF, BA, RR.
C
Atributo que representa o órgão que expediu o RG do usuário.
Atributo que representa um e-mail do usuário.
SSP/DF
[email protected]
C
A
RG
UF do RG
x
Órgão expedidor do RG
e-mail
x
x
RD02 – O sistema deve cadastrar o autor pelos seguintes atributos.
RF02 / RFXX
Nome
O
S
E
Descrição
Nome Autor
x
Atributo que representa o nome completo do autor
Unidade Federação - UF
x
x
Atributo que representa a unidade da federação do endereço do autor
Exemplo
Pedro Silva Motta.
DF, BA, RJ, SP
Cidade
x
Atributo que representa a cidade do endereço do autor
São Paulo
Endereço
Bairro
x
x
x
x
Endereço do autor
Bairro do endereço do autor
SQN 216 BL V APT 326
Asa Norte
Município
x
x
Município do endereço do autor
CEP
x
x
CEP do endereço do autor
70000-000
Telefone residencial
x
Número do telefone residencial do autor
(61) 3034-8457
Telefone Celular
x
Número do telefone celular do autor.
(61) 9999-8877
e-mail
x
e-mail do autor
[email protected]
x
3) Estudo de Caso – Modelagem de Dados
RD03 – O sistema deve cadastrar o livro pelos os seguintes atributos
RF03
E Descrição
x Atributo que representa o título do livro do autor.
/ RFXX
Exemplo
Qualidade de Software
x
x Atributo que representa o(s) autor(es) de um mesmo livro
Ivan Mecenas e Viviane Oliveira
Edição
Editora
x
x
x Atributo que representa a edição do livro
x Atributo que representa a editora do livro
3ª.
Atlas
Ano
x
x Atributo que representa o ano da edição do livro
2010
ISBN
x
x Atributo que representa o código ISBN (International Standard Book Number)
978-85-7194-312-4
Nome
Título livro
O
x
Autor
S
3) Estudo de Caso – Modelagem de Dados
DER atualizado após a análise dos Requisitos de dados
3) Estudo de Caso – Modelagem de Dados
Identificação da regra de Descrição da regra de negócio
negócio
RNG01
Quando o livro for cadastrado o sistema deve permitir cadastrar um ou mais
autores
RNG08
Quando cadastrar o premio o sistema deve permitir relacionar prêmio ao autor
Regras de negócio consideradas
3) Estudo de Caso – Modelagem de Dados
DER atualizado após a análise das regras de execução
3) Estudo de Caso – Métrica de Software
O iRON sugere a utilização da APF e da NESMA para mensuração
do tamanho do software no processo de produção de requisitos.
Outras métricas de tamanho podem ser utilizadas, pois o método
iRON possibilita a identificação de todos os dados necessários para
a mensuração inicial e final.
Após a elaboração do DAN pode-se realizar a contagem estimada
(Nesma), e após a elaboração da DDR realizar-se-ia a contagem
detalhada (IFPUG).
Para realizar a contagem estimada do estudo de caso da Editora
ABC, analisa-se o modelo de dados e os requisitos funcionais que
facilitam a identificação dos ALIS e AIES.
3) Estudo de Caso – Métrica de Software
Identificação dos ALI, Dados de código e Dados de referência do modelo de dados da Editora ABC
3) Estudo de Caso – Métrica de Software
Pela Contagem Estimada tem-se o valor de 7 PF x 5 ALIS
computando o total de 35 PF e 7 PF para o dado de
referência.
Ao todo são 42 PF correspondentes as funções de dados.
Não existem AIES nesse estudo de caso.
3) Estudo de Caso – Métrica de Software
Com relação as funções transacionais, o quadro apresenta parte dos
requisitos funcionais.
Essa tabela permite identificar inicialmente as EE, SE e CE.
Seriam inicialmente 6 EE. Na contagem estimativa cada EE recebe 4 PF.
Assim teríamos 6 EE x 4 PF = 24 PF.
A contagem estimada até o momento é de 42 PF + 24 PF = 66 PF.
Identificador Requisito Funcional
Requisito de Regra
de
Dado
Execução
RF01
O sistema deve incluir usuário
RD01
RF02
O sistema deve incluir autor
RD02
RF03
O sistema deve incluir livro
RD03
RE02
RF04
O sistema deve permitir alterar usuário
RD01
RE01
RF05
O sistema deve permitir excluir usuário
RD04
RE03
RF06
O sistema deve permitir incluir premio
RD05
RE08
Parte dos requisitos funcionais da Editora ABC
RE01
3) Estudo de Caso – Métrica de Software
O Quadro apresenta a contagem
detalhada de parte dos requisitos da Editora ABC.
A contagem detalhada até o momento é de 42 PF (7 x 6) + 18 PF (3 x 6) = 60 PF.
Funcão
Identificação
Complexidade
QTD PF
ALI
Autor
Baixa
7
ALI
Usuário
Baixa
7
ALI
Prêmio
Baixa
7
ALI
Livro
Baixa
7
ALI
Editora
‘Baixa
7
Dados de referencia
Baixa
7
EE
Municipio
O sistema deve incluir usuário
Baixa
3
EE
O sistema deve incluir autor
Baixa
3
EE
O sistema deve incluir livro
Baixa
3
EE
O sistema deve permitir alterar usuário
Baixa
3
EE
O sistema deve permitir excluir usuário
Baixa
3
EE
O sistema deve permitir incluir premio
Baixa
3
Perguntas??
Eduardo Castro, Msc
[email protected]
http://lattes.cnpq.br/2217593248315675
br.linkedin.com/pub/eduardo-castro/6/64b/4b2/