Mostrando postagens com marcador Requisitos. Mostrar todas as postagens
Mostrando postagens com marcador Requisitos. Mostrar todas as postagens

sexta-feira, 14 de junho de 2013

Requisitos - XVI

Produção

A partir da implantação da aplicação entra em cena a equipe de produção, que algumas vezes é um subconjunto da equipe de suporte. Eis algumas tarefas da equipe de produção :
  • Fornecer suporte ao uso da aplicação
  • Inspecionar logs de eventos gerados pela aplicação identificando possíveis problemas em  produção
  • Montar uma linha base de performance para a aplicação
  • Conhecer as características da aplicação de forma a poder auxiliar a equipe de suporte no planejamento do remanejamento da aplicação em relação aos servidores da empresa.
  • Apontar para a equipe de desenvolvimento problemas de performance na aplicação

Possíveis rupturas no processo

Mesmo muito bem organizado da forma como aqui foi descrita, podem ocorrer rupturas nesse processo de desenvolvimento que causarão problemas de custo e cronograma :
  • Excesso de alterações na especificação durante a etapa de codificação
  • Excesso de erros em homologação ou produção
  • Dificuldade na comunicação entre o analista e os desenvolvedores
  • Cronogramas imprecisos 

Excesso de alterações na especificação durante a codificação

Isso pode ser causado por uma inicial inexperiência de um analista. Deve-se registrar este fato como um índice qualitativo do processo de desenvolvimento e o analista deve utilizar cada ocorrência para aperfeiçoar-se, reduzindo este valor a cada projeto realizado.

Excesso de erros em homologação ou produção

Isso ocorre por inexperiência dos testers, responsáveis por identificar os erros da aplicação. Da mesma forma que o item anterior, isso deve ser registrado como um fator qualitativo do processo e os testers devem utilizar cada ocorrência para aperfeiçoar-se e reduzir este valor

Dificuldade na comunicação entre o analista e os desenvolvedores

Uma das rupturas mais críticas, quando o analista, por estar muito envolvido com o negócio, passa a ter dificuldade de se comunicar com o desenvolvedor e suas especificações se tornam mais distantes do ambiente físico da codificação.
Neste caso torna-se necessária a utilização de um arquiteto de sistemas como intermediário entre o analista e o desenvolvedor. Deve-se tomar muito cuidado na escolha de quem irá realizar esse papel, pois a pessoa deve ser capaz de utilizar a linguagem de negócio e traduzi-la para os desenvolvedores, tendo liberdade de requisitar alterações nas especificações quando estas estiverem por demais distantes do ambiente físico. Essa pessoa deve estar altamente atualizada para definir as melhores tecnologias para cada projeto.

Cronogramas imprecisos

Isso normalmente reflete uma inexperiência do analista na especificação do tempo para desenvolvimento. Neste ponto duas coisas devem ocorrer :

O analista deve usar as falhas de cronograma para aperfeiçoar-se em termos de calculo de duração de um projeto
Deve-se aperfeiçoar a aplicação da técnica de análise de pontos de função de forma a depender o mínimo possível do instinto do analista

Grande Abraço,
Gilberto Ribeiro.

quinta-feira, 13 de junho de 2013

Requisitos - XV

Testes

Os testes se dividem em 5 tipos :
  • Teste de bancada
  • Teste de qualidade
  • Teste de Stress
  • Teste de Segurança
  • Homologação

Destes 3 tipos apenas o teste de bancada é realizado em ambiente de desenvolvimento, em geral pelo próprio analista conforme comentado anteriormente. Os demais testes são realizados em um ambiente denominado ambiente de qualidade.

Ambiente de Qualidade 
O ambiente de qualidade é um ambiente o mais similar possível ao ambiente de produção da empresa. Este ambiente é utilizado para a realização de testes de qualidade na aplicação.

Raramente, porém, é possível ter um ambiente de qualidade realmente idêntico ao de produção. Cabe à equipe de suporte juntamente com o analista/arquiteto do sistema realizar um relatório de riscos relativo a passagem da aplicação para produção, ou seja, o risco de mesmo depois dos testes em qualidade a passagem para produção não funcionar devido a diferença entre qualidade e produção.

Montagem do ambiente de qualidade

A montagem do ambiente de qualidade é, de fato, um teste : Testa-se o passo-a-passo de instalação do sistema, garantindo que o processo de instalação funcionará quando for executado em ambiente de produção.

Teste de Qualidade
  • O teste de qualidade é, de todos, o teste mais detalhado do sistema. É realizado por testers, profissionais especializados na realização de testes da aplicação.
  • Os testers podem fazer uso do plano de testes criado pelo analista, mas não se prendem a ele. O objetivo principal dos testers é fazer o que é chamado de monkey test : Fazer exatamente o contrário do que a aplicação pede em cada tela e verificar como a aplicação reage. Desta forma obtém-se a garantia de que a aplicação funcionará mesmo perante os piores tipos de usuário existentes.
  • Os testers em geral são desenvolvedores, mas não precisam ser tão especializados como os próprios desenvolvedores do projeto. Em alguns casos podem ser outra equipe de desenvolvimento da própria empresa, mas não devem ser os mesmos desenvolvedores do projeto, pois por mais que tentem os desenvolvedores do projeto sempre fazem testes para fazer a aplicação funcionar, ao contrário de testers que devem fazer a aplicação dar erro
  • Há um trabalho circular entre os testers e o processo de codificação. Os testers devem gerar um relatório de volta para o processo de codificação, gerando uma reimplantação da aplicação em qualidade e novo teste até o momento em que os testers não identifiquem nenhum erro

Teste de Stress
  • O teste de stress tem por objetivo testar a aplicação em condições de uso muito maciço, verificando como o hardware e o software respondem em ambiente simulado.
  • O teste envolve tanto o analista/arquiteto, responsável por especificar a simulação de teste, como a equipe de banco, responsável pela análise da resposta do servidor de banco ao teste como a equipe de suporte, responsável pela análise da resposta do hardware e do sistema operacional. 

