Você está na página 1de 320
Modelagem de Sistemas de Informação Da análise de requisitos ao modelo de interface Geraldo Xexéo
Modelagem de Sistemas de Informação Da análise de requisitos ao modelo de interface Geraldo Xexéo
Modelagem de Sistemas de Informação Da análise de requisitos ao modelo de interface Geraldo Xexéo

Modelagem de Sistemas de Informação

Da análise de requisitos ao modelo de interface

Geraldo Xexéo

Modelagem de Sistemas de Informação Da análise de requisitos ao modelo de interface Geraldo Xexéo Edição
Modelagem de Sistemas de Informação Da análise de requisitos ao modelo de interface Geraldo Xexéo Edição

Edição Ago/2007

Modelagem de Sistemas de Informação Da análise de requisitos ao modelo de interface Geraldo Xexéo Edição

Modelagem de Sistemas de Informação: Da Análise de Requisitos ao Modelo de Interface

Geraldo Xexéo.

Versão 2007/Ago

Copyright © 2006,2007 Geraldo Xexéo.

Versão 2007/Ago Copyright © 2006,2007 Geraldo Xexéo. Este documento está licenc iado sob a Creative Commons
Este documento está licenc iado sob a Creative Commons

Este documento está licenciado sob a Creative Commons

Atribuição - Uso Não-Comercial - Não a obras derivadas 2.0 Brasil.

Para ver uma cópia dessa licença visite:

http://creativecommons.org/li censes/by-nc-nd/2.0/br/

http://creativecommons.org/licenses/by-nc-nd/2.0/br/

ou envie uma carta a Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

ou envie uma carta a Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105,

Todo o esforço foi feito para fornecer a mais completa e adequada informação. Contudo, o autor não assume responsabilidade pelos resultados e uso da informação fornecida.

e-mail de contato: xexeo@ufrj.br

A versão mais atualizada desse livro, e ainda material de apoio ao ensino, pode ser obtida em:

http://wiki.xexeo.org

Sumário

CAPÍTULO I. INTRODUÇÃO

 

1

CAPÍTULO II. SISTEMAS DE INFORMAÇÃO

4

II.1

DADOS, INFORMAÇÃO, CONHECIMENTO

5

II.2

CARACTERÍSTICAS DOS SISTEMAS DE INFORMAÇÃO

7

II.3

SISTEMAS DE INFORMAÇÃO E A ORGANIZAÇÃO

7

II.4

TIPOS DE PROJETOS DE SISTEMAS DE INFORMAÇÃO

9

II.4.1

Porque são feitos projetos de SI

10

II.5

CUSTO TOTAL DE PROPRIEDADE

10

II.6

BENEFÍCIOS DO SISTEMA

11

II.7

O PODER ESTÁ COM O USUÁRIO

11

II.8

EXERCÍCIOS

12

CAPÍTULO III. O DESENVOLVIMENTO DE SOFTWARE

 

14

III.1

A DIFICULDADE DO PROBLEMA

15

III.2

ANÁLISE

16

III.2.1

Modelos de Análise

16

III.2.2

Ferramentas da Análise

17

III.2.3

A Tecnologia

17

III.2.4

O Analista de Sistemas

17

III.3 CICLO DE VIDA E PROCESSO DE DESENVOLVIMENTO

18

III.3.1

A Necessidade de Garantir a Qualidade

18

III.3.2

Modelos de Processo mais Comuns

19

III.4

A EQUIPE DE DESENVOLVIMENTO

23

III.5

NOSSA ABORDAGEM

25

III.6

EXERCÍCIOS

26

III.6.1

Trabalho em Grupo (Projeto de Cadeira)

26

CAPÍTULO IV. MODELOS, ABSTRAÇÕES E FRAMEWORKS

 

27

IV.1 TIPOS DE ABSTRAÇÕES

28

IV.1.1

Ocultação da Informação (Caixa-preta)

28

IV.1.2

Classificação (é um membro de)

29

IV.1.3

Composição ou Agregação (é feito de, é parte de)

29

IV.1.4

Generalização (é um, é como)

30

IV.1.5

Identificação (é identificado por)

30

IV.1.6

Simplificação pelo Caso Normal

30

IV.1.7

Foco e Inibição

31

IV.1.8

Refinamento Sucessivo

31

IV.1.9

Separação de Interesses

31

IV.2

TRABALHANDO COM AS ABSTRAÇÕES

31

IV.3

OS MODELOS E AS ORGANIZAÇÕES

32

CAPÍTULO V. USUÁRIOS E REQUISITOS

35

V.1 STAKEHOLDERS E USUÁRIOS

35

V.1.1 Interesses e Objetivos 36

V.2

PERSPECTIVAS DOS USUÁRIOS

36

V.3

O QUE É UM REQUISITO

38

V.3.1

Características de um Bom Requisito

39

V.3.2

Efeitos de Requisitos Errados

40

V.3.3

Requisitos Mudam com o Tempo 41

V.4

REQUISITOS E NECESSIDADES

42

V.5

TIPOS DE REQUISITOS

44

V.5.1

Requisitos Funcionais e de Informação

44

V.5.2

Requisitos não funcionais 44

V.5.3

Outros tipos de Requisitos 46

V.6

DESCREVENDO REQUISITOS

46

V.6.1

Exemplos de Requisitos 46

V.6.2

Documentando os requisitos

48

V.6.3

Dependência de Requisitos 49

V.6.4

Priorizando Requisitos 50

V.6.5

Questionando os requisitos

50

V.7

A ESPECIFICAÇÃO DE REQUISITOS

51

V.8

MÉTODOS DE ELICITAÇÃO DE REQUISITOS

52

V.8.1 Processo de elicitação de requisitos

53

V.9 MÉTODOS SIMPLES DE ELICITAÇÃO DE REQUISITOS

55

V.9.1

A entrevista 55

V.9.2

Realizando a entrevista

59

V.9.3 JAD 63

65

V.10 EXERCÍCIOS

V.10.1

Projeto 1: Livraria ABC 65

V.10.2

Projeto de Curso 65

CAPÍTULO VI. UMA PROPOSTA INICIAL

67

VI.1

O PRIMEIRO CONTATO E OS PRIMEIROS RESULTADOS

67

VI.2

A SOLICITAÇÃO DO CLIENTE

67

VI.3

OBJETIVO DO SISTEMA

68

VI.4

PROBLEMAS

69

VI.5

OPORTUNIDADES

70

VI.6

METAS E SUAS MÉTRICAS

71

VI.6.1

Metas subjetivas 72

VI.6.2

Levantando Objetivos e Metas

72

VI.6.3

Metas em sistemas novos 73

VI.7

OS REQUISITOS PRELIMINARES

73

VI.7.1

Definindo o Escopo 73

VI.7.2

Documentando os requisitos iniciais

74

VI.8

O SISTEMA ATUAL

74

VI.8.1 Problema do sistema atual 74

75

VI.9 VISÃO DO NOVO SISTEMA

VI.9.1

Oportunidades para o novo sistema 75

VI.9.2

Pontos Críticos ou Pontos Chave 75

VI.9.3 Restrições 76

VI.10

CONSTRUINDO UM GLOSSÁRIO

76

VI.11

PROPOSTA COMERCIAL

76

VI.11.1 Calculando Preço e Custo 76

VI.12

O RESUMO EXECUTIVO

77

VI.13

ESTRUTURA DA PROPOSTA INICIAL

77

VI.14

EXERCÍCIO

78

VI.14.1

Projeto 1: Livraria ABC 78

 

VI.14.2

Projeto

de curso

79

CAPÍTULO VII. MODELO DE NEGÓCIO

 

80

VII.1

O ORGANOGRAMA

81

VII.2

NÍVEIS DE ABSTRAÇÃO TRATADOS NESSE CAPÍTULO

83

VII.3

FUNÇÕES DE NEGÓCIO

84

VII.4

MODELAGEM DE FUNÇÕES COM IDEF0

85

VII.4.1

Introdução ao IDEF0 85

VII.4.2

Sintaxe do IDEF0 95

VII.4.3

Construção de um modelo IDEF0

103

VII.4.4

Exemplo de IDEF0 106

VII.5

PROCESSOS DE NEGÓCIO

109

VII.6

FLUXOGRAMAS

110

VII.7

EPC

110

VII.7.1 Uso Básico 111

VII.7.2 eEPC 118

VII.7.3

Diagramas de Resumo

121

VII.7.4

Formas diferentes dos diagramas 121

VII.7.5

EPC e 5W2H 122

VII.7.6

Regras de ouro de EPCs[B23]

122

VII.7.7

EPC e Loops/Laços 124

VII.7.8

Algumas sentenças em EPC 126

VII.7.9

Exemplo

127

VII.8

DIAGRAMAS DE ATIVIDADE (UML 2.0)

127

VII.8.1

Nós, vértices 128

VII.8.2

Ações, Objetos e Fluxos 129

VII.8.3

Controle

132

VII.8.4

Interrupções, Exceções e Sinais 135

VII.8.5

Diagramas de Raias 135

VII.8.6

Exemplo

138

VII.9

REGRAS DE NEGÓCIO

 

138

VII.9.1

Declarações

Estruturais

139

VII.9.2

Declarações de Ações (ou Restrições) 140

VII.9.3

Derivações

141

VII.9.4

Regras e Eventos 141

VII.9.5

Descrevendo Regras de Negócio

142

VII.10

OUTRAS FERRAMENTAS DE MODELAGEM

145

VII.10.1

Responsáveis por decisão (Processo x Organização) 145

 

VII.10.2

Dados x Processos (CRUD) 146

VII.10.3

Corrente/Planejado

147

VII.11

RESUMO DA MODELAGEM DE NEGÓCIO

147

VII.12

EXERCÍCIOS

147

VII.12.1 Projeto 1: Livraria ABC

147

CAPÍTULO VIII. MODELO CONCEITUAL DE DADOS

 

148

VIII.1

MODELOS DE DADOS E REGRAS DE NEGÓCIO

149

VIII.2

A MEMÓRIA DO SISTEMA

149

VIII.2.1

Modelo Conceitual (MC) 149

 

VIII.2.2

Modelo Lógico 150

VIII.2.3

Modelo Físico 151

VIII.3

MODELO DE ENTIDADES E RELACIONAMENTOS

