ESTUDO DE VIABILIDADE DE SOFTWARE

O estudo da viabilidade de um projeto de software é o ponto de partida para a criação do relatório de viabilidade e
obtenção dos requisitos. É uma visão geral do sistema e de como ele será utilizado dentro de uma organização.
O estudo de viabilidade envolve áreas distintas em suas análises:
VIABILIDADE OPERACIONAL: mede o grau de adequação da solução para a organização. É também uma avaliação
de como as pessoas se sentem sobre ele. Performance: tempo de respostas adequados; informação: o modo de
operação atual oferece informação rápida e confiáveis aos gestores; economia: relação entre custo e eficiência;
controle: controle eficiente para evitar fraudes; eficiência: extrair o máximo da capacidade das pessoas envolvidas;
serviço: oferece serviço confiável.
VIABILIDADE ECONÔMICA: analisa o custo do desenvolvimento com a renda ou benefícios do sistema depois de
pronto. O sistema será construído internamente ou fora da organização, será necessário comprar hardware,
implantação, treinamento, contratação, licenças de software, etc.
VIABILIDADE DE CRONOGRAMA: é uma avaliação de quão razoável está o cronograma do projeto. Apresentar
análise dos impactos do não cumprimento dos marcos estabelecidos no cronograma.
VIABILIDADE TÉCNICA: analisa a função, o desempenho e as restrições que podem interferir na produção do
sistema. A solução proposta pelo novo projeto é prática? o cronograma está razoável? Os prazos devem ser
identificados como desejáveis ou obrigatórios.
VIABILIDADE LEGAL: analisa o sistema a ser desenvolvido em relação às leis vigentes;
A VIABILIDADE TÉCNICA ENVOLVE: Riscos do desenvolvimento: o projeto pode ser desenvolvido dentro das
restrições iniciais? disponibilidade de recursos: físicos, hardware, software, etc. tecnologia: as tecnologias
necessárias ao desenvolvimento do projeto estão disponíveis?
A viabilidade legal inclui: contratos; responsabilidade legal;

MODELOS DE PROCESSOS DE SOFTWARE

MODELO SEQUENCIAL LINEAR:

O modelo sequencial linear é um modelo de desenvolvimento de software que começa no nível de sistema e progride,
de maneira sequencial, através da análise, projeto, codificação, teste e manutenção. Modelado segundo um ciclo
convencional de engenharia, o modelo sequencial linear abrange as seguintes atividades:

ANÁLISE E ENGENHARIA DE SISTEMAS: envolve a coleta de requisitos em nível do sistema, pequena quantidade
de projeto e análise de alto nível.
ANÁLISE DE REQUISITOS DE SOFTWARE: processo de coleta dos requisitos é intensificado e concentrado
especificamente no software.
PROJETO: tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto
à qualidade, antes que a codificação se inicie.
CODIFICAÇÃO: tradução das representações do projeto para uma linguagem “artificial” resultando em instruções
executáveis pelo computador.
TESTES: Concentram-se nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido
testadas.
MANUTENÇÃO: o software deverá sofrer mudanças depois que for entregue ao cliente por conta de erros, adaptação
do software e de desempenho.

MODELO DE PROTOTIPAGEM:

Nesse modelo de processo de software constrói-se um protótipo, um modelo executável de como será um software.
Esse protótipo é construído de maneira rápida, não há preocupação com a sua qualidade, por exemplo. Dessa forma,
esse protótipo deveria ser, em tese, descartado.

PROTOTIPAÇÃO - Obtenção dos Requisitos início: desenvolvedor e cliente definem os objetivos gerais do software,
identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais

1
Projeto Rápido: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e
formatos de saída)

Construção Protótipo: implementação rápida do projeto

Avaliação do Protótipo :cliente e desenvolvedor avaliam o protótipo

Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido.
Ocorre neste ponto um processo de iteração

Construção Produto fim: identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser
construída considerando os critérios de qualidade.

Protótipos de Baixa Fidelidade: Desenhados geralmente à mão utilizando lápis, borracha e papel, essas
representações são feitas de maneira rápida e superficial, apenas margeando a ideia do projeto e definindo
superficialmente sua interação com o usuário, não se preocupando ainda com elementos de layout, cores, disposições,
etc.

