Engenharia de Software: Modelo de Ciclo de Vida

Artigo da Série Engenharia de Software.

O tema de hoje: Modelo de Ciclo de Vida.

Em Engenharia de Software, o Modelo de Ciclo de Vida é o processo de planejar, criar, testar e colocar em produção um Sistema da Informação.

Categorias:

  • Sequenciais
    • Modelo em Cascata (Clássico) : Segue uma sequência linear.
  • Incrementais
    • Modelo Incremental: Combinação do modelo Linear e Prototipação.
  • Evolutivos
    • Prototipação (Prototipagem): Facilita o entendimento pelo usuário
    • Espiral: Ciclos de desenvolvimento que melhoram a cada iteração. Focado em Risco.
  • Agéis
    • Incremental + Evolutivo

Leia também:

Engenharia de Software: Engenharia de Requisitos

Artigo da Série Engenharia de Software.

O tema de hoje: Engenharia de Requisitos.

Engenharia de Requisitos é o processo de definir, documentar e manter os requisitos em Engenharia de Software.

Quais as principais atividades?

Antes de mostrar quais as atividades estão envolvidas na Engenharia de Requisitos, é importante fazer um Estudo de Viabilidade com as partes interessadas, para saber se a solução a ser implementada agrega valor ao negócio, se tem orçamento, se tem integração e se já não existe uma solução pronta de mercado.

Após o estudo teremos:

  • Levantamento (Elicitação)

Analistas e Stakeholders se reunem para levantar necessidades. Aqui podemos fazer uso de técnicas como: Entrevistas, Questionários, Workshops de Requisitos, Cenários, Prototipagem e Etnografias (vivenciar na prática a situação, semelhante aos Laboratórios que atores realizam pra montar uma personagem).

  • Análise/Negociação de Requisitos

Aqui classificamos, resolvemos conflitos ( inclusive políticos), priorizamos e confirmamos os requisitos.

  • Especificação

Esta é a atividade de documentação e modelagem. Definimos requisitos para os usuários, requisitos de sistema, o design da aplicação. Estes requisitos classificamos como requisitos funcionas (RF) e requisitos não funcionais (RNF). Criamos Casos de Usos, e outros diagramas presentes na UML.

  • Validação

Com a documentação em mãos, o analista de requisitos verifica e valida se o sistema atende ao clientes. Algumas técnicas usadas são Revisão, Prototipação, Criação de Casos de Testes.

  • Gestão de Requisitos

A gestão de requisitos faz o controle de mudanças para atender à dinâmica dos negócios, visão do usuário, ….

Leia também:

Engenharia de Software: Teste de Software

Artigo da Série Engenharia de Software.

O tema de hoje: Teste de Software.

Teste de Software é o processo de investigar o Software em busca de defeitos críticos e para a validação de requisitos. E tem por finalidade aumentar a qualidade do mesmo e evitar transtornos ou prejuízos para as pessoas e/ou empresas envolvidas.

Quais são as fases:

  • Teste Unitário

    Nesta fase quem participa é o desenvolvedor. Ele será responsável por criar os testes unitários, e verificar a funcionalidade de classes e metódos.

  • Teste de Integração

    Nesta fase os desenvolvedores de diferentes partes do sistema, testa como cada parte interage entre si.

  • Teste de Sistema

    Nesta fase o desenvolvedor e usuário testam o sistema.

  • Teste de Aceitação

    Os usuários que vão utilizar o Sistema vão dar o OK, para colocar o sistema em produção.

  • Teste de Operação

    O Administrador do Sistema faz a validação da Administração do Sistema

Algumas técnicas:

  • Caixa Preta (Teste Funcional)

Verifica a entrada e saída, não olha o código. Não é preciso conhecer a arquitetura ou tecnologia.

  • Caixa Branca

Aqui olhamos o código, é um teste voltado a lógica de programa. Fazemos o uso de ferramentas como o junit.

  • Teste baseado em Erros

Testa-se erros conhecidos em Computação. Por exemplo: Divisão por Zero.

  • Teste de Regressão

Aplica-se a cada nova versão do Software, os testes que forma aplicados na versão anterior, afim de verificar a nova versão não comprometeu os requisitos inalterados.

  • Teste de Estresse

Verifica a carga suportada pelo software. A quantidade de usuários que serão atendidos, ….