Teste de Segurança
  • Em geral é realizado por uma equipe externa de hackers contratados especialmente para testar a segurança do sistema, este teste tem se tornado comum nas atuais arquiteturas de desenvolvimento para web.

Homologação 
É o teste realizado pelos usuários finais, que podem ou não seguir o plano de testes preparado pelo analista
  • O processo de homologação pode gerar um trabalho circular com a etapa de codificação, assim como ocorreu com o teste de qualidade, mas é mais improvável que o processo de homologação encontre muitas falhas no sistema
  • O usuário vai, como sempre, pedir modificações no sistema. Porém o analista deve ser cuidadoso de direcionar as modificações solicitadas pelo usuário para a próxima versão do sistema.
  • Ao final da homologação o usuário dá sua aprovação final para o sistema 

Implantação

Não existe uma regra específica para o processo de implantação, mas o analista, a equipe de suporte e a de banco de dados devem estar em conjunto solucionando os seguintes problemas.
  • Treinamento para os usuários
  • Trabalho em paralelo com aplicações existentes quando necessário
  • Migração de dados de bancos de dados existentes quando necessário

Observe que tanto o analista, como a equipe de suporte e a equipe de banco de dados devem ter trabalhado deste o término da etapa de análise no planejamento do processo de implantação. Desta forma o trabalho neste etapa torna-se bem planejado e organizado, menos sujeito a falhas.

Grande Abraço,
Gilberto Ribeiro.

quarta-feira, 12 de junho de 2013

Requisitos - XIV

Codificação

A etapa de codificação envolve o desenvolvimento em si do projeto.

Ambiente de codificação
  • Os desenvolvedores devem possuir um ambiente apartado no qual tenham total controle de forma a poderem rapidamente resolver problemas nas máquinas.
  • A equipe de suporte deve dar total apoio aos desenvolvedores, tal como em termos de instalação das máquinas, backup e solução rápida de problemas que sejam exclusivamente de infraestrutura. Deve também procurar, junto com o analista, as melhores técnicas de otimização do ambiente de codificação.
  • Deve estar em uso um sistema de controle de versões.
Ocorrências comuns no ambiente de codificação

Alterações no modelo de dados
  • Devem ser aprovadas pela equipe de banco de dados e deve ser gerado um script evolutivo que será armazenado juntamente com script 0 do banco de dados. 
Alterações no protótipo
  • Devem ser aprovadas pelo usuário
    • Alterações na modelagem do sistema
    • Alterações no desenho do processo
  • Essas duas últimas podem ter impacto médio a grande no desenvolvimento do sistema. É importante verificar se é realmente absolutamente necessário que essas modificações sejam feitas ou se seria possível que essas modificações fossem implementadas apenas em uma versão 2 do sistema.
  • Caso seja absolutamente necessária a realização destas modificações o cronograma do sistema deve ser corrigido com base no impacto destas mudanças.
  • Normalmente mudanças deste porte causam as outras 2, alteração de protótipo e de modelo de dados
O trabalho do analista 
O analista aproveita o período de desenvolvimento, no qual seu trabalho fica mais direcionado à gerencia de projeto, para realizar as seguintes tarefas :
  • Criar um plano de testes para a aplicação
  • Realizar o “teste de bancada”, teste inicial ainda em ambiente de desenvolvimento, conforme os desenvolvedores terminam cada trecho da aplicação
  • Planejar o teste de stress em conjunto com a equipe de suporte
  • Planejar o processo de implantação da aplicação em conjunto com a equipe de suporte e banco de dados
Cronograma e desempenho 
Uma técnica muito útil para a análise de tempo gasto em desenvolvimento é a análise de pontos de função.
Esta análise intenciona quantificar o software que está sendo desenvolvido em pontos de função e identificar a produtividade dos desenvolvedores também em pontos de função/dia.
Com isso consegue-se :
  • Identificar os desenvolvedores muito e pouco produtivos
  • Montar cronogramas mais precisos com base na produtividade real dos desenvolvedores
  • Identificar a necessidade de mais desenvolvedores para cumprir um determinado prazo
  • Identificar mais precisamente os custos do projeto
A análise de ponto de função é muito detalhista e normalmente demanda tempo na etapa de análise, por isso é muito comum as empresas criarem pequenas adaptações desta análise conforme a arquitetura utilizada.

Grande Abraço,
Gilberto Ribeiro.

terça-feira, 11 de junho de 2013

Requisitos - XIII

Análise

A etapa de análise é a etapa na qual se faz o levantamento da necessidade existente e define-se de que forma o software a ser criado deverá solucionar esta necessidade.

Em alguns ambientes os desenvolvedores tem o mal costume de pular a etapa de análise passando diretamente a etapa de desenvolvimento. Isso causa frequentemente falhas na definição do software, ou seja, descobre-se após o desenvolvimento que o que foi feito não atende a necessidade existente.

Divisões da etapa de análise
  • Levantamento de informações
  • Desenho de processo (Use Cases)
  • Modelagem de Dados (MER)
  • Modelagem do sistema
  • Prototipação
  • Definições finais
Levantamento de Informações (Analista de Requisitos e de Sistema)

Nesta etapa o analista realiza o levantamento de informações com o usuário. O analista faz uso de muitas entrevistas com o usuário para descobrir as necessidades existentes.
  • O analista deve estar atento as informações fornecidas pelo usuário, cada detalhe mencionado por usuário as vezes pode resultar em mudanças no planejamento que o analista já estava realizando.
  • O analista não deve se confundir quando o usuário tentar indicar como algo deve ser feito fisicamente (estrutura de tabela, tela, programas, etc.). O usuário não tem conhecimento técnico para fazer essa indicação, o analista deve extrair do usuário apenas as especificações ligadas ao negócio da empresa.
  • Nem sempre o usuário tem todas as informações que o analista precisa. Muitas vezes o usuário tem uma informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim sendo o analista deve consultar outras pessoas além dos usuários da aplicação.