Protótipos de Média Fidelidade: Utilizando lápis e papel ou softwares de prototipação, como o Balsamiq ou Axure,
esses documentos apresentam a estrutura e o conteúdo da interface, definindo peso, relevância e relação dos
elementos, formando o layout básico do projeto.

Protótipos de Alta Fidelidade: Os mockups ou protótipos funcionais constituem a representação mais próxima do
sistema a ser desenvolvido. Em alguns casos, é possível simular o fluxo completo das funcionalidades, permitindo a
interação do usuário como se fosse o produto final.

MODELOS DE PROCESSOS DE SOFTWARE EVOLUCIONÁRIOS:

Os modelos evolucionários são utilizados quando os sistemas que serão desenvolvidos evoluirão com certo período de
tempo. Eles são interativos e caracterizados de forma a permitir aos engenheiros de software desenvolver versões cada
vez mais completas do software.

Modelo Incremental: Esse modelo combina aspectos do modelo sequencial linear com a filosofia interativa da
prototipagem. Sequencias lineares são aplicadas e, ao final, elas produzem um incremento.

Modelo espiral: Combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo
sequencial linear. Fornece potencial para o desenvolvimento rápido de versões incrementais do software, onde os
primeiros incrementos podem ser modelos de papel ou protótipos, mas já nas últimas iterações são produzidas versões
incrementais cada vez mais completas.

Um modelo espiral é dividido em regiões de tarefas. Tipicamente, há de três a seis regiões de

tarefas: Comunicação com o cliente – tarefas necessárias para estabelecer uma comunicação efetiva entre
desenvolvedor e cliente. Planejamento – tarefas que definirão informações como recursos e prazos. Análise de
risco – tarefas que analisarão os riscos técnicos e gerenciais. Engenharia – tarefas necessárias para construir
representações da aplicação. Construção e liberação – tarefas necessárias para construir, testar, instalar e fornecer
apoio ao usuário. Avaliação pelo cliente – tarefas necessárias para obter realimentação do cliente.

TÉCNICAS DE 4AGERAÇÃO:

Técnicas de 4aGeração: Concentra-se na capacidade de se especificar o software a uma máquina em um nível que
esteja próximo à linguagem natural. Engloba um conjunto de ferramentas de software que possibilitam que o sistema
seja especificado em uma linguagem de alto nível e o código fonte seja gerado automaticamente a partir dessas
especificações.

OBTENÇÃO DOS REQUISITOS: o cliente descreve os requisitos os quais são traduzidos para um protótipo
operacional
2
ESTRATÉGIA DE "PROJETO": para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos
para o passo de Implementação usando uma Linguagem de 4G
IMPLEMENTAÇÃO USANDO 4GL: os resultados desejados são representados de modo que haja geração automática
de código. Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL
TESTE: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido
deve ser construído de maneira que a manutenção possa ser efetuada prontamente.
COMENTÁRIOS: Proponentes: redução dramática no tempo de desenvolvimento do software (aumento de
produtividade); Oponentes: as 4GL atuais não são mais fáceis de usar do que as linguagens de programação

ENGENHARIA DE REQUISITOS

ESTUDOS DE VIABILIDADE O estudo de viabilidade deverá contemplar a produção de um relatório e deverá

determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e
organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível.
O que é engenharia de requisitos? é um processo que engloba todas as atividades que contribuem para a produção
de um documento de requisitos e sua manutenção ao longo do tempo.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível : identificação, análise e
negociação, especificação e documentação, validação

IDENTIFICAÇÃO
IDENTIFICAÇÃO: caso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos.um bom
levantamento de requisitos começa sempre pela seleção das melhores fontes de informação que serão usadas para
montar a matriz de requisitos, que será matéria-prima para definir o escopo do projeto

TÉCNICAS PARA LEVANTAMENTO DE REQUISITOS (PRINCIPAIS)

ENTREVISTASE QUESTIONÁRIOS entrevistas e questionários é talvez a técnica mais simples de utilizar. Ainda que
seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas),

WORKSHOPS DE REQUISITOS o workshop de requisitos consiste numa técnica usada através de uma reunião
estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente, para então obter um
conjunto de requisitos bem definidos. Ao contrário das reuniões, promove-se a interação entre todos os elementos
presentes no workshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe,

