Desenvolvimento de sistemas e novas tecnologias

O modelo em cascata (ウォータフォールモデル) é um modelo de desenvolvimento que avança pelas fases em ordem, das iniciais às finais, como uma cascata, finalizando os entregáveis (成果物) de cada fase antes de seguir adiante. Construir em iterações curtas é o desenvolvimento ágil (アジャイル開発), consolidar requisitos com protótipos é o modelo de prototipação (プロトタイピングモデル) e combinar serviços existentes descreve um mashup (マッシュアップ).

O modelo de prototipação (プロトタイピングモデル) tem como objetivo construir cedo um protótipo (プロトタイプ) e deixar os usuários experimentá-lo, resolvendo em uma fase inicial as ambiguidades nos requisitos e as diferenças de entendimento entre o contratante e os desenvolvedores. Reduzir as linhas de código não é o objetivo, e ele não permite omitir testes nem eliminar a manutenção.

O desenvolvimento ágil (アジャイル開発) é uma abordagem que acumula software funcional a cada iteração curta (反復) e responde com flexibilidade partindo do pressuposto de que as especificações vão mudar; o Scrum (スクラム) e o XP são métodos representativos. Finalizar todos os requisitos antes de desenvolver tudo de uma vez, esperar documentos completos para começar e envolver os usuários só no final são abordagens próximas do modelo em cascata e não são características do ágil.

Um sprint (スプリント) é o período curto e fixo que forma a unidade de desenvolvimento no Scrum (スクラム); cada período repete o ciclo de planejar, desenvolver, produzir software funcional e fazer uma retrospectiva (振り返り). Não é um termo para a fase de definição de requisitos nem para o período do teste de aceitação, nem um período dedicado apenas à correção de bugs.

O modelo em cascata (ウォータフォールモデル) avança partindo do pressuposto de não voltar atrás, por isso, quando erros de requisitos ou de projeto aparecem na fase final de testes, o custo de voltar às fases iniciais para refazer o trabalho (手戻りコスト) é muito grande. Como cada fase finaliza entregáveis como especificações e documentos de projeto, acompanhar o progresso é, na verdade, um ponto forte, e o modelo é adequado a desenvolvimentos grandes. Também não é verdade que ele não permita documentar os requisitos.

O modelo incremental (インクリメンタルモデル) divide o sistema em unidades funcionais e acumula desenvolvimentos e lançamentos em etapas; assim como os modelos de desenvolvimento iterativo (反復型開発モデル), tem a vantagem de que algumas funções podem ser usadas cedo. O modelo em cascata desenvolve o todo em uma única passagem sequencial, a análise estruturada (構造化分析手法) é um método de análise que usa DFDs e afins, e um mashup é uma combinação de serviços existentes; nenhum deles se encaixa.

Basicamente, o desenvolvimento começa pela análise de requisitos (要求分析), que organiza as necessidades dos usuários, e segue para o projeto externo (外部設計) das partes visíveis aos usuários, o projeto interno (内部設計) da implementação interna, a programação e os testes. Ordens em que o projeto vem antes da análise de requisitos, ou os testes antes da programação, não se sustentam, dadas as dependências entre os entregáveis.

O projeto externo (外部設計) abrange as partes visíveis aos usuários e ao exterior — especificações de telas, especificações de relatórios (帳票) e interfaces com outros sistemas. Decidir os algoritmos internos e o layout físico de armazenamento pertence ao projeto interno (内部設計) e ao projeto de programas, e verificar módulos individuais é trabalho do teste unitário (単体テスト).

O teste unitário (単体テスト) é a primeira etapa do processo de testes e verifica, módulo por módulo, se cada um funciona de acordo com o seu projeto detalhado. Combinar módulos para verificar interfaces é o teste de integração (統合テスト), o julgamento de aceitação pelo contratante é o teste de aceitação (受け入れテスト) e verificar o desempenho sob carga pesada descreve os testes de carga e de desempenho (負荷テスト・性能テスト).

Os testes se acumulam a partir das menores unidades: primeiro os testes unitários (単体テスト) por módulo, depois os testes de integração (統合テスト) que combinam os módulos, em seguida o teste de sistema (システムテスト) que verifica o sistema inteiro e, por fim, o teste de aceitação (受け入れテスト) pelo contratante e pelos usuários. Verificar o todo ou aceitar primeiro significaria realizar testes de nível superior com defeitos dos componentes ainda misturados, o que não é razoável.