151

VIII.4

O DIAGRAMA DE ENTIDADES E RELACIONAMENTOS

152

VIII.4.1 Exemplo de Modelo E-R 155

VIII.5

DESENVOLVENDO O MODELO CONCEITUAL

155

VIII.6

ENTIDADES

156

VIII.6.1

Onde encontrá-las

159

VIII.6.2

Descrevendo Entidades

159

VIII.7

RELACIONAMENTOS

161

VIII.7.1 Cardinalidade 163

VIII.7.2 Descrevendo Relacionamentos 168

VIII.8 ATRIBUTOS

169

VIII.8.1 Descrevendo Atributos

169

VIII.9

IDENTIFICANDO ENTIDADES

170

VIII.9.1

Atributos Identificadores (Chaves Candidatas e Chaves Primárias) 170

VIII.9.2

Relacionamentos Identificadores 171

VIII.10 DESCRIÇÃO GRÁFICA DO MODELO

172

VIII.10.1 Exemplos de notações 173

VIII.10.2 Notação adotada

176

VIII.11 TÉCNICAS DE DESENVOLVIMENTO DO MODELO

177

VIII.11.1

Técnica

Top-Down

177

VIII.11.2

Técnica Bottom-Up 179

VIII.11.3

Técnica

Inside-Out

180

VIII.11.4

Técnica

Mista

180

VIII.11.5

Que técnica usar 181

VIII.11.6

Equivalência de modelos 181

VIII.12

REPRESENTANDO O ASPECTO TEMPORAL

181

VIII.13

FORMAS NORMAIS

181

1.1.1

Primeira Forma Normal (1FN) 182

VIII.13.1

Algumas Anomalias Resolvidas pelas Formas Normais

184

VIII.13.2

Dependência Funcional 184

VIII.13.3

Segunda Forma Normal (2FN) 185

VIII.13.4

Terceira

Forma

Normal

185

VIII.13.5

Outras formas normais 186

VIII.13.6

Formas Normais e o Modelo E-R 187

VIII.14

OUTROS TERMOS

187

VIII.15

VERIFICANDO O MODELO

187

VIII.16

LEITURA COMPLEMENTAR

188

CAPÍTULO IX. MODELO FUNCIONAL ESSENCIAL

 

189

IX.1

PERSPECTIVA HISTÓRICA

189

IX.2

A ANÁLISE ESSENCIAL

190

IX.3

OS PRINCÍPIOS DA MODELAGEM ESSENCIAL

190

IX.3.1

O Orçamento para a Complexidade

191

IX.3.2

A Neutralidade Tecnológica 191

 

IX.3.3

A Tecnologia Interna Perfeita 192

IX.3.4

O Modelo Essencial Mínimo

192

IX.3.5

O Princípio da Ausência de Surpresas 192

 

IX.4 A ESSÊNCIA

193

IX.4.1 A tecnologia imperfeita

194

IX.5

REQUISITOS ESSENCIAIS VERDADEIROS E FALSOS

195

IX.6

AGENTES EXTERNOS

197

IX.7

EVENTOS ESSENCIAIS

198

IX.7.1

Propriedades dos eventos 200

IX.7.2

Tipos de Eventos

200

IX.7.3

Um Exemplo 201

IX.7.4

Habilitando Eventos 202

IX.8

DESCREVENDO EVENTOS ESSENCIAIS

203

IX.9

LEVANTANDO OS EVENTOS ESSENCIAIS

204

IX.9.1

Classificando os Eventos 205

IX.9.2

Encontrando Eventos

206

IX.9.3

Simplificando Eventos 207

IX.10 AS RESPOSTAS AOS EVENTOS

207

IX.10.1

Representando

Atividades

208

IX.10.2

Confundindo eventos e respostas/atividades 208

IX.11

A MEMÓRIA DO SISTEMA

209

IX.11.1

IX.11.2

IX.11.3

Eventos x Entidades (Matriz CRUD)

209

Verificando a consistência

210

Agrupando eventos e atividades na Matriz CRUD

210

IX.11.4

Calculando a afinidade entre eventos/atividades 211

IX.11.5

Extensões da Matriz CRUD

214

IX.12

DESCRIÇÃO GRÁFICA DE UM EVENTO ESSENCIAL

214

IX.13

ENTENDENDO UM EVENTO

215

IX.14

O DICIONÁRIO DE EVENTOS

216

IX.15

ESPECIFICANDO PROCESSOS

218

IX.15.1

IX.15.2

Especificação do Tipo Caixa Preta 219

Especificação do Tipo Caixa Branca 219

IX.15.3 Mini-especificações 219

IX.15.4

O Diagrama de Transição de Estados

221

IX.15.5

Tabelas de Decisão

223

IX.15.6

Pré-condições e pós-condições

223

IX.16

DICIONÁRIO DE DADOS

223

IX.17

EXERCÍCIO

225

IX.17.1 Rede Bobo de Televisão

225

IX.18

MODELOS ADICIONAIS

226

IX.18.1 Finalizando a Análise

226

CAPÍTULO X. CASOS DE USO

 

228

X.1

CONCEITUAÇÃO

228

X.2

ATOR

229

X.2.1

Objetivos

229

X.2.2

Cenários

230

X.3 FORMAS DE NARRATIVA

232

X.3.1

Descrição contínua 232

X.3.2

Descrição

numerada

233

X.3.3

Descrição

particionada

233

X.4 TIPOS DE DETALHAMENTO

234

X.4.1

Exemplo de caso de uso Breve

234

X.4.2

Exemplo de caso de uso casual

234

X.4.3

Exemplo de caso de uso expandido

234

X.5

DIAGRAMAS DE CASO DE USO

235

X.6

RELAÇÕES ENTRE CASOS DE USO

236

X.6.1

Generalização entre Atores 236

X.6.2

Relações entre Casos de Uso

237

X.6.3

Inclusão de Casos de Uso

238

X.6.4

Extensão de Casos de Uso 238

X.6.5

Generalização de Casos de Uso 239

X.7

TIPOS DE CASO DE USO

239

X.8

NÍVEIS DE ABSTRAÇÃO DE UM CASO DE USO

240

X.9

ESCOPO DE UM CASO DE USO

241

X.10

ESCOPO X ABSTRAÇÃO

242

X.11

PARTES DE UM CASO DE USO

243

X.11.1 Possíveis Seções para um Caso de Uso Expandido 243 X.11.2 Atores 243

Interessados - Stakeholders 243

X.11.4 Pré-condições 244

X.11.3

X.11.5

Pós-Condições ou Garantias de Sucesso

244

X.11.6

O “Caminho Feliz” ou Fluxo Principal 244

X.11.7

Extensões ou Fluxos Alternativos 244

X.11.8

Requisitos Especiais

245

X.11.9

Variações Tecnológicas e de Dados 245

X.11.10 Questões em aberto

245

X.12

UM BOM CASO DE USO

245

X.13

COMO DESCOBRIR CASOS DE USO?

245

X.14

COMO FAZER CASOS DE USO

246

X.14.1

X.14.2

Identifique os atores e seus objetivos

246

2) Para cada caso: escreva um caso simples

246

X.14.3

X.14.4

3) Escreva as condições de falha e extensões 247

4) Resolva as falhas 247

X.14.5

X.14.6

X.14.7

5) Detalhe as variações de dados 247

Boas Perguntas 247

Casos de Uso Especiais 248

X.14.8

Comentários

248

X.14.9

Casos de uso NÃO 248

X.14.10

O Processo de Escrita

249

X.14.11

Priorizando Casos de Uso 249

X.15 CASOS DE USO ESSENCIAIS E REAIS

249

X.15.1

Aparência - Essencial 249

X.15.2

Aparência

– Real

249

X.16 VERBOS PARA USAR EM CASOS DE USO

251

X.17 UMA SOLUÇÃO PARA O PROBLEMA DA LIVRARIA

251

CAPÍTULO XI. MODELO DE INTERFACE

 

253

XI.1

A INTERAÇÃO HOMEM COMPUTADOR (IHC)

253

XI.1.1

Projetando a Interface com o Usuário 254

 

XI.1.2

Modelo Cognitivo 255

XI.1.3

As Ações dos Usuários

255

XI.2

COLETANDO INFORMAÇÕES SOBRE O USUÁRIO

255

XI.3

PROTÓTIPOS

257

XI.3.1 Protótipos de Baixa Fidelidade & StoryBoarding

259

XI.4 MODELOS DE NAVEGAÇÃO

264

XI.4.1 O Diagrama de Navegação de Telas

264

CAPÍTULO XII. QUAL O TAMANHO DO SOFTWARE

 

266

XII.1

QUAL O TAMANHO DO SISTEMA?

266

XII.2

PREÇO E CUSTO

266

XII.3

ESFORÇO E TEMPO DE DESENVOLVIMENTO

267

XII.4

O TAMANHO DO SOFTWARE

267

XII.5

UMA VISÃO REDUZIDA DO MODELO COCOMO II

268

XII.5.1 Distribuição do Esforço 271

 

XII.6 ANÁLISE DE PONTOS DE FUNÇÃO

271

XII.6.1

Procedimento de Contagem 272

 

XII.6.2

Identificando Funções de Negócio 274

XII.6.3

Entendendo as Lógicas de Processamento

275

XII.6.4

Identificando Arquivos Internos 276

 

XII.6.5

Identificando Arquivos Externos 277

XII.6.6

Determinando a Complexidade

277

XII.6.7

As Perguntas 279

 

XII.6.8

Cálculo dos Pfs Finais 280

XII.6.9

Contando PFs na Análise

281

XII.6.10

Inflação de PFs ao decorrer do projeto 281

 

XII.6.11

Utilizando Pfs para previsões 281

XII.7

LIGANDO COCOMO II E PONTOS DE FUNÇÃO

282

XII.8

ESTIMANDO O TAMANHO

283

XII.8.1 A Técnica de Delfos

283

XII.8.2 Cenários 283

 

XII.8.3 Técnicas baseadas em Pontos de Função 284

XII.9

VERIFICANDO A SANIDADE DA ESTIMATIVA

284

XII.10

PRODUTIVIDADE EM PONTOS DE FUNÇÃO

284