CENÁRIOS (SÉRIE DE EVENTOS HIPOTÉTICOS) uma forma de levar as pessoas a imaginarem o comportamento de
um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus
usuários podem comentar acerca do seu comportamento e da interação que esperam ter com ele.

PROTOTIPAGEM o uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por
exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda
pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão
facilmente identificáveis.

ESTUDOETNOGRÁFICO os estudos etnográficos são uma análise de componente social das tarefas desempenhadas
numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se esperar que
esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar
a cabo. Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário
é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais.

ANÁLISE E NEGOCIAÇÃO DOS REQUISITOS

ANÁLISE E NEGOCIAÇÃO DOS REQUISITOS:

Classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para
o sistema;

3
Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura
e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes
conflitos o mais breve possível;
Priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa);
obviamente, este pode ser um fator gerador de conflitos;
Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de
acordo com o que se pretende do sistema).

ESPECIFICAÇÃO E DOCUMENTAÇÃO

Especificação e documentação Fase onde é realizada de fato a produção do documento de especificação de

requisitos.
REQUISITOS FUNCIONAIS: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma
completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o
sistema será desenvolvido

REQUISITOS NÃO-FUNCIONAIS: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o
sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em requisitos não-funcionais de:
utilidade, confiança, desempenho, suporte e escalabilidade.

PODEM-SE DISTINGUIR TRÊS TIPOS DE ESPECIFICAÇÃO: especificação de requisitos do usuário ou utilizador;

especificação de requisitos do sistema; especificação do design da aplicação.

REQUISITOS DO USUÁRIO OU UTILIZADOR: descreve as funções e restrições do sistema de forma abstrata e deve
ser inteligível pelo usuário / cliente.

ESPECIFICAÇÃO DE REQUISITOS DO SISTEMA: devem ser padronizados, completo se consistentes, usados pela
equipe de desenvolvimento, fazem parte do contrato.

ESPECIFICAÇÃO DO DESIGN DA APLICAÇÃO: a especificação do design da aplicação consiste num documento

usado pela equipe de desenvolvimento do sistema no qual estão definidos pormenores, em um nível mais técnico,
acerca da implementação do sistema e sua arquitetura.

DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS

STAKEHOLDERS
CLIENTES: confirmar a completude dos requisitos e propor alterações.
GESTORES: orçamentar o sistema e planejar o processo de desenvolvimento.
ENGENHEIROS: compreender o sistema a desenvolver.
ENGENHEIROS (TESTES): desenvolver testes para validar o cumprimento dos requisitos.
ENGENHEIROS (MANUTENÇÃO): compreender o sistema e a ligação entre as suas partes.

VALIDAÇÃO nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao
sistema que o cliente pretende

O QUESÃO SISTEMAS? um grupo de itens que interagem entre si ou que sejam interdependentes, formando um todo
unificado.

TIPOS DE SISTEMAS

SISTEMAS NATURAIS: escalares: galáxia, sistema solar, etc.…

SISTEMAS FEITOS PELO HOMEM: sistemas sociais: organização de leis, costumes, “regras”.
Sistemas de comunicação: telefone, correios, sinais de fumaça, etc. Sistemas automatizados: hardware, software,
pessoas, etc. sistema de tempo real, sistemas de apoio a decisão, sistemas baseados em conhecimento, e outros…

4
.
SISTEMAS QUE FAZEM PARTE DE OUTRO SISTEMA: EX. DE SISTEMA – carro ex. de subsistema de carro:
sistema de freios, sistema elétrico, sistema de arrefecimento.

SISTEMAS QUE GERAM INFORMAÇÃO!!!

SISTEMAS DOS QUAIS PODEMOS EXTRAIR INFORMAÇÃO

DEFINIÇÃODE SOFTWARE: software é uma sequência de instruções escritas para serem interpretadas por um
computador como objetivo de executar tarefas específicas. Também pode ser definido como os programas que
comandam o funcionamento de um computador

TIPOS DE SOFTWARE

SOFTWARE DE SISTEMA: S.O.: WINDOWS, LINUX, OSX, ANDROID…

SOFTWARE DE PROGRAMAÇÃO: NETBEANS, ECLIPSE, XCODE, DELPHI, ETC…
SOFTWARE DE APLICAÇÃO: PHOTOSHOP, MS.OFFICE, STEAM, ETC…