O teste de aceitação (受け入れテスト) é o teste da etapa final em que o contratante e os usuários examinam o sistema entregue do ponto de vista do negócio e julgam se o aceitam (検収). Verificar a lógica interna é o teste unitário realizado pelos desenvolvedores (teste de caixa branca, ホワイトボックステスト), verificar sem executar é o teste estático (静的テスト) e verificar as conexões entre módulos é o teste de integração (統合テスト); nenhum deles descreve o teste de aceitação.

O teste de caixa preta (ブラックボックステスト) trata o interior do programa como uma "caixa preta" e verifica apenas se a relação entre entrada e saída corresponde à especificação. O teste de caixa branca (ホワイトボックステスト) se concentra em cobrir as ramificações e os caminhos internos, o teste estático (静的テスト) verifica por meio de revisões sem executar o programa, e o teste de regressão (回帰テスト) verifica se as correções não quebraram outras partes.

Verificar se o sistema suporta uma carga alta — muitos acessos simultâneos ou grandes volumes de dados — e mantém o seu desempenho é o teste de carga (負荷テスト), realizado na etapa do teste de sistema (システムテスト) junto com os testes de desempenho (性能テスト) de tempos de resposta e afins. O teste unitário verifica módulos individuais, o teste estático verifica sem executar e o teste de caixa branca é uma técnica centrada na estrutura interna.

O documento de definição de requisitos (要件定義書) reúne, como resultado da análise de requisitos (要求分析), as funções, o desempenho e as restrições que o sistema deve oferecer, e é acordado entre o contratante e o desenvolvedor, servindo de referência para o projeto, os testes e a aceitação posteriores. O manual de operação é um documento de instruções de uso para os usuários, o relatório de teste unitário registra resultados de testes e o diagrama de rede é um desenho de projeto; nenhum deles é o documento de referência acordado.

A WBS é uma técnica que decompõe hierarquicamente e estrutura os entregáveis do projeto e o trabalho necessário para eles, evitando omissões e esclarecendo as unidades para estimativa e atribuição. Mostrar cronogramas em barras horizontais é o gráfico de Gantt (ガントチャート), o gerenciamento por valor agregado (出来高) é o EVM, e avaliar os riscos descreve a análise de riscos (リスク分析).

Um gráfico de Gantt (ガントチャート) mostra o início e o término previstos de cada tarefa como barras horizontais e é amplamente usado para visualizar cronogramas e o progresso. Um diagrama de fluxo de dados (データフロー図) mostra o fluxo dos dados, um diagrama E-R as relações entre entidades e um diagrama de casos de uso (ユースケース図) as interações entre o sistema e seus usuários; nenhum deles é um gráfico de cronograma.

Há 2 caminhos: A→B→D→F (3 + 5 + 4 + 2 = 14 dias) e A→C→E→F (3 + 4 + 6 + 2 = 15 dias). Como F precisa esperar que os dois caminhos terminem, a duração total mínima é a do mais longo, 15 dias. Esse caminho mais longo, A→C→E→F, é o caminho crítico (クリティカルパス). 14 dias considera apenas o lado A→B→D→F, e 12 e 13 dias não correspondem ao total de nenhum caminho.

Há 3 caminhos: A→B→D→F (2 + 4 + 3 + 1 = 10 dias), A→C→D→F (2 + 6 + 3 + 1 = 12 dias) e A→C→E→F (2 + 6 + 4 + 1 = 13 dias). O mais longo, A→C→E→F com 13 dias, é o caminho crítico (クリティカルパス). 10 e 12 dias são os totais dos outros caminhos, e 14 dias não corresponde a nenhum. Qualquer atraso nas tarefas do caminho crítico (A, C, E, F) atrasa o projeto inteiro na mesma medida.

O método de pontos de função (ファンクションポイント法) atribui pontos ao número e à complexidade das funções — entradas, saídas, consultas, arquivos internos etc. — para estimar o tamanho do software, e pode ser aplicado no início do desenvolvimento sem depender das linhas de código. O LOC é uma medida diferente baseada na contagem de linhas, o método Delphi (デルファイ法) faz convergir as opiniões de especialistas por meio de questionários repetidos, e o método KJ (KJ法) é uma técnica de geração de ideias que organiza e agrupa informações em cartões.

A gestão de riscos (リスクマネジメント) segue esta ordem: identificação dos riscos (リスク識別), que levanta os riscos; análise dos riscos (リスク分析, qualitativa e quantitativa), que avalia a probabilidade e o impacto; planejamento das respostas aos riscos (リスク対応計画), que decide as contramedidas; e monitoramento e controle dos riscos (リスクの監視・コントロール), que acompanha a situação durante a execução. Planejar respostas ou monitorar antes da identificação não funciona, pois os riscos em questão ainda não foram determinados.

As mudanças de especificação seguem o processo de controle de mudanças (変更管理): avalia-se o impacto sobre cronograma, custo e qualidade, e o comitê de controle de mudanças (変更管理委員会, CCB) decide pela aprovação ou rejeição. A aceitação incondicional provoca atrasos e queda de qualidade, enquanto recusar tudo faz perder até as mudanças necessárias. Correções feitas na hora por funcionários individuais criam inconsistências com a configuração e os documentos e destroem o controle.

Partes interessadas (ステークホルダ) é o termo coletivo para as pessoas e organizações que têm interesse no resultado do projeto — o contratante, os usuários, os desenvolvedores, a alta direção etc. —, e compreender e conciliar as suas expectativas é uma atividade importante da gestão de projetos. O gráfico de cronograma é o gráfico de Gantt, a decomposição hierárquica é a WBS, e a lista de riscos corresponde ao registro de riscos (リスク登録簿).

Um SLA é um acordo entre o prestador e os usuários de um serviço sobre níveis de qualidade como a disponibilidade (稼働率), o tempo de recuperação de falhas e o horário de suporte, e serve como referência para avaliar o serviço em operação. A proteção dos direitos autorais é um contrato de licença (ライセンス契約), o diagrama de decomposição do trabalho é uma WBS e o empréstimo de equipamentos é um leasing (リース契約); nenhum deles é um SLA.

O ITIL (Information Technology Infrastructure Library) é um conjunto de documentos que sistematiza as melhores práticas (ベストプラクティス) para operar e gerenciar serviços de TI, amplamente consultado como uma estrutura de gestão de serviços que abrange a gestão de incidentes (障害管理), a gestão de mudanças (変更管理), a central de serviços (サービスデスク) e mais. Os padrões de linguagens de programação, a teoria da normalização e os padrões de LAN sem fio pertencem a outras áreas.

A disponibilidade (稼働率) é calculada como MTBF ÷ (MTBF + MTTR). 570 ÷ (570 + 30) = 570 ÷ 600 = 0.95. O MTBF é o tempo médio de operação entre falhas, e o MTTR é o tempo médio de reparo. 0.90 e 0.98 não coincidem nem mesmo trocando o numerador e o denominador, e 0.93 não corresponde a nenhum cálculo.

A gestão de capacidade (キャパシティ管理) prevê o uso futuro — volumes de dados, número de acessos — e garante e amplia de forma planejada a capacidade de servidores, armazenamento e rede, prevenindo antecipadamente a queda de desempenho e a falta de capacidade. A estrutura de contato em caso de falhas pertence à gestão de incidentes e de emergências (障害管理・緊急時対応), a gestão de senhas à gestão de usuários (ユーザ管理) e a quantidade de licenças à gestão de ativos de software (ソフトウェア資源管理).

A virtualização de servidores (サーバ仮想化) é uma tecnologia em que um software de virtualização executa várias máquinas virtuais (仮想マシン) em 1 servidor físico, melhorando o aproveitamento dos recursos pela consolidação de servidores e dando flexibilidade para reconfiguração e recuperação. A distribuição física e os gabinetes menores são questões de hardware, e o armazenamento em papel não tem nada a ver com a virtualização.

O SaaS (Software as a Service) fornece o próprio aplicativo como um serviço pela rede, permitindo que os usuários trabalhem sem instalar o software. O IaaS fornece infraestrutura como servidores, e o PaaS fornece tudo até o ambiente de execução dos aplicativos. On-premises (オンプレミス) significa possuir e operar os equipamentos dentro da própria organização, o que não é um modelo de fornecimento em nuvem.

A Society 5.0 é a visão de uma sociedade que reúne dados do mundo real no ciberespaço (サイバー空間) por meio da IoT e afins, analisa-os e devolve os resultados ao mundo real — uma fusão em alto grau do ciberespaço e do espaço físico (フィジカル空間) que busca, ao mesmo tempo, o crescimento econômico e a solução de problemas sociais. Sobrepor informações à realidade é a AR, dividir o processamento é o processamento distribuído (分散処理), e o corpo de conhecimento em gestão de projetos descreve o PMBOK.

O aprendizado supervisionado (教師あり学習) fornece ao modelo dados com rótulos corretos (正解ラベル) e o treina para prever a resposta a partir da entrada; é usado na classificação de imagens e na previsão de valores numéricos. Encontrar estruturas ou grupos nos dados sem respostas fornecidas é o aprendizado não supervisionado (教師なし学習). Treinar pessoas não é aprendizado de máquina, e gerar saídas aleatórias não tem nada a ver com aprendizado.