GDI003 - Aula 07 - Modelo Estruturado

Objetivo da aula

• Introduzir o conceito de Modelo Estruturado para projetos de software
• Entender as etapas que fazem parte do Modelo Estruturado
• Enquadrar o projeto dentre 4 tipos possíveis

Etapas do Modelo Estruturado

• Desenvolvimento em Cascata

Erro ao criar miniatura: Arquivo não encontrado

Requisitos (Concepção do Software)

Nesta fase, desenvolvem-se:

1. Levantamento das necessidades
2. Coleta de documentos
3. Entrevistas com usuários
4. Observações do problema corrente
5. Avaliação de tecnologias atuais
6. Possibilidades de Inovação tecnológica
7. Definição dos requisitos funcionais
8. Definição dos requisitos não-funcionais

Exemplos:

1. Criação de um sistema de controle para biblioteca
2. Reunião com a diretora que é responsável pelo sistema que está obsoleto
3. A ficha catalográfica dos livros, relatórios do controle atual, código ISBN, cadastro dos usuários, ...
4. Conversas com as bibliotecárias, os alunos, a diretora, os professores, ...
5. Vejo que existem pessoas que reclamam do atendimento! Muitos dizem que o processo de empréstimo é lento!
6. É interessante inserir autenticação do usuário pelo polegar? Autenticação do livro via chip? Controle de uso por NFC? ...
7. Que tal implantar uma pesquisa semântica? E autenticação do usuário pela íris? ...
8. Finalmente: Quais itens serão desenvolvidos?
   1. Função 1: Cadastrar livro
   2. Função 2: Emprestar livro
   3. Função 3: Devolver livro
   4. Função 4: Cadastrar usuário
   5. Função 5: Autenticar usuário
   6. Função 6: Distribuir nas estantes
   7. Função 7: Relacionar devedores
   8. ...
   9. Função n: ....
9. Para completar: Quais os aspectos externos?
   1. Aspecto 1: Sistema Operacional
   2. Aspecto 2: Ambiente web e mobile
   3. Aspecto 3: Dispositivos onde a aplicação será usada
   4. Aspecto 4: Facilidades disponíveis para o usuário
   5. Aspecto 5: Onde o sistema será hospedado
   6. Aspecto 6: Requisitos críticos => tempo de resposta, interface, escalabilidade, ...
   7. ...
   8. Aspecto n: ....

Análise

Viabilidade técnica

• Quando se começa a discutir a possibilidade ou a necessidade de se fazer algo, deve-se avaliar a relação custo-benefício => Why
• Avaliação dos recursos técnicos disponíveis => Who
  • Tendo a certeza de que será feito, quem poderá gerenciar, desenvolver, usar, pagar, manter, etc
• Hardware, software e pessoas => What
  • Com a definição clara do que será feito e sabendo que um sistema é um processo de Input - Processamento - Saída pode-se definir tudo o que interagirá com o sistema em termos de dados.

Viabilidade operacional

• Aspectos das soluções que implicarão mudanças de rotinas existentes => How
  • Um software depois de pronto tem que ser corrigido, melhorado, etc. Os dados devem ser backupeados, atualizados, etc. Existirão pessoas e ambientes que lidarão com ele.
• Para o estudo da viabilidade operacional é preciso entender primeiramente o atual problema do software em questão, e, a partir daí, o programador, ou a equipe, devem se perguntar algumas coisas como: "Vale a pena resolver esse problema?", "A solução proposta pode realmente resolver o problema?" e "Qual será a experiência do usuário final ao utilizar esse programa?". Sendo assim é preciso fazer algumas comparações entre o programa em sua fase atual e como ele estaria depois das alterações necessárias. Alguns critérios interessantes de se analisar nesse quesito são:
  • Performance e eficiência: Nesse critério são feitas comparações do programa atual e o modificado a respeito do tempo de resposta, utilização de todos os recursos disponíveis e também as facilidades para a compreensão de seu funcionamento.
  • Informações: É necessário comparar os programas para ter certeza de que as informações adquiridas são de fato seguras, confiáveis e úteis para a empresa ou usuário que manipula o software.
  • Economia: Obviamente também é preciso checar se a nova solução é economicamente viável, tanto para o programador, quanto para a empresa ou usuário do software em questão.
• Após esse estudo é possível dizer se é viável ou não a modificação do programa em questão, por isso, os temas acima são realmente necessários quando se trata do estudo da viabilidade operacional.
• Impactos na área, na empresa, na sociedade. Discussões de ordem ética e moral => When
  • Durante ou depois que for desenvolvido, será utlizado por pessoas ou empresas. No tempo em que for usado interferirá em alguma regra, ambiental, legal ou regulatória?
    • No tópico acima foram abordados temas de maneira mais geral, mas também é preciso ver a unicidade de cada situação, sendo assim, é preciso entender que cada usuário, empresa ou organização que pode ser usuário desse software e para isso estuda-se as regras internas de cada empresa, os direitos dos trabalhadores e humanos. Não deve-se esquecer também que em pleno século XXI a natureza encontra-se cada vez mais desgastada e por isso faz-se necessária uma análise de legislação ambiental.
• Concluí-se então que, após a análise dos temas do tópico acima somados com as peculiaridades de cada empresa, seus funcionários, usuários e o ambiente temos a compreensão se é viável ou não a alteração do software.

Viabilidade econômica

• Possíveis soluções tecnicamente disponíveis e utilizáveis => Where
  • As estruturas que abrigarão o software devem ser consideradas porque efetivamente ele tem que rodar em algum lugar. Esse lugar tem custo e também requisitos técnicos
• Investimento necessário => How much
  • Com os dados discutidos nos itens anteriores, deve-se ter a noção de custos nas seguintes fases: desenvolvimento, manutenção e operação.

Projeto Lógico

A solução escolhida começa a ser detalhada e criteriosamente desenhada.

Um sistema:

• É um conjunto de componentes inter-relacionados organizados para atingir um certo objetivo

• É organizado para executar certo método, procedimento ou controle ao processar informações

• Automatiza ou apóia a realização de atividades humanas através do processamento das informações.

Codificação (Projeto Físico)

• Implementação do código baseado numa linguagem com a adição de bibliotecas, APIs, Webservices, Banco de Dados e ambientes de desenvolvimento.

Testes

• Avaliação do cumprimento dos requisitos pré-estabelecidos em testes unitários, de carga ou de serviço.

Operação

• Período em que o software será executado em regime de produção.

Tipos de sistemas

• Normalmente cada projeto se enquadra em um dos seguintes tipos:

I - Idéia Radical

• Escopo cujo benchmarking mostra que não existe proposta igual ou que a solução mais parecida ainda está longe da definição do projeto encontrado.
  • Exemplo:
    • Cryptum
  • Dinâmica:
    • A. Se for de médio ou grande porte => requer projeto e protótipo
    • B. Se for de pequeno porte => requer projeto e implementação.

II - Idéia incremental

• Escopo cujo benchmarking mostra que existe proposta parecida e que este projeto pretende manter o escopo básico e criar funções adicionais inovadoras.
  • Exemplo:
    • Bola na Rede
  • Dinâmica:
    • Se for de médio ou grande porte => requer projeto e protótipo
    • Se for de pequeno porte => requer projeto e implementação de todas funções adicionais

III - ­Prototipagem

• Projeto que já tem um protótipo desenvolvido mas que não foi modelado. O escopo descreverá a proposta de construção de um sistema completo, com todas as funcionalidades possíveis para se tornar um produto profissional.
  • Exemplos:
    • Speak Plus
  • Dinâmica:
    • Como já tem protótipo, se for de médio ou grande porte => requer projeto completo e demonstração
    • Como já tem protótipo, se for de pequeno porte => requer projeto e implementação de novas funções.

IV -­ Engenharia Reversa

• Projeto que pretende usar uma solução existente e contribuir para sua evolução ou desenvolver um sistema com funcionalidades muito próximas do original.
  • Exemplos:
    • Power 2048
  • Dinâmica:
    • Como já tem o sistema pronto, se for de médio ou grande porte => requer projeto completo.
    • Como já tem o sistema pronto, se for de pequeno porte => requer projeto e implementação de novas funções.

• Como se enquadra um sistema em pequeno, médio ou grande porte?
  • Número de funções
  • Número de interações
  • Complexidade das funções

Agora mãos a obra!!!!

1. Definir problema
2. Dar nome ao projeto
3. Escrever escopo
4. Executar Etapa de Requisitos
5. Preencher 5W2H

Iniciando um projeto

• Seleção do projeto:
  • Brainstorm
    • Discussão sobre ideias, necessidades ou problemas
  • Definição:
    • Nome e escopo do projeto
  • Criação do link no site
    • Template: 5W2H

• Aquisição dos dados
  • Requisitos Funcionais
  • Requisitos Não-Funcionais

• Análise
  • Discussão em grupo de todos os detalhes possíveis

• Projeto Lógico:
  • Documentação
  • Projeto escrito
  • Diagramas

• Prototipagem:
  • Transformação do projeto lógico em um projeto físico reduzido.
    • Se pequeno: implementação completa
    • Se médio: implementação da navegação e de poucas funções ou casos
    • Se grande: implementação da navegação e de uma função ou caso

Questões

• 01. Com relação ao problema para o qual irá modelar um sistema como pretende coletar dados para aprofundar o máximo possível sobre ele?

• 02. Descreva sucintamente as tecnologias que poderão ajudar a resolver seu problema.

• 03. Quais especialistas sobre o assunto você conhece ou ouviu falar que poderá ajudar a conhecer mais sobre as possíveis soluções para seu problema?

• 04. Você sabia que inovação tecnológica não quer dizer invenção? O que é então?

• 05. Cite um exemplo de inovação tecnológica em qualquer área.

• 06. Descreva um exemplo de operação, por exemplo, na Biblioteca da sua escola.

• 07. Descreva um exemplo de operação, por exemplo, no site de comércio eletrônico.

• 08. O problema que pretende resolver pode ser enquadrado em qual dos tipos de sistemas?

• 09. O que é um SDK?

Explicando sobre Mockups