Desenho de Processo
  • O desenho de processo é realizado com os dados colhidos no levantamento de informações. É uma demonstração gráfica da forma de funcionamento do negócio descrito pelo usuário.
  • O desenho de processo é utilizado para apresentar o resultado do levantamento ao usuário. Na verdade as duas etapas são recorrentes, caso o usuário identifique erros no desenho de processo volta-se ao levantamento para acerta-los e assim consecutivamente até que o usuário aprove o desenho de processo.

Modelagem de Dados

Tendo o desenho de processo sido realizado parte-se para o modelo de dados. A criação do modelo de dados irá novamente se utilizar das informações obtidas durante o levantamento, mas poderá também ter necessidade de novas informações e obrigar o analista a retornar para a etapa de levantamento.
  • O modelo de dados não é tão compreensível para um usuário leigo como o desenho de processo, portanto apresenta-lo ou não ao usuário pode ser uma decisão do analista.
  • O modelo de dados deve ser dividido em lógico e físico, um estando mais próximo das características do negócio enquanto o outro demonstrando características físicas do banco de dados.
  • O analista de sistemas nem sempre é um DBA, portanto o modelo de dados deve ser aprovado pela equipe de administradores de dados.
  • Tendo o modelo de dados sido aprovado gera-se um script 0 do banco de dados, o script inicial deste banco
  • Toda futura alteração do modelo de dados deve  ter a aprovação do DBA, que aproveita seu conhecimento das alterações para se preparar para a fase de implantação. As alteração são realizadas na forma de scripts evolutivos do banco de dados de forma a complementarem o script 0. Assim sendo ganha-se uma sequencia histórica de mudanças realizadas no banco de dados.

Modelagem do Sistema

Feita a modelagem de dados, modela-se o sistema que irá manipular esses dados. Pode-se utilizar DFDs, típicos da análise estruturada, ou diagramas de classe e Sequências, típicos da análise orientada a objetos.
  • Obtêm-se como resultado desta etapa descrições gráficas dos módulos que serão gerados no sistema, quer sejam formulários/funções em aplicações estruturadas quer sejam classes/componentes em aplicações orientadas a objeto.
  • Todas as etapas de análise são interligadas. A modelagem do sistema pode afetar todas as etapas anteriores, eventualmente exigindo que o analista retorne ao levantamento.
  • É papel do analista, durante este processo, realizar suposições sobre diversas situações de negócio que porventura o usuário não tenha imaginado, garantindo assim que o sistema funcione de forma flexível mesmo frente a situações inesperadas. 

Prototipação

Feita a modelagem do sistema parte-se então para a construção do protótipo.
  • O protótipo é um modelo das telas do sistema que tem por intenção obter do usuário a aprovação da navegabilidade do sistema e da forma como suas funcionalidades serão visualmente implementadas. 

Definições finais

Tendo obtido a aprovação do usuário para o desenho de processo e o protótipo a fase de análise encontra-se concluída em sua etapa mais formal.

Da fase de análise obtêm-se definições sobre como serão as fases seguintes:
  • A partir das definições de análise é possível desenvolver um cronograma de execução
  • A partir do cronograma e das necessidades do usuário é possível prever o pessoal que deverá ser envolvido nas fases seguintes do projeto (qtd. Desenvolvedores)
  • A partir das informações acima é possível fazer uma previsão de custo do projeto e a partir desta informação a diretoria identifica sua real viabilidade.

Curiosidades sobre a etapa de análise

A etapa de análise na verdade não termina. Mesmo durante as etapas seguintes a análise continua a ocorrer,  se aprofundando mais tecnicamente no sistema. Eventualmente descobre-se na etapa de codificação novas características do negócio que alteram definições feitas em análise.
  • O analista é, em geral, um gerente de projetos. Após a etapa de análise ele estará gerenciando os desenvolvedores na execução da especificação do sistema.
  • O analista é em geral um já foi um desenvolvedor, mas que adquiriu um linguajar de negócios que permite que ele se comunique com os usuário na mesma língua destes, podendo desta forma extrair informações durante o levantamento.
  • Quando desenvolvedor é comum que o analista não esteja 100% atualizado com as tecnologias atuais. 
Desta forma nem sempre o analista consegue realizar as melhores opções em termos de tecnologia para o projeto e, nos piores casos, o analista chega a ter dificuldade de falar com os desenvolvedores. Neste caso é necessária a presença de um outro personagem, o arquiteto do sistema, que tem por finalidade definir as tecnologias a serem aplicadas para execução do projeto, definir as metodologias de desenvolvimento a serem usadas pelos desenvolvedores e fazer a tradução entre o analista e os desenvolvedores quando necessário. 

A equipe de suporte deve trabalhar em conjunto do analista ou do arquiteto do projeto na definição física do projeto, iniciando uma especificação de equipamentos que serão necessários ao projeto.
Grande Abraço,
Gilberto Ribeiro.

segunda-feira, 10 de junho de 2013

Requisitos - XII

Desenvolvimento de Software

Não é raro em ambientes de desenvolvimento que muitos desenvolvedores sejam envolvidos em múltiplos projetos simultaneamente. Assim sendo ao mesmo tempo em que um desenvolvedor desenvolve dois softwares, está também corrigindo bugs de outros dois, dificultando desta forma o trabalho do desenvolvedor.

As tarefas de desenvolvimento, quer sejam elas de criação de novos softwares ou de manutenção dos softwares existentes, devem ser divididas em projetos e cada projeto deve seguir uma sequência de execução que garanta a qualidade do software que está sendo gerado.

Exemplo: Equipes Envolvidas

As seguintes equipes devem ser delineadas e envolvidas no processo de desenvolvimento:
  • Desenvolvimento
  • Testers
  • Homologação
  • Banco de Dados
  • Suporte
  • Produção

