Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF

1. Identificação de um problema a ser implementado 2. Análise 1. Problemas e práticas recomendadas 2. Levantamento de requisitos 3. Custos relacionados 4. Metodologias de análise 5. Modelagem de bancos de dados 6. Diagramas para análise 7. Visão geral de ferramentas de análise 3. Projeto 1. Técnicas de projeto 2. Projeto de interfaces/interações 3. Projeto de banco de dados 4. Escolha de ferramentas de desenvolvimento 5. Modelos de construção de software 6. Camadas de software 7. Componentes / reutilização de software 8. Criação de protótipos PROJETO E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO I: Msc. Daniele C. Oliveira 2

E mail danieleoliveira@fc.ufu.br Página www.danieleoliveira.com.br Horário de Aula Segunda: 16:50 às 18:30 Quarta: 14:50 às 16:40 Horário de Atendimento Segunda : 15hs às 16:30hs PROJETO E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO I: Msc. Daniele C. Oliveira 3

METODOLOGIAS DE ANÁLISE PROJETO E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO I: Msc. Daniele C. Oliveira 4

Processo de Software Processo de Software é um nome chique para descrever quando sentamos juntos e planejamos construir ou consertar algo: Descobrir o que tem para ser feito. Descobrir como será feito. Fazer. Fazer. Fazer. Fazer. Descobrir se foi feito mesmo o que era para fazer. (enxague, repita) Cada um, a ser visto, representa uma tentativa de colocar ordem em uma atividade inerentemente caótica

O processo de software Um conjunto estruturado de atividades necessárias para desenvolver um sistema de software. Atividades Básicas especificação definição do quê o sistema deve fazer; projeto definição da organização do sistema implementação implementação do sistema; validação checagem de que o sistema faz o que o cliente deseja; evolução evolução em resposta a mudanças nas necessidades do cliente.

Processos dirigidos a planos e ágeis Processos dirigidos a planos são processos em que todas as atividades do processo são planejadas com antecedência e o progresso é medido em relação a esse plano. Nos processos ágeis oplanejamentoéincrementaleémaisfácil modificar o processo para refletir alterações nos requisitos do cliente. Na realidade, os processos mais práticos incluem elementos dos processos ágeis e dirigidos a planos. Não existe processo de software certo ou errado.

Modelos de processo de software Modelo Cascata Modelodirigidoaplanos.Fasesdeespecificaçãoe desenvolvimento separadas e distintas. Desenvolvimento Incremental Especificação, desenvolvimento e validação são intercaladas. Pode ser dirigido a planos ou ágil. Engenharia de software orientada a reúso Osistemaémontadoa partir de componentes já existentes. Pode ser dirigido a planos ou ágil. Na realidade a maioria dos grandes sistemas são desenvolvidos usando um processo que incorpora elementos de todos esses modelos.

MODELO CASCATA PROJETO E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO I: Msc. Daniele C. Oliveira 9

O modelo cascata

Fases do modelo cascata Existem fases identificadas e separadas no modelo cascata: Análise e definição de requisitos Projeto de sistema e software Implementação e teste de unidade Integração e teste de sistema Operação e manutenção O principal inconveniente do modelo cascata é a dificuldade de acomodação de mudanças depois que o processo já foi iniciado. Em princípio, uma fase precisa ser completada antes de se mover para a próxima fase.

Problemas do modelo cascata Divisão inflexível do projeto em estágios distintos torna difícil responder às mudanças nos requisitos do cliente. Por isso esse modelo só é apropriado quando os requisitos são bem entendidos e as mudanças durante o processo de projeto serão limitadas. Poucos sistemas de negócio possuem requisitos estáveis. O modelo cascata é mais usado em projetos de engenharia de grandes sistemas onde o sistema é desenvolvido em vários locais.

Desenvolvimento incremental

Benefícios do desenvolvimento incremental O custo para acomodar mudanças nos requisitos do cliente é reduzido. A quantidade de análise e documentação que precisa ser menor do que o necessária no modelo cascata. feita é bem É mais fácil obter feedback do cliente sobre o trabalho de desenvolvimento que tem sido feito. Os clientes podem comentar demonstrações do software e ver quanto foi implementado. Possibilidade de mais rapidez na entrega e implantação de software útil para o cliente. Os clientes podem usar e obter ganhos do software mais cedo do que é possível no processo cascata.

Problemas do desenvolvimento incremental O progresso não é visível. Gerentes precisam de entregas regulares para medir o progresso. Se os sistemas são desenvolvidos de forma rápida, não é viável do ponto de vista do custo produzir documentação para refletir todas as versões do sistema. A estrutura do sistema tende a degradar conforme novos incrementos são adicionados. A menos que tempo e dinheiro sejam gastos na reconstrução para melhorar o software, as mudanças regulares tendem a corromper a estrutura do sistema. A incorporação posterior de mudanças no software se torna progressivamente mais difícil e cara.