CAPÍTULO XIII. PROJETO 1: LIVRARIA ABC XIII.1 ATENÇÃO: 286

286

XIII.2

ENTREVISTA 1: PROPRIETÁRIO DA EMPRESA SR. JOSÉ LETRADO

286

XIII.3

ENTREVISTA 2: HENRIQUE CUPIM LETRADO, FUNCIONÁRIO E FILHO DO

PROPRIETÁRIO (PATROCINADOR)

287

XIII.4

ENTREVISTA 3: SRA. LÚCIA PINHO, FUNCIONÁRIA

288

XIII.5

ENTREVISTA 4: ENRON LANDO NOPAPO, VENDEDOR

289

XIII.6

NESSE EXERCÍCIO:

289

CAPÍTULO XIV. PROJETO 2: EMPRESA DE CLIPPING CLIPTUDO

 

290

CAPÍTULO XV. O DIAGRAMA DE FLUXO DE DADOS

291

XV.1.1

Algumas regras sintáticas 293

XV.1.2

Entendendo os Fluxos de Dados

293

XV.1.3

Entendendo as Memórias 294

 

XV.1.4

Tipos de DFD 294

XV.1.5

Criando o DFD Particionado

295

XV.1.6

Criando o DFD hierárquico

295

CAPÍTULO XVI. SISTEMA ACADÊMICO DA UNIVERSIDADE DO POVO

 

299

XVI.1

A ESTRUTURA DA UNIVERSIDADE

299

XVI.2

OS CURSOS E SEUS CURRÍCULOS

299

XVI.3

CADEIRAS, EMENTAS, CURSOS E HORÁRIOS

300

XVI.4

ALUNOS, INSCRIÇÕES, MATRÍCULAS E APROVEITAMENTO

301

XVI.5

GLOSSÁRIO

301

CAPÍTULO XVII. BIBLIOGRAFIA

 

303

CAPÍTULO XVIII. INDÍCE

308

Capítulo I. Introdução

Capítulo I. Introdução

Este livro é sobre a Modelagem de Sistemas de Informação seguindo uma forma bastante atualizada da Análise Essencial, unificada com outros métodos importantes no dia a dia do desenvolvedor de software, como o Modelo de Entidades e Relacionamentos.

Ele é fruto da experiência de 12 anos ensinando Análise de Sistemas para graduação, primeiro na Universidade Estácio de Sá e depois na Universidade Federal do Rio de Janeiro, já como professor Adjunto. O texto foi criado, alterado, cortado e aumentado de forma a atender as necessidades do curso, do mercado e dos alunos. Muito do conteúdo aqui apresentado é resultado direto de dúvidas e dos erros mais comuns que os alunos apresentaram. A matéria também é resultado de 15 anos de atuação como consultor, envolvido direta ou indiretamente na análise e implementação de sistemas em diferentes projetos, sobre temas variados como administração pública, gerência de satélites e controle de frota.

O livro foi construído com dois propósitos. O primeiro é apoiar um primeiro

curso de modelagem de sistemas de informação, fundamentado na análise essencial, no nível de graduação ou extensão, visando formar um analista de sistemas. O segundo é fornecer uma base de sustentação para o analista no seu dia a dia no trabalho. Não apresentamos um método único de análise ou especificação de sistemas, mas sim um conjunto de ferramentas, ou linguagens, que podem ser usadas tanto em conjunto como em separado, porém baseadas em uma filosofia comum. Este livro não trata de modelagem orientada a objeto, que é normalmente assunto de um segundo curso de modelagem de sistemas.

Algumas premissas foram importantes na construção do texto. Não é um texto com foco teórico, mas sim aplicado. Durante os 12 anos em que o curso já foi dado, todas as provas foram práticas, apresentando problemas para serem analisados e modelados, e com consulta.

Neste livro, seguindo a análise essencial, estamos interessados em sistemas de informação que produzem respostas planejadas, isto é, que executam ações pré- programadas em função de mudanças reconhecíveis e previsíveis no ambiente externo. Chamamos essas mudanças no estado do ambiente de eventos essenciais. Não estamos interessados em respostas ad-hoc, isto é, respostas que tem que ser praticamente inventadas caso a caso, mas sim em eventos que podem ser previstos e para os quais podemos programar respostas em um computador digital.

É importante deixar claro que a análise essencial, unificada com o modelo de

entidades e relacionamento, é uma ferramenta de grande qualidade para o desenvolvimento de sistemas de informação.

Quando um cliente solicita um sistema de informação, pensa em automação de algum processo, na modernização de um processo já automatizado ou na criação de um novo processo em sua empresa. O cliente então imagina um sistema que executa algumas funções, gerencia alguns dados e fornece alguns relatórios. Esse sistema imaginado pelo cliente, porém, raramente descreve de forma clara o que ele realmente precisa, ou que precisará no dia que o sistema ficar pronto. Cabe ao analista ajudar ao cliente a descobrir como é o sistema realmente necessário.

O segundo capítulo faz uma pequena introdução aos Sistemas de Informação,

principalmente aqueles que encontramos dentro de organizações. O terceiro capítulo discute o desenvolvimento de software. Ambos os capítulos são introdutórios e têm como finalidade nivelar conhecimento, sendo que o ideal é que o aluno envolvido nesse estudo tenha feito antes desse curso cadeiras equivalentes a Sistemas de Informação e Introdução a Engenharia de Software.

O quarto capítulo discute o levantamento de requisitos do sistema. Apresenta

ao leitor dois conceitos importantes: o stakeholder, palavra que significa “aquele que tem algum interesse (aposta)”, e que traduzimos de forma liberal para interessado, e uma classificação de tipos de requisitos de um sistema, onde se sobressaem os requisitos funcionais e não funcionais. O capítulo também apresenta uma leve introdução a métodos de elicitação de requisitos, discutindo os métodos tradicionais e mais comuns, a entrevista e o JAD, detalhadamente.

O quinto capítulo apresenta a proposta inicial. O objetivo é permitir ao desenvolvedor compreender de forma geral o que será feito no projeto de desenvolvimento, dando margem para a criação de uma proposta comercial. Nesse capítulo ainda tratamos o desenvolvimento de sistemas como uma atividade informal, a nível de negócios.

O sexto capítulo trata da modelagem de negócios, partindo de modelos de alto

grau de abstração, como o IDEF0, para modelos detalhados do comportamento da organização, como EPC e regras de negócio. Esses métodos podem substituir na sua totalidade o uso de DFDs para modelar a encarnação de um sistema, sendo na prática mais adequados para o mapeamento do funcionamento real de uma organização.

O sétimo capítulo trata da modelagem conceitual de dados, baseado no modelo

de entidades e relacionamentos, necessidade primordial para uma boa análise de sistemas. O oitavo capítulo trata da modelagem funcional essencial. Juntos, esses dois modelos definem o funcionamento esperado do novo sistema.

Esta edição apresenta a primeira versão de um capítulo sobre Casos de Uso (o nono). Casos de Uso são provavelmente a forma mais indicada, hoje em dia, para levantar requisitos funcionais de uma aplicação. Porém, o conhecimento da Análise Essencial ainda me parece importante para poder trabalhar com Casos de Uso, que são mais informais. Por outro lado, já há alguns anos não vejo projetos usando DFDs, e resolvi definitivamente relega-los a um apêndice.

Esses modelos são completados com um modelo da interface do sistema, preferivelmente na forma de um protótipo, que é discutido no capitulo dez.

Finalmente o capítulo onze trata de formas de prever o esforço necessário para desenvolver um sistema de software, usando como fator de determinação os documentos previamente gerados.

Além disso, apresentamos ao final alguns projetos para os alunos usarem nos exercícios.

Recomenda-se que os capítulos sejam apresentados na ordem em que estão no

livro.

Os capítulos de análise funcional e modelagem de dados já foram dados em diferentes ordens, tanto um quanto o outro na frente, porém a análise de dados independe da análise funcional e o inverso não é verdade, o que recomenda que seja a ordem adotada. Além disso, a modelagem de dados pode ser vista como uma forma de

detalhar, a nível do sistema, as regras de negócio, o que apresenta uma continuidade ao curso. O livro suporta bem um período de 15 semanas, com 4 horas por semana, incluindo aulas teóricas e exercícios, duas provas e um trabalho por equipe, de 3,4 ou 5 alunos, que tem em média 15 eventos e 10 entidades, e que deve modelar de forma completa um sistema, de acordo com todo material apresentado.

Capítulo II. Sistemas de Informação

Capítulo II. Sistemas de Informação

"A complex system that works is invariably found

to have evolved from a simple system that worked." John Gall

Sistemas de Informação Dados, Informação, Conhecimento SI e a Organização ERP Custo Total de Propriedade

Sistemas de Informação são utilizados em organizações para planejamento, monitoração, comunicação e controle das suas atividades, por meio da manipulação e guarda de informações.

Segundo o Dicionário Aurélio, a palavra sistema significa, entre outras coisas, um “Conjunto particular de instrumentos e convenções adotados com o fim de dar uma informação”. Os instrumentos são as ferramentas, os mecanismos, concretos ou abstratos, que utilizamos para fazer funcionar os sistemas, tais como: programas de computador, relatórios, formulários, etc. As convenções são as suas regras de utilização. Apesar de sistemas de informação não necessitarem de computadores para existir, hoje em dia é comum associar o termo imediatamente a uma implementação usando software, hardware e redes.

Um exemplo típico de sistema de informação é um sistema de aluguel para uma vídeo-locadora. Entre suas várias finalidades, a principal é certamente controlar o aluguel das fitas, informando quem está com qual fita em um determinado momento (quando), e quanto deve pagar por isso. Além disso, o sistema permite outras atividades, como a gerência do estoque de fitas (quais fitas existem), a monitoração das fitas mais e menos alugadas (quantas vezes cada fita foi alugada), etc.

Um Sistema de Informação é um conjunto de componentes inter-relacionados que coleta dados no ambiente em que opera, usando recursos de sensoriamento e telecomunicações (entrada), analisa esses dados (processamento) e finalmente apresenta o produto como informação útil (saída), sendo construído de forma a atender os interesses de uma organização, de seus clientes internos e externos e de todos aqueles atingidos direta ou indiretamente pelo novo produto 1 .

Ao longo deste livro usaremos a palavra organização para representar empresas, órgãos públicos, entidades beneficentes, associações e qualquer outra forma de instituição com objetivos definidos e que pode obter algum benefício com o uso de sistemas de informação. Nisso incluímos um enorme espectro de interesses e tamanhos, tanto um consultório dentário quanto uma multinacional de bebidas.

1 Xexéo, J.A. “Tese de Doutorado” XXX

Apesar de estarmos preocupados com o desenvolvimento de sistemas de informação automatizados, implementados na forma de programas de computador, isso não é uma necessidade. Durante séculos as organizações usaram sistemas de informação apenas com o uso de pessoas, papel e tinta. Apenas bem mais tarde, aparecem máquinas como máquinas de escrever e de somar. Não seria exagerado dizer que a escrita e os números foram criados para suportar os primeiros sistemas de informação, que tratavam, por exemplo, de colheitas e comércio Muitas das técnicas deste livro podem, e devem, ser aplicadas para entender sistemas de informação manuais.

Este capítulo apresenta uma breve descrição de como funciona, para que servem e quem usa os sistemas de informação dentro de uma organização.

usa os sistemas de informação dentro de uma organização. Figura 1. Uma tela de um sistema

Figura 1. Uma tela de um sistema de informações real.

II.1

Dados, Informação, Conhecimento

Antes de entender o que é um Sistema de Informação, é preciso entender melhor o que significa a palavra Informação.

Novamente, vamos recorrer a dicionários para ter uma definição inicial. Segundo o American Heritage, informação é o dado quando processado, guardado ou transmitido. Já no dicionário Aurélio, informação, entre outros significados, pode ser “Conhecimento amplo e bem fundamentado, resultante da análise e combinação de vários informes”, “Coleção de fatos ou de outros dados fornecidos à máquina, a fim de se objetivar um processamento” ou ainda “Segundo a teoria da informação, medida da redução da incerteza, sobre um determinado estado de coisas, por intermédio de uma mensagem”. Apesar de não estarmos diretamente envolvidos com a teoria da informação, não podemos de deixar de notar a importância da definição que diz que a informação reduz a incerteza por meio de uma mensagem.

Estamos interessados em criar uma diferenciação entre dados, informação e conhecimento, mesmo que as palavras possam ser consideradas sinônimas em muitos contextos. Apesar de serem normalmente confundidas ou utilizadas de forma

intercambiável, elas podem ser mais bem entendidas e utilizadas se analisadas como representando conceitos diferentes.

Dados são apenas os símbolos que usamos para representar a informação, o registro de diferentes aspectos de um fato ou fenômeno. Os números que guardamos em um banco de dados são, como diz o nome, “dados”. Dados não são interpretados, eles existem, são adquiridos de alguma forma, via coleta, pesquisa ou criação, guardados de outra forma e, possivelmente, apresentados em uma terceira. O computador é uma máquina que manipula dados.

Por outro lado, informação é o dado com significado, normalmente processado de forma a ser útil. Uma informação deve permitir responder perguntas como “quando”, “quanto”, “quem”, “qual” e “onde” 2 sobre alguma coisa.

Informação = Dado + Significado

É necessário fazer um mapeamento entre dados e informação. Esse mapeamento pode ser simples ou complexo, dependendo de várias variáveis envolvidas, que vão desde decisões arbitrárias tomadas pelo desenvolvedor até padrões internacionais. Por exemplo, em muitos sistemas é preciso ter a informação do sexo de uma pessoa (masculino ou feminino). Para isso, guardados um número (1 ou 0) ou uma letra (M ou F) que é o dado que faz a indicação da informação.

Conhecimento é a aplicação da informação. Podemos dizer que permite responder a pergunta “como”, pois envolve argumentos, explicações e justificativas. Entre as três palavras que estamos analisando, conhecimento é a que tem significado mais geral na língua portuguesa, podendo ser usada no dia a dia como sinônimo de informação. Em informática, porém, normalmente chamamos de conhecimento algo que pode ser escrito na forma de regras (como em “se for maior de 18 anos, então pode tirar carteira de motorista”).

Além disso, ainda podemos analisar as palavras compreensão (ou entendimento) e sabedoria. A compreensão permite responder a pergunta “por que”, enquanto a sabedoria é um processo complexo e pessoal de compreensão e avaliação do entendimento, que não pode ser compartilhado [B1].

Bellinger et. al. [B2] afirmam que com o aumento da compreensão e da capacidade de fazer conexões entre partes (dados, informações, etc.), passamos do trabalho direto com o dado em si para informação, então para o conhecimento e finalmente para a sabedoria.

2 What, where, when, who, How much

Figura 2. Entendimento das relações entre dados, informação, conhecimento e sabedoria, segundo Bellinger et al.[B2]

Figura 2. Entendimento das relações entre dados, informação, conhecimento e sabedoria, segundo Bellinger et al.[B2]

II.2

Características dos Sistemas de Informação

É importante entender que sistemas de informação são sistemas interativos e

reativos.

Interativo significa que o sistema troca informações com o ambiente, em especial com os agentes externos que fazem parte desse ambiente, pessoas e outros sistemas de computador. O sistema só faz sentido se é capaz dessa interação.

Reativo significa que o sistema funciona reagindo a mudanças no ambiente, e em especial, a mudanças provocadas pelos agentes externos.

Nossos sistemas também são sistemas de respostas planejadas. Isso significa que nossas respostas são determinadas e determinísticas, que podemos criar um programa que as produza. Também significa que todas as perguntas que podem ser feitas ao sistema podem, e são, identificadas previamente.

Escolhendo essas regras de modelagem, escolhemos um caminho para decidir quando o sistema vai funcionar: em vez de deixar isso incerto, como em muitos métodos, nós determinamos que o sistema só funciona para responder um evento no ambiente, causado por um agente externo, e que possua uma resposta planejada.

A metodologia de desenvolvimento apresentada neste livro é feita sob medida

para sistemas interativos e reativos, de respostas planejadas. Nesse caso, somos ao mesmo tempo restritivos, pois se o sistema não pode ser modelado dessa forma não

serve para nossa metodologia, como ampliativos, pois a grande maioria dos sistemas pode ser modelada de forma natural com esses princípios.

II.3

Sistemas de Informação e a Organização

Sistemas de informação atualmente servem em todas as áreas e níveis das organizações, sendo considerados como ferramenta essencial para o sucesso de suas atividades. Isso nos permite classificá-los de acordo com a responsabilidade assumida por seus usuários dentro da organização em quatro tipos principais, como sugerido por Laudon [B3]:

Sistemas de nível operacional, que tratam da execução, acompanhamento e

registro da operação diária da empresa, sendo geralmente sistemas fortemente

transacionais. Exemplos são sistemas de vendas, folha de pagamento, etc.

Sistemas de nível de conhecimento, que suportam as pessoas que trabalham com

dados e conhecimento dentro da organização. Exemplos simples de sistemas desse tipo são os processadores de texto e as planilhas eletrônicas.

Sistemas de nível gerencial, que utilizam dados da operação e outros dados

inseridos nesses sistemas para permitir a obtenção de informações que permitam a gerência da empresa, suportando a tomada de decisões, o controle e o monitoramento.

Sistemas de nível estratégico, que são sistemas destinados a decisões de mais

alto nível (efeito estratégico) e utilizam dados de todos os sistemas anteriores,

normalmente de forma agregada e processada, sendo utilizados pela alta gerência.

Estratégico Gerencial Conhecimento Operacional
Estratégico
Gerencial
Conhecimento
Operacional

Figura 3. Níveis dos sistemas de informação dentro de uma organização

Ainda segundo Laudon, a cada nível de sistemas de informação podemos associar um ou mais tipos de sistemas.

Sistemas de Suporte Executivo (SSE), encontrados no nível estratégico, são

destinados a apoiar a alta gerência em tarefas estratégicas, como o planejamento de

longo prazo. Usam dados fortemente agregados, internos e externos a organização e são capazes de responder perguntas específicas ou ainda fazer projeções. Podem ser capazes de fazer simulações e ter uma interface interativa.

Sistemas de Apoio a Decisão (SAD), encontrados no nível gerencial, são

utilizados pelos vários níveis de gerência e utilizam como entrada dados em pequeno

volume (agregações) ou ainda bases massivas de dados previamente preparadas para permir atividades de análise de dados. Como resposta, devem fornecer relatórios específicos, análises e decisões e respostas a perguntas ad-hoc.

Sistemas de Informação Gerencial (SIG), também encontrados no nível

gerencial, são utilizados pelos vários níveis de gerência. Utilizam grande volume de

dados ou sumários de transações e modelos simples para obter relatórios sumários (agregados) e de exceções.

Sistemas de Trabalho com Conhecimento (STC), encontrados no nível de

conhecimento, utilizam projetos, especificações e bases de conhecimento em geral

para produzir modelos e gráficos. Normalmente são utilizados por profissionais com nível superior.

Sistemas de Escritório (SE), encontrados no nível de conhecimento, tem como

objetivo aumentar a produtividade na manipulação de dados em um escritório.

Permitem a manipulação de documentos, correio eletrônico e agendas.

Sistemas Processamento de Transações (SPT), encontrados no nível

operacional, tratam eventos e transações e fornecem relatórios detalhados, listas e sumários, utilizados pelos gerentes, além de documentos específicos para a transação

em que são utilizados.

Os SPT suportam não só a operação diária da empresa, mas também criam os dados que são mais tarde utilizados pelos outros tipos de sistemas.

II.3.1.1 Sistemas de Informações Típicos Atualmente já consideremos que vários sistemas de informações típicos de uma empresa são necessidades básicas que podem ser atendidas de uma só vez. Esses sistemas constroem o que é comumente chamado de ERPs – de Enterprise Resource Planning – ou Sistemas de Gestão Empresarial em português – mas que na prática não são sistemas de planejamento (ou de recursos), mas sim de controle e administração de uma empresa.

Entre as características encontradas em ERPs podemos citar a integração das atividades da empresa e o uso de um banco de dados único. O líder mundial do mercado é a SAP AG, com o produto SAP R/3. O custo de implantação de um ERP de grande porte pode chegar até 300 milhões de dólares. No Brasil, existem produtos menos ambiciosos e mais baratos.