Quais são os ciclos:

  • Planejamento
  • Preparação
  • Especificação
  • Execução
  • Entrega

O que é critério de teste?

Estabelece uma exigência ou nível para a aceitação do programa, isto é:

Se o software não atender a 80% das nossas necessidades então abortamos o projeto.  🙁

Leia também:

Engenharia de Software: Gerência de Configuração de Software

Artigo da Série Engenharia de Software.

O tema de hoje: Gerência de Configuração de Software.

O desenvolvimento de Software é uma atividade dinâmica. Mudanças são inevitáveis. Mudam as regras de negócio, muda a visão do usuário sobre o sistema.

A Gerência de Configuração de Software (GCS) é uma área da Engenhar de Software, que atua sobre essas mudanças/modificações afim de manter a consistência e a integridade do Software com as especificações, minimizando problemas durante o desenvolvimento e controlando sistematicamente essas modificações.

As atividades e ferramentas da GCS são:

  • Controlar e acompanhar mudanças (Controle de Mudança)
    • Ferramentas: GitHub, Jira, BugZilla
  • Registrar a evolução do projeto (Controle de Versão)
    • Ferramentas: Git, SubVersion
  • Estabelecer a integridade do Sistema (Integração Contínua)
    • Ferramentas: Jenkins, IBM Urban Code

Vale lembrar, que em cada fase do ciclo de desenvolvimento um conjunto bem definido de itens de configuração é definido, este conjunto é chamado de Baseline.

Leia também:

Projetos em Node.js com boas práticas

Como o Node.js é uma plataforma e não um framework, as boas práticas ficam dependentes do projeto e dos desenvolvedores envolvidos.

Os padrões de design e as melhores práticas existem para evitar armadilhas comuns e construir aplicativos mais estáveis, mas esses princípios orientadores na maioria das vezes não são bem documentados.

Mas existem bons guias e filosofias disponíveis, recomendo visitar o The Node Way. Lá descrevem práticas recomendadas e princípios orientadores para a escrita de módulos de manutenção, aplicações escaláveis e códigos que são realmente agradáveis de ler.

 

Uma sugestão que ajuda bastante é utilizar um linter desde o início.

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs in C language source code. Wikipedia

No caso de Javascript, o mais bem availado é o ESLint, veja a comparação com outros neste link.

Como dica de uma boa leitura utilize JavaScript Standard Style, que exemplifica e evita de você criar as suas próprias regras.

Leia também:

A metodologia 12 factor

A metodologia 12 factor consiste em um série métodos que você deve seguir para construir uma aplicação como Software-as-a-Service (SaaS).

Quando li sobre a 12-factor, ficou mais claro pra mim, como aplicações rodando em Cloud estão organizadas em provedores como Amazon AWS, Microsoft Azure, IBM Bluemix ou como soluções Cloud Foundry.

Fator 1 – Um código base em um repositório com multiplos deployments.

Utilize de um sistema de controle de versão como Git ou Subversion, e a partir deste código fonte faça o deploy em múltiplos lugares, como ambiente de desenvolvimento, homologação e produção.

Fator 2 – Declare e separa as dependências.

As dependências da aplicação devem estar fora do código fonte. Por exemplo, no arquivo package.json para uma aplicação em Node.js.
Com isso, o deploy de uma aplicação pode ser feito em diversos servidores, e assim não nos preocupamos com as suas dependências.

Fator 3 – Armazene configuraçòes no seu ambiente.

As configurações da aplicação devem estar fora do código fonte. Nos principais provedores de Cloud, essas configurações são declaradas como variáveis de ambiente.

Exemplo:
set PORT “8080”
set JDBC_URL “jdbc://db_server:port/”

Fator 4 – Trate serviços de apoio como recursos anexado.

Um serviço de apoio é qualquer serviço que a aplicação faça através da rede. Exemplos: Banco de dados (MySql/MongoDB), Sistemas de Mensagens/Filas, serviços SMTP para emails externos (tais como Postfix), e serviços do IBM Watson.

Você deve preparar sua aplicação para usar estes serviços independente do local onde estejam (local ou remoto), e usar variáveis de ambiente para alterar essas configurações. Podendo usar Web UI dashboard do provedor Cloud ou comandos como “cf create-service” e “cf bind-service” para ligar os serviços.

