Problemas, qualidade e processo de desenvolvimento de software

Introdução

Desenvolver um software significa transformar necessidades humanas, organizacionais ou técnicas em uma solução computacional que possa ser utilizada de maneira confiável. Essa transformação envolve muito mais do que escrever código. Antes da programação, é necessário compreender o problema, identificar quem será afetado pelo sistema, descobrir o que precisa ser realizado, analisar restrições, organizar o trabalho e estabelecer uma solução. Depois da programação, ainda é necessário verificar o comportamento do produto, implantá-lo em seu ambiente de operação, acompanhar seu uso e modificá-lo quando o contexto mudar.

Os materiais de Freitas e de Gonçalves e Cortés apresentam o desenvolvimento de software como uma atividade de engenharia, apoiada por processos, métodos, modelos, documentação e ferramentas. Nessa perspectiva, o código é uma parte importante do produto, mas não representa sozinho todo o trabalho necessário para construí-lo. Gonçalves e Cortés destacam que o desenvolvimento deixou de ser tratado como uma atividade puramente artesanal justamente porque sistemas maiores e mais importantes precisam atender expectativas de custo, prazo e qualidade. Freitas, de modo semelhante, situa a qualidade como fundamento das diferentes camadas da Engenharia de Software.

Essa visão é particularmente relevante porque muitos problemas de um sistema não surgem somente de erros de programação. Um software pode executar exatamente aquilo que foi implementado e, ainda assim, ser inadequado porque a equipe compreendeu incorretamente a necessidade do usuário. Pode possuir funcionalidades corretas, mas apresentar desempenho insuficiente, interface de difícil utilização ou regras que já não correspondem ao funcionamento da organização. Pode também ser tecnicamente satisfatório no momento da entrega e tornar-se difícil de modificar por falta de documentação, organização do código ou conhecimento sobre as decisões que orientaram sua construção.

Por isso, problemas de comunicação, requisitos insuficientes, alterações de necessidade, retrabalho, custos e qualidade não devem ser estudados isoladamente. Eles fazem parte de uma mesma relação. Quanto menor a compreensão compartilhada sobre o que deve ser construído, maiores tendem a ser as incertezas incorporadas ao projeto. Quando essas incertezas somente são percebidas em etapas posteriores, modificações podem atingir partes já analisadas, projetadas, programadas ou testadas, ampliando o trabalho necessário para adequar o sistema.

O processo de desenvolvimento existe, entre outras razões, para tornar esse trabalho administrável. Ele organiza atividades, define resultados esperados, permite revisões e cria oportunidades para que cliente, usuários e equipe técnica confirmem progressivamente se a solução construída permanece coerente com o problema que motivou o projeto.

Problemas e desafios no desenvolvimento de software

Um projeto de software reúne pessoas com conhecimentos, interesses e responsabilidades diferentes. Usuários conhecem sua rotina de trabalho; gestores conhecem objetivos e restrições da organização; profissionais técnicos conhecem tecnologias, arquiteturas e limitações de implementação. O sistema precisa integrar essas diferentes perspectivas em uma representação suficientemente clara para orientar decisões.

Essa necessidade torna a comunicação um elemento estrutural do desenvolvimento. A equipe não programa uma necessidade diretamente: primeiro precisa interpretá-la. Quando alguém solicita, por exemplo, “um sistema para controlar os atendimentos”, ainda existem muitas informações indefinidas. É preciso saber o que caracteriza um atendimento, quem pode registrá-lo, quais dados são obrigatórios, quais estados ele pode assumir, quem pode consultar as informações, quais relatórios são necessários, quais regras já existem e quais restrições devem ser respeitadas. Uma expressão aparentemente simples pode esconder dezenas de decisões.

Comunicação e construção de uma compreensão comum

Calazans apresenta a Engenharia de Requisitos como uma forma de esclarecer, organizar e documentar requisitos de maneira sistemática. A autora ressalta que um programa bem projetado ou bem codificado ainda poderá provocar problemas quando seus requisitos tiverem sido mal analisados ou mal especificados. O ponto central é que a qualidade da implementação não compensa automaticamente uma compreensão incorreta daquilo que deveria ser implementado.

A comunicação entre cliente, usuários e equipe técnica enfrenta um problema adicional: as pessoas podem empregar as mesmas palavras com significados diferentes. Um gestor pode utilizar a palavra “cliente” para representar a empresa contratante, enquanto o sistema precisa distinguir pessoa física, representante comercial, comprador e responsável financeiro. O usuário pode explicar uma regra como se ela fosse óbvia por fazer parte de sua rotina, enquanto a equipe técnica ainda não possui o conhecimento necessário para perceber suas exceções.