Os sistemas de ERP atuais contêm módulos representando os mais típicos sistemas de informações necessários em uma empresa, tais como: Contabilidade Fiscal, Contabilidade Gerencial, Orçamento e Execução Orçamentária, Ativo Fixo, Caixa e bancos, Fluxo de Caixa, Aplicações e Empréstimos, Contas a Receber, Contas a Pagar, Controle de Viagens, Controle de Inadimplência, Administração dos preços de venda, Compras, Controle de fretes, Controle de contratos, Controle de investimentos, Cotações de vendas, Estoque, Exportação, Faturamento, Gerenciamento de armazéns, Importação, Obrigações fiscais, Pedidos, Previsão de vendas, Recebimento, Gestão de informação de RH, Pagadoria, Treinamento, RH scorecard, Planejamento de RH, Planejamento de produção, Planejamento da capacidade, Custos industriais, Controle de chão de fábrica, Controle da produção, Configurador de produtos, Planejamento de Manutenção, Acompanhamento de Manutenção e ainda muitos outros

II.4

Tipos de Projetos de Sistemas de Informação

Existem três tipos de projeto de sistemas de informação: manual, manual para automático e re-automação [B4]. Os processos de re-automação ainda podem se dividir em recodificação, re-projeto e re-desenvolvimento, melhoria ou manutenção.

Todos esses tipos de projeto apresentam ao analista de sistemas o mesmo desafio: descobrir o que deve ser feito. Porém, cada tipo apresenta certas particularidades que facilitam ou dificultam esse trabalho de análise.

O trabalho do analista em sistemas manuais é mais relacionado à formalização, por meio de documentação e padrões, de processos já adotados, a criação de novos processos e a transformação de processos existentes tendo em vista otimizá-los ou possibilitar que atendam novas necessidades da organização. Esses processos podem ser bastante complexos e convolutos em alguns casos, o que exige do analista uma boa capacidade de compreensão e modelagem. Porém, como não serão transformados em programas de computador, o analista pode trabalhar com ferramentais mais informais e mais próximas ao dia a dia do usuário.

Os projetos que apresentam maior dificuldade são os de passagem do processo manual para o automático. Isso acontece porque normalmente esses projetos exigem todo o trabalho feito no tipo anterior, e, de forma adicional, a criação de um modelo computacional e com certo grau de formalidade, que possa ser usado pelos desenvolvedores. Não há, a princípio, uma guia que indique a adequação da automação ou que novos resultados podem ser obtidos. O usuário, por não ter acesso a sistemas de informação que executem a mesma atividade, tem pouco conhecimento sobre o que é possível fazer, ou não tem idéia de qual o custo de produzir certos resultados.

Já os projetos de re-desenvolvimento apresentam a vantagem de possuir uma base que pode ser utilizado como referência do que deve ser feito (repetido), do que não deve ser mantido (eliminações) e das novas atividades necessárias. O usuário, acostumado e experiente com um sistema existente, pode fornecer informações mais adequadas sobre o que espera do novo sistema, ou da manutenção ou melhoria sendo feita.

II.4.1 Porque são feitos projetos de SI Muitos são os motivos que influenciam o início de um projeto de desenvolvimento de um Sistemas de Informação. Em geral, usando um raciocínio econômico, podemos dizer que um projeto é iniciado quando o benefício do retorno esperado supera o custo do projeto 3 . O problema é que não é fácil converter esses valores em números normalmente.

II.5

Custo Total de Propriedade

Quanto se analisa o custo de um sistema é normal falar de Custo Total de Propriedade, conhecido pela sigla em inglês TCO (Total Cost of Ownership). O TCO

de um produto é o custo total que ele implica para uma organização. Por exemplo, se decidirmos trocar todo o parque computacional de uma empresa que usa Windows para Linux, mesmo que o custo do Linux seja zero, o TCO é bem alto, pois envolve o

processo de troca, novos profissionais, treinamento, etc

da compra de uma impressora. Seu TCO não envolve apenas o custo da impressora, mas também o custo do material consumível, quando uma certa produção é prevista. Por isso é que grandes empresas compram menos impressoras, porém impressoras maiores e mais caras, para baixar o TCO.

Outro exemplo comum é o

Para o software desenvolvido vale o mesmo conceito. Qual seu TCO? Envolve o preço pago pelo software mais tudo que vai ser pago para possibilitar a implantação

3 Na verdade, a compreensão econômica é mais complicada, mas essa explicação nos serve como motivador adequado.

e utilização do produto (instalação, cursos de treinamento, manutenção mensal, etc

II.6

Benefícios do Sistema

).

Vários motivos podem ser analisados como benefícios esperados de um projeto. O principal benefício que um sistema de informação pode oferecer é melhorar significativamente o negócio do usuário, aumentando seu lucro. Porém, essa não é a única motivação possível.

Uma motivação comum é modernização de um sistema. Com o tempo a tecnologia de um sistema vai se tornando superada. Isso faz com que o risco e o custo de manter o sistema funcionando naquela tecnologia aumentem, aumentando gradativamente o interesse de se transportar o sistema para uma nova plataforma. Simultaneamente, novas tecnologias apresentam novas oportunidades, como desempenho superior ou facilidade de aprendizado, aumentando também com o tempo o interesse nessa atualização. Chega um momento então que passa a valer a pena o investimento em modernização.

Outro motivo importante é a mudança de premissas básicas do negócio, causada pela atuação da firma no mercado. Essas mudanças tanto podem de dentro da empresa quanto podem ser provocadas por mudanças na legislação ou por ação dos concorrentes. Por exemplo, há alguns anos atrás, no Brasil, foram feitas várias modificações nos sistemas financeiros das empresas para aceitar a mudança de moedas e o convívio com moedas diferentes simultaneamente. Em outro exemplo, com a invenção e grande aceitação dos sistemas de premiação por viagens ou por milhas, as companhias aéreas tiveram que desenvolver sistemas específicos, interagindo com seus sistemas de passagens, para tratar do assunto. Muito comum também é a mudança de uma atividade da empresa, seja por um processo contínuo, como o de qualidade total, quanto por processos radicais como os de reengenharia e downsizing.

Os sistemas de informação também são importantes por oferecerem as empresas uma capacidade maior de competição. Com a informação correta e com os processos corretos de tratamento da informação uma empresa pode ter um diferencial de qualidade no mercado. Por outro lado, se todo um mercado já adotou um tipo de sistema, ou se pelo menos um concorrente já o fez, a empresa que não tem um sistema equivalente fica prejudicada na competição. Esse tipo de efeito foi visto quando as companhias aéreas passaram a vender passagens via Internet. No início era mais uma propaganda, depois passou a ser um diferencial positivo. Atualmente todas as companhias aéreas possuem formas de vender passagens diretamente via Internet.

Hoje em dia um grande motivador de novos projetos e a busca por melhor tratamento da informação que já existe em sistemas de tipo operacional, como a criação de Sistemas de Suporte Executivo.

O Poder está com o usuário

Um dos acontecimentos mais marcantes da computação é a transferência do

poder daqueles que operavam as máquinas, os famosos e muitas vezes odiados CPDs

– os Centros de Processamento de Dados – para o usuário final.

II.7

Para aqueles que só chegaram ao mundo da informática agora, ou para aqueles que nasceram após a revolução causada pelos microcomputadores, é muitas vezes difícil de entender a complexidade e a mística que cercavam os grandes computadores. Resfriados a água, mantidos em salas seguras, gastando espaço e energia, esses computadores da década de 1970 tinham o poder computacional de um telefone celular do início do século XXI. Eram esses computadores, porém, que mantinham os dados fluindo, as contas e salários sendo pagos, à custa de uma vigilância permanente de seu funcionamento e do uso de recursos. Até hoje, muitos serviços críticos funcionam em versões modernizadas desses computadores, geralmente a custos altos, mas com alto risco de transferência para outras tecnologias 4 .

Grande parte da transferência de poder aconteceu quando os microcomputadores chegaram em grande quantidade as empresas, permitindo que os usuários que não eram atendidos no prazo e na qualidade que esperavam tomassem a rédea do processo de software, desenvolvendo seus próprios aplicativas, usando planilhas eletrônicas e sistemas simples de banco de dados (como dBase II e Access) e, muitas vezes, passando por cima da estrutura da própria organização e contratando soluções terceirizadas, já que não precisavam do computador central para executa-las.

Isso alterou drasticamente a estrutura de poder das organizações, que eram fortemente dependentes dos dados processados de forma central, em grandes máquinas, com software de ciclo de desenvolvimento muito longo. O processo de mudança não poupou carreiras, sendo que algumas empresas simplesmente fecharam seus CPDs, terceirizando suas atividades e despedindo ou transferindo todos seus funcionários.

Hoje em dia o próprio nome CPD é estigmatizado. Cabe agora ao setor de TI – tecnologia da informação –manter uma estrutura muito mais complexa que a anterior, unificando sistemas de várias gerações, em redes com grande quantidade de computadores executando sistemas operacionais diferentes e aplicações diferentes. Ainda existem conflitos em o pessoal de TI e as outras partes da empresa, mas o foco cada vez mais é melhorar o negócio e atender melhor os usuários.

II.8

Exercícios

1)

Escolha um tipo de negócio de pequeno porte, como uma agência de viagens, e descubra (ou imagine) quais os principais sistemas de informação que ela necessita ou pode usar.

2)

Classifique os sistemas anteriores quanto ao seu nível na organização.

3)

Classifique os sistemas anteriores quanto ao seu tipo.

4)

Imagine que esse negócio se torna um grande negócio, por exemplo, uma grande cadeia de agências de viagens, e descubra (ou imagine) que novos sistemas podem ser necessários.

4 É importante perceber que computadores de grande porte ainda são bastante úteis em sistemas especiais, principalmente aqueles que exigem atender simultaneamente uma grande quantidade de usuários, devido a possuírem uma arquitetura planejada com esse objetivo, ao contrários dos PCs, que foram planejados para atender um único usuário.

5)

Que sistemas de informação fazem parte de seu dia a dia? Que papel você assume ao utilizar esses sistemas?

6)

Que sistemas de informação você pode se lembrar que contém informações importantes sobre sua vida pessoal ou profissional?

7)