Divisões do Processo de Desenvolvimento
  1. Análise (Requisito/Sistemas)
  2. Codificação (Desenvolvimento)
  3. Testes
  4. Implantação
  5. Produção 
Grande Abraço,
Gilberto Ribeiro.

segunda-feira, 27 de maio de 2013

Requisitos - XI

Softwares

“Quando um projeto de software falha, raramente a causa é técnica”.
Jim Johnson, do The Standish Group.

Tal afirmação reforça o conceito de que o problema não está na tecnologia que usamos para implementação de um sistemas, mas sim na QUALIDADE dos REQUISITOS, ou seja, o entendimento do domínio do negócio.

A raiz da maioria das falhas está na (ausência de) utilização de metodologias de desenvolvimento adequadas e como elas interagem com os stakeholders em um projeto de software, e principalmente pela dificuldade do entendimento dos conceitos básicos dos processos de negocio.

Por “metodologia de desenvolvimento” entende-se o conjunto das:
  • Atividades
  • Responsabilidades
  • Artefatos (documentos, diagramas, código-fonte etc.)
  • Orientação e boas práticas usadas para planejar, construir e implementar software.

Um METODOLOGIA estabelece um caminho único no desenvolvimento de sistemas novos ou na evolução de sistemas já existentes. Ela introduz consistência ao longo do desenvolvimento de vários projetos de sistemas, provendo uma lista de todas as atividades a serem realizadas, estabelecendo pontos de verificação para auditoria e controle do projeto.

Então vejamos algumas situações que temos de enfrentar:

“Estou precisando de um website...

Ótimo, podemos fazê-lo. Gostaria de marcar uma reunião para fazermos um briefing do que precisa, conhecer alguns detalhes de design, tipo de hospedagem...

Não, não, você não está entendendo, é pra ontem!”

IMPORTANTE:
  • Nem se estresse tentando definir requisitos de sistemas em prazos absurdos que não permitam o seu correto entendimento e especificação.
  • Sistemas não são feitos da noite para o dia, eles englobam muito mais que linhas de programação, horas de testes, manuais, documentação e treinamento fazem parte do que chamamos de software.
  • Se o cliente exige um prazo absurdamente curto, rediscuta ou não o faça, pois o resultado da pressa é proporcional à qualidade do resultado de sistema.
  • Se o cliente do projeto de sistema quer que você converse, faça levantamento de requisitos em curto espaço de tempo, com agendas apertadas, lembre-se de que você não tem como estar levantando informações e necessidades de um grupo de usuários ao mesmo tempo em que de outro, de áreas distintas, ou operações distintas.
  • Conhecer e dominar uma linguagem de programação é bom, mas não é tudo, assim como conhecer processos como CMMI ou MPS-BR. É preciso mais que um bom processo ou boa linguagem e bons analistas e programadores.

A necessidade de estabelecer os requisitos de maneira e de forma precisas é crítica à medida que o tamanho e a complexidade do software aumentam.

Os requisitos exercem influências uns sobre os outros, logo não podemos realizar análise de necessidades sem buscar sempre o entendimento do todo. Isso é o que chamamos de ter Visão Sistêmica de Processo, enxergar e abstrair de cada necessidade a sua implicação com as outras dentro do contexto operacional do negócio. Então, vemos que a análise de requisitos e análise de processos estão intimamente ligadas.

Grande Abraço,
Gilberto Ribeiro.

sexta-feira, 24 de maio de 2013

Requitos - X

Requisitos de Processos de Negócio

O propósito a partir deste instante é associar os processos de negócio à definição de requisitos.

Requisitos de Processo de Negócio são aqueles que estão diretamente ligados ao processo de negócio, ao como se faz, aos conceitos de subprocesso, de tarefas de processo. Esses requisitos somente são obtidos através da observação detalhada da execução do processo e do estudo da documentação de normas e processos de uma organização.

Podemos questionar como entender a observação da execução de uma processo sem ter conhecimento técnico de regras que regem esse processo, sejam elas normas legais ou técnicas inerentes ao negócio. Este é um dos objetivos que vamos explorar repetidamente através de exemplos de quatro situações ou estudo de casos.

Processo
  • Como definição clássica temos que: Processo é uma série de atividades executadas sequencialmente para produzir um produto ou serviço.

Não podemos nos atrelar a uma visão por função quando da análise de requisitos, pois essa visão leva a uma distorção na interpretação de processos que nos induz a erros no entendimento deles, assim como leva as organizações a lapsos administrativos e à criação de uma visão por silos de informações.

A visão por função não mostra como um valor é agregado a um processo ou por um processo. Isso equivale a realizar levantamento de requisitos baseados nas pessoas e nos setores por onde o fluxo dele ocorre.

Vamos analisar tudo sobre o enfoque da visão de processos que traz a definição de processo:

Qualquer atividade ou um conjunto de atividades, disparado ou inicializado por um evento externo, provendo resultados de negócio, através da transformação de insumos em produtos e serviços, objetivando sempre a satisfação do cliente deste processo.

Um processo é caracterizado da seguinte forma:
  • Missão do processo
  • Fatores críticos de sucesso
  • Restrições
  • Decomposição de suas atividades

Missão do Processo

Identificar a razão de existência do processo no ciclo dos produtos e/ou serviço da empresa. Define os objetivos permanentes que devem ser alcançados pelo processo e a forma como ele agrega valor a produtos, serviços e controles da empresa.

Eventos

Eventos são acontecimentos externos ou não ao processo que, de alguma forma, estimulam a execução de uma ação por parte dele em resposta ao evento.

Os eventos podem ser classificados da seguinte forma:

Quanto à natureza do evento
  • Eventos externos programados
  • Eventos temporais
  • Eventos Externos Ad Hoc

Quanto à cronologia do processo
  • Eventos iniciais
  • Eventos Finais