Gonçalves e Cortés destacam que a elicitação de requisitos envolve o contato com clientes e usuários para conhecer o domínio, as funcionalidades esperadas, o desempenho e as restrições de infraestrutura. Os autores também ressaltam que diferentes perfis de uma organização podem precisar participar desse trabalho. A razão é simples: nenhuma pessoa necessariamente possui, sozinha, uma visão completa do processo que será informatizado.

Requisitos insuficientes, ambíguos ou contraditórios

Os requisitos descrevem serviços, comportamentos e restrições que o sistema deve satisfazer. Quando estão incompletos, parte da necessidade permanece fora da especificação. Quando estão vagos, diferentes pessoas podem interpretá-los de formas incompatíveis. Quando são contraditórios, duas partes do projeto podem exigir comportamentos que não podem coexistir sem uma decisão adicional.

Gonçalves e Cortés destacam propriedades desejáveis como precisão, ausência de ambiguidade, completeza e consistência. Um requisito incompleto pode omitir uma regra necessária; um requisito ambíguo pode ser implementado segundo uma interpretação diferente daquela esperada pelo usuário; requisitos inconsistentes podem levar duas partes da equipe a construir comportamentos incompatíveis. O problema não é apenas documental. Cada imprecisão pode propagar-se para modelos, código e testes.

Freitas identifica ainda problemas de escopo, de entendimento e de volatilidade durante o levantamento. Problemas de escopo ocorrem quando o objetivo do sistema não está claramente delimitado ou quando são introduzidas informações sem relação direta com esse objetivo. Problemas de entendimento aparecem quando usuários têm dificuldade de expressar suas necessidades ou quando essas necessidades ainda não estão suficientemente claras. A volatilidade refere-se às mudanças que atingem os requisitos ao longo do desenvolvimento.

A volatilidade merece atenção porque mudança não é sinônimo de erro. Uma necessidade pode mudar legitimamente devido a novas regras de negócio, legislação, mudanças organizacionais, descoberta de novas informações ou aprendizagem produzida pelo próprio projeto. O problema surge quando a equipe não possui mecanismos para reconhecer, analisar e controlar o impacto dessas alterações.

Alterações e propagação de impacto

Em software, decisões estão interligadas. Um requisito pode originar um modelo, influenciar uma estrutura de dados, resultar em funções específicas, determinar regras de interface e gerar casos de teste. Quando esse requisito muda, as consequências não se restringem ao texto que o descreve. Dependendo da etapa em que a mudança ocorre, pode ser necessário revisar vários artefatos e partes do sistema.

Um exemplo simples ajuda a perceber essa propagação. Considere um sistema que permita cancelar um pedido enquanto ele estiver “em processamento”. Depois de parte do sistema ser construída, a organização informa que pedidos já faturados também poderão ser cancelados, desde que seja iniciado um procedimento de estorno. Essa alteração não exige apenas adicionar um botão. Ela pode afetar os estados do pedido, permissões de usuários, registro financeiro, integração com outros sistemas, mensagens apresentadas ao usuário, persistência de dados e testes relacionados ao processo.

Quanto mais tarde uma necessidade relevante for descoberta, maior pode ser a quantidade de decisões dependentes dela que já foram tomadas. Por isso, analisar e validar progressivamente reduz o risco de construir extensas partes do sistema sobre premissas incorretas.

Retrabalho, prazo e custo

Retrabalho é o esforço empregado para refazer, corrigir ou adaptar algo que já havia sido produzido. Nem todo retrabalho pode ser eliminado. Sistemas evoluem e projetos geram aprendizagem. Entretanto, parte significativa do retrabalho pode ser consequência de comunicação deficiente, ausência de validação, requisitos frágeis, decisões apressadas ou falta de integração entre atividades.

Retrabalho técnico normalmente utiliza novamente recursos que já haviam sido consumidos: tempo de análise, programação, revisão, testes e implantação. Além disso, uma correção pode interromper outras atividades planejadas. O impacto financeiro não está apenas no número de horas utilizadas para alterar o código; pode envolver replanejamento, repetição de testes, reorganização de entregas, indisponibilidade de profissionais e atraso na obtenção do benefício esperado pelo cliente.