Fator 5 – Faça a separação do Build, Release and Run.

Separe as fases de:

  • Build = Pegue uma versão do código do repositório, forneça as dependências, compile binários e empacote.
  • Release = Envie o Build para um servidor, ajuste as configurações necessárias para que ele seja executado.
  • Run = Rode a aplicação no ambiente de execução, através do início de alguns dos processos da aplicação, para que ele esteja disponível para os usuários acessarem.

Fator 6 – Execute a aplicação como um ou mais processos stateless

Execute a aplicação como um ou mais processos que não armazenam estado.

Quando você cria aplicativos, use vários processos ou serviços conforme necessário.
Evite dependências em stick sessions e mantenha os dados da sessão em um armazenamento persistente para garantir que o tráfego possa ser roteado para outros processos sem interrupção do serviço.

Fator 7 – Exporte de serviços pela porta de TCP/IP

A aplicação lê a variável de ambiente e exporta o serviço através do bind a uma porta de TCP/IP, que recebe as requisições que chegam na mesma.
Depois você pode adicionar um servidor Nginx, que faz um proxy para esse serviço ou utilizar o serviço de roteamento de tráfico do seu provedor cloud.

Fator 8 – Escale atráves do uso de um processo modelo.

Escale horizontalmente a sua aplicação através da criação de processos modelos. Por exemplo, solicitações HTTP podem ser manipuladas para um processo web, e tarefas background de longa duração podem ser manipuladas por um processo trabalhador.

Fator 9 – Maximize a robustez com inicialização e desligamento rápido

Processos no 12-factor são descartáveis, significando que podem ser iniciados ou parados a qualquer momento. Um processo dever iniciar rapidamente, fazendo
o mínimo de ações. E quando o processo for encerrado, deve seguir o mesmo padrão.
Isso facilita o escalonamento, rápido deploy de código ou mudanças de configuração, e robustez de deploys de produção.

Fator 10 – Mantenha os ambientes de desenvolvimento, homologação, produção o mais semelhante possível

Manter ambientes semelhantes evita erros durante o processo de envio da aplicação para produção.

Ferramentas como Docker, Puppet auxiliam nisso. Outras soluções com Spaces no IBM Bluemix provem metodos efetivos para separar diferentes níveis da aplicação.

Esta abordagem permite a entrega de software ágil ( Agile Software) e a integração contínua (continuous integration).

Fator 11 – Trate logs como fluxo de eventos

Utilize os logs da aplicação para entender o funcionamento e utilização da sua aplicação.

A aplicação deve enviar as mensagens para a saída padrão e esta deve ser redirecionada para locais específicos de acordo com o ambiente onde a aplicação está executando, em desenvolvimento para um arquivo.

Exemplo: No Bluemix ou Cloud Foundry, o Loggregator coleta os dados de log em vários componentes do aplicativo e você pode visualizar atráves do comando cf logs.

Fator 12: Executar tarefas de administração/gerenciamento como processos pontuais

Crie tarefas que precisam ser executadas uma vez ou ocasionalmente em componentes separados que podem ser executados quando necessário em vez de adicionar o código diretamente em outro componente.
Por exemplo, se um aplicativo precisa migrar dados para um banco de dados, coloque essa tarefa em um componente separado ao invés de adicioná-lo ao código principal do aplicativo na inicialização.

E aí. Vai utilizar a metodologia 12-factor na sua próxima aplicação?

Leia também:

O que são aplicações Servless?

Apesar do termo Servless, significar “sem servidor”, o conceito de aplicação Servless é bem diferente.

Em aplicações Servless, o desenvolvedor cria uma aplicação que atende a eventos, como por exemplo uma request http, enquanto a gestão do Application server, database, container ou VM, fica por conta do provedor de Cloud.

Dessa maneira, o desenvolvedor foca no desenvolvimento da solução, não se preocupando com a infraestrutura. O faturamento também é diferente, pois o provedor de Cloud vai cobrar pelo eventos, do exemplo anterior, pela quantidade de requisições.

Em breve vou postar algumas dicas de como desenvolver, construir, fazer o deploy, manter e ganhos de eficiência de soluções de software construídas com essas modernas tecnologias de cloud.

Por enquanto, listo abaixo alguns dos principais players de cloud e as tecnologias usadas:

Leia também: