Engenharia de Software: Processos, Requisitos e UI

Escrito em 25 de Outubro de 2025 em português com um tamanho de 20,2 KB

Iteração de Processo

Requisitos de sistema sempre evoluem no curso de um projeto e, sendo assim, a iteração de processo, onde estágios iniciais são retrabalhados, é sempre parte do processo dos sistemas de grande porte.

A iteração pode ser aplicada a qualquer um dos modelos genéricos do processo.

Abordagens Relacionadas à Iteração

Entrega Incremental;
Desenvolvimento Espiral.

Entrega Incremental

Ao invés de entregar o sistema como uma única entrega, o desenvolvimento e a entrega são separados em incrementos, sendo que cada incremento fornece parte da funcionalidade solicitada.

Os requisitos de usuário são priorizados e os requisitos de prioridade mais alta são incluídos nos incrementos iniciais.

Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são congelados, embora os requisitos para os incrementos posteriores possam continuar evoluindo.

Vantagens do Desenvolvimento Incremental

O valor pode ser entregue para o cliente com cada incremento e, desse modo, a funcionalidade do sistema é disponibilizada mais cedo.
O incremento inicial age como um protótipo para auxiliar a elicitar os requisitos para incrementos posteriores do sistema.
Riscos menores de falha geral do projeto.
Os serviços de sistema de mais alta prioridade tendem a receber mais testes.

Extreme Programming (XP)

Uma abordagem baseada no desenvolvimento e na entrega de incrementos de funcionalidade muito pequenos.

Baseia-se no aprimoramento constante do código, no envolvimento do usuário na equipe e no desenvolvimento e programação em pares.

Desenvolvimento Espiral

O processo é representado como uma espiral ao invés de uma sequência de atividades com realimentação (feedback).

Cada loop na espiral representa uma fase no processo.

Sem fases definidas, tais como especificação ou projeto — os loops na espiral são escolhidos dependendo do que é requisitado.

Os riscos são explicitamente avaliados e resolvidos ao longo do processo.

Setores do Modelo Espiral

Definição de Objetivos: Objetivos específicos para a fase são identificados.
Avaliação e Redução de Riscos: Riscos são avaliados e atividades são realizadas para reduzir os riscos-chave.
Desenvolvimento e Validação: Um modelo de desenvolvimento para o sistema, que pode ser qualquer um dos modelos genéricos, é escolhido.
Planejamento: O projeto é revisado e a próxima fase da espiral é planejada.

Atividades do Processo de Software

Especificação de Software;
Projeto e Implementação de Software;
Validação de Software;
Evolução de Software.

O Processo de Software

Um conjunto estruturado de atividades necessárias para o desenvolvimento de um sistema de software:

Especificação;
Projeto;
Validação;
Evolução.

Um modelo de processo de software é uma representação abstrata do processo. Ele apresenta a descrição de um processo a partir de uma perspectiva particular.

Modelos Genéricos de Processo de Software

O Modelo Cascata: Fases separadas e distintas de especificação e desenvolvimento.
Desenvolvimento Evolucionário: Especificação, desenvolvimento e validação são intercalados.
Engenharia de Software Baseada em Componentes: O sistema é montado a partir de componentes existentes.

Existem muitas variantes destes modelos, por exemplo, o desenvolvimento formal onde um processo semelhante ao cascata é usado, mas a especificação é uma especificação formal, que é refinada durante os vários estágios para um projeto implementável.

Fases do Modelo Cascata

Análise e Definição de Requisitos;
Projeto de Sistema e Software;
Implementação e Teste de Unidade;
Integração e Teste de Sistema;
Operação e Manutenção.

A principal desvantagem do modelo cascata é a dificuldade de acomodação das mudanças depois que o processo está em andamento. Uma fase tem de estar completa antes de passar para a próxima.

Problemas do Modelo Cascata

Particionamento inflexível do projeto em estágios distintos, o que dificulta a resposta aos requisitos de mudança do cliente.

Portanto, este modelo é apropriado somente quando os requisitos são bem compreendidos e quando as mudanças forem bastante limitadas durante o desenvolvimento do sistema. Poucos sistemas de negócio têm requisitos estáveis.

O modelo cascata é o mais usado em projetos de engenharia de sistemas de grande porte, onde um sistema é desenvolvido em várias localidades.

Desenvolvimento Evolucionário

Desenvolvimento Exploratório: O objetivo é trabalhar com os clientes e desenvolver um sistema final a partir de uma especificação inicial. Deve iniciar com requisitos bem compreendidos e adicionar novas características à medida que forem propostas pelo cliente.
Protótipação: O objetivo é compreender os requisitos de sistema. Deve iniciar com requisitos mal compreendidos para esclarecer o que é realmente necessário.

Problemas do Desenvolvimento Evolucionário

Falta de visibilidade do processo;
Os sistemas são frequentemente mal estruturados;
Habilidades especiais (por exemplo, em linguagens para prototipação rápida) podem ser solicitadas.

Aplicabilidade do Desenvolvimento Evolucionário

Para sistemas interativos de pequeno e médio portes;
Para partes de um sistema de grande porte (por exemplo, a interface de usuário);
Para sistemas com curto ciclo de vida.

O que é RUP (Rational Unified Process)?

É um modelo de processo moderno derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software associado.

Normalmente descrito a partir de três perspectivas:

Uma perspectiva dinâmica que mostra as fases ao longo do tempo;
Uma perspectiva estática que mostra atividades de processo;
Uma perspectiva prática que sugere boas práticas.

Requisitos de Software

O que é um Requisito?

Pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição de sistema para uma especificação matemática funcional.

Isto é inevitável quando os requisitos podem servir uma função dual:

Pode ser a base para uma proposta de um contrato — portanto, deve ser aberta para interpretação;
Pode ser a base para o contrato em si — portanto, deve ser definido em detalhe.

Ambas as declarações podem ser chamadas de requisitos.

Abstração de Requisitos (Davis)

“Se uma empresa deseja estabelecer um contrato para um projeto de desenvolvimento de software de grande porte, deve definir suas necessidades de forma suficientemente abstrata, para que uma solução não esteja pré-definida. Os requisitos devem ser escritos de tal forma que vários fornecedores possam apresentar propostas para o contrato, oferecendo, talvez, diferentes formas de atender às necessidades organizacionais do cliente. Uma vez que o contrato for aprovado, o fornecedor deve escrever uma definição de sistema para o cliente, em mais detalhes, tal que o cliente compreenda e possa validar o que o software irá fazer. Ambos os documentos podem ser chamados de documento de requisitos do sistema.”

Tipos de Requisitos

Requisitos de Usuário: Declarações em linguagem natural mais diagramas de serviços que o sistema fornece e suas restrições operacionais. Escritos para os clientes.
Requisitos de Sistema: Um documento estruturado estabelecendo descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e, assim, pode ser parte de um contrato entre o cliente e o desenvolvedor.

Requisitos Funcionais e Não Funcionais

Requisitos Funcionais: Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
Requisitos Não Funcionais: Restrições sobre serviços ou funções oferecidos pelo sistema, tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc.
Requisitos de Domínio: Requisitos que vêm do domínio de aplicação do sistema e que refletem as características desse domínio.

Detalhes sobre Requisitos de Domínio

Derivados do domínio de aplicação e descrevem características de sistema que refletem o domínio.

Podem restringir os requisitos funcionais existentes ou estabelecer como cálculos específicos devem ser realizados.

Se os requisitos de domínio não forem satisfeitos, o sistema pode não funcionar.

Requisitos de Usuário

Devem descrever requisitos funcionais e não funcionais, de tal modo que sejam compreensíveis pelos usuários do sistema que não têm conhecimento técnico detalhado.

Requisitos de usuário são definidos usando uma linguagem simples, tabelas e diagramas quando estes podem ser compreendidos por todos os usuários.

Diretrizes para Escrever Requisitos

Inventar um formato padrão e usá-lo para todos os requisitos.
Usar a linguagem de uma forma consistente. Use ‘deve’ para requisitos obrigatórios, e ‘deveria’ para requisitos desejáveis.
Realçar o texto para identificar as partes principais do requisito.
Evitar o uso de jargões de computação.

Requisitos de Sistema

Mais especificações detalhadas das funções do sistema, dos serviços e das restrições do que requisitos de usuário.

Eles pretendem ser uma base para o desenvolvimento do projeto de sistema.
Eles podem ser incorporados no contrato de sistema.