Imagine uma empresa de plano de saúde que possui um sistema de nível operacional que registra e permite a aprovação pela pessoa responsável de exames e consultas. Que sistemas de informação de outros níveis podem ser feitos para utilizar essa informação? Que outros sistemas de informação podem fornecer informação para o sistema de aprovação?

8)

Defina, para um sistema de informação escolhido por você, as informações necessárias, que dados às descrevem e que conhecimento pode ser obtido a partir delas.

9)

Muitas lojas no Rio de Janeiro ainda utilizam sistemas de informação feitos em MS-DOS. Faça uma análise dos custos e benefícios para mudar um sistema desse tipo para Windows ou de mantê-lo como está. Qual a melhor opção atualmente? Qual a melhor opção nos próximos 2, 5 e 10 anos?

10)

Que tipos de sistemas podem interessar a Livraria ABC?

11)

Que tipos de sistemas podem interessar a Empresa de Clipping ClipTudo?

12)

Uma empresa precisa comprar uma impressora nova. Existem duas opções interessantes no mercado, como descritas na tabela abaixo. Qual impressora comprar se a empresa prevê fazer 30.000 impressões com a impressora. E se forem 100.000? E se forem 146.668? E se forem 500.000?

Característica

Impressora A

Impressora B

Preço da impressora (sem tinta)

R$ 300,00

R$ 5.000,00

Preço do cartucho de tinta

R$ 80,00

R$ 250,00

Número de cópias por cartucho

1.000

5.000

Vida útil da impressora

120.000

800.000

Capítulo III. O Desenvolvimento de Software

Capítulo III. O Desenvolvimento de Software

3. Exame de cada parte de um todo, tendo em vista conhecer sua natureza,

suas proporções, suas funções, suas relações, etc.

Novo Dic. Aurélio

Análise:

Análise de Sistemas Analista de Sistemas Ferramentas Ciclo de Vida Equipe de Desenvolvimento

Desenvolver software é a atividade, de longo prazo, de criar um ou mais programas de computador, um sistema, de forma a atender necessidades específicas de um cliente ou grupo de clientes.

No desenvolvimento de software realizamos as atividades de descoberta das necessidades e de criação do produto de software propriamente dito. Podemos dividir as atividades do processo de desenvolvimento em alguns grandes grupos:

Atividades de Análise, cuja finalidade é descobrir “o que” deve ser feito.

Atividades de Projeto, cuja finalidade é descobrir “como” o software deve ser feito.

Atividades de Implementação, cuja finalidade é produzir o produto de software de acordo com as especificações produzidas nas fases anteriores.

Atividades de Controle de Qualidade, onde se incluem todas as atividades com objetivo de garantir a qualidade do produto, como testes e verificações.

De acordo com o processo de desenvolvimento escolhido, cada uma dessas atividades pode ser dividida em várias outras sub-atividades ou tarefas. Elas podem ser executadas de diferentes formas, em diferentes ordens. Também é possível que as atividades de análise e projeto sejam feitas de forma implícita, por exemplo, quando desenvolvemos o software unicamente por meio de protótipos.

Dependendo do grau de formalidade do processo de desenvolvimento, que deve ser escolhido em função de um grupo de variáveis, como a complexidade do projeto, prazo e características da equipe. Enquanto um produto para um único usuário pode ser feito por meio de protótipos, sem nenhuma fase bem-definida, produtos muito grandes, como um sistema de informações para toda um empresa, necessitam ser realizados em passos muito bem planejados.

Esse livro trata de algumas metodologias usadas no processo desenvolvimento de software. Dependendo da fonte que utilizamos, esse processo pode envolver uma miríade de atividades. Na norma ISSO 12207 são citadas, por exemplo: análise de requisitos, projeto, codificação, integração, testes, instalação e aceitação. Outras referências podem apresentar divisões distintas dessas atividades, ou incluir atividades novas (como testes de integração e testes de unidades). Nesse livro estamos principalmente interessados em conhecer ferramentas para realizar a análise de um sistema de informação.

III.1 A Dificuldade do Problema

Apesar de parecer uma atividade fácil, desenvolver sistemas de informação é na verdade uma atividade muito difícil e que é muitas vezes fadada ao fracasso. Estudos do Standish Group conhecidos como CHAOS Report, envolvendo 8380 projetos de TI, indicam que, em 2004, 18% são um fracasso total, enquanto 53% tem algum problema de prazo, custo e funcionalidade. Apenas 29% dos processos são um sucesso.

18% 29% 53%
18%
29%
53%

Bem sucedidosCom Problemas Fracassados

Com ProblemasBem sucedidos Fracassados

FracassadosBem sucedidos Com Problemas

Figura 4. Resultados do CHAOS Report 2004 sobre projetos de TI (Standish Group, 2004)

Desenvolver software é difícil porque normalmente estamos lidando com problemas tão complexos que não os entendemos sem um grande esforço e, às vezes, sem tentar uma solução. Alguns autores chamam esses problemas de wicked problems, o que poderia ser traduzido para “problemas perversos”.

Estas taxas tão alta de fracasso se refletem principalmente em sistemas muito caros. Novamente, do CHAOS report, obtemos os seguintes dados, sobre a taxa de sucesso de projetos de TI de acordo com o custo do projeto:

Menos de 750M$ 55% Entre 750K$ e 1.5M$ 33% Entre 1.5 e 3M$ 25% Entre
Menos de 750M$
55%
Entre 750K$ e 1.5M$
33%
Entre 1.5 e 3M$
25%
Entre 3 e 5 M$
15%
Entre 6 e 10M$
8%
Maior que 10M$
0%
0%
10%
20%
30%
40%
50%
60%

Figura 5. Taxa de sucesso dos projetos, de acordo com o tamanho, em dados de 1998 (Standish Group, 1998)

Casos específicos não faltam para “contar a história” desses grandes fracassos:

Sainsbury, US $526 milhões jogados fora em um software de gerência de cadeia de suprimentos

Controle de Vôo Americano – US $ 2.6 bilhões jogados fora em um sistema que não chegou a fase de produção.

A Volkswagen do Brasil anunciou recall para cerca de 123 mil veículos dos modelos Gol, Fox e Kombi, que precisarão reprogramar um software que controla o funcionamento dos componentes eletrônicos do carro, inclusive do motor. Trata-se do terceiro maior recall já promovido pela montadora no Brasil.

FBI: US$ 170 milhões jogados fora em um sistema para identificar terroristas que tem que ser começado do início

Ford: US$ 200 milhões acima do budget em novo software de compra, que foi abandonado.

McDonald’s: US$170 milhões abandonados em um projeto de software.

III.2 Análise

Por análise entendemos a tarefa de levantar e descrever os requisitos de um sistema, definindo de que forma deve funcionar para atender as expectativas de todos que nele possuem algum interesse. Normalmente se diz que a análise define “o que” o sistema deve fazer sem especificar “como” fará. Durante a análise devem ser explicitadas que tarefas o sistema deve executar e que dados deve manter em memória. Para isso, criamos um ou mais modelos do sistema, descrevendo-o com diferentes perspectivas e graus de detalhe.

É a partir da análise de desenvolvemos um sistema. Ela é, simultaneamente, um acordo entre os desenvolvedores e seus clientes e um mecanismo de comunicação entre os desenvolvedores. Em ambos os casos, a análise define que serviços devem ser fornecidos pelo sistema a ser implementado e, por conseqüência, que serviços não estão no escopo do sistema.

Segundo Pressman [B5], “todos os métodos de análise devem ser capazes de suportar cinco atividades:

Representar e entender o domínio da informação;

Definir as funções que o software deve executar;

Representar o comportamento do software em função dos eventos externos;

Separar os modelos de informação, função e comportamento de maneira a apresentar os detalhes de forma hierárquica, e,

Prover a informação essencial em direção à determinação dos detalhes de implementação.”

Dessa definição, é possível deduzir que para a análise de um sistema ser útil e de qualidade, não basta entender “o que” deve ser feito, mas também desenvolver uma representação que permita documentar e comunicar essa informação.

III.2.1

Modelos de Análise Vários autores fizeram propostas de modelos para descrever a análise de sistemas.

Dentro do conceito de análise, apresentaremos os seguintes modelos:

Modelo de Negócio, que descrevem como funciona o negócio onde o sistema está inserido.

Modelo de Dados, que descreve os dados guardados pela memória do sistema, na forma de um Modelo Conceitual e segundo o método de entidades e relacionamentos.

Modelo Funcional, que descreve a funcionalidade essencial do sistema, utilizando diagramas de fluxo de dados.

Incorporamos também, em nossa fase de análise, a modelagem por pontos de função, que nos permitirá definir um tamanho para nosso sistema.

III.2.2 Ferramentas da Análise

A maior parte do trabalho de análise é feita da comunicação entre pessoas. Muito

dessa comunicação é feita na linguagem natal dessas pessoas, como o português. Um grande problema dessa comunicação é que línguas como o Português e o Inglês permitem a construção de sentenças ambíguas.

No desenvolvimento de sistemas temos que evitar ao máximo as ambigüidades. Para isso, temos que restringir a linguagem utilizada de forma que uma sentença só tenha uma interpretação possível (ou mais provável). Para isso foram criadas várias linguagens, algumas gráficas, que tem o poder de restringir as interpretações possíveis do que queremos dizer. Veremos no decorrer desse livro uma visão geral de algumas dessas linguagens.

III.2.3 A Tecnologia

A grande maioria dos autores advoga que não devemos levar em conta a tecnologia

que a ser empregada no desenvolvimento durante a análise de sistemas. A análise deve se

preocupar com o “o que fazer” e nunca com o “como fazer”.

Como estaremos seguindo os princípios da análise essencial, esta questão ficará inicialmente ainda mais restrita, pois o modelo essencial não pode conter nenhuma referência à tecnologia, sob o risco de produzir requisitos falsos.

Isso não quer dizer que o analista não possua as informações sobre a tecnologia, apenas que não as usa enquanto faz o trabalho de análise. Na prática, estamos sempre limitados por escolhas como linguagens, sistemas gerenciadores de bancos de dados, arquiteturas de rede e de computador. O que devemos fazer é não deixar que essas limitações influenciem nossas decisões sobre “o que” deve fazer o sistema 5 .