Exemplo de eventos
  • Eventos externos Programados
  • Chegada de uma nota fiscal e materiais de um fornecedor
  • Emissão de uma nova previsão de vendas

Eventos temporais
  • Todo dia 5 de cada mês é feita a apuração de resultados.
  • Todos os dias as 20h encerra-se a inclusão de pedidos de venda.

Eventos Externos Ad Hoc
  • Mudanças inesperadas na legislação.
  • Mudanças repentinas de mercado.
  • Quanto à cronologia do processo.

Fatores Críticos de Sucesso (FCS)
  • Qualquer tipo de aspecto que ponha em risco a missão do processo.
  • Os FCS podem dizer respeito a qualquer tipo de recurso (material, humano, tecnológico etc.) ou a aspectos de qualidade quanto a entradas e controles.
  • Ao serem analisados, os FCS devem ser acompanhados das medidas a serem tomadas para a sua garantia.

Restrições
  • Restrições significam limites de atuação ou alcance do processo.
  • São em geral estabelecidas pelas políticas e regras de negócio ou por procedimentos que devem ser executados em resposta a eventos Ad Hoc.

Atividades
  • Os processos também são caracterizados pela relação de suas atividades.
  • As atividades são as ações tomadas pelo processo em resposta a eventos.
  • As atividades utilizam-se das entradas, regras, políticas e recursos para a produção de saídas específicas (produtos do processo)
  • Atividades observadas em níveis de abstração diferentes podem ser classificadas segundo uma hierarquia de processos, o que permite uma organização eficaz deles com objetivo de melhor entender o seu desempenho e a qualidade necessária.

Grande Abraço,
Gilberto Ribeiro.

quinta-feira, 23 de maio de 2013

Requsito - IX

Requisitos Funcionais e Não Funcionais

Os requisitos, de modo geral, podem ser classificados em dois grandes grupos:

Requisitos funcionais
  • Que especifica como o sistema interage com o contexto a sua volta.

Descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquele que descreve as funcionalidades, as quais se espera que o sistema forneça. Eles dependem do tipo de software que está sendo desenvolvido, do conhecimento passado pelos usuários sobre o negócio em si e do que deve fazer o software que se espera desenvolver.

A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz.

É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o design do software. No design do software deve-se tomar a decisão de quais funções o sistema efetivamente terá para satisfazer aquilo que os usuários querem, ou melhor, que o processo de negócio exige.

Requisitos não funcionais
  • Que expressão atributos de qualidade da solução.

Os requisitos não funcionais não estão ligados diretamente com as funções fornecidas pelo sistema. Em geral se preocupa com padrões de qualidade como:

  • Confiabilidade
  • Desempenho
  • Robustez
  • Segurança
  • Usabilidade
  • Portabilidade
  • Legibilidade
  • Qualidade
  • Manutenibilidade

São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer. Um sistema ineficiente certamente não será usado.
  • A base de dados deve ser protegida para acesso apenas de usuários autorizados.
  • O tempo de resposta do sistema não deve ultrapassar 30 segundos.
  • O software deve ser operacionalizado no sistema Linux.
  • O tempo de desenvolvimento não deve ultrapassar seis meses.



Grande Abraço,
Gilberto Ribeiro.

quarta-feira, 22 de maio de 2013

Requisitos - VIII

Elementos Básicos

Os elementos básicos de formação do processo apresentado são os utilizados pelo RUP, para descrever seus aspectos estáticos, como:
  • Papéis
  • Artefatos
  • Atividades
  • Fluxo de atividades

Os três fluxos de atividades de engenharia de requisitos são:
  • Definir o Escopo do Sistema
  • Refinar Requisitos de software
  • Gerenciar Mudanças

Papéis

O comportamento é descrito por meio das atividades associadas àquele papel e as responsabilidades são definidas com relação aos artefatos criados, modificados ou controlados por ele.
  • Equipe: toda a equipe de desenvolvimento.
    • Analista de Sistemas – o principal responsável pela engenharia de requisitos:
      • Elicitação
      • Análise
      • Especificação
      • Validação
    • Gerência de requisitos.
    • Gerente de Projetos – responsável pelo bom andamento do projeto, monitoração de riscos, alocação de recursos e demais atividades de planejamento.
    • Cliente: representa um stakeholders do sistema, pertencente à organização cliente e que possui autorização para atuar como fornecedor de requisitos ao projeto.
    • Comitê de Controle de Mudanças: é formado por representantes de todos os stakeholders.
      • Uma configuração típica seria – o gerente de projeto, o gerente do projeto na organização cliente, um analista e um líder técnico.
      • Em projeto pequenos, pode ser formado apenas pelo gerente de projeto.
    • Qualquer Papel: qualquer membro da equipe de desenvolvimento ou stakeholders da organização cliente.
Artefatos