Requisitos de sistema podem ser definidos ou ilustrados usando modelos de sistema discutidos no Capítulo 8.

Requisitos e Projeto

Em princípio, requisitos devem definir o que o sistema deve fazer e o projeto deve descrever como ele faz isto.

Na prática, requisitos e projeto são inseparáveis:

Uma arquitetura de sistema pode ser projetada para estruturar os requisitos;
O sistema pode interoperar com outros sistemas que geram requisitos de projeto;
O uso de um projeto específico pode ser um requisito de domínio.

O Documento de Requisitos

O documento de requisitos é a declaração oficial do que é requisitado pelos desenvolvedores do sistema.

Deve incluir ambos: uma definição dos requisitos de usuário e uma especificação dos requisitos de sistema.

NÃO é um documento de projeto. É crucial definir O QUÊ o sistema deve fazer ao invés de COMO deve ser feito.

Projeto de Interface de Usuário (UI)

A Interface de Usuário

As interfaces de usuário devem ser projetadas para atender às habilidades, experiências e expectativas dos seus usuários previstos.

Os usuários do sistema frequentemente julgam um sistema pela sua interface ao invés de sua funcionalidade.

Uma interface fracamente projetada pode levar um usuário a cometer erros catastróficos.

Projeto fraco de interface com usuário é a razão pela qual muitos sistemas de software nunca são usados.

Fatores Humanos no Projeto de Interface

Memória Limitada de Curto Prazo: As pessoas podem se lembrar instantaneamente de sete itens de informação. Se você apresentar mais que isso, elas podem cometer erros.
As Pessoas Cometem Erros: Quando as pessoas cometem erros e os sistemas não funcionam direito, alarmes e mensagens inapropriados podem aumentar o estresse e, consequentemente, a probabilidade de mais erros.
As Pessoas São Diferentes: As pessoas têm uma faixa variada de capacidades físicas, por isso os projetistas não devem desenvolver projetos somente para suas próprias capacidades.
As Pessoas Têm Preferências Diferentes de Interação: Alguns gostam de figuras, outros, de textos.

Princípios de Projeto de UI

Um projeto de UI deve levar em conta as necessidades, experiências e capacidades dos usuários do sistema.

Os projetistas devem estar cientes das limitações físicas e mentais das pessoas (por exemplo, memória limitada de curto prazo) e devem reconhecer que as pessoas cometem erros.

Os princípios de projeto de UI apoiam os projetos de interface, embora nem todos os princípios sejam aplicáveis a todos os projetos.

Princípios de Projeto de UI Detalhados

Familiaridade do Usuário: A interface deve ser baseada em termos e conceitos de orientação a objetos, ao invés de conceitos de computador. Por exemplo, um sistema de escritório deve usar conceitos, tais como cartas, documentos, folhetos, etc., ao invés de diretórios, identificadores de arquivos, etc.
Consistência: O sistema deve apresentar um nível de consistência apropriado. Comandos e menus devem ter o mesmo formato, a pontuação de comandos deve ser similar, etc.
Surpresa Mínima: Se um comando opera em modo conhecido, o usuário deve ser capaz de prever a operação de comandos comparáveis.
Facilidade de Recuperação: O sistema deve fornecer alguma resistência a erros do usuário e permitir que o usuário se recupere de erros. Isso poderia incluir um recurso de ‘refazer’, confirmação de ações destrutivas, deletes fracos, etc.
Guia do Usuário: Alguns guias de usuários, como sistemas de help, manuais on-line, etc., devem ser fornecidos.
Diversidade do Usuário: Recursos de interação para tipos diferentes de usuários devem ser apoiados. Por exemplo, alguns usuários têm dificuldades de visão e, assim, textos maiores devem estar disponíveis.

Tópicos de Projeto em UI

Dois problemas devem ser considerados em um projeto de sistemas iterativos:

Como as informações do usuário devem ser fornecidas para o sistema de computador?
Como as informações do sistema de computador devem ser apresentadas para o usuário?

Interação de usuário e apresentação de informações podem ser integradas por meio de um framework coerente, tal como uma metáfora de interface de usuário.

Estilos de Interação

Manipulação Direta;
Seleção de Menu;
Preenchimento de Formulários;
Linguagem de Comando;
Linguagem Natural.

Apresentação de Informações

