Objetivo da aula
- Explicar uma técnica de detalhamento de um projeto
- Mostrar projetos anteriores que servem como benchmarking
- Identificar um projeto modelo
- Sugerir passos para o levantamento de dados para construção do software
- Entender Requisitos Funcionais e Requisitos Não-Funcionais
- Avaliar métricas para Requisitos Não-Funcionais
5W2H
- Pesquisa de projetos anteriores:
- Sugestão: Ler o escopo dos projetos para entender o objetivo de cada um
- http://www.sourceinnovation.com.br/index.php/Modelo_Estruturado
What
- Qual o nome do seu projeto?
- Qual o objetivo deste projeto?
- Quais os maiores desafios, na sua opinião, para se realizar este trabalho?
- Quais os conhecimentos básicos que devemos ter para se implementar este projeto?
- Quais soluções similares existem no mercado?
Why
- Porque é interessante desenvolver este projeto?
- Porque deve usar a tecnologia escolhida?
- Porque usar o hardware específico?
- Porque usar o sistema específico?
Who
- Quem pode se beneficiar deste projeto?
- Quem poderá operar o sistema?
- Quem deverá participar do desenvolvimento do sistema?
Where
- Onde os dados serão inseridos?
- Onde os dados serão externalizados, publicados?
- Onde esta aplicação poderá ser usada?
- Onde os dados serão armazenadas?
- Onde o software deverá ser hospedado?
When
- Em quanto tempo pretende desenvolver o sistema?
- Quais serão as fases e em quanto tempo cada uma?
- Qual o tempo de resposta do dispositivo ou do sistema?
- Quanto tempo para responder a uma entrada?
- Quanto tempo para gerar a saída?
How
- Como será dividido o desenvolvimento do sistema?
- Como será feita a entrada de dados?
- Como será feita a saída de dados?
- Descreva a 1a. funcionalidade?
- Descreva a 2a. funcionalidade?
- ............
- Descreva a enésima funcionalidade?
How much
- Quanto custa cada parte do sistema?
- Quanto deverá custar todo o sistema?
- Quantas pessoas deverão ser usadas (Equipe) ?
- Quanto custa cada profissional?
- Qual deverá ser o preço de aquisição do seu software para o usuário final (Valor de mercado)?
Requisitos
- Levantamento de requisitos é útil para:
- Identificar as necessidades dos usuários
- Verificar a viabilidade de implementar estas necessidades
- Distribuir as funções do sistema entre as pessoas, o hardware, o software e outros elementos do sistema
- Criar um modelo do sistema que será utilizado nas fases de desenvolvimento seguintes
- Técnicas para levantamento de dados
- O sucesso de um projeto depende diretamente do levantamento de dados
- O levantamento de dados é tão importante no desenvolvimento do projeto que seu resultado pode colaborar ou comprometer o desempenho do projeto
- Para realizá-lo em um sistema de informação, existem diversas técnicas de levantamento de dados
- Dependendo das características do projeto, essas técnicas podem ser aplicadas de forma isolada ou em conjunto
- Abaixo, algumas dessas técnicas:
- Entrevistas: Identificar as pessoas que serão entrevistadas buscando especialistas no assunto.
- Questionários: Gerar perguntas organizadas com o objetivo de levantar dados para uma pesquisa ou estudo, cujas respostas são fornecidas pelo informante sem a orientação direta do pesquisador;
- Revisão de documentação: Utilizar várias fontes de informação como:manuais de procedimentos, documentação, manuais de projeto, relatórios, diagramas e outros;
- Análise de observação: Observar os usuários em seu ambiente de trabalho enquanto eles executam suas atividades. Pode ser usada para confirmar os resultados de uma entrevista, identificar documentos que devem ser analisados etc.
- Brainstorm: Termo do Inglês que significa “tempestade de ideias”. É uma metodologia que objetiva explorar as ideias de um grupo de pessoas a fim de obter as melhores soluções. Não há julgamento ou autocrítica. Todas as idéias são aceitas, mesmo aquelas que parecem ser absurdas. Tem-se como objetivo principal fazer com que o grupo libere o seu conhecimento e criatividade. O resultado da técnica Brainstorm tem o seu mérito distribuído porque foi obtido usando as ideias de todo o grupo envolvido.
- JAD: Join Application Design é uma metodologia criada pela IBM e baseada em sessões de dinâmica de grupo. Define o ponto de vista dos usuários sobre o sistema, incluindo objetivos e as aplicações do sistema até a geração de telas e relatórios. Diferente da técnica Brainstorm, é refinada, organizada e com uma abordagem mais estruturada;
Classificação dos requisitos
Requisitos funcionais
- Especificam ações que um sistema deve executar, sem levar em consideração restrições físicas
- Melhor descrito quando são usados casos de uso
- Descrevem a funcionalidade ou os serviços do sistema
- Depende do tipo de software, possíveis usuários e o tipo de sistema em que o software é usado
- Requisitos funcionais dos usuários podem ser declarações de alto nível a respeito do que o sistema deve fazer
- Devem descrever detalhadamente os serviços do sistema
- Exemplos:
- Um sistema acadêmico fictício deve:
- Matricular os alunos
- Montar uma turma para cada grupo de alunos
- Alocar a turma em salas
- Gerar Diário
- Controlar frequência e faltas
- Calcular pontuação do aluno
- Gerar relatório de aprovados e reprovados
- Um sistema acadêmico fictício deve:
Requisitos não-funcionais
- Descrevem qualidades do sistema (como ele é) ao invés de suas funcionalidades (o que ele faz)
- Definem as propriedades e as restrições do sistema, por exemplo:
- confiabilidade
- tempo de resposta
- ocupação de área
- As restrições são capacidades de dispositivos de E/S, as representações do sistema, etc
- Os requisitos de processo também podem ser especificados impondo um IDE particular, linguagem de programação ou método de desenvolvimento
- Podem ser mais críticos do que os requisitos funcionais. Se esses não forem atendidos,o sistema pode ser inútil
- Exemplos:
- O sistema:
- não poderá ficar parado por mais de 15 minutos [Robusto]
- tem que ser restaurado imediatamente caso haja corrupção dos dados [Disponível]
- será inibido o acesso para mais de 3 tentativas com falha [Seguro]
- deve ter baixo tempo de resposta [Ágil]
- precisa ser Orientado a Objeto
- necessita usar o Banco de Dados Oracle
- deverá estar hospedado na nuvem
- tem que ser desenvolvido em Java
- requer utilização de sensores
- necessita de ferramentas específicas
- precisa ter segurança contra acessos indevidos
- exige uso de interfaces de entrada específicas
- deve rodar no Android e IoS
- será embarcado dentro de um equipamento
- terá que suportar exabytes de dados
- deverá ter interface intuitiva
- obrigatória o uso de solução open source
- requer redundância na comunicação
- O sistema:
Algumas métricas para requisitos não-funcionais
| Propriedade | Medida |
|---|---|
| Velocidade | Transações processadas/segundo |
| Tempo de resposta de usuário/evento | |
| Tempo de atualização de tela | |
| Tamanho | MegaBytes |
| Número de processadores | |
| Área disponível em cm | |
| Facilidade de uso | Tempo de treinamento do usuário |
| Número de telas/campos de entrada | |
| Confiabilidade | Tempo médio para falha |
| Probabilidade de indisponibilidade | |
| Taxa de ocorrência de falhas | |
| Disponibilidade | |
| Robustez | Tempo de reinício após falha |
| Percentual de eventos que causam falhas | |
| Probabilidade de corrupção de dados em caso de falha | |
| Segurança | Número de tentativas erradas de autenticação |
| Número máximo de invasões | |
| Interfaces | Tipo do dispositivo |
| Comunicação | Tipo de tecnologia |
Questões
Pablo Henrique Miranda Ferreira Nunes
- 01. # O que é Benchmarking?
- Benchmarking implica na comparação de um produto, processo ou estratégia de um empresa com outro similar do mercado,medindo assim, qualidade, performance, produtividade, gastos,etc. Dessa maneira, procura-se aperfeiçoar esses aspectos utilizando as referências como desafios a serem batidos para manter competitividade.
- 02. Dê um exemplo de um sistema que conversa com outro sistema?
- Podendo citar vários exemplos, um bem casual seria a comunicação entre aplicativos de celular recebendo e, por muitas vezes, aproveitando de informações do usuário já disponíveis.
- 03. Para um Sistema Hospitalar (Registro de Pacientes, Marcação de Consultas, Geração de Diagnósticos, etc) quais as principais métricas de Requisitos Não-Funcionais?
- Segurança - dados pessoais de pacientes e staff devem ser seguros(Hierarquia de acesso).
- Robustez - falhas devem ser minimas, pois trata-se de informações sobre as condições dos pacientes..
- Confiabilidade - Disponibilidade do sistema deve se ininterrupto, pois as informações contidas são de extrema importância.
- 04. Para um Sistema Industrial (Cadastro de Equipamentos, Controle das Máquinas, Inicia/Para Produção, etc) quais as principais métricas de Requisitos Não-Funcionais?
- Confiabilidade - Tempo médio para falhar deve ser minimo.
- Velocidade - processamento por segundo e tempo de resposta devem ser acelerados para manter um processo exato e contínuo, assim como otimizado.
- Robustez - Tempo de reinício deve ser imediato após qualquer falha, pois quanto mais tempo parado menos produção e mais prejuízo. Porcentagem de eventos que causam falhas devem ser quase nulo, pois a quantidade de eventos por segundo sendo gerenciado pelo sistema é exponencial devido à repetição de várias operações, ou seja, a somatória dos erros seria também exponencial.
- Portabilidade - a independência de ações leva à uma maior segurança em termos de falhas, pois a localização dos erros é facilitado e a produção não será afetado em todos os eventos.
- Tamanho - a otimização da memória utilizada leva a uma maior agilidade do processo e fluxo de produção, assim como menor porcentagem de falhas e mais espaço liberado para processo simultâneos.
- 05. Para um Sistema Comercial (Cadastro de Clientes, Emissão de Nota Fiscal, Relatórios de Vendas, etc) quais as principais métricas de Requisitos Não-Funcionais?
- Facilidade de Uso - os agentes utilizadores do sistema devem ser capaz de manusear o sistema com eficácia, dessa forma, as telas devem ser user-friendly, assim como o tempo de treinamento para a utilização do sistema deve ser um tempo hábil para não gerar custos excedentes à empresa.
- Confiabilidade - Probabilidade de indisponibilidade e taxa de ocorrência de falhas devem ser evitados e de resolução rápido, pois trata-se de um setor de muitas transações financeiros.
- Velocidade - Tempo de resposta ao usuário e processamento dos eventos deve ser quase que instantâneo.
- Robustez - Tempo de reinício pós-falha é crucial.