Os artefatos produzidos durante a execução das atividades do projeto são:
  • Documentos de Entrada: quaisquer documentos relacionados ao projeto que foram produzidos antes da fase de Iniciação. Exemplo típicos de documentos de entrada são RFPs (Request for Proposals) enviados por um cliente, a Proposta Comercial feita pelo departamento de vendas e aceita pelo cliente e a Proposta Técnica, que sugere uma visão inicial das características e módulos do sistema.

  • Atributos de Requisitos: são dados recolhidos ao longo do processo de análise de requisitos, desde a especificação até a aprovação da especificação final ou de posteriores mudanças.
    • Há vário tipos de atributos de requisitos: identificadores e informações cadastrais, especificações e detalhamento, status e índices como importância para o negócio, relevância para arquitetura, estimativa de tamanho (ou complexidade).
    • Um atributo especial é a prioridade do requisito, definida com base nos índices de outros atributos, e cuja definição depende de negociações com o cliente que envolvem atividades de gerência de projeto.

  • Matrizes de Rastreabilidade: documentam as relações de dependência entre requisitos. A rastreabilidade documentada é vertical (obrigatória) e horizontal (opcional).
    • É possível documentar as matrizes de rastreabilidade explicitamente, através de tabelas, planilhas ou ferramentas de gerência de requisitos, ou implicitamente, através dos demais artefatos do projeto.
    • Um exemplo de documentação implícita é a matriz que relaciona requisitos aos recursos de projeto como tempo e pessoas.
    • Os cronogramas do projeto possuem atividades agrupadas em blocos com os mesmos nomes dos requisitos, o que resulta em uma relação implícita com os requisitos armazenados no repositório.

  • Glossário: registro do vocabulário comum do projeto, na linguagem do cliente. É criado no início do projeto e evolui ao longo do desenvolvimento do sistema, servindo como referência para todos os envolvidos.

  • Documento de visão: nesse documento é definida a visão que os envolvidos têm do produto a ser entregue, em termos das principais necessidades e características.
    • Também registra a motivação para o desenvolvimento do sistema, através da breve descrição do principal problema de negócio a ser resolvido pelo sistema, além de descrever os limites do produto e as restrições impostas à solução.
    • Por conter um descrição em alto nível dos requisitos centrais pretendidos, incluindo restrições de design, serve como base contratual para requisitos técnicos mais detalhados.

  • Especificação de Requisitos de Software (ERS): captura todos os requisitos de software do sistema e consiste em um pacote contendo especificações funcionais e não funcionais aplicáveis.
    • As especificações funcionais possuem dois níveis de detalhamento: uma visão geral da funcionalidade é descrita nesse documento e o detalhamentos minucioso de cada requisitos é anotado em um documento chamado Especificação Funcional de Requisitos.

  • Especificação Funcional de Requisitos: os requisitos mais genéricos, alguns requisitos não funcionais e os requisitos que não podem ser bem representados nas especificações funcionais também são registrados na ERS, na seção de Especificação Suplementares.
    • Esse documento descreve minuciosamente a interação que ocorre entre os atores (usuários ou sistemas externos) e o sistema durante a execução deste(s) requisitos(s).
    • O principal objetivo é especificar o funcionamento de um porção do sistema de forma clara o suficiente para que o cliente possa validar o que será desenvolvido e a equipe de desenvolvimento compreenda o que deve entregar.

  • Modelo de Domínio: modelo de objetos inicial do sistema ou outra representação das entidades essenciais do sistema.

  • Protótipo de Interface: descrição de uma ou mais interface com o usuário.
    • Pode ser criada em vários formatos, tais como protótipos funcionais do sistema, protótipos estáticos, exemplos de tela, desenhos à mão livre capturados em meios eletrônicos e etc.

  • Solicitação de Mudanças: utilizada sempre que uma mudança no projeto é requisitada.
    • Esse artefato pode ser criado por qualquer membro da equipe de desenvolvimento ou da equipe do cliente, e deve ser aprovado pelo Comitê de Controle de Mudanças.

  • A Solicitação do Mudança é utilizada para documentar a necessidade de mudança (defeito, melhoria ou novos requisitos), informações sobre impacto e consequências de sua adoção e status de mudança, além das justificativas para as decisões tomadas sobre a implementação da mudança.

  • Repositório do Projeto: contém todos os artefatos utilizados no processo de desenvolvimento do software.
    • Pode ser um conjunto de arquivos, um banco de dados ou qualquer outra base controlada, por exemplo, por uma ferramenta de gerência de requisitos.

  • Aprovações: comunicação oficiais enviadas pelo cliente, atestando aceitação de algum artefato produzido.
    • Geralmente são e-mails com a aprovação de Especificações Funcionais de Requisitos.

Grande Abraço,
Gilberto Ribeiro.

quarta-feira, 15 de maio de 2013

Requisitos - VII

Necessidades, Características e Requisitos de Software

Requisitos são de natureza variável, ele pode ser:
  • uma descrição de funcionalidade no nível do usuário.
  • uma especificação detalhada do comportamento esperado de um sistema.
  • uma propriedade genérica de um sistema.
  • uma restrição técnica do sistema.
  • uma restrição no processo de desenvolvimento.
  • informações sobre como realizar determinado cálculo etc.

Os requisitos podem ser classificados em diferente níveis, de forma que o requisito em um nível dá origem a um ou mais requisitos no nível seguinte (requisitos derivados). O Processo Unificado da Ratinoal (RUP) divide os requisitos em:

Necessidades

Reflexões de problemas de negócio, pessoas ou operacionais que devem ser endereçadas para justificar o desenvolvimento de um novo sistema. O RUP na sua essência trata do Processo de Negócios.

Características

Serviços observáveis externamente através dos quais o sistema satisfaz uma ou mais necessidades dos interessados. Novamente se destaca sem ser explícito que estamos lidando com Processos de Negócios.

Grande Abraço,
Gilberto Ribeiro.

terça-feira, 14 de maio de 2013

Requisito - VI


O que são requisitos?

Os requisitos são o ponto de partida para toda a definição do sistema e, consequentemente, são fatores decisivos no desenvolvimento do produto final.

Segue abaixo algumas definições:
  • Uma condição ou capacidade com a qual o sistema deve estar em conformidade.
  • Uma Especificação do que deve ser implementado ou uma restrição de algum tipo do sistema.

A definição que é padronizada pela IEEE em seus Padrões, Guidelines e Exemplos sobre Engenharia de Requisitos de Sistemas e de Software é a seguinte:
  • Uma condição ou capacidade necessária a um usuário para resolver um problema ou alcançar um objetivo.
  • Uma condição ou capacidade que deve ser alcançada ou possuída por um sistema ou por um componente de sistema para satisfazer um contrato, padrão, especificação ou outros documentos formalmente exposto.
  • Uma representação documentada de uma condição ou capacidade como a dos itens 1 ou 2.



Grande Abraço,
Gilberto Ribeiro.

segunda-feira, 13 de maio de 2013

Requisito - V

Processo