A CRISEDE SOFTWARE: refere-se a um conjunto de problemas encontrados no desenvolvimento de software e na

etapa de manutenção dos softwares desenvolvidos

PERSONAS: são personagens fictícios criados para representar os diferentes tipos de usuário dentro de um alvo
demográfico, atitude e/ou comportamento definido que poderia utilizar um site, uma marca ou produto de um modo
similar.

Questionário

1) “A engenharia de requisitos (no contexto da engenharia de software) é um processo que engloba todas as atividades
que contribuem para a produção de um documento de requisitos e sua manutenção de longo tempo”. Considerando
esta afirmação, quais as quatro principais atividades de alto nível que compõem o processo de engenharia de
requisitos?
B) Identificação; analise e negociação; especificação e documentação; validade.

2)” [...] Quando dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se esperar que esta sinta dificuldade
em articular todos os passos que segue, ou todas as pessoas com as quais interagir[...]”. Com base na dificuldade
citada a obtenção de requisitos mais realistas e de difícil coleta?
E) Estudo Etnográfico

3) A atividade de resolução de conflitos pertence à qual processo da engenharia de requisitos?

E) Análise e Negociação dos Requisitos

4) O documento de especificação de requisitos possui diferentes utilidades para diferentes pessoas. Qual pessoa utiliza
documento de especificação de requisitos para compreender o sistema e a ligação entre as suas partes?
C) Engenheiro (manutenção)

5) Durante a fase de validação na engenharia de requisitos devem ser verificados (através de checklists) alguns
atributos dos requisitos identificados. Qual destes atributos contempla evitar futuras discordância quanto a
concretização dos requisitos especificados, estes que devem ser descritos de modo que seja possível verificar se foram
ou não concretizados, isto é, se o sistema final corresponde à especificação inicial?
D) Verificabilidade

6) Descreva de forma objetiva qual a relevância do estudo de viabilidade na engenharia de requisitos.

R: O estudo de viabilidade deverá contemplar a produção de um relatório e deverá determinar a continuação do
desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e
definindo mesmo alguns requisitos de alto nível.

7) Explique o que são requisitos funcionais e Requisitos não-funcionais

5
R: Requisitos funcionais descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma
completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o
sistema será desenvolvido.
Requisitos não-funcionais referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema
deve operar ou propriedades emergentes do sistema. Costumam ser divididos em requisitos não-funcionais de:
utilidade, confiança, desempenho, suporte e escalabilidade.

8) Para um sistema computacional com um total de 220 pontos de função já ajustados estimados.
A) Considerando um time onde cada programador é capaz de fazer 4 pontos de função por hora trabalhada, de quantos
programadores e preciso para entregar o projeto estimado em 3 meses?
Esforço = 4 * 220
Esforço = 880
66 = 880(x * 6)
396X = 880
880
x¿ x = 2,2 = 3 interações
396
B) Considerando que o custo da hora trabalhada de cada programador acima seja R$20,00, qual o custo estimado do
software?
Custo = esforço * valor hora
Custo = 880* R$20,00
Custo = R$17600,00

APF – Análise de Pontos de Função

APF – Utilizado para estimar o tamanho funcional de um projeto de software.

Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do
IFPUG (IFPUG, 2005)

Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando
métodos diferentes da Contagem de Pontos de Função do IFPUG.

ALI (Arquivo Lógico Interno): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação).

AIE (Arquivo de Interface Externa): Banco de Dados de outras Aplicações, apenas referenciados pela aplicação que
está sendo estimada (tabelas e arquivos mantidos por outra aplicação).

EE (Entrada Externa): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento
da aplicação.

CE (Consulta Externa): funcionalidades que apresentam informações para o usuário sem a utilização de cálculos ou
algoritmos. São os processos elementares do tipo “lê - imprime”, “lê - apresenta dados”, incluindo consultas, relatórios,
geração de disquetes ou CDs, downloads, entre outros.

SE (Saída Externa): Funcionalidades que apresentam informações para o usuário com utilização de cálculos ou

algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da
aplicação. São as consultas ou relatórios com totalização de dados, relatórios estatísticos, gráficos