Prototipação de software Um protótipo é uma versão inicial de um sistema usada para demonstrar conceitos e testar opções de projeto. Um protótipo pode ser usado: No processo de engenharia de requisitos para ajudar na elicitação e validação de requisitos; Nos processos de projeto para explorar opções e desenvolver um projeto de interface de usuário; No processo de testes para executar testes fim a fim.

O processo de desenvolvimento de protótipo

Desenvolvimento de protótipos Pode ser baseado em linguagens ou ferramentas de prototipagem rápida. Pode deixar a funcionalidade de fora do teste. A prototipação deve focar em áreas do produto que não são bem entendidas; Achecagemdeerroserecuperaçãopodemnãoestarincluídasno protótipo; O foco deve ser em requisitos funcionais ao invés de não funcionais como por exemplo, a confiabilidade e a segurança.

Descarte de protótipos Os protótipos devem ser descartados depois do desenvolvimento, pois não são uma boa base para um sistema em produção: Pode ser impossível ajustar o sistema para alcançar requisitos não funcionais; Geralmente os protótipos não possuem documentação; Geralmente a estrutura do protótipo é degradada por mudanças rápidas; Provavelmente o protótipo não irá alcançar os padrões normais de qualidade organizacional.

Entrega incremental Ao invés de entregar o sistema em uma única entrega, o desenvolvimento e a entrega são distribuídos em incrementos, nos quais cada incremento entrega parte da funcionalidade necessária. Os requisitos do usuário são priorizados e os requisitos de mais alta prioridade são incluídos nos primeiros incrementos. Assim que o desenvolvimento de um incremento é iniciado os requisitos são congelados, mas os requisitos dos incrementos posteriores podem continuar a evoluir.

Entrega incremental

Vantagens da entrega incremental Os valores podem ser entregues ao cliente junto com cada incremento, e funções do sistema ficam disponíveis mais rapidamente. Primeiros incrementos agem como protótipos para ajudar a deduzir requisitos para incrementos posteriores. Menor risco de falha geral do projeto. Os serviços mais prioritários do sistema tendem a serem mais testados.

Problemas da entrega incremental A maioria dos sistemas requer um conjunto de funções básicas que são usadas por diferentes partes do sistema. Como os requisitos não são definidos em detalhes até que um incremento seja implementado, pode ser difícil identificar funções comuns que são necessárias a todos os incrementos. A essência dos processos iterativos é que a especificação seja desenvolvida em conjunto com o software. No entanto, essa pode entrar em conflito com o modelo de aquisição de muitas organizações, nos quais a especificação completa do sistema é parte do contrato de desenvolvimento do sistema.

Modelo espiral de Boehm O processo é representado como uma espiral ao invés de uma sequência de atividades com retornos. Cada loop na espiral representa uma fase do processo. Nãoexistemfasesfixascomoespecificaçãoouprojeto osloopsnaespiralsão escolhidos de acordo com a necessidade. Os riscos são avaliados explicitamente e resolvidos no decorrer do processo.

O modelo de processo de software espiral de Boehm

Setores do modelo espiral Definição de objetivos São identificados os objetivos específicos para cada fase. Avaliação e redução de riscos Os riscos são avaliados e atividades executadas para reduzir os principais riscos. Desenvolvimento e validação Um modelo de desenvolvimento para o sistema é escolhido, pode ser qualquer um dos modelos genéricos. Planejamento O projeto é revisto e a próxima fase da espiral é planejada.

Metodologias ágeis conceitos chave do Manifesto Ágil : Indivíduos e interações ao invés de processos e ferramentas. Software executável ao invés de documentação. Colaboração do cliente ao invés de negociação de contratos. Respostas rápidas a mudanças ao invés de seguir planos. Ex. Extreme Programming (XP), Scrum

Análise estruturada Proposta a partir de 1975 por vários autores (Constantine, Tom DeMarco, Yourdon, Gane & Sarson) Caiu em desuso com os modelos orientados a objetos Entretanto... Ainda é usada em novos sistemas Existe muita documentação em sistemas legados

Ferramentas principais Diagrama de Fluxo de Dados Dicionário de dados Linguagem estruturada Tabelas de Decisão Diagrama Entidade Relacionamento

Diagrama de Fluxo de Dados Modelo lógico do software Independente de hardware, software, estrutura de dados... Pode ser particionado em diversos níveis de abstração (Contexto ou nível 0, nível 1,...) 4 elementos básicos Entidade externa (origem/destino) Processo Depósito de dados Fluxo de dados

Entidade Externa Define a origem ou o destino dos dados Normalmente é uma pessoa ou grupo de pessoas, uma organização, ou parte dela, um hardware ou software Produz e recebe informação Como descobrir entidades externas? No mínimo temos duas : quem usa o sistema (cliente) e quem opera o sistema (departamento A)