Informações Estáticas: Iniciam no começo de uma sessão e não mudam. Podem ser numéricas ou textuais.
Informações Dinâmicas: As mudanças durante uma sessão devem ser comunicadas ao usuário do sistema. Podem ser numéricas ou textuais.

Processo de Projeto de UI

O projeto de UI é um processo iterativo que envolve estreita cooperação entre usuários e projetistas.

As três atividades centrais nesse processo são:

Análise de Usuário: Compreender o que os usuários farão com o sistema;
Prototipação de Sistema: Desenvolver uma série de protótipos para experimento;
Avaliação de Interface: Experimentar esses protótipos com usuários.

Análise de Usuário

Se você não compreender o que os usuários querem fazer com o sistema, não terá uma perspectiva realista de projeto de uma interface eficiente.

As análises de usuário têm de ser descritas em termos que os usuários e os outros projetistas possam compreender.

Cenários, onde você descreve episódios típicos de uso, são uma maneira de descrever estas análises.

Requisitos de um Cenário

Os usuários podem não estar conscientes dos termos de busca apropriados. Pode ser necessário acessar ajuda quanto à escolha de termos de busca.
Os usuários têm de ser capazes de selecionar conjuntos para busca.
Os usuários precisam ser capazes de conduzir buscas e solicitar cópias de material relevante.

Técnicas de Análise de Usuário

Análise de Tarefa: Modela os passos envolvidos na realização de uma tarefa.
Entrevistas e Questionários: Questiona os usuários sobre o trabalho que eles fazem.
Etnografia: Observa o usuário no trabalho.

Prototipação de Interface de Usuário

O objetivo da prototipação é permitir que os usuários ganhem experiência direta com a interface.

Sem tal experiência direta, é impossível julgar a usabilidade de uma interface.

A prototipação pode ser um processo de dois estágios:

No início do processo, protótipos de papel podem ser usados;
O projeto é refinado e, cada vez mais, sofisticados protótipos automatizados são desenvolvidos.

Prototipação de Papel

Trabalhar através dos cenários usando rascunhos da interface.

Usar um storyboard para apresentar uma série de interações com o sistema.

A prototipação de papel é uma maneira eficaz de obter reações do usuário para uma proposta de projeto.

Storyboard: série de esboços que ilustram uma sequência de interações.

Técnicas de Prototipação

Prototipação Dirigida a Scripts: Desenvolver um conjunto de scripts e telas. Quando o usuário interage com essas telas, o script é executado, e a próxima tela é apresentada.
Programação Visual: Usar uma linguagem projetada para desenvolvimento rápido, tal como o Visual Basic.
Prototipação Baseada na Internet: Usar um Web browser e scripts associados.

Avaliação de Interface de Usuário

A avaliação de um projeto de interface de usuário deve ser realizada para avaliar a sua adequabilidade.

A avaliação completa é muito dispendiosa e impraticável para a maioria dos sistemas.

Preferencialmente, uma interface deve ser avaliada em relação a uma especificação de usabilidade. Contudo, é raro tais especificações serem produzidas.

Técnicas Simples de Avaliação

Questionários para feedback do usuário.
Registro em vídeo do uso do sistema e avaliação subsequente da fita.
Instrumentalização do código para coletar informações sobre a facilidade de uso e os erros do usuário.
A inclusão de código no software para coletar feedback on-line do usuário.

Pontos-Chave

Os princípios de interface de usuário devem ajudar a guiar o projeto de interfaces de usuário.
Estilos de interação incluem manipulação direta, sistemas de menus, preenchimento de formulários, linguagens de comando e linguagem natural.
Os displays gráficos devem ser usados para apresentar tendências e valores aproximados. Displays digitais devem ser usados somente quando precisão é necessária.
As cores devem ser usadas cuidadosa e consistentemente.
O processo de projeto de interface de usuário envolve análise de usuário, prototipação de interfaces e avaliação de interfaces.
O objetivo da análise de usuário é sensibilizar os projetistas para os meios em que os usuários realmente trabalham.
A prototipação de UI deve ser um processo por estágios, com protótipos de papel usados no início como uma base para protótipos automatizados da interface.
Os objetivos da avaliação de UI são obter feedback sobre como melhorar o projeto de interface e avaliar se a interface atende aos seus requisitos de usabilidade.

Entradas relacionadas:

Etiquetas: