Text Material Preview
<p>4ºAula</p><p>PROCESSOS DE SOFTWARE</p><p>Objetivos de aprendizagem</p><p>Ao término desta aula, vocês serão capazes de:</p><p>• compreender os conceitos e modelos de processos de software;</p><p>• entender o modelos dos processos de software.</p><p>Olá, pessoal,</p><p>Nesta aula, vamos estudar como funcionam os Processos</p><p>de Software, que são as formas em que são estruturadas as</p><p>etapas para que um software seja desenvolvido.</p><p>Leia atentamente a esta aula e faça os exercícios propostos.</p><p>Em caso de dúvida estaremos a sua disposição.</p><p>Vamos lá?</p><p>Bons estudos!</p><p>91</p><p>Introdução a Engenharia de Software 28</p><p>1.</p><p>Seções de estudo</p><p>Processos de software</p><p>2. Modelos de processos de software</p><p>1 - Processos de software</p><p>Para Sommerville (2011), um processo de software diz</p><p>respeito ao conjunto de atividades que são relacionadas e que</p><p>levam à produção de um produto de software. Portanto, o</p><p>processo de software culmina no produto final, entendido</p><p>como produto de software. As atividades podem estar</p><p>relacionadas ao desenvolvimento de software a partir do zero,</p><p>seguindo uma linguagem padrão, como Java ou C.</p><p>Assim, um processo de software define que atividades</p><p>serão executadas para que um software seja desenvolvido. Ele</p><p>serve como um guia, para que possamos fazer um software</p><p>de qualidade. Para entendermos isso, vamos a uma analogia:</p><p>Um processo é uma receita que é seguida por um projeto; o</p><p>projeto concretiza uma abstração, que é o processo. Não se</p><p>deve confundir um processo (digamos, uma receita de bolo de</p><p>laranja) com o respectivo produto (bolo de laranja) ou com a</p><p>execução do processo através de um projeto (a confecção do</p><p>bolo de laranja por determinado cozinheiro, em determinado</p><p>dia).</p><p>Contudo, em aplicações de negócios não há necessidade</p><p>de seguir essa regra. No mundo nos negócios, cada vez</p><p>mais, há o desenvolvimento de novos softwares por meio da</p><p>modificação e alteração de sistemas já existentes. Estes podem</p><p>ser reconfigurados. Apesar de já existirem diversas variações</p><p>em um processo de software, basicamente, devem-se seguir</p><p>quatro atividades fundamentais:</p><p>1. . A funcionalidade do</p><p>software e as restrições a seu funcionamento</p><p>2. Projeto e implementação de software. O software deve</p><p>3. Validação de software. O software deve ser</p><p>validado para garantir que atenda às demandas</p><p>do cliente.</p><p>4. Evolução de software. O software deve evoluir</p><p>para atender às necessidades de mudança dos</p><p>clientes.</p><p>De alguma forma, essas atividades fazem parte de</p><p>todos os processos de software. Na prática, são</p><p>atividades complexas em si mesmas, que incluem</p><p>subatividades como validação de requisitos,</p><p>projeto de arquitetura, testes unitários etc.</p><p>Existem também as atividades que dão apoio ao</p><p>processo, como documentação e gerenciamento</p><p>2011, p. 18).</p><p>você elabora um produto ou sistema é importante percorrer</p><p>uma série de passos previsíveis – um roteiro que o ajuda a</p><p>criar a tempo um resultado de alta qualidade. O roteiro que</p><p>você segue é o processo de software” (PRESSMAN, 2006).</p><p>Continuando, em engenharia de software, os processos</p><p>podem ser definidos como as atividades realizadas para a</p><p>manutenção, para a aquisição, para a contratação de um</p><p>software. Nessa perspectiva, engloba todos os subprocessos</p><p>necessários. Um processo de software envolve diversos</p><p>subprocessos que determinam os requisitos, a análise, o</p><p>desenho, a implementação e os testes.</p><p>Sommerville diz quais são atividades fundamentais de</p><p>um processo de software:</p><p>• Especificação de softwa: a funcionalidade do</p><p>software e as restrições a seu funcionamento devem</p><p>ser definidas.</p><p>• Projeto e implementação de software: o software</p><p>deve ser produzido para atender às especificações.</p><p>• Validação de software: o software deve ser validado</p><p>para garantir que atenda às demandas do cliente.</p><p>• Evolução de software: o software deve evoluir para</p><p>atender às necessidades de mudança dos clientes.</p><p>(SOMMERVILLE, 2011, p. 18)</p><p>Quando se é necessário descrever ou discutir os</p><p>processos, geralmente, tratamos das suas atividades, e as</p><p>relacionamos a um modelo específico de dados e ao modo</p><p>como tais atividades estão descritas. Contudo, as descrições</p><p>do processo podem envolver, também:</p><p>• Produtos: diz respeito aos resultados de uma das</p><p>atividades do processo. Para exemplificar, uma</p><p>atividade de projeto de arquitetura resulta em um</p><p>modelo de arquitetura de software.</p><p>• Papéis: eles refletem as responsabilidades, as funções</p><p>das pessoas envolvidas no processo. Ex.: gerente de</p><p>configuração, programador, entre outros.</p><p>• Pré e pós-condições: são as declarações feitas</p><p>antes e depois de uma atividade do processo e que</p><p>validam a sua veracidade. Um exemplo disso é a</p><p>seguinte afirmação: é necessário que seja obtido uma</p><p>confirmação do cliente em relação à aprovação de</p><p>todos os requisitos (SOMMERVILLE, 2011, p. 19).</p><p>Já percebemos que todas as atividades relacionadas aos</p><p>processos de software são complexas e dependem de pessoas,</p><p>ou seja, os envolvidos devem exercer sua intelectualidade,</p><p>criatividade e ética. Para tanto, tudo precisa ser bem definido</p><p>e claro para que os sujeitos envolvidos atuem de modo a</p><p>favorecer a empresa. Assim, as pessoas dão o seu melhor</p><p>e o processo de software é aproveitado da melhor maneira</p><p>possível:</p><p>Para alguns sistemas, como sistemas críticos,</p><p>é necessário um processo de desenvolvimento</p><p>muito bem estruturado; para sistemas de</p><p>negócios, com requisitos que se alteram</p><p>Os processos de software, às vezes, são</p><p>categorizados como dirigidos a planos ou</p><p>processos ágeis. Processos dirigidos a planos</p><p>são aqueles em que todas as atividades são</p><p>planejadas com antecedência, e o progresso é</p><p>92</p><p>29</p><p>avaliado por comparação com o planejamento</p><p>inicial. Em processos ágeis, que discuto no</p><p>Capítulo 3, o planejamento é gradativo, e</p><p>é mais fácil alterar o processo de maneira</p><p>clientes. Conforme Boehm e Turner (2003),</p><p>cada abordagem é apropriada para diferentes</p><p>tipos de software. Geralmente, é necessário</p><p>encontrar um equilíbrio entre os processos</p><p>dirigidos a planos e os processos ágeis.</p><p>software, há espaço, em muitas organizações,</p><p>para melhorias no processo de software. Os</p><p>processos podem incluir técnicas ultrapassadas</p><p>ou não aproveitar as melhores práticas de</p><p>engenharia de software da indústria. De fato,</p><p>muitas empresas ainda não se aproveitam dos</p><p>métodos da engenharia de software em seu</p><p>desenvolvimento de software.</p><p>Em organizações nas quais a diversidade de</p><p>processos de software é reduzida, os processos</p><p>de software podem ser melhorados pela</p><p>padronização. Isso possibilita uma melhor</p><p>comunicação, além de redução no período de</p><p>treinamento, e torna mais econômico o apoio</p><p>ao processo automatizado. A padronização</p><p>também é um importante primeiro passo</p><p>na introdução de novos métodos e técnicas</p><p>de engenharia de software, assim como as</p><p>boas práticas de engenharia de software</p><p>(SOMMERVILLE, 2011, p. 19).</p><p>Agora que vocês já têm um conhecimento importante</p><p>sobre o assunto, é hora de aprofundarmos, e verificarmos</p><p>alguns dos modelos de processos de software.</p><p>2 - Modelos de processos de software</p><p>Um modelo de desenvolvimento diz respeito a uma</p><p>apresentação do processo de desenvolvimento que irá definir</p><p>as etapas relacionadas ao desenvolvimento de software. Eles</p><p>definem, também, de que modo as etapas serão conduzidas e</p><p>relacionadas de modo a alcançar o objetivo, que é o</p><p>desenvolvimento de um produto de software de alta qualidade,</p><p>e com o menor custo possível. Vamos conhecer cada um</p><p>deles a seguir.</p><p>2.1 - O Modelo em cascata</p><p>O primeiro modelo que vamos estudar é o modelo em</p><p>cascata. Aliás, ele é o primeiro modelo estudado. Sua origem</p><p>está relacionada aos processos mais abrangentes da engenharia</p><p>de sistema. Devido ao encadeamento de uma fase na outra,</p><p>vem seu nome: modelo em cascata:</p><p>Parreira Júnior explica como funciona esse processo:</p><p>O resultado de cada fase envolve um ou mais</p><p>documentos que são aprovados e assinados.</p><p>A fase seguinte só é iniciada após a conclusão</p><p>da fase precedente, mas na prática eles se</p><p>sobrepõem e trocam informações.</p><p>Durante</p><p>por diante. O processo não é um modelo</p><p>linear simples, mas envolve uma sequência de</p><p>interações das atividades de desenvolvimento</p><p>(PARREIRA JUNIOR, 2011, p. 29).</p><p>Figura 1 – O Modelo em Cascata</p><p>Fonte: SOMMERVILLE, 2011, p. 20</p><p>O modelo em cascata envolve, basicamente, as seguintes</p><p>etapas:</p><p>1. Análise e definição de requisitos: são definidas todas</p><p>as atividades e exigências, a partir do contato com o</p><p>usuário.</p><p>2. Projeto de sistema e software: faz-se a identificação e</p><p>descrição das abstrações do sistema de software e de</p><p>seus relacionamentos. Diz respeito a uma arquitetura</p><p>geral do sistema.</p><p>3. Implementação e teste unitário: observa-se, nessa</p><p>atividade, se cada uma das unidades do software está</p><p>atendendo a sua especificação e função.</p><p>4. Integração e teste de sistema: as unidades,</p><p>primeiramente, individuais, nessa fase, não</p><p>integradas e testadas no conjunto. Note que, na fase</p><p>anterior, elas foram testadas individualmente; aqui,</p><p>são testadas no conjunto.</p><p>5. Operação e manutenção: é a fase mais longa,</p><p>geralmente, pois o sistema é utilizado. Durante</p><p>esse processo, a partir do momento que o sistema</p><p>está em uso, podem ser corrigidas possíveis falhas.</p><p>(SOMMERVILLE, 2011)</p><p>2.2 - Prototipação</p><p>Esse modelo é indicado quando o cliente define uma</p><p>série de objetivos gerais para o software, mas não identificou</p><p>os requisitos de entrada, de processamento e de saída de</p><p>modo detalhado. Inicialmente, a finalidade de um protótipo</p><p>era a de avaliar os requisitos e, então, o desenvolvimento</p><p>tradicional não era necessário. Agora, praticamente não</p><p>há definição entre prototipação e o desenvolvimento de</p><p>sistemas. Um protótipo pode ser entendido com a primeira</p><p>versão do software. O objetivo é o de abordar a questão de</p><p>interface com o usuário, definir requisitos e discutir, com o</p><p>cliente, a possibilidade de desenvolvimento do sistema.</p><p>93</p><p>Mobile User</p><p>Introdução a Engenharia de Software 30</p><p>A prototipação permite que clientes e desenvolvedores</p><p>fiquem em interação constante e, juntos, elaboram os</p><p>requisitos e funcionalidades do sistema. Deve-se atentar</p><p>que, muitas vezes, a prototipação encarece o sistema, pois,</p><p>alguns desenvolvedores costumam elaborar um projeto</p><p>de protótipo e um projeto do sistema final, o que vem</p><p>provocando a redução de sua utilização.</p><p>Figura 2 – Etapas da Prototipação</p><p>Fonte: Disponível em: <https://centraldaengenharia.wordpress.com/2011/02/09/</p><p>paradigmas-prototipacao>. Acesso em 20 nov. 2018.</p><p>A principal aplicação da prototipação é no auxílio a</p><p>clientes e desenvolvedores no entendimento dos requisitos</p><p>para o sistema. Os usuários podem experimentar o protótipo</p><p>para ver como o sistema pode apoiar seu trabalho, o que é</p><p>uma vantagem. Esse modelo pode também revelar erros e</p><p>omissões nos requisitos, ou seja, pode promover a validação</p><p>dos requisitos.</p><p>O desenvolvimento da prototipação pode, assim,</p><p>reduzir diversos riscos nos requisitos dos sistemas.</p><p>2.3 - O modelo espiral</p><p>O modelo espiral foi preparado para abranger, de</p><p>modo geral, as melhores características do ciclo de vida</p><p>clássico e as da prototipação. Além disso, o propósito é o</p><p>de adicionar um novo elemento: análise de riscos. Notamos</p><p>que ele parte de outros tipos de modelo, e busca lidar com</p><p>os benefícios ofertados por um e outro. Para tanto, suas</p><p>etapas envolvem, necessariamente:</p><p>• Planejamento;</p><p>• Análise e projeto;</p><p>• Prototipação;</p><p>• Avaliação.</p><p>Os passos vão sendo retomados e somente são</p><p>finalizados quando o projeto é obtido. Há, portanto, para</p><p>seu desenvolvimento, quatro atividades fundamentais:</p><p>• Planejamento: determinam-se os objetivos, as</p><p>alternativas e as limitações. Tais determinações</p><p>devem ser feitas em cada ciclo, e já serem pensadas</p><p>de acordo com o ciclo posterior;</p><p>• Análise dos riscos: faz-se a investigação das</p><p>alternativas, das possibilidades e caminha-se para</p><p>resolução de problemas, ou seja, resolução dos</p><p>riscos.</p><p>• Engenharia: é o momento no qual é feito o</p><p>desenvolvimento e a verificação da solução</p><p>possível.</p><p>• Avaliação do cliente: em contato com o</p><p>cliente, verifica-se o andamento de cada ciclo.</p><p>(SOMMERVILLE, 2011).</p><p>Nota-se que esse modelo se preocupa com uma</p><p>coisa fundamental: a redução dos riscos. Cada etapa é</p><p>feita de modo a possibilitar que se compreendam quais</p><p>são as problemáticas e as soluções possíveis antes que</p><p>se dê encaminhamento. A análise criteriosa por parte do</p><p>engenheiro de software e o contato permanente com o</p><p>cliente são elementos básicos.</p><p>Figura 3 – Modelo Espiral Típico</p><p>Fonte: PRESSMAN, 2016, p. 48</p><p>2.4 - Desenvolvimento baseado</p><p>em componente (desenvolvimento</p><p>Vamos agora estudar como funciona o desenvolvimento</p><p>baseado em componente. Para tanto, vamos pensar: a</p><p>maioria dos projetos de software possibilita que haja</p><p>reaproveitamento de algum software. Desse modo, é</p><p>importante que a pessoa responsável já tenha certo</p><p>conhecimento dos projetos, bem como dos códigos a</p><p>serem elaborados.</p><p>A partir desse conhecimento, é possível que se</p><p>aproveite o software e que este seja incorporado ao sistema.</p><p>Há uma possibilidade significativa de software que podem</p><p>ser utilizados por vários sistemas. Isso facilita e agiliza o</p><p>trabalho, além de reduzir custos e riscos. Certamente,</p><p>garante-se entrega mais rápida e maior satisfação do cliente.</p><p>2.5 - Entrega incremental</p><p>Há, também, a entrega incremental. Ela diz respeito a</p><p>uma abordagem por meio da qual é possível desenvolver</p><p>alguns softwares, bem como elaborar alguns incrementos</p><p>que seja possível que se entregue ao cliente e se implante para</p><p>uso em um ambiente operacional. Nesse tipo de processo,</p><p>o cliente identifica o serviço a ser fornecido pelo sistema,</p><p>avaliando qual é mais e qual é menos importante para ele.</p><p>A partir daí, uma série de incrementos é definida e cada</p><p>um proporciona, com isso, um determinado subconjunto</p><p>da funcionalidade do sistema.</p><p>94</p><p>31</p><p>Figura 4 – Etapas da Entrega Incremental</p><p>Fonte: SOMMERVILLE, 2011, p. 32</p><p>A seguir, vamos abordar as vantagens da Entrega</p><p>Incremental.</p><p>As vantagens da Entrega Incremental</p><p>A entrega incremental tem uma série de vantagens:</p><p>1. Os clientes podem usar os incrementos iniciais como protótipos e</p><p>ganhar experiência, a qual informa seus requisitos para incrementos</p><p>posteriores do sistema. Ao contrário de protótipos, trata-se, aqui,</p><p>de partes do sistema real, ou seja, não existe a necessidade de</p><p>reaprendizagem quando o sistema completo está disponível.</p><p>2. Os clientes não necessitam esperar até que todo o sistema seja</p><p>entregue para obter ganhos a partir dele. O primeiro incremento</p><p>satisfaz os requisitos mais críticos de maneira que eles possam usar o</p><p>software imediatamente.</p><p>3. O processo mantém os benefícios do desenvolvimento incremental,</p><p>o que deve facilitar a incorporação das mudanças no sistema.</p><p>incrementos integrados, os serviços mais importantes recebem a</p><p>encontrarem falhas de software nas partes mais importantes do</p><p>sistema é menor.</p><p>No entanto, existem problemas com a entrega incremental:</p><p>1. A maioria dos sistemas exige um conjunto de recursos básicos,</p><p>usados por diferentes partes do sistema. Como os requisitos</p><p>necessários a todos os incrementos.</p><p>2. O desenvolvimento iterativo também pode ser difícil quando um</p><p>sistema substituto está sendo desenvolvido.</p><p>Portanto, é difícil obter feedbacks úteis dos clientes.</p><p>completa do sistema é parte do contrato de desenvolvimento do</p><p>requer uma nova forma de contrato, à qual os grandes clientes, como</p><p>agências governamentais, podem achar difícil de se adaptar.</p><p>Fonte: SOMMERVILLE, 2011, p. 32</p><p>Agora, vamos abordar o Processo Unificado da Rational.</p><p>2.6</p><p>Esse processo foi criado para dar suporte ao</p><p>desenvolvimento voltado aos objetos. Ele pode fornecer</p><p>uma forma sistematizada para que se obtenham vantagens</p><p>no uso da UML. Ele foi desenvolvido pela Rational Software</p><p>Corporation e foi adquirido em 2003 pela IBM.</p><p>Sua proposta é a de, principalmente, atender às</p><p>prioridades dos usuários. Com isso, garante-se uma produção</p><p>de qualidade dentro de um orçamento e cronograma</p><p>viável</p><p>à equipe e ao cliente. O RUP estipula, de início, os papéis de</p><p>cada um dentro do planejamento. Ele conta com quatro fases:</p><p>• diz respeito</p><p>às tarefas de comunicação com o cliente e ao</p><p>planejamento. São estabelecidas as prioridades, as</p><p>etapas, entre outros.</p><p>• Fase de Elaboração: é o momento em que se faz</p><p>o modelo genérico do processo. O propósito é o de</p><p>analisar o problema, repassar os riscos e arquitetar o</p><p>projeto, ainda em sua forma básica.</p><p>• Fase de Construção: É o momento em que se faz,</p><p>de fato, o desenvolvimento do projeto. Faz-se, aqui,</p><p>a construção do sistema de software, e o enfoque é</p><p>no desenvolvimento de componentes.</p><p>• Fase de Transição: diz respeito à entrega do</p><p>software ao usuário. É, também, a fase de testes. Com</p><p>isso, é possível disponibilizar o sistema ao usuário,</p><p>que pode avaliá-lo. (SOMMERVILLE, 2011)</p><p>A figura a seguir mostra como funciona as fases do RUP.</p><p>E, com isso, finalizamos a nossa aula de hoje. O conteúdo</p><p>que vimos aqui é apenas uma introdução ao que veremos mais</p><p>adiante, na matéria de Metodologias de Desenvolvimento de</p><p>Software. Na próxima aula, veremos como funciona a Análise</p><p>de Requisitos. Até logo.</p><p>Retomando a aula</p><p>1 - PROCESSOS DE SOFTWARE</p><p>A seção I abordou alguns conceitos acerca dos processos</p><p>de software. Nesta aula, foi possível entender que um</p><p>processo de software diz respeito ao conjunto de atividades</p><p>que são relacionadas e que levam à produção de um produto</p><p>de software. Portanto, o processo de software culmina no</p><p>produto final, entendido como produto de software.</p><p>2 - MODELOS DE PROCESSOS DE SOFTWARE</p><p>Esta seção, mais específica, trouxe à tona diversas</p><p>metodologias de processos de software. Conhecemos cada</p><p>uma delas, mas, certamente, é possível ampliar os estudos. Que</p><p>tal verificarmos alguns links que serão úteis nesse sentido?</p><p>95</p><p>Introdução a Engenharia de Software 32</p><p>PAULA FILHO, Wilson de Pádua. Engenharia de</p><p>software: fundamentos, métodos e padrões. 3. ed. Rio de</p><p>Janeiro: LTC, 2012.</p><p>PRESSMAN, Roger S. Engenharia de software: uma</p><p>abordagem profissional. 8. ed. São Paulo: McGraw-Hill;</p><p>Porto Alegre: Bookman; Santana: AMGH Editora, 2016.</p><p>SOMMERVILLE, Ian. Engenharia de software. 9. ed. São</p><p>Paulo: Pearson Addison Wesley, 2014.</p><p>Vale a pena ler</p><p>Vale a pena</p><p>Minhas anotações</p><p>96</p>