Processo Transforma dados Pode representar um software, vários software, um módulo,... Geralmente provoca mudança de estado, estrutura ou conteúdo A numeração não indica sequência de ações Geralmente são verbos na especificação Dica : Para descobrir um processo relate os requisitos do sistema. (Cadastrar Cliente, Efetuar Login, etc.)

Depósito de dados Pode ser um arquivo, uma tabela, ou parte de um banco de dados Independente de unidade de armazenamento Pode receber o nome do fluxo de dados Normalmente está no plural

Fluxo de Dados Insere e retira dados de processos, depósitos de dados e entidades externas Deve ter um nome único Deve ser descrito no dicionário de dados

DFD de Contexto DFD de nível mais alto (DFD de nível 0) Apresenta a visão das principais funções do sistema Apresenta uma visão clara do produto com todos os macro processos, com entidades externas, fluxo de dados e depósito de dados principais.

Sistema de vendas de CDs via Web Diagrama de Contexto

Níveis de DFD Seguem DFD's de nível 1, 2,... A quantidade de níveis depende da complexidade do software Quantos níveis são necessários? O suficiente :) D.F.D nivel 1 É uma expansão do nível zero com mais detalhes e mais completo incluindo o tratamento de exceções.

Explosão de DFD s Uma vez identificadas as funções principais, pode se explodir cada função para níveis mais detalhados A explosão é uma decomposição hierárquica

Elaboração de um DFD Identificar e descrever os requisitos funcionais; Identificar entidades externas(ee); Associar o fluxo de dados que as entidades enviam, consomem ou recebem; Identificar consultas Desenhar o primeiro DFD: Iniciar no canto esquerdo com a entidade externa principal; procurar deixar todas as entidades externas nos cantos; na esquerda as EE de Origem e na direita as EE de Destino; desenhe fluxos que surgem, processo e depósitos de dados; verificar se todas as entradas e saídas foram incluídas; associar manutenções aos depósitos de dados; Explodir ou derivar processos complexos em níveis inferiores.

Sistema de controle acadêmico Entidade externa (Usuários/outros sistemas) Professor, aluno, secretaria, BD_Cadastro (do sistema de Cadastro da Universidade) Processos (Principais serviços) Controlar matrícula, Emitir lista da classe, Atualizar nota e freq, Classificar alunos Fluxos de Dados Dados de Entrada: Disciplinas oferecidas, Inf. Matrícula aluno, Código da disciplina, Boletim da classe, nº de alunos desejados no relatório. Dados de entrada vindos de outro sistema: Inf. Disciplinas cadastradas, Inf. Alunos cadastrados Dados de Saídas (resultados produzidos): Confirmação, Lista de alunos da classe, Relatório dos classificados Depósitos de Dados (dados mantidos pelo sistema) Históricos alunos, Matriculados

Exemplos de DFD s

Dicionário de dados Descrição de dados do software Ajuda a melhorar a comunicação usuário/analista Usado na base de dados Significado de fluxos e depósitos de dados Composição de dados agregados (endereço, identificação,...)

Dicionário de Dados Esquema de Documentação = é composto de + Concatenação {} n repetição [ ] escolha de alternativas () opcional Ex.: nome = [Sr. Sra. Srta.] + família + nome

Dado composto

Outro exemplo Nome = titulo_de_cortesia + (primeiro_nome) + ultimo_nome Titulo_de_cortesia = [Sr. Sra. Dr. Arq Eng] Segundo_nome = 2{caracter}12 Ultimo_nome = {caracter} Caracter = [A Z a z ]

Criação de DFD s a partir de especificações Verbos geralmente originam processos Substantivos são entidades externas, dados ou depósitos de dados O refinamento deve seguir até o processo realizar uma única função

Exercício Crie DFD's de nível 0 e de nível 1 e dicionário de dados para a especificação a seguir

O gerente de um hotel deseja um sistema para gerenciar as reservas. Quando um cliente potencial, acessando através da web, deseja fazer uma reserva, o sistema verifica se existem quartos disponíveis no período, e em caso positivo, o sistema solicitará os dados do cliente (nome, email, endereço, telefone). Os quartos que estivem disponíveis deverão aparecer com cor verde, e os que estivem já reservados deverão aparecer em vermelho. O sistema também deve armazenar dados sobre a reserva, como a data prevista para entrada, a data prevista para saída, e o número de quartos. Cada quarto possui um preço e uma descrição. Os serviços de quarto e o frigobar estão associados a cada reserva, uma vez que a reserva pode ter mais de um quarto. As reservas são garantidas através do pagamento de uma diária por cartão de crédito. Caso o cliente não efetue este pagamento até três dias antes da data prevista de entrada, a reserva é cancelada pelo sistema. São gerados relatórios diários de reservas canceladas, com o objetivo de liberar quartos disponíveis, além de relatórios de reservas não pagas e o relatório sobre as reservas a serem efetivadas no dia. O gerente também deseja que o sistema imprima um relatório de reservas dado um determinado período.