Da mesma forma, não queremos dizer que o analista deve ignorar essas questões ao trabalhar. Ele deve anotá-las, pensar em seus impactos, porém não deve trazê-las para o modelo criado na análise.

III.2.4 O Analista de Sistemas

O Analista de Sistemas é o responsável por levantar os requisitos do sistema e

transformá-los em uma especificação do que deve ser feito, i.e., a Análise do Sistema. Para isso, assume vários papéis [B4]: repórter, detetive, consultor, diagnosticador, investigador, organizador, solucionador de problemas, avaliador, simplificador, artista, escultor, arquiteto, auditor, especialista de organização e métodos, especialista do domínio da aplicação, gerente, etc. O porquê dessa longa relação de papéis é o fato de o analista realmente ter que assumi- los ao longo do processo. Ele entrevista pessoas em busca de fatos e detalhes, descobre fatos

5 Ou seja, essas decisões, muitas vezes tomadas antes de se iniciar a análise de um sistema, devem influenciar apenas a forma de funcionamento, não a razão desse funcionamento.

escondidos (intencionalmente ou não), muitas vezes por meio de inferências ou pistas encontradas, propõe soluções mais adequadas para problemas atuais e futuros, a partir de diagnósticos, planeja sistemas abstratos a partir de diagramas, e ainda muitas outras atividades.

III.3 Ciclo de Vida e Processo de Desenvolvimento

A norma ISO 12207 fornece um framework para compreender as atividades e processos do ciclo de vida do software da sua concepção até o fim do seu uso, que podemos indicar pela figura a seguir. É importante perceber a quantidade de processos envolvidos no ciclo de vida do software, pois eles nos mostram que muitas vezes subestimamos as verdadeiras necessidades para implantar e manter um sistema de informação.

Processos Fundamentais Aquisição Aquisição Fornecimento Fornecimento Operação Operação Desenvolvimento
Processos Fundamentais
Aquisição
Aquisição
Fornecimento
Fornecimento
Operação
Operação
Desenvolvimento
Desenvolvimento
Manutenção
Manutenção
Processos de Apoio Documentação Documentação Gerência de Configuração Gerência de Configuração Garantia de
Processos de Apoio
Documentação
Documentação
Gerência de Configuração
Gerência de Configuração
Garantia de Qualidade
Garantia de Qualidade
Verificação
Verificação
Validação
Validação
Revisão Conjunta
Revisão Conjunta
Auditoria
Auditoria
Solução de Problemas
Solução de Problemas
Adaptação
Processos Organizacionais Infraestrutura Treinamento Gerência Melhoria Figura 6. Framework fornecido pela norma ISO
Processos Organizacionais
Infraestrutura
Treinamento
Gerência
Melhoria
Figura 6. Framework fornecido pela norma ISO 12207, adaptado de
Machado [B6].

III.3.1 A Necessidade de Garantir a Qualidade Desenvolver software é um processo de transformação de uma necessidade do cliente em uma seqüência de produtos de software (análise, projeto, protótipo, manuais) que tem em seu fim um programa de computador. Essas transformações são imperfeitas, devidos a problemas de comunicação entre o usuário e o desenvolvedor e falhas nas técnicas utilizadas pelo desenvolvedor para garantir que nenhuma informação é perdida ou inserida de forma espúria no sistema.

Para garantir que o sistema faz o que o usuário deseja, utilizamos duas técnicas: a verificação e a validação. Verificar significa analisar se o produto de uma fase do processo de desenvolvimento está de acordo com sua especificação. Validar significa analisar se o produto de uma fase do processo de desenvolvimento está de acordo com as expectativas do cliente.

Precisamos ter claro em nossa mente a diferença entre as duas atividades. Quando transformamos um algoritmo em português para pascal, por exemplo, podemos fazer isso de forma perfeita e, ao mesmo tempo, fazer algo que o cliente não deseja. Quando validamos um programa com o cliente e o aprovamos, não necessariamente o que fizemos foi o que estava escrito na especificação do programa.

A tarefa mais importante, na verdade, é a validação, já que devemos atender o cliente.

A validação, porém, é geralmente mais informal e mais custosa que a verificação. Assim,

verificando que cada passo dado durante o processo de desenvolvimento esta conforme o passo anterior previu podemos economizar na validação.

III.3.2

III.3.2.1

Modelos de Processo mais Comuns

Processo em Cascata

Também conhecido como Linear Seqüencial. Nesse processo, assumimos que as atividades de análise, projeto e implementação podem ser feitas de forma seqüencial, sem que sejam necessárias interações entre as fases.

Um processo em cascata típico contaria com as seguintes fases:

Modelagem do Sistema, onde são estabelecidos os requisitos do sistema do qual o software sendo realizado participa, incluindo os requisitos de informação e de negócios.

Análise de Requisitos, onde são modelados os requisitos de informação, funcionais, comportamentais, de desempenho e de interface do software

Projeto, onde são planejadas as estruturas de dados, a arquitetura do sistema e o comportamento é mapeado em procedimentos.

Codificação, onde o projeto é transformado em uma linguagem inteligível pelo computador.

Testes, onde verificamos e validamos o software.

Manutenção, onde garantimos a usabilidade do software.

Defendido inicialmente como a forma correta de desenvolver software, é basicamente impossível de ser realizado. Podemos encontrar alguns exemplos de sucesso em casos onde o produto sendo desenvolvido e o ambiente de desenvolvimento são muito bem conhecidos.

Devido à divisão radical entre as fases, é dada grande ênfase a documentação. Inicialmente assumia-se que cada fase seria executada por uma equipe distinta de especialistas, fato que está se tornando mais raro hoje em dia. Também havia discussões sobre até que ponto deveria ir o projeto e onde começava codificação. De acordo com a complexidade do sistema, muitas vezes as fases de codificação e testes eram dividas em “codificação e teste de unidades” e “integração e testes de integração”.

Entre seus principais defeitos está o fato que o cliente só vê o produto final no último dia do desenvolvimento. Assim, é impossível detectar falhas ou atender demandas imediatas

do cliente. Além disso, a participação do usuário é muito baixa.

Análise Projeto Codificação Testes
Análise
Projeto
Codificação
Testes

Figura 7. O Modelo de Processo em Cascata ou Seqüencial

III.3.2.2 Prototipagem No processo de Prototipagem (pura) o desenvolvedor interage diretamente com o usuário, escutando seus pedidos e desenvolvendo, imediatamente, um protótipo do produto desejado. O usuário, então, utiliza esse protótipo e fornece ao desenvolvedor novas informações que o levam a modificar o protótipo, de maneira a atender todas as necessidades do usuário.

É claramente um processo de desenvolvimento baseado em um ciclo de realimentação de informações, com alta participação do usuário.

Não existe uma fase formal de análise ou projeto. Isso pode causar problemas graves e difíceis de corrigir no produto final, dificultando de sobremaneira a manutenção dos produtos. Pouca ênfase é dada à documentação.

Atualmente quase todos os processos de desenvolvimento utilizam protótipos, mas não um ciclo de vida de prototipagem.

Usamos “protótipos descartáveis” quando o protótipo é usado apenas para levantar alguns ou todos os requisitos e depois abandonado, em troca de uma implementação mais organizada. Um “protótipo operacional” é um software feito rapidamente para atender uma demanda do usuário e que é usado, mais tarde, como modelo de especificação para uma nova implementação do sistema.

Ë possível diferenciar “protótipos” de “mock-ups”. Um protótipo apresentaria o comportamento correto, ou aproximadamente correto, e seria caracterizado principalmente pela falta de rigor na implementação. Um mock-up apresentaria apenas uma interface que serviria como prévia da interface final.

Contrução ou Revisão do Protótipo Avaliação do Protótipo Escutar o
Contrução ou
Revisão do
Protótipo
Avaliação
do Protótipo
Escutar
o

Cliente

Figura 8. O Processo de Prototipagem

III.3.2.3 Processos Evolucionários Os modelos de processo evolucionários reconhecem que sistemas complexos se alteram com o tempo, usando a iteração do ciclo de desenvolvimento para acompanhar a evolução do sistema.

III.3.2.3.1 Processo Incremental

Pode ser visto como combinando o linear com a prototipagem. Tem o foco principal na entrega do produto. Para realizá-lo, repetimos a seqüência linear em vários calendários defasados no tempo. Busca implementar funcionalidades essenciais o mais cedo possível.

Análise Projeto Análise Codificação Projeto Testes Codificação Testes
Análise
Projeto
Análise
Codificação
Projeto
Testes
Codificação
Testes

Tempo

Codificação Projeto Testes Codificação Testes Tempo Análise Análise Projeto Projeto Codificação
Análise Análise Projeto Projeto Codificação Codificação Testes Testes
Análise
Análise
Projeto
Projeto
Codificação
Codificação
Testes
Testes

Figura 9. O Ciclo de Vida Incremental

III.3.2.4 Processo Espiral O Processo Espiral se caracteriza pelo desenvolvimento por uma série de produtos desenvolvidos em seqüência, cada vez mais complexos e mais próximos do produto final desejado. Ele se diferencia do Processo incremental porque os produtos de cada ciclo não são “subsistemas” do sistema original, mas sim produtos específicos que atendem necessidades específicas do projeto, como por exemplo, “teste de viabilidade” e “definição da interface com o usuário”.

Em cada ciclo da espiral, algumas atividades são realizadas em ordem seqüencial:

comunicação com o cliente, planejamento, análise de riscos, engenharia, construção e, finalmente, avaliação dos resultados.

Do RUP foram derivados vários outros processos, sendo o RUP o mais conhecido

deles.

Comunicaçao com Avaliação o Cliente Planejamento Construção Análise de Engenharia Riscos
Comunicaçao com
Avaliação
o Cliente
Planejamento
Construção
Análise de
Engenharia
Riscos

Figura 10. O Processo em Espiral, visão abstrata

III.3.2.5 Processo Win-Win

O Processo Todos Ganham - Espiral (Win-Win Spiral) é a unificação de dois

trabalhos distintos de Barry Boehm. No primeiro, o Processo espiral, ele propõe que um processo de software seja feito de acordo com um ciclo de especificações cada vez mais detalhadas que resultam em versões incrementais das capacidades operacionais desejadas. Cada ciclo envolve a elaboração dos objetivos, restrições e alternativas do produto, a avaliação das alternativas e riscos, a elaboração da definição do produto e do processo e o planejamento do próximo ciclo. No segundo, a Teoria-W, ele propõe que todas as decisões tomadas em um processo gerencial devem gerar uma situação de “todos ganham” 6 .

