Modelagem de Sistemas de Informações
242 pág.

Modelagem de Sistemas de Informações


DisciplinaEngenharia de Software I7.128 materiais70.913 seguidores
Pré-visualização50 páginas
forma, se o problema for a 
dificuldade de utilização, a meta pode ser facilitar a utilização do sistema e as métricas 
podem estar relacionadas ao tempo de aprendizado ou ao número de erros na entrada de 
dados. 
V.9 Visão do novo sistema 
Devemos tentar responder como vai funcionar o novo sistema em uma descrição 
simples, em linguagem corrente. Chamamos essa descrição de Visão do novo sistema. Essa 
visão deve ser escrita com forte apoio do cliente, senão pelo próprio cliente. 
Normalmente a Visão e a descrição do sistema atual têm o mesmo nível de abstração 
dentro de uma mesma proposta inicial. 
A visão pode incluir o protótipo de algumas telas do novo sistema, com a finalidade 
de mostrar a diferença do sistema novo para o velho ou ainda mostrar como será o 
comportamento de uma nova finalidade. 
A visão do sistema pode incluir não só o funcionamento do sistema, mas também 
expectativas de comportamento e de efeitos do sistema no negócio. Deve ficar claro que a 
visão do sistema é uma declaração do usuário, não necessariamente um comprometimento do 
desenvolvedor. Isso, porém, deve ficar claro na documentação. 
A visão do sistema inclui também os requisitos já detectados, informalmente, pelo 
analista. Como descrito no capítulo anterior esses requisitos podem ser divididos em 
requisitos funcionais, requisitos de informação e requisitos não funcionais. Obviamente só 
estamos interessados em requisitos verdadeiros. 
V.9.1 Oportunidades para o novo sistema 
Devemos incluir em nossa proposta oportunidades que detectamos a partir do nosso 
conhecimento do que é factível atualmente ou em futuro próximo. 
As oportunidades que detectamos para um novo sistema estão normalmente ligadas a 
novas tecnologias ainda não utilizadas pelos clientes. 
V.9.2 Pontos Críticos ou Pontos Chave 
Os pontos críticos (ou chave) de sucesso para um projeto são aquelas questões que, 
não estando diretamente relacionada ao desenvolvimento propriamente dito, são essenciais 
para o bom andamento do projeto. 
Exemplos: compromisso de certos funcionários, fornecimento de certa informação, 
chegada de alguma máquina ou software, compromisso de entrega de dados ou equipamentos 
pelo cliente, etc. 
Os pontos críticos devem ser levantados detalhadamente, pois os compromissos do 
desenvolvedor só poderão ser cumpridos caso sejam resolvidos satisfatoriamente. 
 
10
 Sistema operacional simples antecessor do Microsoft Windows. 
 66 
V.9.3 Restrições 
Muitos sistemas têm restrições, que devemos considerar em nossas propostas. Um 
tipo importante de restrições são as exigências de implementação, como banco de dados, 
linguagem, sistema operacional, etc. 
Quanto mais cedo forem detectadas as restrições, mais cedo o analista evitará que haja 
desperdício de recursos pela equipe de desenvolvimento. 
V.10 Construindo um Glossário 
Uma das atividades mais importantes da análise é compreender o domínio da 
aplicação. Essa compreensão só pode acontecer se o analista souber o significado exato das 
palavras típicas do negócio do cliente. Assim, desde o início da análise o analista deve 
construir um glossário, ou seja, um dicionário especializado nos termos do negócio do 
cliente. 
Não podemos enfatizar demais a importância de aprender a linguagem do negócio do 
cliente. Isso não só facilita a comunicação como dá ao cliente uma confiança maior no 
analista. 
V.11 Proposta Comercial 
Se necessário, a proposta inicial se encerra com os termos comerciais sendo propostos 
ao cliente, incluindo preço, tempo de desenvolvimento, formas de cobranças, etc. 
É de praxe no mercado, apesar de não recomendado, o cliente aceitar uma proposta e 
dispensar a assinatura de um contrato ou discutir os termos legais do contrato enquanto se 
inicia o trabalho de análise. 
V.11.1 Calculando Preço e Custo 
Antes de começar essa discussão, devemos deixar clara a diferença entre preço e 
custo: preço é o que cobramos para fazer um sistema, custo é quanto gastamos para 
desenvolvê-lo. 
Não é razoável ensinar como calcular o preço de um sistema em um curso de análise, 
pois esse é um problema de mercado, não um problema de desenvolvimento de sistemas. O 
que um analista pode fazer é calcular o custo de desenvolvimento11 de um sistema. 
Apenas no final de um projeto temos certeza absoluta do custo que tivemos para 
desenvolvê-lo. Até lá, o que podemos fazer é levantar, de forma mais ou menos educada, uma 
previsão de custos para o projeto. Essa previsão deve ser atualizada constantemente enquanto 
o projeto caminha. 
Devemos compreender que o grande fator de custo no desenvolvimento de um 
software é a mão de obra. Normalmente esse custo é levantado em homem-hora ou homem-
mês. O uso dessa mão de obra é proporcional12 a complexidade do projeto, fruto de seu 
tamanho e de suas exigências operacionais ou funcionais. 
Existem várias técnicas de previsão do tamanho de um sistema. No capítulo \u201cQual o 
tamanho do software\u201d estudaremos algumas dessas técnicas. Na prática, porém, devemos 
 
