Modelagem de Sistemas de Informação

Prévia do material em texto

Unidade II
MODELAGEM DE 
SISTEMAS DE INFORMAÇÃO
Profa. Gislaine Stachissini
Assuntos abordados na unidade II
 Metodologia e desenvolvimento de sistemas de informação:
 ciclo de vida;
 fases da metodologia;
 artefatos;
 técnicas de levantamento de dados.
 Metodologia de desenvolvimento ágil de sistemas de 
informação:
 XP;
 Scrum.
Conceitos – I
 Também denominada de método, forma de trabalho, técnica 
ou de um conjunto de passos organizados.
 É a forma organizada de alcançar um objetivo e que permite o 
uso de uma ou de diversas técnicas para o desenvolvimento 
de sistemas de informação. 
Conceitos
 Deve ser discutida, detalhada e sempre revisitada, revisada, 
atualizada e complementada, padronizada e deve ser utilizada 
por toda a organização.
 Como premissa, tem-se a modularidade, que divide um 
sistema complexo em módulos menores, coesos e mais 
gerenciáveis.
Ciclo de vida de desenvolvimento de SI
Ciclo de vida:
 Os sistemas de informação são desenvolvidos visando a 
atender as necessidades de uma organização, com base nas 
necessidades ou nos requisitos fornecidos pelo cliente ou 
pelo usuário.
Fonte: livro-texto
Ciclo de vida – I
Concepção ou nascimento:
 É o momento de estudo e entendimento dos requisitos dos 
clientes e/ou usuários. 
 É importante levar em consideração uma análise do sistema 
atual ou anterior. 
 Fase importante, pois é a partir dela que se define e se 
desenha um sistema que contemple a necessidade real do 
cliente/organização.
Ciclo de vida – II
A construção abrange:
 a análise de sistemas;
 desenvolvimento/construção dos códigos dos SIs.
Ciclo de vida – III
Implantação:
 Ocorre após a realização de todos os testes e a geração da 
documentação do SI. 
 É quando se disponibiliza ao cliente o sistema que foi 
desenvolvido.
Ciclo de vida – IV
Implementação:
 Essa fase tem o sentido de otimizar processos, agregar valor, 
adaptar funções ou realizar melhorias no sistema. 
 Ela é importante, pois garante que a real necessidade do 
cliente e a transparência das informações sejam mantidas 
desde o início do uso.
Ciclo de vida – V
Maturidade:
 Fase de utilização total do sistema, ou seja, do atendimento 
completo dos requisitos funcionais e da sedimentação 
do sistema.
 Esse é o momento de medir a satisfação do cliente.
Ciclo de vida – VI
Declínio:
 Ocorre quando o SI não atende mais ao que se espera dele, o 
que gera a impossibilidade de agregações e a não garantia da 
satisfação do cliente.
 O declínio pode ser atenuado com injeções periódicas de 
ajustes e melhorias.
Ciclo de vida
Manutenção:
 Ocorre em decorrência de uma exigência legal, de correção de 
defeitos/erros ou atualizações, tendo como principal foco a 
sobrevivência do sistema.
Morte:
 É quando ocorre a descontinuidade de um sistema de 
informação.
Obrigações no processo de desenvolvimento de SI 
No processo de desenvolvimento de sistemas, deve-se:
 fornecer uma visão do estado do projeto a qualquer instante;
 servir de meio de comunicação entre os envolvidos;
 indicar o nível de participação de todos os envolvidos;
 detalhar os níveis adequados aos interesses da equipe 
envolvida;
 manter um histórico documental do sistema;
 criar uma base de dados de conhecimento para fases e 
subfases futuras.
Interatividade
Em qual degrau no ciclo de vida é o momento de estudo e 
entendimento dos requisitos dos clientes e/ou usuários?
a) Concepção.
b) Implantação.
c) Construção.
d) Declínio.
e) Manutenção.
Fases da metodologia
 Visão do ciclo de vida do desenvolvimento clássico de 
sistemas de informação.
Fonte: Livro-texto
Fase – estudo preliminar – I
Tem por objetivo compreender:
 A necessidade e a estrutura do sistema a partir de suas 
origens e envolvidos.
 Constitui-se da concepção de um protótipo com a primeira 
definição dos requisitos desejados, objetivos, abrangências, 
integrações, limitações, impactos e áreas englobadas. 
Fase – estudo preliminar
Tem como subfases: 
 definição da equipe;
 recebimento das diretrizes e das necessidades;
 definição dos requisitos funcionais;
 definição da estratégia de análise.
Fase – análise do sistema atual – I
Tem por objetivo:
 obter o conhecimento do ambiente e do produto a partir do 
atual sistema;
 relatando os requisitos funcionais e observando suas 
vantagens e suas desvantagens;
 por meio do levantamento de dados e organização das 
informações.
Fase – análise do sistema atual
Tem como subfases:
 revisão do estudo preliminar;
 estudo do ambiente;
 levantamentos dos pontos críticos;
 desenho do sistema atual;
 definição do projeto lógico;
 validação da análise atual.
Fase – projeto lógico 
 Tem por objetivo definir o que o sistema fará, os requisitos e o 
detalhamento da lógica ideal do projeto.
Possui as seguintes subfases:
 rever a análise atual;
 definir a macroproposta;
 descrever a lógica;
 planejar o projeto físico;
 validar o projeto lógico.
Fase – projeto físico
 Tem por objetivo definir o que o sistema fará, como será a 
execução e a confecção de seus respectivos subsistemas.
Apresenta as seguintes subfases:
 rever o projeto lógico;
 elabora o modelo de dados;
 padronizar a arquitetura;
 desenvolver o sistema;
 fazer a conclusão do sistema;
 definir o projeto de implantação; 
 validar o projeto físico.
Fase – projeto de implantação
 Tem por objetivo definir o plano real de treinamento e a 
capacitação do cliente e o acompanhamento pós-implantação.
Possui as seguintes subfases:
 rever o projeto físico;
 refinar o plano de implementação;
 concluir o sistema;
 entregar o sistema definitivamente;
 realizar a pós-implantação;
 finalizar o projeto.
Artefatos, documentos, templates
 Durante o processo de desenvolvimento devem ser utilizados 
diversos modelos de documentação que podem ser 
modificados de acordo com a necessidade de cada projeto.
 Todos devem ser padronizados e identificados, contendo o 
título ou nome do projeto, a data de seu início e os nomes dos 
responsáveis por eles.
Artefatos modelo – I
 Termo de abertura do projeto.
Documento que define:
 o objetivo do projeto, a demanda, o escopo, os interessados, 
as interfaces com projetos existentes, prazo estimado para a 
conclusão do projeto, orçamento estimado, equipe básica, 
restrições, premissas e gerente do projeto.
Artefatos modelo – II
 Plano para gerenciamento de escopo e mudanças.
Documento que contém:
 os aspectos gerais do gerenciamento, o processo de 
gerenciamento do escopo e mudanças, relação dos 
participantes do comitê de controle de mudanças, o processo 
de gerenciamento de configuração e os itens de configuração 
e responsáveis.
Artefatos modelo – III
 Declaração de escopo do projeto.
Documento que declara:
 o resumo do projeto, o objetivo do projeto, as metas do 
projeto, a lista de entregas e requisitos, exclusões de escopo, 
estimativas de tempo e custo, funções e responsabilidades, 
premissas, restrições, riscos e critérios de aceitação do 
produto/serviço.
Artefatos modelo – IV
Plano para gerenciamento de custos:
 Documento que contém a montagem do plano, estimativas de 
custos, orçamento e cronograma.
Plano para recursos humanos:
 Documento que descreve a quantidade de RHs necessários 
em cada especialidade que o projeto necessita.
Artefatos modelo 
Plano para gerenciamento de riscos:
 Documento que descreve os aspectos gerais do 
gerenciamento de riscos, como serão identificados,qualificados e quantificados.
Plano para aquisições:
 Documento que declara os itens que serão comprados e de 
que forma a compra será realizada.
Técnicas de levantamento de dados – I
Destacam-se as seguintes técnicas:
 Questionário:
 Formulário previamente desenvolvido com questões a 
serem apresentadas e discutidas com os stakeholders do 
projeto.
 Entrevista:
 Técnica para atuar junto dos interessados para obter 
conhecimento sobre suas necessidades.
Técnicas de levantamento de dados
 Seminário:
 Workshop ou dinâmica de grupo a fim de obter informações 
sobre a empresa.
 Pesquisa:
 Forma de verificar o que ocorre no cotidiano do 
cliente/usuário.
 Documentação:
 Registro de todos os conhecimentos adquiridos no projeto 
e garantia que serão utilizadas no futuro.
Interatividade
Na fase de projeto lógico da metodologia de desenvolvimento 
de sistemas: 
a) Definem-se as necessidades do cliente em forma de 
requisitos.
b) Definem-se as necessidades do cliente em forma de 
protótipo. 
c) Define-se a macroproposta de solução para o SI. 
d) Desenvolve-se realmente o sistema. 
e) Define-se a macroproposta, descrevem-se as lógicas de 
implementação dos códigos e se planejam as soluções 
físicas do SI.
Metodologia ágil – motivação – I
Proposta que surge com a necessidade de desenvolvimento 
rápido de softwares, devido:
 à grande quantidade de informações que trafegam nas 
corporações;
 à viabilidade para converter essa gama de informações 
desencontradas em informações úteis para a organização.
Metodologia ágil – motivação – II
 Já que o desenvolvimento tradicional, ao longo do tempo, 
mostrou-se muito demorado, e quando o software é entregue 
já está desatualizado e não atende completamente à 
necessidade do cliente. 
 Obviamente, isso não ocorre com todos os projetos.
Metodologia ágil – motivação
 As organizações necessitam de outro tipo de metodologia que 
possa atender as suas necessidades de forma ágil e, dessa 
forma, torna-se fundamental alterar seus processos de 
desenvolvimento. 
 Essa é a proposta da metodologia ágil ou os métodos ágeis.
Metodologia ágil – características fundamentais – I
 O projeto e a implementação são realizados de forma 
intercalada.
 A documentação pode ser gerada automaticamente pelo 
ambiente de programação (automação do desenvolvimento).
 No documento de levantamento de requisitos constam apenas 
as características importantes do sistema.
Metodologia ágil – características fundamentais – II
 O sistema não é desenvolvido de uma só vez, e sim em uma 
série de versões ou releases.
 Os stakeholders são envolvidos na especificação e na 
validação de cada versão.
 Utiliza-se uma interface interativa com uma tela rápida de 
criação com uso intensivo de figuras, desenhos e ícones, o 
que facilita a comunicação com o usuário final. 
Princípios da metodologia ágil
Nos métodos ágeis mais utilizados, ou seja, no Scrum e no XP, 
têm-se fortemente definidos os princípios da metodologia ágil 
que são focados:
 no cliente;
 em pessoas;
 em mudanças;
 na entrega;
 na simplicidade.
Metodologia ágil – constatação
A metodologia ágil tem sido bem sucedida:
 nas organizações de pequeno e médio porte;
 no desenvolvimento de sistemas personalizados;
 dentro das empresas que permitem que se trabalhe de forma 
não tão metódica.
Metodologia ágil – pontos fracos e riscos
 Dependência da participação do cliente na equipe de 
desenvolvimento.
 As pessoas não estão acostumadas a definir sua própria 
forma de trabalho e trabalhar em parcerias.
 Conflitos quando existem muitos stakeholders envolvidos no 
projeto.
 Pressões por prazos e cronogramas.
 Existência de um processo definido e implementado.
Ciclo de desenvolvimento ágil
 O projeto e a implementação são considerados foco central. 
 Todas as outras atividades, como levantamento de requisitos, 
teste e implementação, estão inseridos dentro desses 
processos. 
 Na metodologia ágil, o amadurecimento dos requisitos é feito 
internamente no processo. 
Fonte: Livro-texto
Metodologia comum x metodologia ágil
 Comparação – abordagens:
Fonte: Livro-texto
Interatividade
Qual dos itens abaixo não é um foco da metodologia ágil?
a) No cliente.
b) Em pessoas. 
c) Em mudanças. 
d) No hardware.
e) Na simplicidade.
Metodologia ágil – XP
 Uma das mais utilizadas no método ágil de desenvolvimento.
 Surgiu com o objetivo de se ter um desenvolvimento levado 
ao extremo.
 Testada por diversos desenvolvedores com opiniões 
diferenciadas.
 Os requisitos viram cenários que são trabalhados pelos 
desenvolvedores em pares. 
Metodologia ágil XP – fundamentos – I
 Os requisitos são baseados em cenários e têm como base a 
simplicidade.
 Existe um envolvimento contínuo da equipe, incluindo o 
cliente.
 As mudanças são apresentadas em releases ao cliente e são 
frequentemente avaliadas por ele.
Metodologia ágil XP – fundamentos
 A metodologia é sustentada por pessoas, e não por processos. 
 Com o uso dos pares, os casos são solucionados em menos 
tempo, pois duas cabeças pensam em mais possibilidades.
 Pela simplicidade, a manutenção é realizada pela releitura 
constante, o que gera melhoria de qualidade no código fonte.
Metodologia ágil XP
Fonte: Livro-texto
Metodologia ágil XP – melhores práticas – I
 O uso de pares para agregar valor ao trabalho e reduzir tempo, 
custo e estresse.
 Liberação em releases com poucas funcionalidades para o 
cliente.
 O plano é incremental a partir dos cenários acordados com o 
cliente.
 O projeto deve ser simples e se ater a trabalhar as 
necessidades em contrato. 
Metodologia ágil XP – melhores práticas – II
 Os testes podem ser escritos antes mesmo da codificação do 
sistema.
 Uso da refatoração para deixar o código simples e aplicar as 
melhorias contínuas.
 A propriedade do código é do time e não de um único 
desenvolvedor.
 A integração é contínua e os pedaços podem ser enviados 
para análises e testes de sistemas.
Metodologia ágil XP – melhores práticas
 Sustentabilidade: não é aceito excesso de horas extras, já que 
comprometem a qualidade e a produtividade esperadas.
 O cliente presente: o cliente não é apenas um observador, ele 
é parte integrante e importante durante todo o projeto, 
opinando em todas as fases.
Gerenciamento nas metodologias ágeis
 O foco principal de um gerente de projetos na metodologia 
ágil é garantir que o projeto seja entregue no prazo e dentro 
do orçamento estimado. 
 Supervisiona as atividades que estão sendo realizadas 
conforme o cronograma estipulado, porém o faz de forma que 
se faça o melhor uso do tempo e dos recursos disponíveis 
para a equipe.
Metodologia ágil SCRUM
 O método ágil SCRUM tem como foco o gerenciamento do 
desenvolvimento ágil.
 Ciclos devem ser cumpridos para a entrega do produto final.
 Possui uma nomenclatura própria, são termos-padrão 
utilizados, mesmo que os nomes desses itens em inglês soem 
estranhos, não é usual que eles sejam traduzidos no momento 
de sua utilização.
SCRUM – envolvidos I
Product Owner:
 É a pessoa da equipe que define os itens que comporão o 
Product Backlog e suas prioridades.
 Gerente na metodologia tradicional.
Scrum Team:
 É formado pelos integrantes do grupo que irão desenvolver o 
projeto com base na lista de tarefas negociada para o Sprint. 
SCRUM – envolvidos II 
Scrum Master:
 É o responsável por garantir os valores e as práticas do 
SCRUM nas equipes. 
Product Backlog:
 É uma lista de funcionalidades levantadas combase na 
necessidade do cliente e que deve passar por um processo de 
categorização no qual serão atribuídas prioridades para cada 
uma delas.
SCRUM – envolvidos 
Product Backlog:
 Uma lista de funcionalidades levantada nas necessidades do 
cliente.
Sprint Planning Meeting:
 É uma reunião realizada com todas as pessoas envolvidas no 
projeto. 
 É obrigatória a presença do Product Owner, do Scrum Master
e de todo o Scrum Team.
 Com o objetivo traçado, o Sprint é avaliado no Sprint Review
Meeting. 
Metodologia ágil SCRUM
Fonte: Agile Project Management with Scrum (2004) – livro-texto.
Interatividade
Na metodologia SCRUM, o Sprint Planning Meeting:
a) É uma reunião realizada com todas as pessoas envolvidas no 
projeto. 
b) Não é obrigatória a presença do Product Owner, já que é uma 
reunião técnica.
c) É uma reunião para avaliar se os objetivos traçados foram 
cumpridos.
d) É uma reunião inicial para que o Scrum Master defina as 
prioridades do desenvolvimento.
e) É uma reunião de equipe para discutir somente cronogramas.
ATÉ A PRÓXIMA!