Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Um processo de software – conjunto de atividades e resultados associados que geram um produto Existem também os custos de evolução (manutenção), alteração do software depois que foi
de software. Essas atividades são, em sua maioria, executadas por desenvolvedores sistemas.. colocado em uso.
Há 4 atividades fundamentais no processo de software: 0 25 50 100
1. Especificação do Software – definição de requisitos e análise de requisitos - a
funcionalidade do software e as restrições em sua operação devem ser definidas. Desenvolvimento Evolução do Sistema
2. Desenvolvimento do Software – projeto e implementação - o software deve ser produzido de
modo que atenda a suas especificações.
3. Validação do software – integração e teste - o software tem de ser validado para garantir que
ele faz o que o cliente deseja. O que é uma CASE – Computer-aided software engineering – refere-se a uma ampla gama de
4. Evolução do software – o software deve evoluir para atender às necessidades mutáveis do diferentes tipos de programas utilizados para apoiar as atividades de processo de software, como
cliente. análise de requisitos, a modelagem de sistemas, a depuração e os testes.
Ferramentas CASE podem também incluir um gerador de códigos que, automaticamente, origina
MODELO DE PROCESSO DE SOFTWARE código fonte a partir do modelo de sistema e alguma orientação de processo.
É a descrição simplificada de um processo de software, que é apresentada a partir de uma Upper-CASE – destinada a dar apoio à análise e ao projeto. (apoio às fases iniciais)
perspectiva específica. Os modelos são abstrações do processo real que está sendo descrito. Dentre
os modelo de processo destacam-se atividades que são parte do processo de software, produtos de Lower-CASE – destinadas a dar apoio à implementação e aos testes, com os depuradores, sistemas
software e o papel das pessoas envolvidas na engenharia de software. de análise de programa, geradores de casos de testes e editores de programas.
Exemplos de tipos de processo.
Propriedades de um Bom Software
1. Um modelo de workflow – mostra a seqüência de atividade no processo, juntamente com Os software devem ser controlados por propriedades intrínsecas a ele, como: tempo de resposta do
suas entradas, saídas e dependências. As atividades, nesse modelo, representam ações software à consulta do usuário e a facilidade de compreensão do código do programa.
humanas. Por exemplo: um sistema bancário tem de ser seguro, um jogo interativo deve ter uma resposta
2. Um modelo de fluxo de dados ou de atividade – representa o processo como um conjunto de rápida, um sistema de controle de telefonia precisa ser confiável, etc.. Podem ser resumidos na
atividades, cada uma das quais realiza alguma transformação de dados. Esse modelo mostra Tabela 1.
como a entrada para o processo, tal como uma especificação, é transformada em uma saída,
como um projeto. As atividades podem estar em um nível inferior ao das atividades em um Tabela 1 – Atributos para um bom software
modelo de workflow. Elas podem representar transformações realizadas por pessoas ou Facilidade de Manutenção O software deve ser escrito de modo que possa evoluir para
computadores. atender às necessidades mutáveis dos clientes. Essas
3. Um modelo de papel/ação – representa papéis das pessoas envolvidas no processo de mudanças estão relacionadas ao ambiente de negócios que
software e as atividades pelas quase elas são responsáveis. pode ter constantes mutações
Nível de Confiança Tem uma gama de características que incluem confiabilidade,
proteção e segurança. O software confiável não deve ocasionar
Custos da engenharia de software danos físicos ou econômicos, no caso de defeitos no sistema.
Depende do processo utilizado e do tipo de software que está sendo desenvolvido. O custo total de Eficiência O software não deve desperdiçar os recursos do sistema, como
desenvolvimento de um complexo sistema de software como sendo de cem unidades de custo, a memória e ciclos de processador. A eficiência, portanto, inclui
distribuição dessas unidades será semelhante ao mostrado nos esquemas a seguir. a rapidez de resposta, o tempo de processamento, a utilização
0 25 50 100 de memória, entre outros.
Facilidade de Uso Deve ser utilizável, sem esforços indevidos, pelo tipo de
Especificação Projeto Implementação Integração e teste usuário para quem foi projeto. Isso significa que ele deve
dispor de uma interface apropriada com o usuário e de
Se uma abordagem não linear, mas iterativa, com refinamentos sucessivos for utilizada, não existe documentação adequada.
uma linha exata entre especificação projeto e desenvolvimento.
O processo de desenvolvimento do software deve ser de qualidade, com essas propriedades
garantidas, para que o produto também seja.
3 4
Responsabilidade Profissional e ética Esses itens não podem ser pensados antecipadamente.
1. Confidencialidade – respeitar seus empregadores ou clientes, quer tenham ou não assinado Sistemas e seu ambiente
um acordo formal, quanto ao sigilo de informações. Sistemas não são entidades independentes, mas existem em um ambiente. Esse ambiente afeta o
2. Competência – não devem enganar quanto ao seu nível de competência, ou seja, não devem funcionamento e o desempenho do sistema. A figura 1 mostra alguns dos sistemas que podem ser
aceitar serviços que estejam fora do seu limite de competência. incorporados em um edifício de escritórios, subsistemas.
3. Direitos de propriedade intelectual – estar cientes das leis locais que regulam o uso da
Cidade
propriedade intelectual, como patentes e direitos autorais. Eles devem ser cuidadosos, a fim
de assegurar que a propriedade intelectual de empregadores e clientes seja protegida. Rua
4. Má utilização de computadores – não empregar suas habilidades técnicas para o mau uso de Edifício
computadores de outras pessoas. Abrange desde casos triviais – jogar no computador do
Sistema de Sistema de Sistema de
cliente- até casos sérios – disseminação de vírus. Aquecimento energia água
Existem sociedade e instituições profissionais que desempenham importante papel a esse respeito – Sistema de Sistema de Sistema de
Segurança iluminação esgoto
ACM (Association for Computing Machinery), o IEEE (Institute of Electrical am d Electronic
Engineers) e a British computer Society – publicam um código de conduta profissional ou código
de ética.
Engenharia de Sistemas
É a atividade de especificar, projetar, implementar, validar, implantar e manter os sistemas como Figura 1 - Hierarquia de Sistemas
um todo. Os engenheiros de sistema não se ocupam apenas com o software, mas com as interações
de software, hardware e sistema com os usuários e seu ambiente. O ambiente local do sistema de segurança, por exemplo, são os outros sistemas dentro do edifício.
Enquanto que o ambiente total inclui todos os outros sistemas do lado de fora do edifício, na rua e
(recordar conceitos de sistemas) na cidade, bem como os sistemas naturais.
3. Mudanças organizacionais - sistema modifica a estrutura de poder político em uma 1. Componentes de sensores – coletam informações do ambiente do sistema. Exs: radares em
organização? Exemplo, se uma organização depende de um sistema complexo, aqueles que um sistema de controle de tráfego aéreo, sensores de posicionamento de papel em uma
sabem operar o sistema têm bastante poder político. impressora, um par termoelétrico em uma fornalha.
Modelagem de sistemas 2. Componentes de atuadores causam alguma mudança no ambiente do sistema. Exs: válvulas
que se abrem e fecham para passagem de líquidos, superfícies de vôo em uma aeronave, que
Como parte dos requisitos do sistema e da atividade de projetos, o sistema precisa ser modelado controlam o ângulo de vôo, e o mecanismo de alimentação de papel em uma impressora.
como um conjunto de componentes e de relações entre esses componentes Æ Modelo de 3. Componentes de computação – aqueles que considerando alguma entrada realizam algumas
arquitetura. computações sobre essa entrada e produzem uma saída. Ex: processador de ponto flutuante
que realiza computações sobre os nros reais.
A arquitetura do sistema é retratada como um diagrama de blocos, mostrando os subsistemas 4. Componentes de comunicação – aqueles cuja função é coordenar uma operação com outros
principais e as inter-conexões entre eles. Cada subsistema é representado por um retângulo, no componentes. Exs: um escalador em um sistema de tempo real, que decide quando os
diagrama de blocos; as flechas indicam a existência de uma relação entre eles (Figura 2). diferentes processos devem ser escalados para serem executados em um processador.
5. Componentes de interface – que transformam a representação utilizada por um componente
Sensores de
de sistema em uma representação empregada por outro componente. EX:um componente de
movimento Sensores de interface humana, que considera algum modelo de sistema e o exibe para o operador
porta humano. Conversor analógico-digital que converte uma entrada analógica em saída digital.
Tabela 4 – Leitores para os diferentes tipos de especificação estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de
Requisitos dos usuários Gerentes de clientes, usuários finais de sistemas, engenheiros facilidade de uso.
de clientes, gerentes do fornecedor, arquitetos de sistemas
Requisitos de sistema Usuários finais de sistemas, engenheiros do cliente, arquitetos Requisitos de
facilidade de
de sistemas, desenvolvedores de software. uso
Requisitos do
Especificação de projeto Engenheiros do cliente (talvez), arquitetos do sistema, produto
de software desenvolvedores de software. Requisitos de
confiabilidade Requisitos de
desempenho
Definindo Requisitos Funcionais e Não Funcionais
Requisitos de
eficiência Requisitos de
Requisitos funcionais: São declarações de funções que o sistema deve fornecer, como o sistema espaço
deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns
casos, os requisitos funcionais, podem também explicitamente declarar o que o sistema não deve Requisitos de
portabilidade
fazer. Especificação deve ser completa e consistente.
Completa – que todas as funções requeridas pelo usuário devem estar definidas.
Consistente – requisitos não devem ter informações contraditórias.
Requisitos de
Requisitos não Requisitos entrega
A maioria dos problemas na especificação/desenvolvimento de sistemas ocorre devido ao não funcionais organizacionais
cuidado nessa fase.
Requisitos de
Requisitos não funcionais: São aqueles que não dizem respeito diretamente às funções específicas implementação
fornecidas pelo sistema. Eles podem estar relacionados a propriedades de sistemas como :
confiabilidade, tempo de resposta e espaço em disco. Como alternativa, eles podem definir Requisitos de
restrições para o sistema como a capacidade dos dispositivos de E/S e as representações de dados padrões
utilizadas nas interfaces de sistema.
O não cumprimento de um requisito não funcional pode tornar o sistema inútil. Requisitos Requisitos de
Exemplo: Se um sistema de aviação não atender aos seus requisitos de confiabilidade, ele não será externos interoperabilidade
atestado como seguro para operação; se um sistema de tempo real falhar em cumprir com seus
requisitos de desempenho, as funções de controle não operarão corretamente. Requisitos de
Requisitos de privacidade
éticos
Os requisitos não funcionais nem sempre dizem respeito ao sistema de software a ser desenvolvido.
Alguns requisitos não funcionais podem restringir o processo que pode ser utilizado para
Requisitos de Requisitos de
desenvolver o sistema. legais segurança
Exemplos: Especificação de padrões de qualidade, que deve ser utilizada no processo, uma
especificação de que o projeto deve ser produzido com um conjunto especificado de ferramentas
CASE e uma descrição de processo a ser seguido. Figura 4 - Classificação dos Tipos de Requisitos Não Funcionais
A Figura 4 exibe os tipos de requisitos não funcionais existentes. 3. Requisitos organizacionais: são procedentes de políticas e procedimentos nas organizações
do cliente e do desenvolvedor. Exemplos: padrões de processo que devem ser utilizados, os
1. Requisitos de produtos: são os requisitos que especificam o comportamento do produto. requisitos de implementação, como a linguagem de programação ou o método de projeto
Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve utilizado, e os requisitos de fornecimento, que especificam quando o produto e seus
operar e a quantidade de memória que ele requer, os requisitos de confiabilidade, que documentos devem ser entregues.
estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de 4. Requisitos externos: abrange todos os requisitos procedentes de fatores externos ao sistema
facilidade de uso. e a seu processo de desenvolvimento. Dentre eles destacam-se os requisitos de
2. Requisitos de produtos: são os requisitos que especificam o comportamento do produto. interoperabilidade, que definem como o sistema interage com outras organizações, os
Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve requisitos legais, que devem ser seguidos para assegurar que o sistema opera de acordo com
operar e a quantidade de memória que ele requer, os requisitos de confiabilidade, que a lei, e os requisitos éticos. Os requisitos éticos são definidos em um sistema para garantir
que este será aceitável para seus usuários e o publico em geral.
11 12
Requisito Externo: O sistema não deverá revelar aos operadores nenhuma informação pessoal É a declaração oficial do que é exigido dos desenvolvedores de sistema. Ele deve incluir os
sobre os clientes, além de seus nomes e o número de referencia. requisitos de usuário para um sistema e uma especificação detalhada dos requisitos de sistema.
Algumas vezes, esses dois tipos de requisitos podem ser integrados em uma única descrição. Em
Tratamento dos Requisitos de usuário – Problemas e formas de Solução outros casos, os requisitos de usuários são definidos em uma introdução à especificação dos
requisitos de sistema. Podem ser apresentados em documentos separados se possuírem um número
Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não funcionais grande de requisitos.
de modo compressível pelos usuários do sistema que não têm conhecimentos técnicos detalhados. Vários usuários utilizam o documento de requisitos:
Eles devem especificar somente o comportamento externo do sistema, evitando tanto quanto
possível as características de projeto de sistema. Conseqüentemente, não devem ser definidos Conselhos de Heninger (1980) sobre seis requisitos aos quais um documento de requisitos de
utilizando-se um modelo de implementação. Eles podem ser descritos com o uso de linguagem software deveria satisfazer:
natural, formulários e diagramas intuitivos simples. 1. Especificar somente o comportamento externo do sistema.
2. Especificar as restrições à implementação
Problemas que normalmente ocorrem: 3. Ser fácil de ser modificado
1- Falta de clareza – é difícil utilizar a linguagem de maneira precisa e sem ambigüidade, sem 4. Servir como uma ferramenta de referencia para os responsáveis pela manutenção do sistema
produzir um documento de difícil leitura. 5. Registrar a estratégia sobre o ciclo de vida do sistema
2- Confusão de requisitos – quando os requisitos funcionais e não funcionais, os objetivos do 6. Caracterizar respostas aceitáveis para eventos indesejáveis.
sistema e as informações sobre o projeto não estão claramente definidos.
3- Fusão de requisitos – quando vários requisitos diferentes são expressos junto como um A Tabela 5 apresenta os diferentes usuários de um documento de requisitos e a forma como o
único requisito. utilizam.
São descrições mais detalhadas dos requisitos dos usuários. Eles podem servir de base para um Um padrão sugerido para o documento de requisitos tem a seguinte estrutura e foi proposta pelo
contrato destinado à implementação do sistema e, portanto, devem ser uma especificação completa IEEE.
e consistente de todo o sistema. São utilizados pelos engenheiros de software como ponto de partida
para o projeto de sistema. 1. Introdução
13 14
"Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de Respostas às questões de entrada e saída fornecerão informações substanciais sobre as
que aquilo que ouviu não é o que eu pretendia dizer". funções do sistema.
constante). Porém, muitos detalhes não foram tocados. A descrição dos objetivos e da principal • ambiente e que o sistema será desenvolvido poderá impor restrições quando as funções e
função do sistema está em muito alto – nível. Isto é, detalhes funcionais não foram descritos, não desempenho do sistema.
foram identificadas as entradas e saídas específicas, e detalhes de implementação foram omitidos. É
importante notar, no entanto, que estas omissões são completamente aceitáveis no inicio. O objetivo É importante reconhecer que atitudes fatalistas podem, muitas vezes, ser improdutivas.
é desenvolver uma declaração inicial do escopo que descreve a função principal do sistema. Embora o hardware tenha sido selecionado, pode não ser tão tarde efetuar mudanças, se as
restrições impostas no software forem tão severas que: (1) uma quantidade exorbitante de tempo
Pode parecer desnecessário e redundante desenvolver uma declaração do escopo para o seja necessária para desenvolver o software, aumentando dramaticamente o custo de
sistema Piloto – automático. Porém deve se ter em mente que: desenvolvimento; (2) a habilidade de alcançar o desempenho de controle esteja em risco ou (3)
modificações no sistema operacional sejam possíveis.
“Todos sabem o que o sistema deverá fazer até que alguém decida
descreve-lo”. Por listar as restrições, está se conduzindo uma revisão implícita. Por exemplo, considere o
desenvolvimento de uma rede de caixas eletrônicas para um grande banco. O sistema é composto de
Uma declaração de escopo deve ser o mais simples possível no início. A primeira declaração diferentes computadores e softwares, uma base de dados, operadores humanos, e substancial
os rascunho das principais funções do sistema devem ser sentenças simples (sujeito, verbo e objeto). documentação e procedimentos. A capacidade de processamento do hardware, a organização da
Por exemplo, uma primeira declaração de um sistema de piloto automático poderia ser: base de dados, os registros impostos para operadores humanos (clientes do banco), e muitos outros
fatores irão criar um conjunto de restrições para o sistema. Além disso, a natureza da aplicação dita
as suas próprias restrições implícitas:
O sistema piloto automático mantém constante a velocidade do automóvel.
1. A necessidade da segurança apropriada para proteger os interesses do banco e de seus clientes
Interações subseqüentes dessa sentença pode refinar o sujeito, verbo e objeto, para fornecer 2. A necessidade da disponibilidade de um caixa ao cliente
maiores detalhes e menor ambigüidade. 3. A necessidade de expandir a rede de acordo com o crescimento do banco
4. A necessidade de estender características e funções devido à pressões da concorrência.
3. - Identificar as principais entradas e saídas
Cada uma dessas restrições implícitas deve ser listada nesta fase. Cada uma implica que
Independente da área de aplicação, todo sistema computacional transforma informações. Isto certos elementos do sistema devem ter características especificas e, em muitos casos, especificas
é, dados fornecidos são transformados pelo sistema para produzir dados de saídas.O próximo passo funções de desempenho.
na criação de uma declaração de escopo é uma descrição das principais entradas e saídas do sistema
computacional. Durante os primeiros estágios do trabalho de análise, sempre é útil classificar os 5. - Escrever um parágrafo claro
dados transformados pelo sistema em duas grandes categorias genéricas: itens de dados e itens de
controle Um item de dados é qualquer entrada ou saída do sistema cujo conteúdo da Se tiver sido realizado cada um dos passos associados com o desenvolvimento de uma
informação é transformado (isto é, modificado, reorganizado, calculado, combinado) pelo declaração de escopo, têm-se agora as seguintes informações:
elemento software. Em geral, algoritmos computacionais ou combinatoriais transformam itens de
dados de uma forma ou de outra . Um item de controle geralmente implica na ocorrência de
• Uma descrição da função principal do sistema.
uma ação ou evento específico, ou requisito a inicialização de uma ação ou evento específico.
• Uma lista das principais entradas e saídas.
Para ilustrar a diferença entre itens de dados e itens de controle, considere que o sistema
Piloto automático permite ao motorista definir a velocidade desejada usando um teclado numérico • Uma lista de restrições que afetam o sistema.
do painel. A velocidade desejada é um item de dados – isto é, uma entrada do sistema que é
processada pelo software e transformada em velocidade. Para desligar o sistema, o motorista deve Estas informações são a base para um parágrafo claro que descreva todas as operações e
pressionar o freio ou o botão de desliga. Ambas ações causam um pulso que é lido pelo software. características do sistema. O parágrafo deve descrever as funções importantes do sistema de forma
Devido ao pulso não ser transformado (modificado, reorganizado, calculado, combinado) de alguma objetiva, correta e simples. Deve conter referências á item de dados e de controle e, também, a
forma, mas representar um evento que provoca uma mudança imediata na função do sistema, ele maneira como eles interagem com as principais funções do sistema. Devido ao parágrafo ser a
será considerado um item de controle. entrada essencial os próximos passos da análise de sistemas, ele deve ser desenvolvido com muito
cuidado. De fato, é sempre vantajoso desenvolver o parágrafo interativamente. Isto é, começa-se a
escrever um rascunho inicial, então se faz refinamentos, até a versão final.
4. - Listar todas as restrições que afetam o sistema
A cada elaboração da declaração do escopo as ambigüidades devem ser eliminadas e mais
A especificação e projeto de um sistema computacional são restringidos por muitas razões:
detalhes são fornecidos. Para ilustrar, considere o rascunho inicial da declaração de escopo do
sistema Piloto-automático.
• Considerações econômicas podem limitar tanto os recursos técnicos como humanos.
• As características de um elemento do sistema podem restringir a maneira como um outro
O sistema "Piloto-automático" mantém constate a velocidade do automóvel.
elemento do sistema é especificado e, conseqüente, projetado.
19
Embora este rascunho defina a principal função do sistema, fornece poucos detalhes e deve
ser refinado. Após dialogar com o cliente, escreve-se:
Em cada elaboração, maiores detalhes são fornecidos e futuras questões são levantadas e
respondidas. O processo termina quando o analista der-se por satisfeito, ou seja, não tiver mais
questões a levantar.
Para execução desse processo de definição do escopo do sistema, várias técnicas podem ser
utilizadas. A seguir, são apresentadas as principais técnicas para apoiar a etapa de levantamento de
requisitos.