Análise e Projeto de Sistemas
© 2001 Jaelson Castro Evitando os Problemas 1
Evitando os Problemas
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 2
Objetivos Modelo de ciclo de vida em cascata Modelo de ciclo de vida incremental e
prototipagem Importância do gerenciamento de projeto Como usuários podem estar envolvidos
num projeto Ferramentas CASE no desenvolvimento
de sistemas
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 3
Desafios Bom gerenciamento do projeto Qualidade no sistema entregue Mas software é intangível!
Não pode ser pesado Sua força não pode ser medida Sua durabilidade não pode ser avaliada Sua resistência ao esforço físico não
pode ser estimada
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 4
Atividades que Precedem o Projeto de Desenvolvimento de Sistemas de Informação
Planejamento Estratégico de Sistemas de Informação Sistemas de Informação funcionam dentro
do contexto de uma organização e devem satisfazer suas necessidades atuais e futuras
Decisão estratégica do caso de estudo Agate: atrair companhias multinacionais para campanhas internacionais de advertência
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 5
Atividades que Precedem o Projeto de Desenvolvimento de Sistemas de Informação
Modelagem do Negócio Entender como uma determinada
atividade do negócio é realizada e como ela contribui para os objetivos da organização
Gerenciamento de campanha é uma importante função do negócio para Agate:
Deve ser modelado para determinar como será realizado
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 6
Ciclos de Vida dos Projetos O ciclo de vida descreve as relações temporais, de
interesse e de entrada/saída entre diferentes ciclos de vida
O conceito de ciclo de vida inclui o conceito de feedback (retornando para uma fase anterior) assim como indo para a próxima fase.
No passado, o conceito de ciclo de vida era aplicado para o gerenciamento de sistemas complexos que tinham algum tipo de hardware como produto final, exemplo: mísseis, redes de computadores, aeronaves, etc.
Não é fácil avaliar e observar os resultados da análise e projeto de sistemas de informação
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 7
Ciclos de Vida Benefícios
Processa o entendimento e compreensão Ordena as atividades globais Melhora a qualidade do produto Reduz os custos de software
Deficiências Granularidade muito baixa -- esconde detalhes
importantes do processo
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 8
O modelo do Ciclo de Vida em Cascata
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 9
Resultados do Ciclo de Vida em Cascata
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 10
O modelo do Ciclo de Vida em Cascata Críticas
Divisão inflexível do projeto em estágios distintos. Projetos reais raramento seguem isso!
Iterações são inevitáveis Pode levar muito tempo Difícil de responder às mudanças de requisitos do
cliente Adequado quando os requisitos são bem
entendidos
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 11
O modelo do Ciclo de Vida em Cascata com interação
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 12
O modelo do Ciclo de Vida em Cascata
Vantagens As tarefas de um determinado estágio
podem ser atribuídas a equipes especializadas
O progresso do projeto pode ser avaliado no final de cada fase para saber se o projeto deve ou não proceder
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 13
Modelo de Ciclo de Vida “Prototipagem”
Construir rapidamente para explorar alguns aspectos dos requisitos do sistema
Não é requerido como a funcionalidade final do sistema
Incompleto (faltam algumas funcionalidades) Não atende a todos requisitos não funcionais
(ex. Performance, segurança)
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 14
Modelo de Ciclo de Vida “Prototipagem”
Investigar requisitos do usuário Que dados devem ser fornecidos e que dados
devem ser capturados Investigar o modelo adequado de interface
Determinar se uma particular plataforma de implementação é apropriada
Determinar a eficiência de uma linguagem, SGBD ou infra-estrutura de comunicação
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 15
Modelo de Ciclo de Vida “Prototipagem”
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 16
Vantagens da “Prototipagem” Demonstrações antecipadas das funcionalidades
do sistema ajudam a identificar erros de entendimento entre o desenvolvedor e o cliente
Requisitos do cliente que tenham sido esquecidos são identificados
Dificuldades na interface podem ser identificadas
A possibilidade e utilidade pode ser testada (parcialmente)
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 17
Problemas da “Prototipagem” O cliente pode não entender o esforço extra
necessário para produzir um sistema completo e pode esperar uma entrega rápida
Pode desviar a atenção de características funcionais, unicamente para as características de interface
Requer o envolvimento significativo do usuário Gerenciar o ciclo de vida da prototipagem não é
fácil
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 18
Aplicabilidade da “Prototipagem”
Para sistemas interativos de tamanho pequeno ou médio
Para partes de grandes sistemas (interface do usuário)
Para sistemas de curto tempo de vida
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 19
Modelo de Ciclo de Vida Espiral Processo é representado como um espiral ao invés
de uma sequência de atividades com possibilidade de retorno
Cada volta no espiral representa uma fase no processo.
Não há fases fixas como especificação ou projeto - repetições no espiram são escolhidas dependendo do que é requisitado
Riscos são explicitamente avaliados e resolvidos através do processo
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 20
Modelo de Ciclo de Vida Espiral
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 21
Setores do Modelo Espiral Atribuindo objetivos
Objetivos específicos para a fase são identificados Avaliação e redução de riscos
Riscos são avaliados e atividades são identificadas para reduzir os riscos chave
Desenvolvimento e validação Um modelo de desenvolvimento para o sistema é
escolhido e pode ser qualquer um dos modelos genéricos
Planejamento O projeto é revisado e o próxima fase do espiral é
planejada
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 22
Fases do Desenvolvimento de Sistemas de Informação
Nós focalizamos agora na parte de desenvolvimento do ciclo de vida de um software.
Existem várias maneiras de dividir o desenvolvimento de um sistema de informação em fases
Para esse curso, nós identificamos quatro fases: estudo de possibilidades, análise de requisitos, projeto do sistema, implementação
Todas as atividades associadas a cada fase devem ser realizadas, gerenciadas e documentadas.
Suporte ao Desenvolvimento -- ferramentas e metodologias que auxiliam a realização, gerenciamento e documentação das quatro fases
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 23
Fases do Ciclo de Vida de um Sistema de Informação
Survey project
scope & feasibility
Study current system
Define end user
reqs.
Select feasible solution
Design new
system
Select & Acquire
new S&H/W
Construct new
system
Deliver new
system
Maintain & improve
system
project request
feasibility study
problem statement
initial requirements
detailed requirements
design spec
configuration
S/Wnew system
delivered system
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 24
Fase I: O Estudo de Possibilidades
Decidindo o que fazer Confirma que um problema existe Realiza um estudo para determinar se o sistema pode
desenvolvido para solucionar o problema (2 dias - 4 semanas)
Um estudo de possibilidades olham o problema no seu mais alto nível (sem detalhes)
O estudo de possibilidades é revisado pelo cliente (usualmente por um gerente) e se a revisão for positiva, então é feito um estudo mais detalhado dos requisitos.
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 25
Fase II: A Análise de Requisitos
Estudar detalhadamente procedimentos e sistemas de informação computadorizados já existeantes e documentá-los.
Definir objetivos a serem atingidos pelo novo sistema
Propor processos de négocios alternativos (várias possibilidades) que possam se adaptar melhor aos objetivos e metas da organização. Discutí-los com o cliente e ter o feedback de qual é a alternativa desejada.
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 26
Fase II: A Análise de Requisitos
Definir os limites do sistema de informação a ser construído como parte da coleção dos processos de negócio.
Definir requisitos não-funcionais do sistema proposto, incluindo requisitos de entrada/saída, requisitos de resposta, requisitos de arquivo, etc.
Colecionar estatísticas de volumes, quantidades de dados gerenciados pelo sistema.
Oferecer estimativas de custos e redimentos para a solução proposta.
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 27
Fase III: O Projeto Especificar uma arquitetura e um projeto
detalhado para o sistema de informação proposto Primeiro é especificado o sistema ideal,
encontrando todos os requisitos funcionais, então o sistema é modificado para ter os requisitos não-funcionais e outras restrições
Recursos alocados para equipamentos de hardware, tarefas pessoais e tarefas de programação.
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 28
Fase III: O Projeto Especificações técnicas são preparadas para:
Arquitetura de sistema (componentes, interfaces de sistema para sistemas existentes)
Processamento lógico (como o sistema faz o que é suposto a fazer?),
Projeto da base de dados (Que informação é manipulada pelo sistema?),
Entrada/saída (O que os usuários vêem?), Requisitos de plataforma (em que sistemas o sistema
roda?) e Procedimentos manuais (como as pessoas usam o
sistema?).
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 29
Fase IV: A Implementação (não coberto nesse curso)
O sistema é implementado com base na especificação do projeto
Programação do sistema é realizada São conduzidos os testes do sistema, tanto das
partes individuais quanto do sistema como um todo (teste de aceitação)
Equipamento é adquirido e instalado Procedimentos, manuais do sistema, especificações
de software e documentações são concluídas Pessoal é treinado
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 30
Gerenciando o Desenvolvimento de Sistemas de Informação
Com a continuação do projeto mais detalhes tornam-se disponíveis, assim como o que o sistema proposto deve fazer e como operá-lo
Em cada estágio são identificados riscos para a organização e suas importâncias
Se existe um risco de falha catastrófica então o sistema também deve ser redefinido ou cancelado.
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 31
Envolvimento do Usuário Garante que há o envolvimento contínuo e
efetivo do usuário com o projeto. Usuários podem estar envolvidos em vários
níveis e desempenhar muitos diferentes papéis Envolvimento direto Coleta de fatos Consulta
Explica cuidadosamente o papel deles Oferece treinamento quando requerido Dá tempo suficiente
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 32
Abordagens Metodólogicas Abordagem para desenvolvimento de software (ex.
OO) Um conjunto de técnicas e notações (ex. UML) Um modelo de ciclo de vida (ex. Espiral
incremental) Um conjunto unificado de procedimentos e filosofia Nesse curso nós não seguimos uma metodologia
específica Nós apenas aplicamos técnicas de OO de uma forma
coordenada usando UML
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 33
Processo de Apoio Automático (CASE)
Computer-aided software engineering (CASE) é um software de apoio aos processos de desenvolvimento e evolução de software
Automação de atividade Editores gráficos para desenvolvimento do modelo de
sistema Dicionário de dados para gerenciar entidades de projeto Construtor de GUI para construção da interface do
usuário Debuggers para ajudar a encontrar falhas no programa Tradutores automáticos para gerar novas versões do
programa
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 34
Apoio CASE para Preparação de Diagramas Verificação da corretude sintática Suporte ao dicionário de dados Verificaçã da consistência e completude Navegação para ligar diagramas Estender em camadas Rastrear Geração de relatórios Simulação do sistema Análise de performance
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 35
Apoio CASE para Construção de Software Gerador de código Debuggers Ferramentas de manutenção etc
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 36
CASE - Benefícios Padronizar a notação e diagramação Realizar verificação automática da
qualidade dos modelos Reduzir tempo na recuperação de dados
sobre o sistema Reduzindo tempo e esforço para
produzir código Promover reuso de modelos
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 37
CASE - Desvantagens Limitações na flexibilidade da
documentação oferecida A necessidade de trabalhar de um
modo específico Falso sentido de corretude Custos adicionais para instalação e
treinamento
© 2001 Jaelson Castro
Análise e Projeto de Sistemas
Evitando os Problemas 38
Tecnologia Case Tecnologia Case tem conduzido melhorias
significativas no processo de software embora não na ordem de magnitude dita anteriormente Desenvolvimento de software exige
pensamento criativo - não é uma leitura automática.
Desenvolvimento de software é uma atividade de equipe e, para grandes projetos, o maior tempo é gasto nas interações da equipe. Tecnologia CASE, realmente não auxilia isso.