11
 E ainda implantação, manutenção e operação. 
12
 De forma exponencial 
 67 
compreender que a maioria das empresas ainda as desconhece ou não as implementa. Nesse 
caso, elas acabam utilizando a experiência de seus funcionários para, informalmente, fazer 
previsões que normalmente se mostram pouco acuradas. 
Quanto ao preço, podemos fazer algumas observações. A primeira é que não há 
necessariamente uma relação direta entre custo e preço. Apesar de muitas empresas de 
desenvolvimento fazerem uma previsão de custo e calcularem o preço em cima dessa 
previsão, usando margens de lucro e de risco previamente acordadas, o verdadeiro preço vem 
do valor de mercado do produto, ou ainda do ganho previsto. Isso pode inclusive ser uma boa 
oportunidade de negócios. Muitas empresas, ao perceberem que um produto específico vai 
dar um lucro direto ao seu cliente, propõem fazer esse produto de graça em troca de um 
percentual sobre o lucro. Em longo prazo isso pode ser altamente vantajoso para a empresa de 
desenvolvimento, enquanto que para o cliente pode ser a única forma de conseguir um 
sistema que exigiria um investimento inicial muito alto para seu caixa. 
V.12 O Resumo Executivo 
O resumo executivo deve permitir que o leitor tenha uma visão completa do texto do 
documento em uma página. Resumos executivos têm esse nome por partir da hipótese que 
um executivo, ao tomar uma decisão, não tem tempo para ler longos documentos. Na prática 
eles leriam o resumo executivo e folheariam os documentos. 
 
Se você nunca fez análise de sistemas, essa proposta pode parecer 
difícil demais. Isso acontece porque para fazer a proposta inicial 
devemos fazer, de maneira extremamente simplificada, uma análise 
de sistema. 
V.13 Estrutura da Proposta Inicial 
Uma proposta de trabalho pode se configurar de várias formas, em função de que 
pontos desejamos ressaltar ou em que ordem desejamos apresentá-la. A seguir apresentamos 
uma estrutura possível para uma proposta inicial que uma empresa de desenvolvimento de 
software poderia fazer para um cliente. 
\u2022 Resumo Executivo 
\u2022 Apresentação do Documento 
\u2022 Identificação do Projeto 
o Objetivo13 
o Identificação do Cliente 
o Identificação do Prestador de Serviço 
o Histórico do Apresentador de Serviço 
\u2022 Proposta Técnica 
o Pequena Descrição da Solicitação do Cliente 
 
13
 O Objetivo do projeto é implementar o sistema, que tem um objetivo para cumprir no negócio. 
 68 
o Descrição Sucinta do Sistema Atual 
o Stakeholders 
o Identificação de Problemas 
o Descrição do Sistema Proposto 
\ufffd Objetivo do Sistema 
\ufffd Objetivos de Negócios e Interesses 
\ufffd Metas 
\u2022 Métricas