Um processo é um conjunto de práticas executadas para atingir determinado objetivo, pode incluir:

  • Ferramentas
  • Métodos
  • Materiais
  • Pessoas

Modelo de Processo
É uma coleção estruturada de elementos que descreve características de processos efetivos. O CMMI por exemplo é um modelo de processo cuja utilização é comprovadamente efetiva, através de um histórico amplo de projetos utilizado como base para sua criação.

É importante ressaltar que MODELOS são ABSTRAÇÕES da realidade e, por isso, não devem ser empregados diretamente como foram definidos, mas sim adaptados de acordo com a realidade cultural da organização, o domínio de aplicação, o projeto realizado etc.
 

A qualidade de um sistema é altamente influenciado pela qualidade do processo utilizado em sua obtenção, desenvolvimento e manutenção.

Metodologia

Uma metodologia é uma coleção recomendada de:

  • Fases
  • Procedimentos
  • Regras
  • Técnicas
  • Ferramentas
  • Documentação
  • Gerência
  • Treinamento utilizados para desenvolver um sistema.
A filosofia das metodologias é representada por meio de valores, princípios ou práticas fundamentais.
 

Stakeholders

É qualquer pessoa materialmente afetada pelo resultado do projeto:

  • Cliente
  • Usuários diretos e indiretos
  • Investidores
  • Acionistas
  • Fornecedores
  • Supervisores
  • Gerentes
  • Compradores
  • Pessoal de suporte e manutenção
  • Redatores técnicos (que documentam o sistema)
Eles representam diversos grupos distintos dentro de uma organização e, assim, apresentam diferentes pontos de vista a respeito do sistema.

Grau de influência no sistema:




A compreensão de quem são os stakeholders e suas necessidades particulares são elementos-chaves no desenvolvimento de uma solução efetiva de sistema de software.

Os stakeholders estão diretamente envolvidos na orientação, forma e escopo do projeto.

Cliente
        
É um tipo especial de stakeholders. Ele representa o responsável pelo orçamento do projeto. Podemos entende-lo também como o stakeholders do projeto que interagem com a equipe de desenvolvimento para definir os requisitos do sistema.

Elicitar

Significa extrair, obter, produzir os requisitos do sistema. Na elicitação podemos utilizar técnicas sistemáticas como protótipos ou entrevistas estruturadas, para identificar e documentar proativamente necessidades dos stakeholders.

Cenário

Sequência de eventos que podem ocorrer durante a utilização de um sistema. Podem ser usado para explicar a necessidade específicas de um cliente ou para contribuir com a definição de um casa de uso. Vamos ver mais detalhes de cenários no capítulo sobre Casos de Uso.

Disciplina

É um corpo de conhecimento disponível, relacionado a um modelo de processo. Agrupa as atividades de um processo de desenvolvimento de software, de acordo com a sua natureza.

Artefato


É uma porção de informação que é produzida, modificada ou utilizada por um processo. Artefatos são produtos tangíveis de um projeto. As coisas que o projeto produz ou usa enquanto trabalha rumo ao produto final.

Podem ser modelos como por exemplo:

  • Diagramas de classe
  • Elementos de modelos como as próprias classes
  • Documentos
  • Código-fonte
  • Código executável

Grande Abraço,
Gilberto Ribeiro.

sábado, 11 de maio de 2013

Requisito - IV


Negócio do Cliente


Um caminho prático para encontrar um requisito funcional:

  • O sistema deve...
  • Depois colocamos o verbo e o complemento, como, por exemplo, ... , realizar o cadastramento de funcionários.


A partir de então mudamos ou acrescentamos uma nova forma de ver o objetivo para o qual vamos construir um sistema e focamos no NEGÓCIO DO CLIENTE.

O processo de negócio consiste em:

  • Informações cujo significado é ...
  • O tratamento dessas informações é realizado da seguinte forma ...


A análise de requisitos tem como objetivo tratar do processo dos requisitos de software e sua aderência e atendimento dos requisitos de PROCESSO DE NEGÓCIO.


Todas as atividades precisam ser criteriosamente elaboradas e desenvolvidas. É essencial que a equipe compreenda exatamente o que é o NEGÓCIO, como ele FUNCIONA, quais as INFORMAÇÕES, o que se ESPERA do aplicativo a ser construído e também o que NÃO é ESPERADO nem DESEJADO.


Isso pode parecer óbvio, mas existe o fator de DESCONHECIMENTO do NEGÓCIO DO CLIENTE, que faz com que nem sempre fique claro para todos os envolvidos no projeto qual será o ALCANCE da APLICAÇÃO.


Concluindo, podemos afirmar que sem uma correta DEFINIÇÃO e GESTÃO dos REQUISITOS do APLICATIVO é praticamente certo que o projeto TERÁ O SEU SUCESSO COMPROMETIDO, frustrando as expectativas do cliente e comprometendo as metas e planos da empresa contratante do projeto.


“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer...”


Ouvir não basta, é necessário observar e possuir técnica para entender.

Grande Abraço,
Gilberto Ribeiro.

sexta-feira, 10 de maio de 2013

Requisitos - III


Um software tem como base: Entrada - Processamento - Saída.
  • O que entra como dados, informações, eventos, seja o que for, é um REQUISITO.
  • O processamento que será realizado tem regras, fórmulas, normas, critérios, arquivos, tabelas etc., para que seja executado.
  • A saída desse processamento também é composta de dados e informações, ou de disparo de eventos, ou outra coisa qualquer.

Olhando dessa forma podemos observar que existe uma infinidade de objetos que podem ser candidatos a requisitos de software, e podemos classifica-los em dois grandes grupos:

Requisitos Funcionais

São aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem de ser feito pelo sistema, assim como o que deve sair do sistema. (Funcionalidades do Sistema)

Requisitos Não Funcionais

São aqueles que expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como: Requisitos Não-Funcionais

