ENGENHARIA DE SOFTWARE - roteiro de estudo

Prévia do material em texto

ENGENHARIA DE SOFTWARE 
TÓPICOS DE ASSUTOS ABORDADOS EM AULAS 
 
 
AULA 03 
 
 
INTRUDUÇÃO À ENGENHARIA DE SOFTWARE 
A engenharia de software tem por objetivo apoiar o desenvolvimento profissional de software, 
mais do que a programação individual. Ela inclui técnicas que apoiam especificação, projeto e 
evolução de programas, que normalmente não são relevantes para o desenvolvimento de software 
pessoal. 
Muitas pessoas pensam que software é simplesmente outra palavra para programas de computador. No 
entanto, quando falamos de engenharia de software, não se trata apenas do programa em si, mas de 
toda a documentação associada e dados de configurações necessários para fazer esse programa 
operar corretamente. Um sistema de software desenvolvido profissionalmente é, com frequência, mais 
do que apenas um programa; ele normalmente consiste em uma série de programas separados e 
arquivos de configuração que são usados para configurar esses programas. Isso pode incluir 
documentação do sistema, que descreve a sua estrutura; documentação do usuário, que explica 
como usar o sistema; e sites, para usuários baixarem a informação recente do produto. 
No entanto, se você está escrevendo um software que outras pessoas usarão e no qual outros 
engenheiros farão alterações, então você provavelmente deve fornecer informação adicional, assim como 
o código do programa. 
O que é software São programas de computador e documentação associada. Produtos de 
Software podem ser desenvolvidos para um cliente específico ou para o 
mercado em geral. 
Quais os atributos de um 
bom software 
Deve prover a funcionalidade e o desempenho requerido pelo usuário; 
além disso, deve ser confiável e fácil de manter e usar. 
O que é engenharia de 
software? 
É uma disciplina de engenharia que se preocupa com todos os aspectos 
de produção de software. 
Quais são as principais 
atividades da engenharia 
de software? 
Especificação do software, desenvolvimento de software, validação de 
software e evolução de software. 
Qual a diferença entre 
engenharia de software e 
engenharia de sistemas? 
Engenharia de sistemas se preocupa com todos os aspectos do 
desenvolvimento de sistemas computacionais, incluindo engenharia de 
hardware, software e processo. Engenharia de software é uma parte 
específica desse processo mais genérico. 
Quais são os principais 
desafios da engenharia de 
software? 
Lidar com o aumento da diversidade, demandas pela diminuição do tempo 
para entrega e desenvolvimento de software confiável. 
Quais são os custos da 
engenharia de software 
Aproximadamente 60% do custo de software são de desenvolvimento; 
40% são custos de teste. Para software customizado, os custos de 
evolução frequentemente superam os custos de desenvolvimento. 
Quais são as melhores 
técnicas e métodos da 
engenharia de software 
Enquanto todos os pojetos de software devem ser gerenciados e 
desenvolvidos profissionalmente, técnicas diferentes são adequadas para 
tipos de sistemas diferentes. Por exemplo, jogos devem ser sempre 
desenvolvidos usando uma série de protótipos, enquanto sistemas de 
controle críticos de segurança requerem uma especificação analisável e 
completa. Portanto, não se pode dizer que um método é melhor do que o 
outro. 
Quais diferenças foram 
feitas pela internet na 
engenharia de software? 
A internet tornou serviços de software disponíveis e possibilitou o 
desenvolvimento de sistemas altamente distribuídos baseados em 
serviços. O desenvolvimento de sistemas baseados em Web gerou 
importantes avanços nas linguagens de programação e reuso de software. 
 
Quando falamos sobre a qualidade do software profissional, devemos levar em conta que o software é 
usado e alterado pelas pessoas, além de seus desenvolvedores. A qualidade, portanto, implica não 
apenas o que o software faz. Ao contrário, ela tem de incluir o comportamento do software enquanto 
ele está executando, bem como a estrutura e a organização dos programas do sistema e a 
documentação associada. Isso se reflete nos atributos de software chamados não funcionais ou de 
qualidade. Exemplos desses atributos são o tempo de resposta do software a uma consulta do usuário e 
a compreensão do código do programa 
ATRIBUTOS NÃO FUNCIONAIS OU ATRIBUTOS DE QUALIDADE 
Um conjunto específico de atributos que você pode esperar de um software obviamente depende da 
aplicação. 
Sistema Banco Seguro 
Jogo Interativo e Ágil 
Comutação de 
Telefonia 
Confiável 
 
ATRIBUTOS ESSENCIAIS DE UM BOM SOFTWARE 
Características do 
produto 
Descrição 
Manutenibilidade O software deve ser escrito de forma que possa evoluir para atender ás 
necessidades dos clientes. Esse é um atributo crítico, porque a mudança do 
software é um requisito inevitável de um ambiente de negócio em mudança 
Confiabilidade e 
Proteção 
Confiabilidade, proteção e segurança. Não deve causas prejuízos físicos e 
econômicos, em uma caso de falha. Usuários maliciosos não devem ser 
capazes de acessar ou prejudicar o sistema. 
 
Eficiência Trabalhar de forma a otimizar os recursos do sistema, como memória e ciclos 
do processador. Pontanto eficiência incluir: Capacidade de resposta, tempo de 
processamento, uso da memória etc. Um software pouco eficiente é também 
um software muito pesado e lento. 
Aceitabilidade O software deve ser aceitável para o tipo de usuário para o qual foi projetado. 
Isso significa deve ser compreensível, usável e compatível com outros 
sistemas usados por ele. 
Compativel com outros sistemas, usável e compreensível. 
 Um software que tem pouco aceitabilidade, é um sistemas que ninguém quer 
usar, por ser de difícil compreensão e que não é integrado com outros 
sistemas que o usuário já utiliza. 
 
Engenharia de software – Foco em todos os aspectos da produção de software. Desde os estágios 
iniciais de especificações de sistema até sua manutenção, quando o sistema já esta sendo usado. Fazem 
parte também atividade não só da produção do software, mas de gerenciamento de projetos, 
desenvolvimento de ferramentas, métodos, teorias para apoiar a produção de software. 
Uma abordagem mais criativa e formal pode ser eficiente em algumas circunstâncias. 
Processo de software: Sequencia de atividade para a produção do mesmo. Existem quatro 
atividades fundamentais comuns a todos os processos de software. 
 
1 – Especificação: Definição do software em sí e suas restrições de sua operação. 
2 – Desenvolvimento: Nesta fase o software é projetado e programado. 
3 – Validação do software: O SOFTWARE é verificado para garantir que é exatamente o que o 
cliente quer 
4 – Evolução: O sistema é modificado para refletir a mudança de requisitos do cliente e do 
mercado.(Em constante processo). 
 
ENGENHARIA DE SISTEMAS: Se preocupa menos com a engenharia dos componentes dos 
sistemas, (hardware, software) 
 
ASPECTOS GERAIS QUE AFETAM VÁRIOS TIPOS DIFERENTES DE SOFTWARE: 
Heterogeneidade, Mudança de negócio e social; Segurança e confiabilidade 
(Sistemas distribuídos com tipos diferentes de computadores e dispositivos móveis.) Linguagens 
de programação antigas, de modo que é necessário criar um software confiável e flexível o 
suficiente para lidar com essa heterogeneidade. 
DIVERSIDADE NA ENGENHARIA DE SOFTWARE 
 Engenharia de software é uma abordagem sistemática para a produção de software; ela 
analisa questões práticas do curso, prazo e confiança, assim como as necessidades dos clientes 
e produtores do software. Tipos diferentes de aplicações: 
1 – Aplicações Stand-Alone 
2 – Aplicações interativas baseadas em transações 
3 – Sistemas de controle embutidos 
4 – Sistemas de processamento de lotes 
5 – Sistemas de entretenimento 
6 – Sistemas paramodelagem e simulação 
7 – Sistemas de coleta de dados 
8 – Sistema de sistemas 
 
Apesar disso, existem fundamentos de engenharia de software que se aplicam a todos 
os tipos de sistemas de software: 
1. Eles devem ser desenvolvidos em um processo gerenciado e compreendido. A organização 
que desenvolve o software deve planejar o processo de desenvolvimento e ter ideias claras do 
que será produzido e quando estará finalizado. É claro que processos diferentes são usados 
para tipos de software diferentes. 
2. Confiança e desempenho são importantes para todos os tipos de sistema. O software deve se 
comportar conforme o esperado, sem falhas, e deve estar disponível para uso quando requerido. 
Deve ser seguro em sua operação e deve ser, tanto quanto possível, protegido contra ataques 
externos. O sistema deve executar de forma eficiente e não deve desperdiçar recursos. 
3. É importante entender e gerenciar a especificação e os requisitos de software (o que o 
software deve fazer). Você deve saber o que clientes e usuários esperam dele e deve gerenciar 
suas expectativas para que um sistema útil possa ser entregue dentro do orçamento e do 
cronograma. 
4. Você deve fazer o melhor uso possível dos recursos existentes. Isso significa que, quando 
apropriado, você deve reusar o software já desenvolvido, em vez de escrever um novo. 
 
ENGENHARIA DE SOFTWARE E A INTERNET 
ESTAGIO 01 – WEBSERVICES: Componentes de software acessados pela net e fornecem 
funcionalidade específica e útil. 
ESTAGIO 02 – SOFTWARE COMO SERVIÇO: O software não executará em computadores 
locais, e sim em nuvem computacionais acessadas pela internet. Se você usa um serviço como 
um webmail, está usando um sistema baseado na nuvem. Uma nuvem computacional consiste 
em um grande número de sistemas computacionais interligados, os quais são compartilhados 
entre vários usuários. 
Os usuários não compram o software, mas pagam de acordo com o uso ou possuem acesso 
gratuito em troca de propagandas que são exibidas em suas telas. Os softwares agora são 
altamente distribuídos. As vezes pelo mundo todo. 
O reuso de software tornou-se a abordagem dominante para a construção de sistemas Web. 
Quando construímos esses sistemas, pensamos em como podemos montá-los a partir de 
componentes e sistemas de software preexistentes. 
Os três tipos de sistema que uso como estudos de caso são: 
1. Um sistema embutido: Trata-se de um sistema no qual o software controla um dispositivo de 
hardware e é embutido nesse dispositivo. As questões em sistemas embutidos incluem 
tipicamente o tamanho físico, a capacidade de resposta, o gerenciamento de energia etc. O 
exemplo de um sistema embutido que uso é um sistema para controlar um dispositivo médico. 
2. Um sistema de informação: Esse é um sistema cujo principal objetivo é gerenciar e prover 
acesso a um banco de dados de informações. As questões em sistemas de informação incluem 
proteção, usabilidade, privacidade e manutenção da integridade dos dados. O exemplo de um 
sistema de informação que uso é um sistema de registros médicos. 
3. Um sistema de coleta de dados baseado em sensores. Esse é um sistema cujo principal 
objetivo é coletar dados a partir de um conjunto de sensores e processá-los de alguma forma. Os 
principais requisitos de tais sistemas são confiabilidade, mesmo em condições ambientais hostis, 
e manutenibilidade. 
O exemplo de um sistema de coleta de dados que uso é uma estação meteorológica no deserto. 
Apresento cada um desses sistemas neste capítulo, com mais informações a respeito de cada 
um deles disponíveis na Internet 
2.1 - ÉTICA NA ENGENHARIA DE SOFTWARE 
Assim como outras disciplinas de engenharia, a engenharia de software é desenvolvida dentro de um 
framework social e legal que limita a liberdade das pessoas que trabalham nessa área. Como um 
engenheiro de software, você deve aceitar que seu trabalho envolve maiores responsabilidades do que 
simplesmente aplicar habilidades técnicas. Você também deve se comportar de forma ética e moralmente 
responsável se deseja ser respeitado como um engenheiro profissional 
1. Confidencialidade: Você deve respeitar naturalmente a confidencialidade de seus 
empregadores ou clientes, independentemente de ter sido ou não assinado um acordo formal de 
confidencialidade. 
2. Competência: Você não deve deturpar seu nível de competência. Você não deve aceitar 
conscientemente um trabalho que esteja fora de sua competência. 
3. Direitos de propriedade intelectual: Você deve ter conhecimento das leis locais a respeito da 
propriedade intelectual, como patentes e copyright. Você deve ter cuidado para garantir que a 
propriedade intelectual dos empregadores e clientes seja protegida. 
4. Mau uso do computador: Você não deve usar suas habilidades técnicas para fazer mau uso de 
computadores de outras pessoas. Esse mau uso varia de relativamente trivial (jogar videogames 
em uma máquina do empregador, por exemplo) até extremamente sério (disseminar vírus ou 
outros malwares) 
ESTUDO DE CASO 
Exemplo de tipos de sistemas 
 SISTEMA EMBUTIDO 
 SISTEMA DE INFORMAÇÃO 
 SISTEMA DE COLETA DE DADOS BASEADOS EM SENSORES 
 
 Engenharia de software é uma disciplina de engenharia que se preocupa com todos os aspectos 
da produção de software. 
 Software não é apenas um programa ou programas; ele inclui também a documentação. Os 
atributos principais de um produto de software são manutenibilidade, confiança, proteção, 
eficiência e aceitabilidade. 
 O processo de software inclui todas as atividades envolvidas no desenvolvimento do software. 
Atividades de alto nível de especificação, desenvolvimento, validação e evolução são parte de 
todos os processos de software. 
 As ideias fundamentais da engenharia de software são universalmente aplicáveis para todos os 
tipos de desenvolvimento de sistemas. Esses fundamentos incluem processos de software, 
confiança, proteção, requisitos e reuso. 
 Existem vários tipos diferentes de sistemas, e cada um requer ferramentas e técnicas de 
engenharia de software adequadas a seu desenvolvimento. Existem poucas, se houver alguma, 
técnicas específicas de projeto e implementação aplicáveis para todos os tipos de sistemas. 
 As ideias básicas da engenharia de software são aplicáveis a todos os tipos de sistemas de 
software. Esses fundamentos incluem processos de software gerenciados, confiança e 
proteção de software, engenharia de requisitos e reuso de software. 
 Engenheiros de software têm responsabilidades com a profissão de engenharia e com a 
sociedade. Eles não devem se preocupar apenas com as questões técnicas. 
 Sociedades profissionais publicam códigos de conduta que definem os padrões de 
comportamento esperado de seus membros. 
LISTA EXERCÍCIOS 
1.1 Explique por que software profissional não é apenas os programas que são desenvolvidos 
para o cliente. 
1.2 1.2 Qual a diferença mais importante entre o desenvolvimento de um produto genérico de 
software e o desenvolvimento de software sob demanda? O que isso pode significar na 
prática para usuários de produtos de software genérico? 
1.3 1.3 Quais são os quatro atributos importantes que todo software profissional deve possuir? 
Sugira outros quatro atributos que, às vezes, podem ser significantes. 
1.4 1.4 Além dos desafios de heterogeneidade, mudanças sociais e corporativas, confiança e 
proteção, identifique outros problemas e desafios que a engenharia de software 
provavelmente enfrentará no século XXI (Dica: pense no meio ambiente). 
1.5 Baseado em seu conhecimento de alguns tipos de aplicações discutidos na Seção 1.1.2, 
explique, com exemplos, por que tipos de aplicações diferentes requerem técnicas 
especializadasde engenharia de software para apoiar seu projeto e desenvolvimento. 
1.6 Explique por que existem ideias fundamentais na engenharia de software que se aplicam a 
todos os tipos de sistemas. 
1.7 Explique como o uso universal da Internet mudou os sistemas de software. 
1.8 Discuta se os engenheiros profissionais devem ser certificados da mesma forma que 
médicos e advogados. 
1.9 Para cada uma das cláusulas no Código de Ética da ACM/IEEE m stradas 
1.10 Para ajudar a combater o terrorismo, muitos países estão planejando desenvolver, ou já 
desenvolveram, sistemas computacionais que rastreiam grandes números de cidadãos e 
suas ações. Obviamente, isso tem implicações nas questões da privacidade. Discuta a ética 
de se trabalhar desenvolvendo esse tipo de sistema. 
 
PROCESSOS DE SOFTWARE: O objetivo deste capítulo é apresentar a ideia de um processo de 
software — um conjunto coerente de atividades para a produção de software. Ao terminar de ler este 
capítulo, você: 
2.1 Modelos de processo de software 
2.2 Atividades do processo 
2.3 Lidando com mudanças 
2.4 Rational Unified Process (RUP) 
Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades 
fundamentais para a engenharia de software: 
1. Especificação de software. A funcionalidade do software e as restrições a seu funcionamento 
devem ser definidas. 
2. Projeto e implementação de software. O software deve ser produzido para atender às 
especificações. 
3. Validação de software: O software deve ser validado para garantir que atenda às demandas 
do cliente. 
4. Evolução de software: O software deve evoluir para atender às necessidades de mudança dos 
clientes 
 
Existem também as atividades que dão apoio ao processo, como documentação e 
gerenciamento de configuração de software. 
Os processos de software, às vezes, são categorizados como dirigidos a planos ou processos ágeis. 
Processos dirigidos a planos são aqueles em que todas as atividades são planejadas com antecedência, 
e o progresso é avaliado por comparação com o planejamento inicial. Em processos ágeis, que discuto 
no Capítulo 3, o planejamento é gradativo, e é mais fácil alterar o processo de maneira a refletir as 
necessidades de mudança dos clientes. Geralmente, é necessário encontrar um equilíbrio entre os 
processos dirigidos a planos e os processos ágeis. 
Em organizações nas quais a diversidade de processos de software é reduzida, os processos de software 
podem ser melhorados pela padronização. Isso possibilita uma melhor comunicação, além de redução no 
período de treinamento, e torna mais econômico o apoio ao processo automatizado. A padronização 
também é um importante primeiro passo na introdução de novos métodos e técnicas de engenharia de 
software, assim como as boas práticas de engenharia de software. 
MODELOS DE PROCESSO DE SOFTWARE 
O modelo em cascata: Esse modelo considera as atividades fundamentais do processo de 
especificação, desenvolvimento, validação e evolução, e representa cada uma delas como fases 
distintas, como: especificação de requisitos, projeto de software, implementação, teste e assim por diante. 
Desenvolvimento incremental: Essa abordagem intercala as atividades de especificação, 
desenvolvimento e validação. O sistema é desenvolvido como uma série de versões (incrementos), de 
maneira que cada versão adiciona funcionalidade à anterior. 
Engenharia de software orientada a reuso: Essa abordagem é baseada na existência de um número 
significativo de componentes reusáveis. O processo de desenvolvimento do sistema concentra-se na 
integração desses componentes em um sistema já existente em vez de desenvolver um sistema a partir 
do zero. Esses modelos não são mutuamente exclusivos e muitas vezes são usados em conjunto, 
especialmente para o desenvolvimento de sistemas de grande porte. Para sistemas de grande porte, faz 
sentido combinar algumas das melhores características do modelo em cascata e dos modelos de 
desenvolvimento incremental. É preciso ter informações sobre os requisitos essenciais do sistema para 
projetar uma arquitetura de software que dê suporte a esses requisitos. 
Integração e teste de sistema: As unidades individuais do programa ou programas são integradas e 
testadas como um sistema completo para assegurar que os requisitos do software tenham sido 
atendidos. Após o teste, o sistema de software é entregue ao cliente. 
Operação e manutenção: Normalmente (embora não necessariamente), essa é a fase mais longa do 
ciclo de vida. O sistema é instalado e colocado em uso. A manutenção envolve a correção de erros que 
não foram descobertos em estágios iniciais do ciclo de vida, com melhora da implementação das 
unidades do sistema e ampliação de seus serviços em resposta às descobertas de novos requisitos. 
 
 
DESENVOLVIMENTO INCREMENTAL 
 
O desenvolvimento incremental tem três vantagens importantes quando comparado ao 
modelo em cascata: 
1. O custo de acomodar as mudanças nos requisitos do cliente é reduzido. A quantidade de análise e 
documentação a ser refeita é muito menor do que o necessário no modelo em cascata. 
2. É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi feito. Os clientes podem fazer 
comentários sobre as demonstrações do software e ver o quanto foi implementado. Os clientes têm 
dificuldade em avaliar a evolução por meio de documentos de projeto de software. 
3. É possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se toda a 
funcionalidade não for incluída. Os clientes podem usar e obter ganhos a partir do software inicial antes 
do que é possível com um processo em cascata. 
GERENCIAMENTO INCREMENTAL 
Do ponto de vista do gerenciamento, a abordagem incremental tem dois problemas: 
1. O processo não é visível. Os gerentes precisam de entregas regulares para mensurar o progresso. Se 
os sistemas são desenvolvidos com rapidez, não é economicamente viável produzir documentos que 
reflitam cada uma das versões do sistema. 
2. A estrutura do sistema tende a se degradar com a adição dos novos incrementos. A menos que tempo 
e dinheiro sejam dispendidos em refatoração para melhoria do software, as constantes mudanças tendem 
a corromper sua estrutura. Incorporar futuras mudanças do software torna-se cada vez mais difícil e 
oneroso. 
2.1.3 ENGENHARIA DE SOFTWARE ORIENTADA A REUSO 
Na maioria dos projetos de software, há algum reúso de software. Isso acontece muitas vezes 
informalmente, quando as pessoas envolvidas no projeto sabem de projetos ou códigos semelhantes ao 
que é exigido. Elas os buscam, fazem as modificações necessárias e incorporam-nos a seus sistemas. 
1. Análise de componentes. Dada a especificação de requisitos, é feita uma busca por 
componentes para implementar essa especificação. Em geral, não há correspondência exata, e 
os componentes que podem ser usados apenas fornecem alguma funcionalidade necessária. 
2. 2. Modificação de requisitos. Durante esse estágio, os requisitos são analisados usando-se 
informações sobre os componentes que foram descobertos. Em seguida, estes serão 
modificados para refletir os componentes disponíveis. No caso de modificações impossíveis, a 
atividade de análise dos componentes pode ser reinserida na busca por soluções alternativas. 
3. 3. Projeto do sistema com reúso. Durante esse estágio, o framework do sistema é projetado ou 
algo existente é reusado. Os projetistas têm em mente os componentes que serão reusados e 
organizam o framework para reúso. Alguns softwares novos podem ser necessários, se 
componentes reusáveis não estiverem disponíveis. 
4. 4. Desenvolvimento e integração. Softwares que não podem ser adquiridos externamente sãodesenvolvidos, e os componentes e sistemas COTS são integrados para criar o novo sistema. A 
integração de sistemas, nesse modelo, pode ser parte do processo de desenvolvimento, em vez 
de uma atividade separa 
 
 
 
Existem três tipos de componentes de software que podem ser usados em um processo orientado 
a reúso: 
1. Web services desenvolvidos de acordo com os padrões de serviço e que estão disponíveis para 
invocação remota. 
2. Coleções de objetos que são desenvolvidas como um pacote a ser integrado com um framework de 
componentes, como .NET ou J2EE. 
3. Sistemas de software stand-alone configurados para uso em um ambiente particular. Engenharia de 
software orientada a reúso tem a vantagem óbvia de reduzir a quantidade de software a ser desenvolvido 
e, assim, reduzir os custos e riscos. Geralmente, também proporciona a entrega mais rápida do software. 
 
ATIVIDADES DO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE 
Processos reais de software são intercalados com sequências de atividades técnicas, de colaboração e 
de gerência, com o intuito de especificar, projetar, implementar e testar um sistema de software. 
 
2.2.2 PROJETO E IMPLEMENTAÇÃO DE SOFTWARE 
O estágio de implementação do desenvolvimento de software é o processo de conversão de uma 
especificação do sistema em um sistema executável. Sempre envolve processos de projeto e 
programação de software, mas, se for usada uma abordagem incremental para o desenvolvimento, 
também pode envolver o refinamento da especificação do software. 
 
1. Projeto de arquitetura, no qual você pode identificar a estrutura geral do sistema, os 
componentes principais (algumas vezes, chamados subsistemas ou módulos), seus 
relacionamentos e como eles são distribuídos. 
2. Projeto de interface, no qual você define as interfaces entre os componentes do sistema. Essa 
especificação de interface deve ser inequívoca. Com uma interface precisa, um componente 
pode ser usado de maneira que outros componentes não precisam saber como ele é 
implementado. Uma vez que as especificações de interface são acordadas, os componentes 
podem ser projetados e desenvolvidos simultaneamente. 
3. Projeto de componente, no qual você toma cada componente do sistema e projeta seu 
funcionamento. Pode-se tratar de uma simples declaração da funcionalidade que se espera 
implementar, com o projeto específico para cada programador. Pode, também, ser uma lista de 
alterações a serem feitas em um componente reusável ou um modelo de projeto detalhado. O 
modelo de projeto pode ser usado para gerar automaticamente uma implementação. 
4. Projeto de banco de dados, no qual você projeta as estruturas de dados do sistema e como eles 
devem ser representados em um banco de dados. Novamente, o trabalho aqui depende da 
existência de um banco de dados a ser reusado ou da criação de um novo banco de dados. 
 
 
4.2.3 VALIDAÇÃO DE SOFTWARE 
 
1. Testes de desenvolvimento. Os componentes do sistema são testados pelas pessoas 
que o desenvolveram. Cada componente é testado de forma independente, separado 
dos outros. Os componentes podem ser entidades simples, como funções ou classes 
de objetos, ou podem ser agrupamentos coerentes dessas entidades. Ferramentas de 
automação de teste, como JUnit (MASSOL e HUSTED, 2003), que podem reexecutar 
testes de componentes quando as novas versões dos componentes são criadas, são 
comumente usadas. 
2. Testes de sistema. Componentes do sistema são integrados para criar um sistema 
completo. Esse processo se preocupa em encontrar os erros resultantes das interações 
inesperadas entre componentes e problemas de interface do componente. Também 
visa mostrar que o sistema satisfaz seus requisitos funcionais e não funcionais, bem 
como testar as propriedades emergentes do sistema. Para sistemas de grande porte, 
esse pode ser um processo multiestágios, no qual os componentes são integrados para 
formar subsistemas individualmente testados antes de serem integrados para formar o 
sistema final. 
3. Testes de aceitação. Esse é o estágio final do processo de testes, antes que o sistema 
seja aceito para uso operacional. O sistema é testado com dados fornecidos pelo 
cliente, e não com dados advindos de testes simulados. O teste de aceitação pode 
revelar erros e omissões na definição dos requisitos do sistema, pois dados reais 
exercitam o sistema de formas diferentes dos dados de teste. Os testes de aceitação 
também podem revelar problemas de requisitos em que os recursos do sistema não 
atendam às necessidades do usuário ou o desempenho do sistema seja inaceitável. Os 
processos de desenvolvimento de componentes e testes geralmente são intercalados. 
Os programadores criam seus próprios dados para testes e, incrementalmente, testam 
o código enquanto ele é desenvolvido 
2.2.4 EVOLUÇÃO DO SOFTWARE 
A flexibilidade dos sistemas de software é uma das principais razões pelas quais os softwares 
vêm sendo, cada vez mais, incorporados em sistemas grandes e complexos. Uma vez que a decisão pela 
fabricação do hardware foi tomada, é muito caro fazer alterações em seu projeto. Entretanto, as 
mudanças no software podem ser feitas a qualquer momento durante ou após o desenvolvimento do 
sistema 
 
 
 
2.3 LIDANDO COM MUDANÇAS 
A mudança é inevitável em todos os grandes projetos de software. Os requisitos do sistema 
mudam, ao mesmo tempo que o negócio que adquiriu o sistema responde a pressões externas e mudam 
as prioridades de gerenciamento. Com a disponibilidade de novas tecnologias, emergem novos projetos e 
possibilidades de implementação. 
2 3.1 PROTOTIPAÇÃO 
Um protótipo é uma versão inicial de um sistema de software, usado para demonstrar conceitos, 
experimentar opções de projeto e descobrir mais sobre o problema e suas possíveis soluções. O 
desenvolvimento rápido e iterativo do protótipo é essencial para que os custos sejam controlados e os 
stakeholders do sistema possam experimentá-lo no início do processo de software 
 
Entrega incremental (Figura 2.10) é uma abordagem para desenvolvimento de software na qual alguns 
dos incrementos desenvolvidos são entregues ao cliente e implantados para uso em um ambiente 
operacional. Em um processo de entrega incremental os clientes identificam, em linhas gerais, os 
serviços a serem fornecidos pelo sistema. 
 
2.3.3 MODELO ESPIRAL DE BOEHM 
Um framework de processo de software dirigido a riscos (o modelo em espiral) foi proposto por Boehm 
(1988). Isso está na Figura 2.11. Aqui, o processo de software é representado como uma espiral, e não 
como uma sequência de atividades com alguns retornos de uma para outra. 
2.4 RATIONAL UNIFIED PROCESS (RUP) 
O Rational Unified Process — RUP (KRUTCHEN, 2003) é um exemplo de modelo de processo moderno, 
derivado de trabalhos sobre a UML e o Unified Software Development Process associado (RUMBAUGH, 
et al., 1999; ARLOW e NEUSTADT, 2005). Incluí uma descrição aqui, pois é um bom exemplo de 
processo híbrido. Ele reúne elementos de todos os modelos de processo genéricos (Seção 2.1), ilustra 
boas práticas na especificação e no projeto (Seção 2.2) e apoia a prototipação e a entrega incremental 
(Seção 2.3) 
 
 
Os processos de software são as atividades envolvidas na produção de um sistema de software. Modelos 
de processos de software são representações abstratas desses processos. 
 Modelos gerais de processo descrevem a organização dos processos de software. Exemplos 
desses modelos gerais incluem o modelo em cascata, o desenvolvimento incremental e o 
desenvolvimento orientado a reuso. 
 Engenharia de requisitos é o processo de desenvolvimento de uma especificação de software. 
As especificações destinam-se a comunicar as necessidadesde sistema dos clientes para os 
desenvolvedores do sistema. 
 Processos de projeto e implementação estão relacionados com a transformação das 
especificações dos requisitos em um sistema de software executável. Métodos sistemáticos de 
projeto podem ser usados como parte dessa transformação. 
 Validação de software é o processo de verificação de que o sistema está de acordo com sua 
especificação e satisfaz às necessidades reais dos usuários do sistema. 
 Evolução de software ocorre quando se alteram os atuais sistemas de software para atender aos 
novos requisitos. As mudanças são contínuas, e o software deve evoluir para continuar útil. 
 Processos devem incluir atividades para lidar com as mudanças. Podem envolver uma fase de 
prototipação, que ajuda a evitar más decisões sobre os requisitos e projeto. Processos podem 
ser estruturados para o desenvolvimento e a entrega iterativos, de forma que mudanças possam 
ser feitas sem afetar o sistema como um todo. 
 O Rational Unified Process (RUP) é um moderno modelo genérico de processo, organizado em 
fases (concepção, elaboração, construção e transição), mas que separa as atividades 
(requisitos, análises, projeto etc.) dessas fases. 
 
DESENVOLVIMENTO ÁGIL DE SOFTWARE 
O objetivo deste capítulo é apresentar os métodos ágeis de desenvolvimento de software. Ao terminar de 
ler este capítulo, você: 
t compreenderá a lógica dos métodos ágeis de desenvolvimento de software, o manifesto ágil, e as 
diferenças entre desenvolvimento ágil e desenvolvimento dirigido a planos; 
t conhecerá as práticas mais importantes da Extreme Programming e o modo como elas se relacionam 
com os princípios gerais dos métodos ágeis; 
t compreenderá a abordagem Scrum para gerenciamento ágil de projetos; 
t estará ciente das questões e problemas de escalamento de métodos ágeis de desenvolvimento para o 
desenvolvimento de sistemas de software de grande porte. 
3.1 Métodos ágeis 
3.2 Desenvolvimento ágil e dirigido a planos 
3.3 Extreme Programming 
3.4 Gerenciamento ágil de projetos 
3.5 Escalamento de métodos ágeis 
 
 
A filosofia por trás dos métodos ágeis é refletida no manifesto ágil, que foi acordado por muitos 
dos principais desenvolvedores desses métodos. Esse manifesto afirma: Estamos descobrindo melhores 
maneiras de desenvolver softwares, fazendo-o e ajudando outros a fazê-lo. Através desse trabalho, 
valorizamos mais: Indivíduos e interações do que processos e ferramentas Software em funcionamento 
do que documentação abrangente Colaboração do cliente do que negociação de contrato Respostas a 
mudanças do que seguir um plano Ou seja, embora itens à direita sejam importantes, valorizamos mais 
os que estão à esquerda. 
 
1. Embora a ideia de envolvimento do cliente no processo de desenvolvimento seja atraente, seu 
sucesso depende de um cliente disposto e capaz de passar o tempo com a equipe de 
desenvolvimento, e que possa representar todos os stakeholders do sistema. Frequentemente, 
os representantes dos clientes estão sujeitos a diversas pressões e não podem participar 
plenamente do desenvolvimento de software; 
2. Membros individuais da equipe podem não ter personalidade adequada para o intenso 
envolvimento que é típico dos métodos ágeis e, portanto, não interagem bem com outros 
membros da equipe; 
3. Priorizar as mudanças pode ser extremamente difícil, especialmente em sistemas nos quais 
existem muitos stakeholders. Normalmente, cada stakeholder dá prioridades diferentes para 
mudanças diferentes; 
4. Manter a simplicidade exige um trabalho extra. Sob a pressão de cronogramas de entrega, os 
membros da equipe podem não ter tempo para fazer as simplificações desejáveis; 
5. Muitas organizações, principalmente as grandes empresas, passaram anos mudando sua 
cultura para que os processos fossem definidos e seguidos. É difícil para eles mudar de um 
modelo de trabalho em que os processos são informais e definidos pelas equipes de 
desenvolvimento; 
3.2 DESENVOLVIMENTO ÁGIL E DIRIGIDO A PLANOS 
Abordagens ágeis de desenvolvimento de software consideram o projeto e a implementação como 
atividades centrais no processo de software. Eles incorporam outras atividades, como elicitação de 
requisitos e testes no projeto e na implementação. Em contrapartida, uma abordagem de engenharia de 
software dirigida a planos identifica estágios distintos do processo de software com saídas associadas a 
cada estágio. As saídas de um estágio são usadas como base para o planejamento da atividade do 
processo a seguir. A Figura 3.1 mostra as distinções entre as abordagens dirigidas a planos e ágil para a 
especificação do sistema. 
 
3.3 EXTREME PROGRAMMING 
Extreme Programming (XP) é talvez o mais conhecido e mais utilizado dos métodos ágeis. O nome foi 
cunhado por Beck (2000), pois a abordagem foi desenvolvida para impulsionar práticas 
reconhecidamente boas, como o desenvolvimento iterativo, a níveis ‘extremos’. Por exemplo, em XP, 
várias novas versões de um sistema podem ser desenvolvidas, integradas e testadas em um único dia 
por programadores diferentes. Em Extreme Programming, os requisitos são expressos como cenários 
(chamados de histórias do usuário), que são implementados diretamente como uma série de tarefas. Os 
programadores trabalham em pares e desenvolvem testes para cada tarefa antes de escreverem o 
código. Quando o novo código é integrado ao sistema, todos os testes devem ser executados com 
sucesso. Há um curto intervalo entre os releases do sistema. 
 
Extreme Programming envolve uma série de práticas que refletem os princípios dos métodos 
ágeis (elas estão resumidas na Tabela 3.2): 
1. O desenvolvimento incremental é sustentado por meio de pequenos e frequentes releases do sistema. 
Os requisitos são baseados em cenários ou em simples histórias de clientes, usadas como base para 
decidir a funcionalidade que deve ser incluída em um incremento do sistema. 
2. O envolvimento do cliente é sustentado por meio do engajamento contínuo do cliente com a equipe de 
desenvolvimento. O representante do cliente participa do desenvolvimento e é responsável por definir os 
testes de aceitação para o sistema. ( Dono do Produto, na Metodologia Scrum) 
3. Pessoas — não processos — são sustentadas por meio de programação em pares, propriedade 
coletiva do código do sistema e um processo de desenvolvimento sustentável que não envolve horas de 
trabalho excessivamente longas. 
4. As mudanças são aceitas por meio de releases contínuos para os clientes, do desenvolvimento test-
first, da refatoração para evitar a degeneração do código e integração contínua de nova 
funcionalidade. 
5. A manutenção da simplicidade é feita por meio da refatoração constante que melhora a 
qualidade do código, bem como por meio de projetos simples que não antecipam desnecessariamente 
futuras mudanças no sistema 
 
 
 
TESTE EM XP 
Para evitar alguns dos problemas de teste e validação do sistema, a abordagem XP enfatiza a 
importância dos testes do programa. Extreme Programming inclui uma abordagem de testes que reduz as 
chances de erros desconhecidos na versão atual do sistema. 
As principais características dos testes em XP são: 
1. Desenvolvimento test-first; 
2. Desenvolvimento de teste incremental a partir de cenários; 
3. Envolvimento dos usuários no desenvolvimento de testes e validação; 
4. Uso de frameworks de testes automatizados 
3.3.2 A PROGRAMAÇÃO EM PARES 
Outra prática inovadora introduzida no XP é que, para desenvolver o software, os programadores 
trabalhem em pares. Na verdade, para desenvolver o software eles se sentam juntos, na mesma estação 
de trabalho. No entanto, os mesmos pares nem sempre programam juntos. Pelo contrário,os pares são 
criados de maneira dinâmica, de modo que todos os membros da equipe trabalhem uns com os outros 
durante o processo de desenvolvimento. 
3.4 GERENCIAMENTO ÁGIL DE PROJETOS 
A principal responsabilidade dos gerentes de projeto de software é gerenciar o projeto para 
que o software seja entregue no prazo e dentro do orçamento previsto. Eles supervisionam o 
trabalho dos engenheiros de software e acompanham quão bem o desenvolvimento de software está 
progredindo. 
 
MÉTODOS ÁGEIS 
Métodos ágeis são métodos de desenvolvimento incremental que se concentram em desenvolvimento 
rápido, releases frequentes do software, redução de overheads dos processos e produção de códigos de 
alta qualidade. Eles envolvem o cliente diretamente no processo de desenvolvimento. 
 A decisão de usar uma abordagem ágil ou uma abordagem dirigida a planos para o 
desenvolvimento deve depender do tipo de software a ser desenvolvido, das habilidades da 
equipe de desenvolvimento e da cultura da empresa que desenvolve o sistema. 
 Extreme Programming é um método ágil, bem conhecido, que integra um conjunto de boas 
práticas de programação, como releases frequentes do software, melhorias contínuas do 
software e participação do cliente na equipe de desenvolvimento. 
 Um ponto forte da Extreme Programming é o desenvolvimento de testes automatizados 
antes da criação de um recurso do programa. Quando um incremento é integrado ao sistema, 
todos os testes devem ser executados com sucesso. 
 O método Scrum é uma metodologia ágil que fornece um framework de gerenciamento de 
projetos. É centralizado em torno de um conjunto de sprints, que são períodos determinados de 
tempo, quando um incremento de sistema é desenvolvido. O planejamento é baseado na 
priorização de um backlog de trabalho e na seleção das tarefas mais importantes para um sprint. 
 O escalamento de métodos ágeis para sistemas de grande porte é difícil. Tais sistemas 
necessitam de projeto adiantado e alguma documentação. A integração contínua é praticamente 
impossível quando existem várias equipes de desenvolvimento separadas trabalhando em um 
projeto 
ENGENHARIA DE REQUISITOS 
Os requisitos de um sistema são as descrições do que o sistema deve fazer os serviços que 
oferece e as restrições a seu funcionamento. Esses requisitos refletem as necessidades dos 
clientes para um sistema que serve a uma finalidade determinada, como controlar um 
dispositivo, colocar um pedido ou encontrar informações. O processo de descobrir, analisar, 
documentar e verificar esses serviços e restrições é chamado engenharia de requisitos (RE, do 
inglês requirements engineering). 
1. Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de 
quais serviços o sistema deverá fornecer a seus usuários e as restrições com as 
quais este deve operar. 
2. Requisitos de sistema são descrições mais detalhadas das funções, serviços e 
restrições operacionais do sistema de software. O documento de requisitos do sistema 
(às vezes, chamado especificação funcional) deve definir exatamente o que deve 
ser implementado. Pode ser parte do contrato entre o comprador do sistema e os 
desenvolvedores de software 
 
REQUISITOS 
4.1 Requisitos funcionais e não funcionais 
 
Os requisitos de software são frequentemente classificados como requisitos 
funcionais e requisitos não funcionais: 
1. Requisitos funcionais: São declarações de serviços que o sistema deve 
fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema 
deve se comportar em determinadas situações. Em alguns casos, os requisitos 
funcionais também podem explicitar o que o sistema não deve fazer. 
2. Requisitos não funcionais: São restrições aos serviços ou funções oferecidos 
pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e 
restrições impostas pelas normas. Ao contrário das características individuais ou 
serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema 
como um todo. 
 
4.1.1 Requisitos funcionais 
Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles dependem 
do tipo de software a ser desenvolvido, de quem são seus possíveis usuários e da 
abordagem geral adotada pela organização ao escrever os requisitos. Quando 
expressos como requisitos de usuário, os requisitos funcionais são normalmente 
descritos de forma abstrata, para serem compreendidos pelos usuários do sistema. No 
entanto, requisitos de sistema funcionais mais específicos descrevem em detalhes as 
funções do sistema, suas entradas e saídas, exceções etc. 
 
4.1.2 Requisitos não funcionais 
 
Os requisitos não funcionais, como o nome sugere, são requisitos que não estão 
diretamente relacionados com os serviços específicos oferecidos pelo sistema a seus 
usuários. Eles podem estar relacionados às propriedades emergentes do sistema, 
como confiabilidade, tempo de resposta e ocupação de área. Uma alternativa a esse 
cenário seria os requisitos definirem restrições sobre a implementação do sistema, como 
as capacidades dos dispositivos de E/S ou as representações de dados usadas nas 
interfaces com outros sistemas. 
 
 
 
4.2 O DOCUMENTO DE REQUISITOS DE SOFTWARE 
 
é uma declaração oficial de o que os desenvolvedores do sistema devem 
implementar. Deve incluir tanto os requisitos de usuário para um sistema quanto 
uma especificação detalhada dos requisitos de sistema Documentos de requisitos 
são essenciais quando um contratante externo está desenvolvendo o sistema de 
software. 
 
 
 
 
Etnografia é uma técnica de observação que pode ser usada para compreender os 
processos operacionais e ajudar a extrair os requisitos de apoio para esses processos. 
Um analista faz uma imersão no ambiente de trabalho em que o sistema será usado. O 
trabalho do dia a dia é observado e são feitas anotações sobre as tarefas reais em que 
os participantes estão envolvidos. O valor da etnografia é que ela ajuda a descobrir 
requisitos implícitos do sistema que refletem as formas reais com que as pessoas 
trabalham, em vez de refletir processos formais definidos pela organização. 
 
4.6 Validação de requisitos 
 
A validação de requisitos é o processo pelo qual se verifica se os requisitos definem o 
sistema que o cliente realmente quer. Ela se sobrepõe à análise, uma vez que está 
preocupada em encontrar problemas com os requisitos. A validação de requisitos é 
importante porque erros em um documento de requisitos podem gerar altos custos de 
retrabalho quando descobertos durante o desenvolvimento ou após o sistema já estar 
em serviço. 
 
 
 
 
 
 
Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e 
define as restrições sobre seu funcionamento e implementação. 
Os requisitos funcionais são declarações dos serviços que o sistema deve fornecer ou 
descrições de como alguns processamentos devem ser efetuados. 
Muitas vezes, os requisitos não funcionais restringem o sistema que está sendo 
desenvolvido e o processo de Gerenciamento de mudança de requisitos. 
 
 Implementação de mudanças 
 Análise de mudança e custos 
 Análise de problema e especificação de mudanças 
 Problema identificado 
 Requisitos revisados 
 
. Estes podem ser os requisitos de produto, requisitos organizacionais ou requisitos 
externos. Eles costumam se relacionar com as propriedades emergentes do sistema e, 
portanto, aplicam-se ao sistema como um todo. 
O documento de requisitos de software é uma declaração acordada dos requisitos do 
sistema. Deve ser organizado para que ambos — os clientes do sistema e os 
desenvolvedoresde software — possam usá-lo. 
O processo de engenharia de requisitos inclui um estudo da viabilidade, elicitação e 
análise de requisitos, especificação de requisitos, validação e gerenciamento de 
requisitos. 
Elicitação e análise de requisitos é um processo iterativo que pode ser representado 
como uma espiral de atividades — descoberta de requisitos, classificação e organização 
de requisitos, negociação de requisitos e documentação de requisitos. 
A validação de requisitos é o processo de verificação da validade, consistência, 
completude, realismo e verificabilidade dos requisitos. 
Mudanças organizacionais, mudanças nos negócios e mudanças técnicas 
inevitavelmente geram mudanças nos requisitos para um sistema de software. O 
gerenciamento de requisitos é o processo de gerenciamento e controle dessas 
mudanças. 
 
LISTA DE EXERCÍCIOS 
 
4.1 Identifique e descreva brevemente os quatro tipos de requisitos que podem ser definidos 
para um sistema computacional 
4.2 Descubra ambiguidades ou omissões nas seguintes declarações de requisitos para parte de 
um sistema de emissão de bilhetes: 
 Um sistema automatizado para emitir bilhetes vende bilhetes de trem. Os usuários 
selecionam seu destino e inserem um cartão de crédito e um número de identificação 
pessoal. O bilhete é emitido, e sua conta de cartão de crédito, cobrada. Quando o 
usuário pressiona o botão de início, é ativado um display de menu de destinos possíveis, 
junto com uma mensagem ao usuário para selecionar um destino. Uma vez que o 
destino tenha sido selecionado, os usuários são convidados a inserir seu cartão de 
crédito. Sua validade é verificada e, em seguida, é solicitada ao usuário a entrada de um 
identificador pessoal. Quando a operação de crédito é validada, o bilhete é emitido 
4.3 Reescreva a descrição anterior usando a abordagem estruturada descrita neste capítulo. 
Resolva, de um modo apropriado, as ambiguidades identificadas. 
4.4 Escreva um conjunto de requisitos não funcionais para o sistema de emissão de bilhetes, 
definindo sua confiabilidade e tempo de resposta esperados. 
4.5 Usando a técnica sugerida neste capítulo, em que as descrições em linguagem natural são 
apresentadas em formato-padrão, escreva requisitos do usuário plausíveis para as seguintes 
funções: 
 
 
BPMN (Business Process Model and Notation): Notação para uma modelagem de processo de 
software 
 
OBJETIVOS 
Uma linguagem padrão ( comum para modelagem de processos de negócio, facilitando a 
comunicação e tornar um padrão 
Representar um processo de negócio privado detalhado; 
AS IS – Processos de negócios atuiais e antigos 
TO BE – Processos de negócios novos ou propostos 
Atender aos objetivos organizacionais através do mapeamento dos processos para alcançar as 
metas gerenciais e estratégicas do negócio. 
 
 
 
a meta primária da notação 
BPMN é fornecer uma notação que possa ser entendida por todos os usuários 
do negócio (analistas de processos/negócios que criam a versão inicial do processo), 
desenvolvedores responsáveis por implementar a tecnologia que auxiliará os processos 
e, finalmente, as pessoas que irão gerenciar e monitorar os processos. 
 
Entender quais as integrações entre os setores 
Tramitação de documentações, procedimentos, atividade de um processo de produção 
MODELO EKD