Departamento de Ciências Sociais Aplicadas – DCSA

Universidade Regional Integrada do Alto Uruguai e das Missões - URI
Reconhecida pela Portaria Ministerial nº 708 de 19/05/92 - D.O.U. de 21/05/92
Mantida pela Fundação Regional Integrada – FuRI
Conceitos e Princípios da Análise:
Entender os requisitos específicos que precisam ser satisfeitos para construir software de alta qualidade.
o Passos:
 Requisitos de dados, funcionais e comportamentais são identificados pela elicitação da
informação do cliente.
 Requisitos são refinados e analisados para avaliar sua clareza, completeza e consistência.
 Uma especificação que incorpora um modelo do software é criada e depois validada tanto
pelos engenheiros de software quanto pelos clientes/usuários.
o Qualidade:
Os produtos de trabalho da análise de requisitos de software devem ser revistos quanto à clareza,
completeza e consistência.
o Elicitação de Requisitos:
o Princípios da Análise:
 O domínio da informação de um problema precisa ser representado e entendido;
 As funções a serem desenvolvidas pelo software devem ser definidas;
 O comportamento do software (como conseqüência de eventos externos) precisa ser
representado;
 Os modelos que mostram informação, funções e comportamento devem ser particionados de
um modo que revele detalhes em forma de camadas (ou hierarquias);
 O processo de análise deve ir da informação essencial até o detalhe de implementação.
o Especificação
 Separe funcionalidade de implementação;
 Desenvolva um modelo do comportamento desejado do sistema que abranja os dados e as
respostas funcionais a vários estímulos do ambiente;
 Estabeleça o contexto no qual o software opera, especificando o modo pelo qual outros
componentes do sistema interagem com o software;
 Defina o ambiente no qual o sistema opera e indique como “uma coleção altamente
entrelaçada de agentes reage a estímulos do ambiente (modificações em objetos) produzidas
por esses agentes”;
 Crie um modelo cognitivo ao invés de um modelo de projeto ou implementação. O modelo
cognitivo descreve um sistema como ele é percebido pela sua comunidade de usuários;
 Reconheça que “as especificações devem ser tolerantes à incompleteza e ampliáveis;
 Estabeleça o conteúdo e a estrutura de uma especificação de modo que ela possa ser
facilmente modificada.
o Revisão da Especificação.
Conceitos e Princípios de Projeto
Engenharia de Software II (30-710) – Prof. M. Sc. Paulo Ricardo B. Betencourt
Fonte: [4] da referência bibliográfica da disciplina – Aulas nº 2 e 3 do Programa
Universidade Regional Integrada do Alto Uruguai e das Missões - URI
Reconhecida pela Portaria Ministerial nº 708 de 19/05/92 - D.O.U. de 21/05/92
Mantida pela Fundação Regional Integrada – FuRI
(mais informações em http://www.dacs.dtic.mil/techs/design/contemporary.shtml#RTFToC35)
É uma representação de Engenharia de algo que vai ser construído. Ele pode ser delineado para os
requisitos do cliente e ao mesmo tempo avaliado quanto à qualidade, com base num conjunto de critérios
predefinidos para o “bom” projeto. Focaliza: dados, arquitetura, interfaces e componentes.
o Passos:
 O projeto tem início com um modelo de requisitos. Trabalhamos para transformar esse modelo
em quatro níveis de detalhe de projeto: a estrutura de dados, a arquitetura do sistema, a
representação da interface e o detalhe a nível de componente.
o Diretrizes de projeto:
 Um projeto deve exibir uma estrutura arquitetural que (1) tenha sido criada usando padrões de
projeto reconhecíveis, (2) seja composta de componentes que exibam boas características de
projeto, e (3) pode ser implementada de modo evolucionário;
 Um projeto deve ser modular;
 Um projeto deve conter representações distintas dos dados, arquitetura, interfaces e
componentes (módulos);
 Um projeto deve levar a estruturas de dados adequados aos objetivos a serem implementados
e baseadas em padrões de dados reconhecíveis;
 Um projeto deve levar a componentes que exibem características funcionais independentes;
 Um projeto deve levar a interfaces que reduzam a complexidade das conexões entre módulos
e com o ambiente externo;
 Um projeto deve ser derivado usando um método passível de repetição que seja baseado na
informação obtida durante a análise dos requisitos do software.
o Princípios do Projeto:
 O processo do projeto não deve ser “bitolado”;
 O projeto deve ser relacionável ao modelo de análise;
 O projeto não deve reinventar a roda;
 O projeto deve “minimizar a distância intelectual” entre o software e o problema, tal como
existe no mundo real;
 O projeto deve exibir uniformidade e integração;
 O projeto deve ser estruturado para acomodar modificações;
 O projeto não é codificação, codificação não é projeto;
 O projeto deve ser avaliado quanto à qualidade, à medida que é criado, não depois do fato;
 O projeto deve ser revisto para minimizar erros conceituais (semânticos).
Engenharia de Software II (30-710) – Prof. M. Sc. Paulo Ricardo B. Betencourt
Fonte: [4] da referência bibliográfica da disciplina – Aulas nº 2 e 3 do Programa