Gonçalves e Cortés reforçam a importância de modelar e documentar o sistema antes da implementação, observando que alterações realizadas nas fases iniciais tendem a exigir menos esforço do que mudanças descobertas quando a solução já foi amplamente construída. Essa lógica explica por que análise, documentação e validação não devem ser vistas simplesmente como burocracia: elas permitem confrontar decisões antes de incorporá-las de forma mais profunda ao produto.

Qualidade e adequação às necessidades do usuário

A palavra qualidade pode ser interpretada de maneira superficial como ausência de defeitos. Em software, entretanto, um sistema sem falhas evidentes ainda pode ser inadequado. Se ele executar funções que não correspondem ao trabalho real do usuário, exigir procedimentos desnecessariamente complexos, responder lentamente em situações importantes ou não oferecer proteção apropriada às informações, seu valor será limitado.

Nos materiais consultados, qualidade aparece relacionada ao próprio propósito da Engenharia de Software. Freitas apresenta o processo, os métodos e as ferramentas como elementos sustentados por um foco na qualidade. Gonçalves e Cortés associam o emprego de técnicas de engenharia à necessidade de produzir sistemas capazes de satisfazer requisitos de custo, prazo e qualidade. Calazans relaciona diretamente uma boa compreensão do problema e uma especificação adequada à obtenção de software de maior qualidade.

Funcionamento técnico e adequação

Uma distinção importante é aquela entre funcionar conforme a implementação e atender adequadamente à necessidade que justificou o sistema. O primeiro aspecto pode ser verificado examinando se o software executa corretamente as funções especificadas. O segundo exige confirmar se essas funções, condições e restrições realmente representam aquilo de que os usuários e a organização precisam.

Imagine um sistema de agendamento que registre horários sem apresentar erros, salve corretamente os dados e permita consultar cada reserva. Tecnicamente, suas funções principais podem operar. Porém, se o sistema não impedir dois atendimentos incompatíveis no mesmo horário, não respeitar o intervalo necessário entre procedimentos ou dificultar a consulta da agenda durante o atendimento ao público, seu funcionamento técnico não é suficiente para caracterizar uma solução adequada.

É por isso que requisitos e validação estão ligados à qualidade. Freitas descreve a validação de requisitos como a avaliação da especificação para confirmar sua correspondência com o objetivo final do produto. Gonçalves e Cortés situam a validação do sistema como o momento em que o cliente analisa se o produto gerado atende suas necessidades. Em ambos os casos existe uma comparação entre aquilo que foi construído ou especificado e uma referência que representa a necessidade esperada.

Dimensões relevantes da qualidade

A qualidade percebida em um software resulta de diferentes propriedades. Dependendo do sistema, algumas delas terão peso maior que outras. Um sistema de atendimento emergencial, por exemplo, possui exigências diferentes das de uma aplicação simples para registro pessoal. Ainda assim, algumas dimensões ajudam a compreender que qualidade não é uma característica única.

Essas propriedades não devem ser avaliadas de maneira completamente separada. Uma solução extremamente protegida, mas quase impossível de utilizar em sua rotina real, pode comprometer o trabalho do usuário. Uma interface muito simples que ignore controles necessários pode criar riscos. Um sistema muito rápido, mas que produz resultados incorretos, também não atende seu propósito. A qualidade exige equilíbrio entre as propriedades relevantes para o contexto.

Os requisitos não funcionais são especialmente importantes nessa discussão. Gonçalves e Cortés citam propriedades como confiabilidade, tempo de resposta e armazenamento ao explicar requisitos não funcionais. Calazans apresenta exemplos relacionados a segurança, disponibilidade, compatibilidade, portabilidade e outros aspectos do funcionamento. Essas propriedades precisam ser tratadas como parte da solução desde o início, porque muitas delas não podem ser adicionadas adequadamente apenas no final.

Qualidade e capacidade de evolução

Freitas ressalta uma característica importante: software não sofre desgaste físico como uma peça mecânica. Isso, entretanto, não significa que permaneça adequado indefinidamente. O ambiente ao redor do sistema muda. Regras são alteradas, novas necessidades surgem, tecnologias deixam de ser suportadas, integrações são modificadas e falhas antes desconhecidas são descobertas.

Um software de qualidade precisa ser considerado também em relação à possibilidade de continuidade. Estruturas difíceis de compreender, documentação desatualizada, forte dependência de conhecimento não registrado e código excessivamente acoplado podem transformar uma alteração aparentemente simples em uma intervenção de alto risco. Freitas observa, ao discutir prototipação, que sistemas mal estruturados podem tornar modificações cada vez mais difíceis e custosas à medida que crescem.

Dessa forma, qualidade não termina na primeira entrega. Ela também se manifesta na capacidade de o produto continuar respondendo ao seu contexto ao longo do tempo.

O processo de desenvolvimento de software

Um processo de desenvolvimento de software organiza o conjunto de atividades necessárias para produzir e modificar um sistema. Gonçalves e Cortés descrevem o processo como um conjunto de fases, tarefas, entradas, saídas e papéis. Freitas o apresenta como uma estrutura para organizar as tarefas necessárias à construção de software. Em ambas as perspectivas, o objetivo é substituir uma sequência improvisada de decisões por uma forma compreensível de organizar o trabalho.

As fases não possuem uma nomenclatura universal e não precisam ocorrer sempre uma única vez. Diferentes processos organizam essas atividades de formas distintas. Modelos sequenciais enfatizam a progressão entre fases; abordagens incrementais distribuem a construção em entregas sucessivas; processos iterativos retornam repetidamente a atividades de compreensão, construção e avaliação. Calazans ressalta que não existe um processo único e perfeito aplicável a qualquer projeto.

Apesar das diferenças, é possível apresentar uma visão conceitual que ajuda a compreender o papel das principais atividades.

Da necessidade ao levantamento de requisitos

O desenvolvimento deve começar pela compreensão da situação que exige uma solução. Isso inclui identificar o problema, os objetivos, as pessoas afetadas, o ambiente de operação e as restrições relevantes. Essa etapa evita que uma ideia de solução seja confundida com o problema real.

Depois dessa compreensão inicial, o levantamento ou elicitação de requisitos procura obter informações mais detalhadas. Entrevistas, observação, análise de documentos, questionários, demonstrações de tarefas, prototipação e oficinas são algumas das técnicas apresentadas nos materiais de Calazans e de Gonçalves e Cortés. O método utilizado depende do tipo de sistema, da disponibilidade dos participantes e da natureza do conhecimento que precisa ser descoberto.

O resultado não deve ser apenas uma coleção de desejos. As informações levantadas precisam ser analisadas, negociadas, organizadas e especificadas de forma compreensível. Freitas apresenta atividades como obtenção, análise e negociação, especificação, modelagem e validação. A terminologia pode mudar de um autor para outro, mas a intenção permanece: transformar necessidades dispersas em uma base suficientemente consistente para orientar as decisões seguintes.

Análise, planejamento e projeto

Na análise, a equipe procura aprofundar a compreensão do que o sistema precisa representar e realizar. Freitas caracteriza a análise como uma etapa situada entre os requisitos e o projeto, na qual dados, funções, comportamento, interfaces e restrições são examinados. O foco principal está no entendimento do problema e da solução em nível lógico, antes de determinar todos os detalhes de implementação.

Gonçalves e Cortés descrevem o projeto como uma etapa de aprofundamento das decisões, incluindo o detalhamento dos modelos e o estabelecimento de aspectos arquiteturais. Essa passagem é importante: compreender o que precisa ser realizado não é o mesmo que definir como a solução será organizada tecnicamente.

O planejamento acompanha essas decisões ao organizar recursos, responsabilidades, prioridades e entregas. Em projetos pequenos, parte desse planejamento pode ser simples; em projetos maiores, ele se torna mais explícito. Em qualquer caso, iniciar a programação sem conhecer minimamente o objetivo e as restrições do trabalho aumenta a probabilidade de construir rapidamente uma solução inadequada.

Desenvolvimento e integração

O desenvolvimento transforma as decisões do projeto em componentes executáveis. É nessa atividade que algoritmos, estruturas de dados, interfaces, integrações e regras são implementados em tecnologias concretas. Gonçalves e Cortés descrevem essa fase como a implementação do sistema em uma linguagem de programação tomando como base o que foi estabelecido nas fases anteriores.

Isso não significa que a programação seja uma execução mecânica de documentos prontos. Durante a construção, novas dificuldades aparecem. Limitações técnicas podem ser descobertas, hipóteses podem precisar ser revistas e detalhes antes pouco relevantes podem tornar-se decisivos. O processo precisa permitir que essas descobertas sejam comunicadas e analisadas, evitando que cada desenvolvedor resolva isoladamente um problema que altera o comportamento esperado do sistema.

Testes, verificação e validação

Testar software significa submetê-lo a situações planejadas e observar seus resultados. Gonçalves e Cortés explicam que os testes procuram verificar se o software está de acordo com os requisitos que orientaram sua implementação, podendo também abordar condições de falha e aspectos como desempenho.

A existência de testes reforça uma característica importante dos bons requisitos: eles precisam permitir alguma forma de verificação. Uma afirmação como “o sistema deve ser rápido” é difícil de testar sem estabelecer o que significa rapidez no contexto. Uma condição mais específica oferece uma referência melhor para avaliar o comportamento.

Verificação e validação possuem sentidos complementares. De forma simplificada, a verificação procura examinar se o produto ou artefato está sendo construído de acordo com sua especificação; a validação procura confirmar se o resultado atende à necessidade para a qual foi criado. Essa distinção explica por que a participação do cliente não deve ocorrer apenas no início. Um sistema pode estar coerente com uma especificação que, por sua vez, já não represente adequadamente a necessidade real.

Implantação, operação e manutenção

Depois dos testes e das validações necessárias, o software precisa ser disponibilizado em seu ambiente de utilização. A implantação pode envolver configuração, migração de dados, instalação, liberação de acessos e integração com recursos existentes. A complexidade dessas tarefas varia de acordo com o tipo de sistema.

A operação não encerra o ciclo de vida. O uso real produz informações que não estavam completamente disponíveis durante o desenvolvimento. Falhas podem aparecer, usuários podem identificar necessidades de melhoria e o ambiente organizacional ou tecnológico pode mudar. Freitas destaca que o software não se desgasta fisicamente, mas pode sofrer modificações para continuar atendendo seus usuários.

Manutenção, portanto, não deve ser entendida apenas como correção de defeitos. Ela também compreende adaptações e evoluções necessárias para preservar a utilidade do sistema. Quanto maior a qualidade das decisões anteriores, da arquitetura, do código, dos testes e da documentação, melhores tendem a ser as condições para compreender os impactos dessas modificações.

Documentação e participação do cliente como elementos transversais

A documentação conecta decisões tomadas em diferentes momentos do projeto. Gonçalves e Cortés destacam a importância da rastreabilidade, isto é, do relacionamento entre artefatos que possuem dependência entre si. Um requisito pode estar relacionado a casos de uso, modelos, código e testes. Quando o requisito muda, esses vínculos ajudam a identificar o que precisa ser examinado.

Documentar não significa produzir grande quantidade de texto. Significa preservar informações necessárias para que pessoas possam compreender decisões relevantes sem depender exclusivamente da memória de quem participou do projeto. A forma da documentação varia conforme o processo: pode incluir requisitos textuais, modelos, histórias de usuário, critérios de aceite, registros de decisão, especificações técnicas e documentação de testes.

A participação de clientes e usuários também atravessa o processo. Freitas mostra, ao discutir prototipação, que a avaliação realizada pelo usuário auxilia no refinamento dos requisitos. Calazans enfatiza que a validação dos artefatos deve registrar o aceite do cliente. Essas práticas reduzem a distância entre a interpretação da equipe e a necessidade de quem utilizará ou será afetado pelo produto.

Como problemas, qualidade e processo se relacionam

Problemas, qualidade e processo constituem três perspectivas sobre o mesmo trabalho. Os problemas revelam onde o desenvolvimento pode perder alinhamento; a qualidade define propriedades que a solução precisa preservar; o processo organiza atividades que permitem descobrir, construir e verificar essas propriedades.

Uma falha de comunicação no início pode gerar um requisito incorreto. O requisito incorreto pode orientar um modelo inadequado. O modelo pode produzir uma implementação tecnicamente correta em relação ao que foi especificado, mas incompatível com a necessidade do usuário. Quando a divergência for finalmente percebida, será necessário revisar documentos, código e testes. Surge então o retrabalho, acompanhado de impacto sobre prazo e custo.

O sentido do processo é interromper essa cadeia o mais cedo possível. Elicitação amplia a compreensão; análise identifica relações e inconsistências; especificação cria uma referência comunicável; modelagem permite representar aspectos complexos; validação envolve o cliente na confirmação; projeto estrutura a solução; testes confrontam o comportamento construído com critérios definidos; manutenção permite continuar o ciclo quando novas necessidades surgem.

Considere novamente um sistema de agendamento. Antes do desenvolvimento, a equipe identifica que o objetivo é organizar a ocupação de horários de uma clínica. Durante o levantamento descobre que diferentes procedimentos possuem durações diferentes e que alguns dependem de equipamentos específicos. Na análise, percebe-se que não basta controlar a agenda do profissional: também é necessário impedir conflito de equipamento. No projeto, essas regras são traduzidas para a organização da solução. Nos testes, são simuladas situações de concorrência entre agendamentos. Na validação, profissionais da clínica confirmam se os comportamentos correspondem à rotina real.

Se a restrição de equipamentos só fosse descoberta depois da implantação, a mudança provavelmente alcançaria várias partes do sistema. O exemplo demonstra que atividades anteriores à programação não são acessórios: elas reduzem o risco de consolidar decisões incompletas e melhoram a capacidade de avaliar a qualidade antes que o produto esteja totalmente construído.

Ao mesmo tempo, não é possível esperar que o projeto inicial elimine toda incerteza. O próprio uso pode revelar necessidades novas. Por isso, processos de desenvolvimento precisam combinar disciplina e capacidade de adaptação. Documentação, rastreabilidade, testes e participação das partes interessadas formam uma base para que mudanças sejam incorporadas sem transformar cada evolução em uma reconstrução descontrolada do sistema.

Essa integração mostra também por que qualidade é responsabilidade de todo o processo. Não é possível “adicionar qualidade” apenas na fase de testes. Se uma necessidade essencial nunca foi levantada, o teste baseado na especificação existente pode não detectá-la. Se a arquitetura dificulta qualquer modificação, a manutenção continuará custosa mesmo que as funções atuais estejam corretas. Se o usuário não consegue compreender a interface, o funcionamento interno adequado não resolve integralmente o problema.

O desenvolvimento profissional procura, portanto, construir ciclos de compreensão, decisão, implementação e avaliação. A qualidade resulta da coerência entre essas atividades e da capacidade de manter o sistema alinhado às necessidades que justificam sua existência.

Síntese

O desenvolvimento de software é uma atividade de transformação de necessidades em soluções computacionais. Os principais riscos desse trabalho não estão limitados aos erros de programação. Comunicação inadequada, escopo mal compreendido, requisitos insuficientes, ambiguidades, contradições e mudanças não controladas podem produzir decisões incorretas que se propagam por modelos, código, testes e implantação.

Quando uma divergência é descoberta depois que diversas decisões já dependem dela, surge retrabalho. Esse retrabalho pode afetar prazo, custo e organização da equipe. Por isso, compreender, documentar, analisar e validar necessidades antes e durante a construção é uma forma de reduzir riscos, e não apenas uma exigência documental.

Qualidade de software não significa somente ausência de falhas aparentes. Um sistema precisa ser adequado ao contexto para o qual foi criado. Confiabilidade, usabilidade, segurança, desempenho e capacidade de manutenção ajudam a compreender diferentes dimensões dessa adequação. O peso de cada uma depende do tipo de sistema, dos usuários, das restrições e dos riscos envolvidos.

O processo de desenvolvimento organiza o trabalho necessário para alcançar e preservar essa qualidade. Identificação da necessidade, levantamento e especificação de requisitos, análise, planejamento, projeto, desenvolvimento, testes, implantação, operação e manutenção representam atividades que podem ser combinadas de maneiras diferentes segundo a abordagem adotada. Elas não precisam formar uma sequência rígida e irreversível.

Documentação, comunicação e participação do cliente atravessam todo o processo. Elas permitem registrar decisões, relacionar artefatos, validar interpretações e compreender impactos quando o sistema precisa mudar. Assim, processo e qualidade não eliminam a evolução do software; fornecem condições para que essa evolução aconteça de maneira mais controlada, compreensível e coerente com as necessidades dos usuários.

Referências

• CALAZANS, Angélica Toffano Sedel. Análise e Projeto de Sistemas. Curso Técnico em Informática. Brasília: Instituto Federal de Brasília, [s.d.]. Material didático.
• FREITAS, Romualdo Rubens de. Análise e Projeto de Software. Cuiabá: Rede e-Tec Brasil, 2015.
• GONÇALVES, Enyo José Tavares; CORTÉS, Mariela Inés. Análise e Projeto de Sistemas. 3. ed. Fortaleza: EdUECE, 2015.
• BAHIA. Secretaria da Educação. Superintendência da Educação Profissional e Tecnológica. Ementa - Técnico em Informática - PROSUB. Salvador: SUPROT, [s.d.].