A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados:
  • Funcionalidade (finalidade do produto)
  • Usabilidade (esforço para utilizar, aprender o produto)
  • Confiabilidade (frequência de falhas, recuperabilidade)
  • Eficiência (característica relacionada ao desempenho)
  • Manutenibilidade (esforço necessário para modificar)
  • Portabilidade (capacidade de transferir o produto para outros ambientes)

Pressman define Requisitos Não-Funcionais como: Fatores de qualidade de software que podem ser medidos de forma indireta, ou como:  Características implícitas que são esperadas de todo software profissionalmente desenvolvido.
  • Reusabilidade - Capacidade de reutilização de módulos do sistema em outras aplicações. Este requisito está relacionado a outros fatores tais como:
o   Modularidade: independência funcional dos componentes
o   Generalidade: amplitude do potencial de aplicação
o   Encapsulação
o   Abstração
  • Portabilidade - Esforço exigido para transferir um sistema de um ambiente de hardware e/ou software para outro.  Fator diretamente relacionado à reusabilidade e às linguagens de programação e ferramentas utilizadas. 
  • Manutenibilidade - Esforço exigido para localizar e reparar erros em um sistema ou para modificá-lo com o propósito de adaptá-lo a um novo ambiente, a novas funcionalidades ou a outras metas de qualidade. Este requisito está relacionado a outros fatores tais como:
o   Boa documentação
o   Legibilidade
o   Reusabilidade e portabilidade

  • Multimodalidade - Uso de diferentes mecanismos para representação ou apresentação da informação e para a interação com o usuário. Este requisito está relacionado ao uso de diversos canais de comunicação:
o   Visual
o   Tátil
o   Auditiva
o   Motora

  • Eficiência e Desempenho
o   Eficiência: quantidade de recursos de computação e de código exigida para que o programa execute a sua função.
o   Desempenho: é medido avaliando-se a velocidade de processamento, o tempo de resposta, o consumo de recursos, o throughput e a eficiência.

  • Usabillidade - Refere-se ao grau de facilidade oferecido para que um usuário aprenda a operar, fornecer entradas e interpretar saídas de um componente ou sistema. A usabilidade de um sistema é um conceito que se refere à qualidade da interação de sistemas com os usuários e depende de vários aspectos. Alguns destes fatores são:
o   Facilidade de aprendizado do sistema: tempo e esforço necessários para que os usuários atinjam um determinado nível de desempenho;
o   Facilidade de uso: avalia o esforço físico e cognitivo do usuário durante o processo de interação, medindo a velocidade de uso e o número de erros cometidos durante a execução de uma determinada tarefa; Pressupõe  a existência de Help, manuais de usuário e boa documentação;
o   Satisfação do usuário: avalia se o usuário gosta e sente prazer em trabalhar com este sistema;
o   Flexibilidade e Nível de Parametrização: avalia a possibilidade de o usuário acrescentar e modificar as funções e o ambiente iniciais do sistema. Assim, este fator mede também a capacidade do usuário utilizar o sistema de maneira inteligente e criativa, realizando novas tarefas que não estavam previstas pelos desenvolvedores;
o   Produtividade: avalia se o uso do sistema permite ao usuário ser mais produtivo do que seria se não o utilizasse;
o   Consistência de interface;
o   Cuidado com a navegabilidade;
o   Tolerância a erros;

  • Rastreabilildade - Capacidade de manutenção de histórico das ações dos usuários tais como: número de acessos ao sistema e material consultado ou do comportamento do sistema.

  • Extensibilidade - Capacidade de ampliar o sistema, pela incorporação de novas funcionalidades, pelo aumento da capacidade de armazenamento, etc. e a Medida do esforço necessário para isso. 
  • Escalabilidade - Capacidade de um componente ou de um software manter o mesmo desempenho (tempo de resposta) quando há um aumento no número de usuários e/ou de requisições simultâneas ). Este requisito está relacionado aos fatores:
o   Pool de conexões
o   Cuidado com operações de I/O
  • Configurabilidade - Capacidade de organizar e controlar elementos da configuração do sistema ou Capacidade de gerar diferentes configurações ou visões do sistema ). Este requisito está relacionado a outros fatores tais como:
o   Habilitação ou omissão de conteúdos e serviços
o   Parametrização
o   Personalização e customização do sistema ou componente de acordo com o  contexto ou com o perfil de usuário.
  • Variabilidade - Está associada à variação de componentes de uma arquitetura. Podem haver variações:
o   de funcionalidade
o   de dados
o   de fluxo de controle
o   de tecnologia
o   de ambiente
o   de metas de qualidade

  • Segurança - Premissas e Restrições para o controle e segurança do software além da disponibilidade de mecanismos que controlam ou projetam programas e dados. Este requisito está relacionado aos fatores como: necessidade de criptografia, autenticação de usuários, etc.
o   Controle de acesso e manipulação de recursos.
o   Autenticação.
o   Autorização/permissão.
o   Integridade dos dados e confiabilidade.
o   Privacidade e confidencialidade.

  • Tolerância à Falhas - Capacidade do sistema de manter o seu funcionamento normal dada a ocorrência de uma falha de hardware ou software.  Este requisito está relacionado aos fatores:
o   Disponibilidade
o   Confiabilidade
o   Frequência e gravidade das falhas
o   Acurácia dos resultados
o   Capacidade de recuperação
o   Redundância

  • Interoperabilidade
  • Testabilidade
  • Correção
  • Consistência
  • Compatibilidade
  • Complexidade
  • Internacionalização - Capacidade do sistema de suportar diferentes línguas (Português, Inglês, Espanhol, etc.) sem a necessidade de recodificação.

Todos os requisitos acima são muito importantes, pois definem se o sistema será eficiente para a tarefa a que se propõe a fazer. Neles também são apresentados restrições de uso para os requisitos funcionais. Cabe aos envolvidos o bom senso para avaliar quando se aplica ou não os requisitos de sistemas.

Grande Abraço,
Gilberto Ribeiro.