Baixe o app para aproveitar ainda mais
Prévia do material em texto
ENGENHARIA DE SOFTWARE Professora Me. Márcia Cristina Dadalto Pascutti Professora Esp. Janaína Aparecida de Freitas Professora Esp. Talita Tonsic Gasparotti GRADUAÇÃO Unicesumar C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a Distância; PASCUTTI, Márcia Cristina Dadalto; FREITAS, Janaína Aparecida de; GASPAROTTI,Talita Tonsic. Engenharia de Software. Márcia Cristina Dadalto Pascutti; Janaína Aparecida de Freitas; Talita Tonsic Gasparotti. (Reimpressão revista e atualizada) Maringá-Pr.: UniCesumar, 2016. 2ª edição revista e atualizada 184 p. “Graduação - EaD”. 1. Engenharia. 2. Software . 3. EaD. I. Título. CDD - 22 ed. 005.1 CIP - NBR 12899 - AACR/2 Ficha catalográfica elaborada pelo bibliotecário João Vivaldo de Souza - CRB-8 - 6828 Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de Matos Silva Filho Pró-Reitor de EAD Willian Victor Kendrick de Matos Silva Presidente da Mantenedora Cláudio Ferdinandi NEAD - Núcleo de Educação a Distância Direção Operacional de Ensino Kátia Coelho Direção de Planejamento de Ensino Fabrício Lazilha Direção de Operações Chrystiano Mincoff Direção de Mercado Hilton Pereira Direção de Polos Próprios James Prestes Direção de Desenvolvimento Dayane Almeida Direção de Relacionamento Alessandra Baron Head de Produção de Conteúdos Rodolfo Encinas de Encarnação Pinelli Gerência de Produção de Conteúdos Gabriel Araújo Supervisão do Núcleo de Produção de Materiais Nádila de Almeida Toledo Supervisão de Projetos Especiais Daniel F. Hey Coordenador de Conteúdo Fabiana de Lima Design Educacional Yasminn Zagonel Iconografia Isabela Soares Silva Projeto Gráfico Jaime de Marchi Junior José Jhonny Coelho Arte Capa André Morais de Freitas Editoração Matheus Felipe Davi Qualidade Textual Hellyery Agda Pedro Barth Nayara Valenciano Ilustração Marta Sayuri Kakitani Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos. A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para liderança e so- lução de problemas com eficiência tornou-se uma questão de sobrevivência no mundo do trabalho. Cada um de nós tem uma grande responsabilida- de: as escolhas que fizermos por nós e pelos nos- sos farão grande diferença no futuro. Com essa visão, o Centro Universitário Cesumar assume o compromisso de democratizar o conhe- cimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros. No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária” –, o Centro Universi- tário Cesumar busca a integração do ensino-pes- quisa-extensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que contribua para o desenvolvimento da consci- ência social e política e, por fim, a democratização do conhecimento acadêmico com a articulação e a integração com a sociedade. Diante disso, o Centro Universitário Cesumar al- meja ser reconhecido como uma instituição uni- versitária de referência regional e nacional pela qualidade e compromisso do corpo docente; aquisição de competências institucionais para o desenvolvimento de linhas de pesquisa; con- solidação da extensão universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação da comunidade interna; qualidade da gestão acadêmica e administrati- va; compromisso social de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também pelo compromisso e relaciona- mento permanente com os egressos, incentivan- do a educação continuada. Diretoria Operacional de Ensino Diretoria de Planejamento de Ensino Seja bem-vindo(a), caro(a) acadêmico(a)! Você está iniciando um processo de transformação, pois quando investimos em nossa formação, seja ela pessoal ou profissional, nos transformamos e, consequentemente, transformamos também a sociedade na qual estamos inseridos. De que forma o fazemos? Criando oportu- nidades e/ou estabelecendo mudanças capazes de alcançar um nível de desenvolvimento compatível com os desafios que surgem no mundo contemporâneo. O Centro Universitário Cesumar mediante o Núcleo de Educação a Distância, o(a) acompanhará durante todo este processo, pois conforme Freire (1996): “Os homens se educam juntos, na transformação do mundo”. Os materiais produzidos oferecem linguagem dialógica e encontram-se integrados à proposta pedagógica, con- tribuindo no processo educacional, complementando sua formação profissional, desenvolvendo competên- cias e habilidades, e aplicando conceitos teóricos em situação de realidade, de maneira a inseri-lo no mercado de trabalho. Ou seja, estes materiais têm como principal objetivo “provocar uma aproximação entre você e o conteúdo”, desta forma possibilita o desenvolvimento da autonomia em busca dos conhecimentos necessá- rios para a sua formação pessoal e profissional. Portanto, nossa distância nesse processo de cresci- mento e construção do conhecimento deve ser apenas geográfica. Utilize os diversos recursos pedagógicos que o Centro Universitário Cesumar lhe possibilita. Ou seja, acesse regularmente o AVA – Ambiente Virtual de Aprendizagem, interaja nos fóruns e enquetes, assista às aulas ao vivo e participe das discussões. Além dis- so, lembre-se que existe uma equipe de professores e tutores que se encontra disponível para sanar suas dúvidas e auxiliá-lo(a) em seu processo de aprendiza- gem, possibilitando-lhe trilhar com tranquilidade e segurança sua trajetória acadêmica. A U TO RE S Professora Me. Márcia Cristina Dadalto Pascutti Possui graduação em Processamento de Dados pela Universidade Estadual de Maringá (1989) e mestrado em Ciência da Computação pela Universidade Federal do Rio Grande do Sul (2002). Atualmente, é professora no Instituto Federal do Paraná - Campus Umuarama e está cursando o doutorado na PUC- PR. Atua, principalmente, nos seguintes temas: arquitetura de computadores, engenharia de software, processamento de imagens, reconhecimento de padrões, visão computacional. Professora Esp. Janaína Aparecida de Freitas Possui graduação em Informática pela Universidade Estadual de Maringá (2010). Especialização em MBA em Teste de Software pela Universidade UNICEUMAR, Brasil. (2012). Trabalhou na iniciativa privada, na área de Analise de Sistemas e Testes de Software. Tem experiência na área de Engenharia de Software com ênfase em Análise de Requisitos, Gestão de Projetos de Software, Métricas e Estimativas, Qualidade e Teste de Software. Atualmente cursando o curso Técnico em Qualidade no Senac-PR e Licenciatura em Letras - Português/Inglês na UniCesumar. Professora Esp. Talita Tonsic Gasparotti Possui formação em Análise e Desenvolvimento de Sistemas - PD, especialização em Gestão e Coordenação Escolar e especialista em Educação a Distância e as Tecnologias Educacionais SEJA BEM-VINDO(A)! Prezado(a) acadêmico(a), é com muito prazer que apresento a você o livro de engenha- ria de software. A engenharia de software possui uma gama imensa de tópicos, que não seria possível abarcar em cinco unidades (como este livro está organizado), então abordei os assuntos iniciais, sem os quais não seria possível entender todo o contexto da disciplina. Se você gostar da disciplina e quiser se aprofundar, pode consultar os livros citados durante as unidades. Neles, com certeza, você aprenderá muitos outros assun- tos e poderá ter certeza de que a engenharia de software realmente é muito importante quando tratamos de software, como um todo. Este livro estáorganizado em cinco unidades, sendo que todas estão estreitamente re- lacionadas. Na unidade I, apresentarei alguns conceitos referentes à disciplina. Você notará, durante a leitura das outras unidades, que esses conceitos são utilizados com frequência. A engenharia de software surgiu da necessidade de tornar o desenvolvimento de sof- tware confiável, com etapas bem definidas, com custo e cronograma previsíveis, o que, até a época de 1968, quando o termo engenharia de software foi proposto, não aconte- cia. Gostaria de ressaltar que software compreende, além dos programas, toda a docu- mentação referente a ele, sendo que a engenharia de software é a disciplina que trata dessa documentação. Depois, na segunda unidade, começaremos a aplicar os conceitos já estudados e mos- trarei a você que um processo de software genérico é composto de algumas etapas bá- sicas que farão parte de qualquer modelo de processo de software. Essas etapas básicas são: i) a especificação dos requisitos do software a ser desenvolvido; ii) o projeto e a im- plementação do software; iii) a validação do software e, finalmente iv) a evolução do sof- tware. Nesta unidade, abordarei três modelos de processo de software, mas a literatura traz outros modelos. Meu objetivo é mostrar alguns modelos propostos pela literatura, mas, ao final dessa unidade, você poderá elaborar o seu próprio modelo, colocando as etapas na ordem que você achar melhor para a sua empresa. A unidade III é bastante específica, tratando apenas dos conceitos relacionados a requi- sitos de software, já que, para o desenvolvimento de um software da forma esperada pelo cliente, é fundamental que todos os requisitos tenham sido claramente definidos. Um requisito deve estabelecer o que o sistema deve fazer, bem como as restrições sobre seu funcionamento e implementação, podendo ser classificado em requisito funcional e não funcional. Os requisitos funcionais dizem respeito aos serviços que o software deve fornecer, por exemplo, o cadastro dos pacientes de uma clínica odontológica, a emissão de um relatório de vendas. Todos esses requisitos, tanto os funcionais quanto os não funcionais, devem ser claramente definidos no documento de requisitos, pois é a par- tir desse documento que o sistema será modelado, projetado, implementado, ou seja, todo o desenvolvimento do sistema será baseado nesse documento. Em alguns casos, o documento de requisitos pode servir como um contrato entre o cliente e a empresa desenvolvedora do software. APRESENTAÇÃO ENGENHARIA DE SOFTWARE Para você ter uma ideia de como é um documento de requisitos, mostrarei o de uma locadora de filmes na unidade III. O exemplo é bem simples, mas contém detalhes suficientes para a continuidade do processo de desenvolvimento de software. Então, de posse do documento de requisitos, começaremos a estudar a penúltima unidade do nosso livro, a unidade IV que trata da modelagem do sistema. Nessa unidade, utilizaremos os conceitos de orientação a objetos e de UML estudados na primeira unidade. A modelagem é a parte fundamental de todas as atividades rela- cionadas ao processo de software, sendo que, os modelos que são construídos nessa etapa servem para comunicar a estrutura e o comportamento desejados do sistema, a fim de que possamos melhor compreender o sistema que está sendo elaborado. Outro ponto importante que é necessário deixar registrado, é que de nada vale uma documentação desatualizada, por isso, é importante utilizar uma ferramenta CASE para criar e manter a documentação. Representaremos estes modelos por meio de diagramas, utilizando a UML como notação gráfica. Na primeira unidade já explica- mos a importância da UML e agora começaremos a utilizá-la de fato. A UML tem diversos diagramas, mas, em nosso material, trataremos somente do Diagrama de Casos de Uso e do Diagrama de Classes. A fim de auxiliar o entendimento de cada um deles, elaborei uma espécie de tutorial explicando a sua elaboração passo a passo. Isso foi feito para facilitar o seu entendimento, pois esses diagramas são os mais im- portantes e os mais utilizados da UML, servindo de base para os demais diagramas. E, finalmente, chegamos à última unidade do nosso material. Essa unidade é o fe- chamento das etapas do processo de software, ou seja, tratará das etapas de pro- jeto, implementação, teste e manutenção de software. Assim, você compreenderá todo o processo de software com as etapas que o englobam. O projeto de software é onde são definidas as interfaces do sistema. É importante que o usuário participe ativamente deste processo, afinal, será ele quem vai passar a maior par- te do tempo interagindo com o sistema. Depois disso, o sistema pode ser implementado, ou seja, é hora de transformar todo o trabalho realizado até o momento em código fonte. À medida que o sistema vai sendo desenvolvido, cada programa vai sendo valida- do pelo desenvolvedor, mas isso só não basta. É muito importante que a etapa de validação seja cuidadosamente realizada pela equipe de desenvolvimento, pois é preciso assegurar que o sistema funcionará corretamente. Depois que o sistema é colocado em funcionamento, ele precisa evoluir para conti- nuar atendendo as necessidades dos usuários. Em todas estas etapas é importante a aplicação das técnicas da engenharia de software. Assim, chegamos ao final do nosso livro. Espero, sinceramente, que sua leitura seja agradável e que esse conteúdo possa contribuir para seu crescimento pessoal, aca- dêmico e profissional. Prof.ª Márcia. Prof.ª Janaína. Prof.ª Talita. APRESENTAÇÃO SUMÁRIO 09 UNIDADE I INTRODUÇÃO À ENGENHARIA DE SOFTWARE 15 Introdução 16 Conceitos Básicos Sobre Software 18 História da Engenharia De Software 22 Tipos de Aplicações de Software 25 Software Legado 28 Considerações Finais 33 Referências 34 Gabarito UNIDADE II PROCESSOS DE SOFTWARE 37 Introdução 38 Processos de Software 40 Modelos de Processo de Software 48 Atividades Básicas do Processo de Software 54 Considerações Finais 60 Referências 61 Gabarito SUMÁRIO 10 UNIDADE III REQUISITOS DE SOFTWARE 65 Introdução 66 Requisitos de Software 72 O Documento de Requisitos de Software 78 Engenharia de Requisitos 91 Considerações Finais 95 Referências 96 Gabarito UNIDADE IV MODELAGEM DE SISTEMAS 101 Introdução 102 Modelagem de Sistemas 104 Diagrama de Casos de Uso 114 Diagrama de Classes 131 Ferramentas Case (Computer-Aided Software Engineering) 134 Conceitos Básicos de Orientação a Objetos 142 Uml – Unified Modeling Languag 144 Considerações Finais 149 Referências 150 Gabarito SUMÁRIO 11 UNIDADE V PROJETO, IMPLEMENTAÇÃO, TESTES E MANUTENÇÃO DE SOFTWARE 157 Introdução 158 Projeto de Software 164 Implementação de Software 168 Teste de Software 173 Manutenção de Software 176 Considerações Finais 182 Referências 183 Gabarito 184 CONCLUSÃO U N ID A D E I Professora Me. Márcia Cristina Dadalto Pascutti Professora Esp. Talita Tonsic Gasparotti INTRODUÇÃO À ENGENHARIA DE SOFTWARE Objetivos de Aprendizagem ■ Entender o que é engenharia de software e qual a sua importância. Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade: ■ Conceitos básicos sobre Software ■ História da Engenharia de Software ■ Tipos de Aplicações de Software ■ Mitos Relativos ao Software ■ Software Legado INTRODUÇÃO Caro(a) aluno(a), nesta primeira unidade, trataremos alguns conceitos relacio- nados à engenharia de software como um todo, que serão fundamentais para o entendimento de todas as unidades. O termo engenharia de software foi proposto, inicialmente, em 1968, em uma conferênciaorganizada para discutir o que era chamado de crise de sof- tware. Essa crise foi originada em função do hardware, que nessa época tinha seu poder de processamento e memória aumentados, sendo que o software deveria acompanhar esse avanço. E o que se notou, na época, é que o desenvolvimento de grandes sistemas de maneira informal, sem seguir regras ou etapas pré-defi- nidas, não era suficiente. O software desenvolvido, até então, não era confiável, não era desenvolvido dentro do tempo e custos previstos inicialmente, seu desempenho era insatisfa- tório e era difícil de dar manutenção. Os custos em relação ao hardware estavam caindo, em função de que a sua produção passou a ser em série, porém, o custo do software não acompanhava essa queda, muitas vezes, sendo aumentado. A ideia inicial da engenharia de software era tornar o desenvolvimento de software um processo sistematizado, em que seriam aplicadas técnicas e méto- dos necessários para controlar a complexidade inerente aos grandes sistemas (SOMMERVILLE, 2007, p. 4). A engenharia de software é tão vasta que o software atual está envolvido intrinsecamente em nosso cotidiano, portanto é impossível ignorarmos sua importância. A engenharia de software moderna tem como objetivo elaborar metodolo- gias baseadas na evolução, ou seja, os softwares modificam-se continuamente e também novos softwares são construídos a partir dos antigos. Neste livro, abordaremos somente alguns tópicos da engenharia, pois, com certeza, precisaríamos de dezenas de livros como esse para esgotar esse assunto, portanto, gostaria de deixar claro, que aqui estudaremos somente uma pequena parte dessa abrangente disciplina. Introdução Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 15 ©shutterstock INTRODUÇÃO À ENGENHARIA DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E16 CONCEITOS BÁSICOS SOBRE SOFTWARE O software é um segmento de instru- ções que serão analisadas e processadas pelo computador, ele dará significado a elas com o objetivo de executar tarefas específicas, pois são os softwares que comandam o funcionamento de qual- quer computador; o software é a parte lógica que fornece explicações para o hardware do computador. Pressman (2011 p. 32) afirma que: “Software de computadores continua a ser uma tecnologia única e mais impor- tante no cenário mundial”. Podemos observar outra percepção do que é o software: Software de computador é um produto desenvolvido por profissionais de software que também dão suporte a ele a longo prazo e abrange pro- gramas executáveis em computadores de diversos portes ou arquitetu- ra, conteúdos que são apresentados quando programas são executados, informações descritivas em forma impressa ou virtual. (MEDEIROS, 2016, online). De acordo com Sommerville (2007), o software é composto não somente pelos programas, mas também pela documentação associada a esses programas. Para Pressman (2011), o software possui, pelo menos, três características que o diferenciam do hardware: 1. Software é desenvolvido ou passa por um processo de engenharia, não sendo fabricado no sentido clássico. Apesar de existir semelhanças entre o desenvolvimento de software e a fabricação de hardware, essas atividades são muito diferentes. Os custos de software concentram-se no processo de engenharia, por causa disso os projetos de software não podem ser conduzidos como se fossem pro- jetos de fabricação. Conceitos Básicos Sobre Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 17 2. Software não se desgasta. Normalmente, o hardware apresenta taxas de defeitos mais altas no início de sua vida, porém esses defeitos são corrigidos tendo assim a taxa decres- cida, ou seja, atingindo um nível estável. Porém, com o uso, o hardware pode se desgastar devido à poeira, má utilização, temperaturas extremas e outros. Já com o software é diferente, ou seja, ele não está sujeito aos problemas ambientais, como o hardware. Em relação aos problemas ini- ciais, com o software também acontece assim, pois alguns defeitos ainda podem passar pela etapa de validação do software. Quando um componente de hardware se desgasta, ele normalmente é tro- cado por um novo componente e o hardware volta a funcionar. Com o software, isso não acontece, não tem como simplesmente trocar o com- ponente, pois quando um erro acontece no software, pode ser de projeto, de requisito mal definido, levando o software a sofrer manutenção, que pode ser considerada mais complexa que a do hardware. 3. Embora a indústria caminhe para a construção com base em componentes, a maioria dos softwares continua a ser construída de forma personali- zada (sob encomenda). A reutilização de componentes de hardware é parte natural do seu pro- cesso de engenharia, já para o software é algo que apenas começou a ser alcançado (PRESSMAN, 2011, p. 34). Os componentes reutilizáveis de software são criados para que o desenvolvedor possa se concentrar nas partes do projeto que representam algo novo. Esses componentes encap- sulam dados e o processamento aplicado a eles, possibilitando criar novas aplicações a partir de partes reutilizáveis. “Software não se desgasta, mas ele se deteriora.” – autor desconhecido. ©shutterstock INTRODUÇÃO À ENGENHARIA DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E18 HISTÓRIA DA ENGENHARIA DE SOFTWARE A engenharia do software se define: “[...] o estabelecimento e o emprego de sólidos princípios de modo a obter software de maneira econômica, que seja confiável e funcione de forma eficiente em máquinas reais” (MEDEIROS, 2016, online). A principal característica da engenharia do software são seus métodos e téc- nicas que são utilizados para o desenvolvimento do software. Segundo Tsui e Karam (2013), o termo engenharia do software foi mencio- nado pela primeira vez em uma conferência da OTAN (Organização do Tratado do Atlântico Norte) conduzida na Alemanha em 1968. Tendo como objetivo aplicar técnicas e utilizar ferramentas na área da com- putação, para o desenvolvimento e a produção de software, é preciso planejar a curto e longo prazo a equipe que vai ser montada e a qualidade do produto e do seu processo, e tudo isso está presente no nosso dia a dia; as pessoas não perce- bem, mas estamos ligados à engenharia de software no nosso cotidiano. Segundo Sommerville (2011), a engenharia de software é uma disciplina cujo foco é o desenvolvimento de sistemas de software de alta qualidade por um custo acessível. Além disso, é preciso ter em conta que “o software é abstrato e intangível, História da Engenharia De Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 19 e que esta engenharia é preocupada com todos os aspectos da produção de software, desde os estágios iniciais de especificação de um sistema até a manutenção do sis- tema após ter sido posto em uso” (TSUI; KARAM 2013). Essa disciplina ou área de conhecimento surgiu em decorrência da preocupação em contornar a crise que estava se abatendo no software e dar a ele um tratamento de engenharia. Isso aconteceu em 1970, fazendo formar a engenharia do software, que veio para implementar sistemas mais complexos. Segundo Sommerville (2011), “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 este programa operar corretamente”. Além disso: Para ser considerada como prática de engenharia profissional deve in- cluir o código e os regulamentos que seus membros devem seguir. Por- tanto, a engenharia do software também inclui diretivas para a aqui- sição de conhecimento por parte de seus membros e diretivas para as práticas comportamentais de seus membros (TSUI; KARAM, 2013, p. 36). As pessoas que trabalham diretamente com a engenharia do software estão envolvidas e dirigem seus conhecimentos para o desenvolvimento do software, atentas à manutenção e adequação, bem como aos seus diferentes processos produtivos. De acordo com Sommerville (2011), “a engenharia de software é uma dis- ciplina cujo foco está em todos os aspectos da produção de software, desde os estágios iniciais da especificação do sistema até sua manutenção”. Para Sommerville (2011, p. 5), a engenharia de software é importante por dois motivos: 1. A sociedade, cada vez mais, depende de sistemas de software avançados, portanto é preciso que os engenheiros de software sejam capazes de pro- duzir sistemas confiáveis de maneira econômica e rápida. 2. A longo prazo, normalmente, é mais barato usar métodos e técnicas propostos pela engenharia de software, ao invés de somente escrever os programas como se fossem algum projeto pessoal. Para a maioria dos sis- temas, o maior custo está na sua manutenção, ou seja, nas alterações que são realizadas depois que o sistema é implantado. INTRODUÇÃO À ENGENHARIA DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E20 A PRÁTICA DA ENGENHARIA DE SOFTWARE De acordo com Pressman (2011, p. 43), devemos utilizar os seguintes princí- pios e conceitos: 1. Compreender o problema: nem sempre é fácil o quanto pensamos. Quem tem interesse na solução do problema? Quais são os interessados? Quais recursos, dados e funções são necessários para resolver apropria- damente o problema? O problema pode ser compartimentalizado? É possível representar em problemas menores? Talvez seja mais fácil para ser compreendido. O problema pode ser representado graficamente? É possível termos um modelo analítico? 2. Planejar uma solução: realize um pequeno projeto. Você já viu problemas similares anteriormente? Existem padrões que são reconhecíveis em um potencial de soluções? Existe algum software que implemente os dados, as funções e características necessárias? Algum problema similar já foi resolvido? Em caso positivo, existem ele- mentos da solução que podem ser reutilizados? É possível definir subproblemas? Em caso positivo, existem soluções apa- rentes e imediatas para eles? É possível representar uma solução de maneira que conduza a uma imple- mentação efetiva? É possível criar um modelo de projeto? 3. Executar o plano: podem surgir desvios inesperados, mas é possível descobrirmos caminhos melhores; se seguirmos o planejamento, conti- nuaremos sem nos perder. Verificar se a solução se adequa ao plano? O código fonte pode ser atri- buído ao projeto? Projeto e códigos foram revisados? Os componentes da solução estão pro- vavelmente corretos? História da Engenharia De Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 21 4. Examinar resultado para ter precisão: não podemos ter certeza de que uma solução seja perfeita, porém asseguramos que testes são suficientes para revelar um número maior de erros. Podemos testar cada parte componente da solução? Foi implementado uma estratégia de testes? Os resultados da solução se adequam aos dados, funções e característi- cas? O software foi validado em relação às solicitações dos interessados. PRINCÍPIOS GERAIS De acordo com Pressman (2011), são: 1. A razão de existir: antes de especificar uma necessidade do sistema todas as decisões deveriam ter princípios voltados aos seus usuários, verificar se realmente vai haver agregação diante da necessidade. 2. KISS – (Keep it simple, ou seja, Faça de forma simples): há diversos fatores a ser considerados em qualquer esforço do projeto, um software com qualidade de fácil manutenção e menos propensos a erros. 3. Mantenha a visão: para o sucesso, é preciso mantermos uma visão clara, sem ela o projeto se torna ambíguo; corre-se o risco de transformar o pro- jeto em vários recortes, comprometendo, então, a visão clara . 4. O que um produz, os outros consomem: o sistema de força industrial é construído e utilizado de forma isolada. Outras pessoas poderão documen- tar, manter e usar. Sendo assim, projete e implemente ciente de que alguém mais deverá entender o que você está desenvolvendo, dessa forma você agrega mais valor ao sistema e facilita o trabalho de todas outras pessoas. 5. Esteja aberto para o futuro: jamais desenvolva projetos limitados, pois um software com maior tempo de vida mais tem valor. 6. Planeje com antecedência: alcançar o nível de reuso é indiscutivelmente a meta mais difícil de ser atingida quando se desenvolve um software, pois a reutilização economiza tempo e esforço. 7. Pense: é a forma mais clara e qual produz melhores resultados sempre! ©shutterstock INTRODUÇÃO À ENGENHARIA DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E22 TIPOS DE APLICAÇÕES DE SOFTWARE Atualmente, com o software sendo utilizado em praticamente todas as ativida- des exercidas pelas pessoas, existe uma grande variedade de aplicações. Vamos ver algumas delas: ■ Software de sistema – de acordo com Pressman (2011, p. 34), são aqueles programas desenvolvidos para atender a outros programas, por exemplo, editores de texto, compila- dores e sistemas operacionais. ■ Software de aplicação – são programas desenvolvidos para solucionar uma necessi- dade específica de negócio, processando dados comerciais ou técnicos de forma que ajude nas operações comerciais ou tomadas de decisão pelos administradores da empresa. ■ Software científico/de engenharia – são apli- cações que vão da astronomia à vulcanologia, da biologia molecular à fabricação automatizada, normal- mente utilizando algoritmos para processamento numérico pesado. ■ Software embutido – controla ou gerencia dispositivos de hardware, como celular, painel do micro-ondas, controle do sistema de freios de um veículo. ■ Software de inteligência artificial – utiliza algoritmos não numéricos para solucionar problemas complexos que não poderiam ser solucionados pela computação ou análise direta, por exemplo, sistemas especialistas, robótica, redes neurais artificiais. MITOS RELATIVOS AO SOFTWARE Mitos de software são caracterizados como uma série de “falsas verdades”, pois apresentam uma sensação intuitiva, distorcendo a verdadeira face do processo de engenharia. Atualmente, profissionais com muita experiência na engenha- ria de software reconhecem os mitos e as atitudes enganosas que representam. Tipos de Aplicações de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 23 Podemos observar alguns exemplos a seguir de acordo com Presmann (2011, p. 46-47). 1. Mitos de Gerenciamento: Mito: temos um livro com padrões e procedimentos para desenvolver software. Realidade: o livro pode existir, mas ele é usado? Os praticantes sabem que ele existe? O livro reflete a prática moderna da engenharia de software? É adaptável,está alinhado para melhorar o tempo de entrega, mantendo o foco na qualidade? Em muitos casos, a resposta para essas perguntas é “não”. Mito: se o cronograma atrasar, poderemos acrescentar mais programa- dores e ficarmos em dia? Realidade: o desenvolvimento de software não é um processo mecânico como os das fábricas. Nas palavras de Brooks[Bro95]: “acrescentar pes- soas num projeto de software atrasado o tornará mais atrasado ainda”. O que ocorre com a chegada de novas pessoas em um projeto, as que já estavam terão de gastar tempo situando os recém-chegados, reduzindo consequentemente o tempo destinado ao desenvolvimento produtivo. Para que sejam inseridas novas pessoas esta ação deverá ser de forma planejada e coordenada. Mito: posso terceirizar o projeto de software e simplesmente relaxar e dei- xar a essa empresa realizá-lo. Realidade: caso essa organização não saiba gerenciar e controlar projetos de software, provavelmente irá se deparar com dificuldades. 2. Mitos de Clientes: É importante sabermos que os clientes solicitantes do software podem ser pes- soas comuns, ou seja, não necessariamente é preciso conhecimento específico na área computacional, porém, é necessário saber da sua regra de negócio. Mito: definição geral é suficiente para começar a escrever os programas. Realidade: nem sempre será possível uma definição ampla e estável dos requisitos. Estes são obtidos somente por meio da comunicação entre cliente e desenvolvedor, sendo assim nem sempre é possível. INTRODUÇÃO À ENGENHARIA DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E24 3. Mitos de profissionais da área: Tem residido por mais de 50 anos de cultura de programação. Modos e atitudes antigos dificilmente são esquecidos. Mito: uma vez feito programa e colocado em uso, nosso trabalho está terminado? Realidade: uma vez que alguém já disse que “o quanto antes se começa a codificar, mais tempo levará para termina-lo”. Mito: até que um programa entre em funcionamento, não há maneira de avaliar sua qualidade. Realidade: um dos mecanismos de garantia da qualidade de software mais eficaz pode ser aplicado desde a concepção de um projeto. Mito: o único produto passível de entrega é o programa em funcionamento. Realidade: um programa funcionando é somente uma parte de uma con- figuração de software que inclui muitos elementos. Mito: a engenharia de software nos fará criar documentação volumosa e desnecessária. Realidade: a engenharia de software não trata de criação de documentos, mais sim da criação de um produto de qualidade. Ter ciência das realidades dos profissionais que trabalham com software é o primeiro passo para buscar soluções práticas na engenharia de software. Por isso, muitos profissionais de software reconhecem com facilidade om mitos que acabamos de descrever. “Se o processo estiver correto, os resultados falarão por si mesmos.” Takashi Osada Software Legado Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 25 SOFTWARE LEGADO Denominam-se aos softwares antigos os que são foco de contínua atenção e pre- ocupação desde os anos 1960. Dayani-Fard e seus colegas [Day99] descrevem software legado da seguinte forma: Sistemas de software legado... Foram desenvolvidos há décadas atrás e em sido continuamente modificado para se adequar a mudanças dos requisitos de negócio e a plataformas computacionais. A proliferação de tais sistemas está causando dores de cabeça para grandes organizações que consideram dispendiosos de manter e arriscado de evoluir. Liu e seus colegas [Liu98] observaram que “muitos sistemas legados permane- cem dando suporte para funções de negócios vitais e são ‘indispensáveis’ para o mesmo”. Softwares legados, por sua vez, podem apresentar projetos não expansí- veis, código intrincado, documentação inexistente ou escassa, testes que nunca foram arquivados. E que, mesmo assim, esses softwares possuem funções vitais de negócios e são indispensáveis para ele. Surge-nos, então, a pergunta, o que devemos fazer? Nada, isso mesmo, nada, até que o software legado se submeta a modificações significativas. Vale lembrarmos que, caso o software legado atenda às necessidades de seus usuários, possibilitando confiança e vitalidade, não precisa ser “consertados”. Entretanto, esses sistemas evoluem com o passar do tempo, por uma ou mais das seguintes razões (Pressman 2011): ■ O software deve ser adaptado para atender às necessidades de novos ambientes ou de novas tecnologias computacionais. ■ O software deve ser aperfeiçoado para implementar novos requisitos de negócio. ■ O software deve ser expandido para torná-lo interoperável com outros bancos de dados ou softwares mais modernos. ■ O software deve ser rearquitetado para torná-lo viável dentro de um ambiente de rede. INTRODUÇÃO À ENGENHARIA DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E26 O objetivo da engenharia de software moderna é de “elaborar metodologias baseadas na evolução”, ou seja, os softwares modificam-se continuamente e que novos softwares são construídos a partir dos antigos... [Day99]. INTRODUÇÃO À QUALIDADE DE SOFTWARE Para que o software possa ser funcional e prático, é preciso qualidade na pro- dução e na manutenção. A qualidade em software se refere às características dos produtos que atendam requisitos de funcionalidade. Esses requisitos estão ligados, diretamente, com a área de utilização do programa. Para cada requi- sito, temos um campo de abrangência, uma especificidade. Esses requisitos são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade, por- tabilidade, estabilidade. Esses requisitos fazem parte da qualidade do software de forma que cada produto, cada programa, possa atender às necessidades tecnológicas, econômicas, sociais, intelectuais e práticas do setor ao qual se destinam, observando as especificidades de cada área onde o produto é utilizado. Assim deve se levar em consideração a utilização do produto. Em áreas econômicas certos requisitos serão mais necessários do que na área educacional, onde os requisitos de um programa atendem as necessidades daquele público em particular. (VASCONCELOS, ROUILLER, MACHADO, MEDEIROS, 2006). Ao observar essas especificidades, o software responde aos anseios de um mer- cado em particular. Sem deixar de levar em consideração o que cada um precisa. Áreas de lazer precisam de certos requisitos, áreas educacionais outros, áreas sociais outros. O programa atende às necessidades de cada setor, sem perder a sua qualidade. Software Legado Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 27 A qualidade se torna uma parte importante em todo o processo de pro- dução de um software, em que se leva em consideração não apenas aspectos tecnológicos, econômicos ou sociais, mas a praticidade do mesmo, as funções que desempenha, a facilidade de uso, a capacidade de ser reciclado, manuten- ção, entre outros. A qualidade visa apresentar um produto completo que atenda a todas as necessidades do setor a qual se destina. O que é engenharia reversa? O nome “engenharia reversa” define muito bem o conceito do que ela faz. Trata-se do estudo de um objeto, seja um processador, um monitor, um pro- grama ou até mesmo um simples relógio, desmontando-o e analisando suas peças, seus componentes, seus comandos e seu comportamento (no caso de programas). Isso éfeito para descobrir como ele foi fabricado, como ele poderia ser melhorado e que outras funções ele poderia realizar. Fonte: Hautsch (online).1 INTRODUÇÃO À ENGENHARIA DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IU N I D A D E28 CONSIDERAÇÕES FINAIS Nesta primeira unidade, foram apresentados alguns conceitos básicos sobre enge- nharia de software que serão utilizados no decorrer de todo o livro, por isso, é muito importante que esses conceitos fiquem bem claros para você. A engenharia de software foi proposta para tentar levar a precisão da enge- nharia para o desenvolvimento de software, pois até aquela época, desenvolver um software era algo que não podia ser mensurado, nem em relação ao tempo, nem em relação ao custo, levando-se, normalmente, muito mais tempo do que o previsto. E o que acontecia era que não se tinha uma regra, uma sequência de atividades para o desenvolvimento. Você vai ver, na próxima unidade que, para tentar solucionar esse problema, os estudiosos da engenharia de software pro- puseram vários modelos de processos de software, sendo que a empresa pode escolher o que melhor se adequa a ela. Isso tem ajudado muito o desenvolvimento de software. Você vai perceber isso durante o estudo das próximas unidades. Outro conceito importante que foi tratado nesta primeira unidade é o con- ceito de software. Algumas pessoas que conheço acham que desenvolver software é simplemesmente sentar em frente ao computador e escrever as linhas de código. Você percebeu que sim, isso faz parte do software, mas que desenvolver software é muito mais abrangente, pois o software envolve, além dos programas, a docu- mentação, as pessoas, os procedimentos envolvidos. A engenharia de software trata de todos esses aspectos, mas em nosso livro trataremos mais especifica- mente da modelagem de um software, desde o levantamento dos requisitos até a elaboração de vários diagramas. Não trataremos da implementação propria- mente dita, pois isso você verá em outras disciplinas do curso. A implementação é muito importante, por isso, você terá disciplinas dedicadas a essa tarefa. Essa primeira unidade foi somente um aperitivo. Agora vamos passar a estu- dar assuntos específicos da disciplina e você vai perceber que a engenharia de software é muito importante para o desenvolvimento de um software. 29 1. Segundo Pressman, assinale quais alternativas diferenciam o software do hardware? I. Software não é fabricado no sentido clássico. II. Software se desgasta. III. Software possui componentes reutilizáveis. IV. Software não possui segmento de instruções. V. Software é a parte lógica. São verdadeiras: a. Somente I e II. b. Somente I, III e V. c. Somente I, III e V. d. Todas estão corretas. 2. Quando falamos de engenharia de software, não se trata apenas do ______________ em si, mas de toda a _____________ associada e dados de con- figurações necessários para fazer este programa operar corretamente. 3. Quais são os tipos de aplicações de software? 30 DESENVOLVIMENTO ÁGIL DE SOFTWARE Kend Beck (2001) e outros dezesseis renomados que trabalhavam na área de desen- volvimento, consultoria, do sistema de software assinaram o “Manifesto para o desen- volvimento ágil de Software”. O objetivo era sanar fraquezas que fossem perceptíveis na engenharia de software, para que esse método funcionasse era necessário observar alguns itens: a satisfação do cliente, a maneira como se acolhe os pedidos de alterações, dar preferência a intervalos mais curtos de entrega, trabalhar em conjunto, motivação constante tanto para elaborar o projeto como da equipe que irá realizá-lo, sempre ter uma conversa aberta com a equipe, o software sempre deve estar em funcionamento, ter sempre um ritmo constante, atenção contínua, simplicidade, auto organização da equipe, avaliação da equipe em tempos regulares. Segundo Pressman (2011, p. 86) o desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando o processo de acordo com as pessoas e as equipes específicas. Quando falamos de desenvolvimento ágil da engenharia do software, nos deparamos com inúmeras definições, pois as suas práticas variam muito, mas os princípios são iguais, a entrega rápida do projeto, a agilidade da equipe, e a constante participação di- reta do cliente com seus fornecedores, que são os engenheiros de software, estes têm o enfoque no software em si, e não em sua concepção e documentação. Segundo Steffen (2016, p. 1): Ágil é uma nova forma de gestão e desenvolvimento de Software que usa uma abordagem de planejamento e execução iterativa e incremental voltado para processos empíricos (complexos, caóticos ou com muita incerteza, têm mudanças ao longo do processo, não são repetitivos e são imprevisíveis) que divide o problema em produtos menores e que visa entregar software funcionando regularmente, visa a aproximação e maior colaboração do time de desenvolvimento com os experts de negócios, comunicação face-to-face, redução dos riscos associados às incertezas dos projetos, abraçar e responder as mudanças de forma mais rápida e natural e é claro a satisfação final dos clientes por meio da ado- ção de práticas de gestão e de engenharia de software com foco nos valores e princípios doLean e do agile, resumindo, seu principal objetivo é entregar o produto que o cliente realmente deseja e que será útil e com qualidade. Podemos notar que a engenharia ágil de software tem como prioridade melhorar a sua produtividade, tendo como foco a contínua comunicação com seu cliente, o que muda na sua estrutura, mas só um pouco, essa engenharia planeja apenas o que será feito, com todos os detalhes, se acaso acontecer de ter algum erro, esse pode ser corrigido rapidamente, não deixando a equipe se desmotivar. 31 Nos dias de hoje, as empresas operam em um ambiente global, com mu- danças rápidas. Assim precisam responder a novas oportunidades e no- vos mercados, a mudanças nas condições econômicas e ao surgimento de produtos e serviços concorrentes. Softwares fazem parte de quase todas as operações de negócios, assim novos softwares são desenvolvi- dos rapidamente para obterem proveito de novas oportunidades e res- ponder às pressões competitivas (SOMMERVILLE. p. 39). O método ágil não é fechado em si, tendo várias vertentes ou campos de atuação, como: A Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nas- cida nos Estados Unidos no final da década de 90. Destaca-se, em diversos países, por auxiliar o desenvolvimento de sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Os objetivos são alcançados por meio de um pequeno conjunto de valores, princípios e práticas, que diferem subs- tancialmente da forma tradicional de se desenvolver software. Propondo que somente a documentação estritamente necessária seja gerada, com o código e os testes de uni- dade servindo como documentação. Scrum é uma metodologia de desenvolvimento que surgiu no início dos anos 90, seu nome foi originado a partir de uma atividade durante a partida de rugby. Incorpora atividades estruturais, sendo elas: requisitos, análise, projeto, evolução e en- trega. Para cada atividade metodológica, é utilizado padrões de processo: Registro pendente de trabalhos (Backlog): lista de requisitos e prioridades ou funciona- lidades que fornecem valor comercial aos clientes. Urgências (sprints): consiste em realizar ajustes dentro de prazo pré-estabelecido. Alterações: permitem que membros trabalhem em curto prazo, porém estáveis. Reuniões: são realizadas diariamente pela equipe com duração máxima de 15 minutos. Demos: demonstração ao cliente das funcionalidades implementadas, lembrando que esta poderá não ter todas as funcionalidades.Por meio desses métodos a engenharia de software pode aplicar em seus projetos, sendo eles não muito complexos, de maior rapidez, pois os ciclos são mais curtos, o planejamento é mais funcional, tolerância a mudanças, maior proximidade da equipe com seu cliente e vice versa e o foco geral no ambiente de trabalho e de seus colabora- dores. MATERIAL COMPLEMENTAR Fundamentos de Engenharia de Software Frank Tsui e Orlando Karam Editora: LTC Sinopse: Em sua segunda edição, Fundamentos da Engenharia de Software consiste em uma introdução abrangente de temas e metodologias essenciais sobre o desenvolvimento de software. Ideal para estudantes universitários e para profi ssionais experientes à procura de uma nova carreira no setor de tecnologia da informação – ou áreas afi ns –, esta obra apresenta o ciclo de vida completo de um sistema de software – da concepção até a liberação e o suporte ao usuário. Fundamentos da Engenharia de Software constitui um texto excepcional para aqueles que estão ingressando no estimulante mundo do desenvolvimento de software. REFERÊNCIAS 33 MEDEIROS, H. Princípios da engenharia de software. Disponível em: <http:// www.devmedia.com.br/principios-da-engenharia-de-software/29630>. Acesso em 11 de fev. de 2016. PRESSMAN, R. S. Engenharia de software. Uma abordagem profissional. 7. Ed. Por- to Alegre: AMGH, 2011. SOMMERVILLE, I. Engenharia de software. 9. Ed. São Paulo: Pearson Prentice Hall, 2011. STEFFEN, J. B. O que são essas tais de metodologias ágeis? Disponível em: <ht- tps://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/ mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en>. Aces- so em 11 de fev. de 2016. TSUI, F. ; KARAM, O. Fundamentos de engenharia de software. 2. Ed. Rio de Janei- ro: LTC, 2013. VASCONCELOS, A. M. L. de; ROUILLER, A. C.; MACHADO, C. Â. F.; MEDEIROS, T. M. M. de. Introdução à engenharia de software e à qualidade de software. Lavras: UFLA/FAEPE, 2006. Disponível em: <http://www.cin.ufpe.br/~if720/downloads/ Mod.01.MPS_Engenharia&QualidadeSoftware_V.28.09.06.pdf>. Acesso em 11 de fev. de 2016. GABARITO 1. – C 2. - Programa, Documentação 3. – • Software de sistema: programas desenvolvidos para atender a outros pro- gramas. • Software de aplicação: programas desenvolvidos para solucionar uma ne- cessidade específica de negócio. • Software científico/de engenharia: são aplicações que vão da astronomia à fabricação automatizada. • Software embutido: controla ou gerencia dispositivos de hardware. • Software de inteligência artificial: solucionar problemas complexos que não poderiam ser solucionados pela computação ou análise. U N ID A D E II Professora Me. Márcia Cristina Dadalto Pascutti PROCESSOS DE SOFTWARE Objetivos de Aprendizagem ■ Compreender os conceitos de processo de software e modelos de processo de software. ■ Mostrar as atividades básicas do processo de software. ■ Mostrar três modelos de processo de software. Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade: ■ Processos de Software ■ Modelos de Processo de Software ■ Atividades Básicas do Processo de Software INTRODUÇÃO Caro(a) aluno(a), na primeira unidade, você aprendeu alguns conceitos bási- cos relacionados à Engenharia de Software. A partir de agora, você começará a estudar assuntos mais específicos da disciplina e você verá que seu estudo ficará cada vez mais interessante. Nos últimos tempos, o desenvolvimento de software é uma das áreas da tec- nologia que mais cresceu, e com esse crescimento vieram, também, problemas que vão desde o não cumprimento dos prazos estabelecidos para o seu desen- volvimento até a falta de qualidade do software desenvolvido. Um software não pode ser desenvolvido de qualquer jeito, sem seguir cri- térios, sem que se saiba qual o próximo passo a ser dado. Por isso, os conceitos relacionados à engenharia de software devem ser utilizados. Hoje em dia, a empresa precisa definir qual o seu processo de software. Nesta unidade, você aprenderá o que é um processo de software e conhe- cerá alguns modelos de processo que já existem em nossa literatura e que são utilizados por muitas empresas. Esses modelos são: modelo em cascata, desen- volvimento incremental e engenharia de software baseada em componentes. É importante, porém, ressaltar que não é preciso seguir um desses modelos que já estão prontos, ou seja, a empresa que vai desenvolver software pode criar o seu próprio modelo. É imprescindível que esse modelo seja seguido. Existem algumas atividades básicas que fazem parte de um processo de sof- tware. Estudaremos cada uma dessas atividades: especificação de software, projeto e implementação de software, validação de software e evolução de software. Você perceberá que os modelos de processo de software apresentados nesta unidade possuem todas essas atividades, e que, às vezes, a atividade possui um nome diferente, mas com o mesmo significado. Você verá também que uma atividade pode se desdobrar em várias etapas ou subatividades. Introdução Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 37 ©shutterstock PROCESSOS DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E38 PROCESSOS DE SOFTWARE Para que um software seja produzido, são necessárias diversas etapas, compostas por uma série de tarefas em cada uma delas. A esse conjunto de etapas dá-se o nome de processo de software. Essas etapas podem envolver o desenvolvimento de software a partir do zero em uma determinada linguagem de programação (por exemplo, o Java ou C) ou, então, a ampliação e a modificação de sistemas já em utilização pelos usuários. Segundo Sommerville (2011), existem muitos processos de software diferen- tes, porém todos devem incluir quatro atividades fundamentais para a engenharia de software: 1. Especificação de software: é necessário que o cliente defina as funcionalidades do software que será desenvolvido, bem como defina todas as suas restrições operacionais. 2. Projeto e implementação de software: o software deve ser confeccio- nado seguindo as especificações definidas anteriormente. Processos de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 39 3. Validação de software: o software precisa ser validado para garantir que ele faz o que o cliente deseja, ou seja, que ele atenda às especificações de funcionalidade. 4. Evolução de software: as funcionalidades definidas pelo cliente durante o desenvolvimento do software podem mudar e o software precisa evo- luir para atender a essas mudanças. Vamos estudar detalhadamente cada uma das atividades mencionadas acima durante a nossa disciplina, inclusive utilizando ferramentas automatizadas (fer- ramentas CASE) para nos auxiliar na elaboração dos diversos documentos que serão necessários. Conforme Sommerville (2011, p. 19), “os processos de software são comple- xos e, como todos os processos intelectuais e criativos, dependem de pessoas para tomar decisões e fazer julgamentos. Não existe um processo ideal, a maioria das organizações desenvolve os próprios processos de desenvolvimento de software”. O que acontece é que nem sempre as empresas aproveitam as boas técnicas da engenharia de software em seu desenvolvimento de software. E, normal- mente, o software não atende aos requisitos do usuário, acaba demorando mais tempo para ser desenvolvido do que o previsto,aumentando assim, o valor do custo do software. As atividades mencionadas por Sommerville podem ser organizadas pelas empresas da forma como ela achar melhor, porém, é importante ressaltar que todas essas atividades são de extrema importância e o processo de software ado- tado pela empresa não deve deixar de considerar nenhuma das etapas. É importante ressaltar que mesmo as empresas que possuem um processo de software bem definido e documentado, para determinados softwares que ela desenvolve, pode ser utilizado outro processo de software, ou seja, dependendo do software a ser desenvolvido, pode ser utilizado um determinado processo de software. Na próxima seção, veremos alguns modelos de processo de software e veremos também que é possível a empresa adotar um processo de software pró- prio, que atenda suas necessidades. PROCESSOS DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E40 MODELOS DE PROCESSO DE SOFTWARE Como foi discutido anteriormente, um processo de software é composto por um conjunto de etapas que são necessárias para que seja produzido. Sommerville (2007) afirma que um modelo de processo de software é uma representação abs- trata, simplificada de um processo de software. Os modelos de processo incluem as atividades que fazem parte do processo de software (você está lembrado das atividades descritas no item anterior?), os artefatos de software que devem ser produzidos em cada uma das atividades (documentos) e também os papéis das pessoas envolvidas na engenharia de software. Além disso, cada modelo de pro- cesso representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informações parciais sobre o processo. Na literatura, existem diversos modelos de processo de software. Aqui, irei mostrar somente três desses modelos e, em seguida, mostrarei as atividades básicas que estão presentes em, praticamente, todos os modelos de processos de software. Os modelos de processo que mostrarei foram retirados de Sommerville (2011, p.20) e são: 1. Modelo em Cascata: esse modelo considera as atividades de especifi- cação, desenvolvimento, validação e evolução, que são fundamentais ao processo e as representa como fases separadas, como a especificação de requisitos, o projeto de software, a implementação, os testes e assim por diante (SOMMERVILLE, 2011). 2. Desenvolvimento Incremental. esse modelo intercala as atividades de especificação, desenvolvimento e validação. Um sistema inicial é rapida- mente desenvolvido a partir de especificações abstratas, que são refinadas com informações do cliente, para produzir um sistema que satisfaça suas necessidades, produzindo várias versões do software (SOMMERVILLE, 2011). 3. Engenharia de Software Orientada a Reuso: esse modelo parte do prin- cípio de que existem muitos componentes que podem ser reutilizáveis. O processo de desenvolvimento do sistema se concentra em combi- nar vários desses componentes em um sistema, em vez de proceder ao desenvolvimento a partir do zero, com o objetivo de reduzir o tempo de desenvolvimento (SOMMERVILLE, 2011). ©shutterstock Modelos de Processo de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 41 O MODELO EM CASCATA O modelo cascata ou ciclo de vida clássico, considerado o paradigma mais antigo da engenharia de software, sugere uma abor- dagem sequencial e sistemática para o desenvolvimento de software, começando com a definição dos requisitos por parte do cliente, avançando pelas atividades de projeto e implementação de software, testes, implan- tação, culminando no suporte contínuo do software concluído. Segundo Sommerville (2007, p. 44), os principais estágios do modelo em cascata demonstram as atividades fundamen- tais do desenvolvimento: 1. Análise e definição de requisitos: as funções, as restrições e os objeti- vos do sistema são estabelecidos por meio da consulta aos usuários do sistema. Em seguida, são definidos em detalhes e servem como uma espe- cificação do sistema. 2. Projeto de sistemas e de software: o processo de projeto de sistemas agrupa os requisitos em sistemas de hardware ou de software. Ele esta- belece uma arquitetura do sistema geral. O projeto de software envolve a identificação e a descrição das abstrações fundamentais do sistema de software e suas relações. 3. Implementação e teste de unidades: durante esse estágio, o projeto de software é compreendido como um conjunto de programas ou unida- des de programa. O teste de unidades envolve verificar que cada unidade atenda a sua especificação. 4. Integração e teste de sistemas: as unidades de programa ou programas individuais são integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos. Depois dos tes- tes, o sistema de software é entregue ao cliente. PROCESSOS DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E42 5. Operação e manutenção: normalmente (embora não necessariamente), esta é a fase mais longa do ciclo de vida. O sistema é instalado e colo- cado em operação. A manutenção envolve corrigir erros que não foram descobertos em estágios anteriores do ciclo de vida, melhorando a imple- mentação das unidades de sistema e aumentando as funções desse sistema à medida que novos requisitos são descobertos. Um estágio somente pode ser iniciado depois que o estágio anterior tenha sido concluído. Porém, Sommerville (2011, p. 21) afirma que na prática esses está- gios acabam se sobrepondo, alimentando uns aos outros de informações. Por exemplo, durante o projeto, os problemas com os requisitos são identificados. O que acontece é que um processo de software não é um modelo linear simples, sequencial, mas envolve iterações entre as fases. Os artefatos de software que são produzidos em cada uma dessas fases podem ser modificados para refletirem todas as alterações realizadas em cada um deles. Pressman (2011) aponta alguns problemas que podem ser encontrados quando o modelo cascata é aplicado: 1. Os projetos que acontecem nas empresas dificilmente seguem o fluxo sequencial proposto pelo modelo. Alguma iteração sempre ocorre e traz problemas na aplicação do paradigma. 2. Na maioria das vezes, o cliente não consegue definir claramente todas as suas necessidades e o modelo cascata requer essa definição no início das atividades. Portanto, esse modelo tem dificuldade em acomodar a incer- teza natural que existe no começo de muitos projetos. 3. Uma versão operacional do sistema somente estará disponível no final do projeto, ou seja, o cliente não terá nenhum contato com o sistema durante o seu desenvolvimento. Isso leva a crer que se algum erro grave não for detectado durante o desenvolvimento, o sistema não atenderá de forma plena as necessidades do cliente. Segundo Sommerville (2011) e Pressman (2011), o modelo em cascata deve ser utilizado somente quando os requisitos são fixos e tenham pouca probabi- lidade de serem alterados durante o desenvolvimento do sistema e o trabalho deve ser realizado até sua finalização de forma linear. Sommerville (2011, p.21) Modelos de Processo de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 43 ainda afirma que “o modelo cascata reflete o tipo de processo usado em outros projetos de engenharia. Como é mais fácil usar um modelo de gerenciamento comum para todo o projeto, processos de software baseadosno modelo em cas- cata ainda são comumente utilizados”. DESENVOLVIMENTO INCREMENTAL O desenvolvimento incremental, segundo Sommerville (2011, p. 21), tem como base a ideia de desenvolver uma implementação inicial, baseada em uma reunião com os envolvidos para definir os objetivos gerais do software, mostrar para o usuário e fazer seu refinamento por meio de várias versões, até que um sistema adequado tenha sido desenvolvido. Figura 1– Atividades concorrentes Especi�cações Versão �nal Versão inicial Atividades concorrentes Validação DesenvolvimentoDescrição do esboço Versões intermediárias Fonte: Sommerville (2011, p.22). Assim, as atividades de especificação, desenvolvimento e validação são reali- zadas concorrentemente com um rápido feedback entre todas as atividades. A cada nova versão, o sistema incorpora novos requisitos definidos pelo cliente. PROCESSOS DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E44 Para Pressman (2011, p. 63), inicialmente, é necessário desenvolver um pro- jeto rápido que deve se concentrar em uma representação daqueles aspectos do software que serão visíveis aos usuários finais, como, o layout da interface com o usuário. O desenvolvimento incremental apresenta algumas vantagens importantes em relação ao modelo em cascata. Sommerville (2011, p. 22) aponta três vantagens: (1) se o cliente mudar seus requisitos, o custo será reduzido, pois a quantidade de análise e documentação a ser refeita é menor do que no modelo em cascata; (2) é mais fácil obter um retorno dos clientes sobre o desenvolvimento que foi feito, pois os clientes vão acompanhando o desenvolvimento do software à medida que novas versões são apresentadas a eles; (3) os clientes podem começar a uti- lizar o software logo que as versões iniciais forem disponibilizadas, o que não acontece com o modelo cascata. Entretanto, a partir de uma perspectiva de engenharia e de gerenciamento, existem alguns problemas: 1. O processo não é visível: os gerentes necessitam que o desenvolvimento seja regular, para que possam medir o progresso. Se os sistemas são desen- volvidos rapidamente, não é viável produzir documentos que reflitam cada versão do sistema. 2. Os sistemas frequentemente são mal estruturados: a mudança constante tende a corromper a estrutura do software. Incorporar modificações no software torna-se cada vez mais difícil e oneroso. 3. Podem ser exigidas ferramentas e técnicas especiais: elas possibilitam rápido desenvolvimento, mas podem ser incompatíveis com outras ferra- mentas ou técnicas, e relativamente poucas pessoas podem ter a habilitação necessária para utilizá-las. Para sistemas pequenos (com menos de 100 mil linhas de código) ou para sis- temas de porte médio (com até 500 mil linhas de código), com tempo de vida razoavelmente curto, a abordagem incremental de desenvolvimento talvez seja a melhor opção. Contudo, para sistemas de grande porte, de longo tempo de vida, nos quais várias equipes desenvolvem diferentes partes do sistema, os problemas de se utilizar o desenvolvimento incremental se tornam particularmente graves. Modelos de Processo de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 45 Para esses sistemas, é recomendado um processo misto, que incorpore as melho- res características do modelo de desenvolvimento em cascata e do incremental, ou ainda algum outro modelo disponível na literatura. Na literatura referente a modelos de processo de software pode-se encontrar a prototipação como um exemplo de abordagem incremental. ENGENHARIA DE SOFTWARE ORIENTADA A REUSO Na maioria dos projetos de software, ocorre algum reuso de software, pois, normalmente, a equipe que trabalha no projeto conhece projetos ou códigos análogos ao que está sendo desenvolvido. Ela busca esses códigos, faz as modi- ficações conforme a necessidade do cliente e os incorporam em seus sistemas. Independentemente do processo de software que está sendo utilizado, pode ocor- rer esse reuso informal. Porém, nos últimos anos, uma abordagem para desenvolvimento de software, com foco no reuso de software existente tem emergido e se tornado cada vez mais utilizada. A abordagem orientada a reuso conta com um grande número de componentes de software reutilizáveis, que podem ser acessados, e com um framework de integração para esses componentes. Às vezes, esses componen- tes são sistemas propriamente ditos (sistemas COTS – commercial off-the-shelf - sistemas comerciais de prateleira), que podem ser utilizados para proporcionar funcionalidade específica, como formatação de textos, cálculo numérico, entre outros (SOMMERVILLE, 2011, p. 23). “Em todo processo há um cliente, pois, sem cliente, um processo deixa de ter sentido.” (V. Daniel Hunt) PROCESSOS DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E46 O modelo genérico de processo baseado em reuso é mostrado na figura 2 (SOMMERVILLE, 2007, p.46). Note que, embora as etapas de especificação de requisitos e de validação sejam comparáveis com outros processos, as etapas intermediárias em um processo orientado a reuso são diferentes. Figura 2: Modelo genérico de processo baseado em reuso Especi�cação de resquisitos Análise de componentes Modi�cação de requisitos Projeto de sistema com reuso Desenvolvimento e integração Validação de sistema Fonte: adaptado de Sommerville (2007). Conforme Sommerville (2011, p.23), essas etapas são: 1. Análise de componentes: considerando a especificação de requisitos, é feita uma busca de componentes para implementar essa especificação. Pode ser que não sejam encontrados componentes que atendam a toda especificação de requisitos, ou seja, pode fornecer somente parte da funcionalidade requerida. 2. Modificação de requisitos: no decorrer dessa etapa, os requisitos são analisados, levando-se em consideração as informações sobre os com- ponentes que foram encontrados na etapa anterior. Se for possível, os requisitos são, então, modificados para refletir os componentes disponí- veis. Quando isso não for possível, ou seja, quando as modificações forem impossíveis, a etapa de análise de componentes deverá ser refeita, a fim de procurar outras soluções. Modelos de Processo de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 47 3. Projeto do sistema com reuso: durante essa etapa, o framework do sis- tema é projetado ou então alguma infraestrutura existente é reutilizada. Os projetistas levam em consideração os componentes que são reusados e organizam o framework para tratar desse aspecto. Se os componentes reusáveis não estiverem disponíveis, pode ser necessário que um novo software deva ser projetado. 4. Desenvolvimento e integração: nessa etapa, o software que não puder ser comprado deverá ser desenvolvido, e os componentes e sistemas COTS serão integrados, a fim de criar um novo sistema. A integração de siste- mas, nessa abordagem, pode ser parte do processo de desenvolvimento, em vez de uma atividade separada. Deve-se tomar muito cuidado ao utilizar essa abordagem, pois não se tem como evitar as alterações nos requisitos dos usuários e isso pode acabar levando ao desenvolvimento de um sistema que não atenda as suas reais necessidades. Há também o fato de que o controle da evolução do sistema fique comprometido, pois as novas versões dos componentes reusáveis não estão sob o controleda organização que as está utilizando. De qualquer forma, a abordagem baseada em reuso tem a vantagem de pro- piciar a entrega mais rápida do software, pois reduz sensivelmente a quantidade de software que a empresa deve desenvolver, reduzindo, consequentemente, os custos de desenvolvimento, bem como os seus riscos. ©shutterstock PROCESSOS DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E48 ATIVIDADES BÁSICAS DO PROCESSO DE SOFTWARE Caro(a) aluno(a), estudando os modelos de processo de software apresentados anteriormente, é possível notar que algumas atividades estão presentes em todos eles, somente, às vezes, essas atividades estão organizadas de forma diferente, dependendo do processo de software que está sendo considerado. Sommerville (2011, p. 24) afirma que no modelo cascata essas atividades são organizadas de forma sequencial, ao passo que no desenvolvimento incremental são intercala- das. A forma como essas atividades serão realizadas depende do tipo de software, das pessoas e da orga- nização envolvida. São quatro as atividades básicas do processo de software: a especificação, o projeto e a implemen- tação, a validação e a evolução. E a partir de agora, iremos detalhar, de forma genérica, sem conside- rar um processo de software em específico, cada uma dessas atividades. Modelos de Processos de Engenharia de Software O artigo de Lessa e Lessa Jr. trata sobre a Engenharia de software e como surgiram os problemas para corrigir com relação ao desenvolvimento de projetos de software, a partir desse surgimento modelos de processos e guia de desenvolvimentos foram criados para otimização do processo de desenvolvimento do software. O artigo também mostrará alguns modelos de processos e um guia chamando de SWEBOK, que foi criado por membros da comunidade científica devido ao vasto material que envolve a área. Vale a pena a leitura. Fonte: Lessa e Lessa Jr. (online)2 Atividades Básicas do Processo de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 49 ESPECIFICAÇÃO DE SOFTWARE A especificação de software, ou engenharia de requisitos, é a primeira atividade básica de um processo de software e tem como objetivo definir quais funções são requeridas pelo sistema e identificar as restrições sobre a operação e o desen- volvimento desse sistema. Essa atividade é muito importante e crítica, pois se a definição dos requisitos não for bem realizada, com certeza problemas posterio- res no projeto e na implementação do sistema irão acontecer. Segundo Sommerville (2011, p.24), “o processo de engenharia de requisitos tem como objetivo produzir um documento de requisitos acordados que espe- cifica um sistema que satisfaz os requisitos dos stakeholders”. O processo de engenharia de requisitos é composto por quatro fases, con- forme descreve Sommerville (2007, p. 50). A unidade seguinte tratará com mais detalhes sobre esse assunto. 1. Estudo de viabilidade: uma avaliação é realizada para verificar se as necessidades dos usuários, que foram identificadas, podem ser atendi- das utilizando as atuais tecnologias de software e hardware, disponíveis na empresa. Esse estudo deve indicar se o sistema proposto será viá- vel, do ponto de vista comercial, e também, se poderá ser desenvolvido considerando restrições orçamentárias, caso existam. Um estudo de viabilidade não deve ser caro e demorado, pois é a partir do seu resul- tado que a decisão de prosseguir com uma análise mais detalhada deve ser tomada. 2. Levantamento e análise de requisitos: nesta fase é necessário levantar os requisitos do sistema pela observação de sistemas já existentes, pela con- versa com usuários e compradores em potencial, pela análise de tarefas e assim por diante. Essa fase pode envolver o desenvolvimento de um ou mais diferentes modelos e protótipos de sistema. Isso pode ajudar a equipe de desenvolvimento a compreender melhor o sistema a ser especificado. PROCESSOS DE SOFTWARE Reprodução proibida. A rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. IIU N I D A D E50 3. Especificação de requisitos: é a atividade de traduzir as informações cole- tadas durante a fase anterior em um documento que defina um conjunto de requisitos. Tanto os requisitos dos usuários quanto os requisitos de sis- tema podem ser incluídos nesse documento. De acordo com Sommerville (2011, p. 24), os requisitos dos usuários são declarações abstratas dos requisitos do sistema tanto para o cliente quanto para os usuários finais do sistema; os requisitos do sistema são descrições mais detalhadas das funcionalidades a serem fornecidas. Na próxima unidade, trataremos com mais detalhes sobre requisitos. 4. Validação de requisitos: essa atividade verifica os requisitos quanto à sua pertinência, consistência e integralidade. Durante o processo de valida- ção, os requisitos que apresentarem problemas devem ser corrigidos, para que a documentação de requisitos fique correta. As atividades de análise, definição e especificação de requisitos são intercaladas, ou seja, elas não são realizadas seguindo uma sequência rigorosa, pois, com cer- teza, novos requisitos surgem ao longo do processo. PROJETO E IMPLEMENTAÇÃO DE SOFTWARE Segundo Sommerville (2011, p. 25), “O estágio de implementação do desenvol- vimento de software é o processo de conversão de uma especificação do sistema em um sistema executável”. Essa etapa sempre envolve processos de projeto e programação de software, porém, se uma abordagem incremental de desenvolvi- mento for utilizada, poderá também envolver o aperfeiçoamento da especificação de software, em que os requisitos foram definidos. Para Pressman (2011, p. 206), o projeto de software cria uma representação ou modelo do software, fornecendo detalhes sobre a arquitetura do software, as estruturas de dados, interfaces e componentes fundamentais para implementar o sistema. O projeto de software é aplicado independentemente do modelo de processo de software que está sendo utilizado, ou seja, se estiver sendo utilizado o modelo em cascata ou a abordagem incremental. Atividades Básicas do Processo de Software Re pr od uç ão p ro ib id a. A rt . 1 84 d o Có di go P en al e L ei 9 .6 10 d e 19 d e fe ve re iro d e 19 98 . 51 O início do projeto ocorre assim que os requisitos tiverem sido analisados e modelados, ou seja, assim que a modelagem do sistema tiver sido realizada. Com base no documento de requisitos, o engenheiro de software, na fase de modelagem do sistema, deverá elaborar os diagramas da UML – Unified Modeling Language (por exemplo, o Diagrama de Caso de Uso e o Diagrama de Classes). Na fase de projeto do sistema, o engenheiro de software deverá: i) definir o Diagrama Geral do Sistema; ii) elaborar as Interfaces com o Usuário (telas e relatórios) e iii) desenvolver um conjunto de especificações de casos de uso, sendo que, essas especificações devem conter detalhes suficientes para permitir a codificação. Geralmente, durante o projeto, o analista de sistemas terá que definir cada com- ponente do sistema ao nível de detalhamento que se fizer necessário para a sua implementação em uma determinada linguagem de programação. A programação, normalmente começa como era de se esperar, quando ter- mina a atividade de projeto. A programação, ou fase de implementação de um projeto típico, envolve a escrita de instruções em Java, C++, C# ou em alguma outra linguagem de programação para implementar o que o analista de sistemas modelou na etapa de projeto. Sendo uma atividade
Compartilhar