As fases para esse Processo são

Identificar X

Identificar condições de ganho para cada X

Conciliar condições de Ganho

Estabelecer objetivos, restrições e alternativas.

Avaliar alternativas de produto e processo, resolver riscos.

Definir produto e processo, incluindo partições.

Validar produto e processo, incluindo partições.

Revisar e alcançar compromisso (commit)

III.3.2.6 Desenvolvimento Acelerado Devido a grande pressão pela produtividade que as empresas sofrem no processo de desenvolvimento de software, constantemente são propostas novas técnicas com a finalidade de acelerar o processo de desenvolvimento. Entre elas podemos citar a própria prototipagem, Rapid Application Development (RAD), Adaptative Programming, Extreme Programming e toda uma gama de processos ágeis.

6 Em contrapartida com o caso normal, onde um ganha e os outros perdem, ou, ainda pior, com os casos onde a decisão tomada é vista como uma situação onde todos perdem.

Figura 11. O processo espiral como definido originalmente por Boehm (1988) III.4 A Equipe de

Figura 11. O processo espiral como definido originalmente por Boehm

(1988)

III.4 A Equipe de Desenvolvimento

A equipe de desenvolvimento é o conjunto de pessoas responsáveis por construir o

software. Dela fazem parte pessoas com diferentes habilidades. Em sistemas de informações

tradicionais teremos gerentes de desenvolvimento, analistas, projetistas, programadores, administradores de banco de dados, etc. Em sistemas mais modernos, como sistemas multimídia e websites, podemos ainda ter profissões novas como artistas e professores.

É importante verificar que as pessoas em uma equipe de desenvolvimento se

comunicam de alguma forma. Seguindo a regra de quanto maior o projeto, maior o número de pessoas, muito maior o número de formas em que essas pessoas podem se comunicar.

A figura a seguir tenta demonstrar essa idéia. Como uma pessoa, não há nenhuma

comunicação. Com duas pessoas, só há uma maneira delas se comunicarem. Com 3 pessoas, escolhendo apenas a comunicação entre duas pessoas, já existem 3 formas. Com 4 pessoas,

são 6 formas, com 5 pessoas são 10 formas. Basicamente, com N pessoas, existem (N×(N- 1))/2 formas delas se comunicarem duas a duas.

Em projetos enormes, se todos puderem falar com todos para fazer algo, a situação fica incontrolável.

Por isso, temos que organizar a equipe de desenvolvimento de alguma forma.

Figura 12. As linhas de comunicação entre as pessoas crescem rapidamente, segundo uma explosão combinatória.

Figura 12. As linhas de comunicação entre as pessoas crescem rapidamente, segundo uma explosão combinatória.

Em uma equipe com organização democrática, todos podem se comunicar com todos. Esse tipo de equipe é razoável para projetos pequenos, com equipes de até 5 ou 6 pessoas, onde a comunicação incentivará a descoberta. Normalmente essas equipes são encontradas em universidades e no desenvolvimento de pequenos projetos de alta tecnologia (um web site, por exemplo).

projetos de alta tecnologia (um web site, por exemplo). Figura 13. Em uma equipe democrática todos

Figura 13. Em uma equipe democrática todos falam com todos

A forma mais tradicional de organizar uma equipe é a forma hierárquica, baseada nas

teorias clássicas de administração (que por sua vez, são baseadas na forma de organização do

Exército e da Igreja).

Na equipe hierárquica temos um ou mais níveis de gerência. Cabe a gerência controlar o funcionamento do projeto. Os níveis mais baixos são responsáveis pela execução do projeto.

A equipe hierárquica é boa para manter regras e padrões, sendo uma escolha boa para

projetos repetidos e que exigem grande estrutura. Muitas empresas utilizam esse tipo de organização, porém ele é considerado fraco para o desenvolvimento de software novo, pois a

estrutura coíbe a criatividade.

Em relação ao uso dos profissionais, podemos indicar um defeito importante: o profissional de desenvolvimento experiente é transformado em gerente e “tira a mão da massa”. Muitas vezes, inclusive, ele é transformado em um mau gerente

Figura 14. Em uma equipe hierárquica, diminuem-se as linhas de comunicação. Brooks[B7] propõe uma equipe

Figura 14. Em uma equipe hierárquica, diminuem-se as linhas de comunicação.

Brooks[B7] propõe uma equipe conhecida como “Equipe do Programador Chefe”. Nesse tipo de equipe o desenvolvedor vai recebendo cada vez mais responsabilidade em relação ao desenvolvimento, mas não em relação à tarefa diária de administração, que é tratada a parte. Cada programador-chefe é responsável por parte do projeto e delega tarefas aos programadores seniores, que por sua vez podem delegar tarefas aos programadores juniores. Alguns desses programadores compõem uma equipe de teste.

Alguns desses programadores compõem uma equipe de teste. Administrador Bibliotecária Programadores Secretária

Administrador

programadores compõem uma equipe de teste. Administrador Bibliotecária Programadores Secretária Chefe Senior

Bibliotecária

Programadores Secretária Chefe Senior Junior
Programadores
Secretária
Chefe
Senior
Junior

Figura 15. Equipes do tipo programador chefe se baseiam na capacidade do programador chefe

Os métodos mais modernos, como RUP e XP, falam de papéis necessários nno processo. Papéis típicos do RUP são “Analista de Sistema”, “Arquiteto”, “Especificador de Use-Case” e “Projetista de Interface com o Usuário”, “Engenheiro de Casos de Uso” e “Engenheiro de Componentes”. Já os papéis do XP são: o comprador ou “GoldOwner”, o cliente ou “GoalDonor”, o gerente, o testador, o programador, o monitor ou “tracker” e o treinador ou “coach”. Em ambos os casos, papéis diferentes podem ser assumidos pela mesma pessoa. É importante notar que no caso do XP os dois primeiros papéis são do cliente.

Existem muitas outras formas de organizar equipes. Cada tipo de produto exige um tipo especial de equipe. Afinal, não desenvolveríamos um software para controle de vôo de um avião com o mesmo tipo de equipe para o qual desenvolvemos um software para controle de uma biblioteca.

III.5 Nossa Abordagem

Esse livro não propõe um método ou um ciclo de vida, mas sim um conjunto de técnicas, ou linguagens, que nos permitem trabalhar, de forma diferenciada, em cada uma das fases do desenvolvimento de software.

III.6 Exercícios

13) Descreva de forma sucinta os seguintes processos descritos na literatura:

1. RUP – Rational Unified Process

2. XP – eXtreme Programming

3. Adaptative Software Development

14) Descreva como são as equipes de desenvolvimento da empresa em que você trabalha e de uma grande empresa (como a Microsoft, por exemplo).

III.6.1 Trabalho em Grupo (Projeto de Cadeira) A turma deve se dividir em grupos de três a cinco pessoas, com quatro sendo o tamanho ideal. Cada grupo deve escolher um projeto de um sistema de informação. Essa escolha deve se basear nos seguintes princípios e conselhos:

O sistema deve ser simples o bastante para que todos o entendam

Algum participante do grupo deve ter experiência com o sistema ou com um sistema parecido

A melhor opção é escolher um aspecto do funcionamento de um negócio familiar que

algum membro do grupo tenha acesso. Exemplos típicos: estoque de uma loja, atendimento de um consultório, notas de um curso, pagamento de mensalidades de uma academia, etc.

Outra opção é um sistema que algum membro do grupo tenha desenvolvido (ou participado do desenvolvimento).

Não será aceito um sistema de locadora de vídeo, por ser um exemplo muito utilizado na literatura, permitindo plágio facilmente.

Na prática, um trabalho de cadeira deve conter de 10 a 20 eventos e mais de cinco entidades para ter “alguma graça”. Porém nesse ponto o aluno não sabe ainda o que é um evento ou uma entidade. O professor deve orientar os alunos para que o sistema faça aproximadamente 15 “coisas”, incluindo cadastros, relatórios e processamentos.

Os alunos muitas vezes misturam em suas “definições” mais de um sistema entre os sistemas de informação típicos. O professor deve orientar e explicar a diferença. Confusões comuns incluem sistemas de vendas, estoque, compras e controle de produção.

Os alunos devem preparar uma descrição informal desse projeto. Esse tema será utilizado no desenvolvimento de um projeto durante todo o curso.

Capítulo IV. Modelos, Abstrações e Frameworks

Capítulo IV. Modelos, Abstrações e Frameworks

Models are to be used, not believed. H. Theil `Principles of Econometrics' The human mind has first to construct forms, independently, before we can find them in things. Albert Einstein (1879-1955)

Todas as técnicas estudadas nesse livro implicam na criação de um modelo, seja ele do domínio da aplicação, do negócio, do problema, do sistema que será implementado, inclusive modelos que fazem a relação entre modelos distintos.

Apesar de usarmos estes termos de forma coloquial, é importante responder as perguntas: o que é um modelo? O que é uma abstração?

Um modelo 7 é uma representação de algum objeto, conceito, conjunto de conceitos ou realidade. Modelos são criados para que nós possamos estudar, normalmente segundo algum aspecto escolhido, o objeto modelado. Na grande maioria das vezes, um modelo é uma versão simplificada ou abstrata do objeto modelado.

No nosso dia a dia nos deparamos constantemente com modelos. Um mapa é u modelo do território que descreve. Uma maquete de um prédio é um modelo. Uma receita de bolo é um modelo do processo para construir o bolo. Uma foto do modelo pode ser vista como modelo.

Um tipo especial de modelo é o protótipo. Um protótipo é um modelo exemplar, no sentido que fornecer um exemplo, onde as simplificações são muito pequenas ou não existem.

Um modelo deve ser simples o bastante para ser fácil de manipular e, simultaneamente, complexo o suficiente para resolver o problema em questão, de acordo com o ponto de vista desejado.

Abstração é o processo mental de separar um ou mais elementos de uma totalidade complexa de forma a facilitar a sua compreensão por meio de um modelo, eliminando (ou subtraindo) o resto.

Quanto mais simples o modelo, maior