engenharia de software turma lin-0154. objetivo da disciplina compreender os conceitos fundamentais...

ENGENHARIA DE SOFTWARE

Turma LIN-0154

OBJETIVO DA DISCIPLINA• Compreender os conceitos fundamentais da Engenharia de

Software;• Entender a área de Engenharia de Software de maneira

sistêmica;• Compreender os principais processos de software;• Conhecer a importância de requisitos de software.• Compreender os fundamentos de design de software;• Entender os aspectos do desenvolvimento de software;• Conhecer as boas práticas de gerenciamento de projetos de

software;• Compreender os principais conceitos relacionados à

qualidade de software. Profº Ricardo luiz 2

INTRODUÇÃO• Para introduzir os conceitos de Engenharia de Software,

outros conceitos iniciais devem ser apresentados: Engenharia, Engenhar, Sistema e Software.– ENGENHARIA - É a arte das construções, com base

no conhecimento científico.– ENGENHAR - É idear, maquinar, inventar, produzir.– SISTEMA - Conjunto de partes que interagem entre

si, visando um objetivo comum. Em informática é o conjunto do software, hardware .

– SOFTWARE - Subsistema de um sistema computacional. São os programas de computadores

Profº Ricardo luiz 3

ENGENHARIA DE SOFTWARE• O Termo Engenharia de Software é relativamente novo,

causando muitas discordâncias de conceitos. Nesse sentido, a sociedade ainda demanda de profissionais capacitados para elevar o software em termos de sistemas para empresas.

• Engenharia de software é a metodologia de desenvolvimento e manutenção de sistemas modulares, com as seguintes características:

• Processo (roteiro) dinâmico, integrado e inteligente de soluções tecnológicas; adequação aos requisitos funcionais do negócio do cliente e seus respectivos procedimentos pertinentes; Profº Ricardo luiz 4

TÓPICO 1: PROCESSOS E REQUISITOS DE SOFTWARE

FUNDAMENTOS DE ENGENHARIA DE SOFTWARE• Quando se fala em Engenharia de Software, logo se

imagina que, por se tratar de uma engenharia, tenha um cunho técnico relativamente alto. Porém, embora as questões técnicas precisem ser consideradas, elas são apenas meios para atingir os objetivos. Para a Engenharia de Software o computador, a teoria da computação e até mesmo os algoritmos, são apenas ferramentas necessárias para prover a solução para um problema (PFLEEGER, 2004).



FUNDAMENTOS DE ENGENHARIA DE SOFTWARE• A Engenharia de Software tem como enfoque lidar

com os aspectos de produção de software em todas as fases do seu ciclo de vida (SOMMERVILLE, 2003). O ciclo de vida de um software inicia no momento em que são registradas as primeiras especificações de funcionamento, até o momento em que o software deixa de ser utilizado pelos seus usuários. Isso significa que tipicamente um software possui um ciclo de vida longo, se considerarmos o esforço necessário para a produção de um software.



FUNDAMENTOS DE ENGENHARIA DE SOFTWARE• Por outro lado, a Engenharia de Software pode

ser vista como um framework para o planejamento, conceituação e projeto de software (PETERS; PEDRYCS, 2001). Na abordagem de framework pode-se considerar o conjunto de aspectos construtivos, seus desafios e considerações sobre produzir tudo ou adquirir partes e fazer com que as mesmas funcionem de maneira harmoniosa.



FUNDAMENTOS DE ENGENHARIA DE SOFTWARE• O fato é que, independente da

abordagem que se utilize, a Engenharia de Software lida com desafios constantemente. Produzir algo que ninguém sabe o que e como será, de forma que não se pode demonstrar de maneira precisa. Isso é no mínimo um trabalho a ser respeitado.



PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE

• Ao iniciarmos os estudos de uma nova área de conhecimento, uma das primeiras dúvidas que temos é sobre sua origem e evolução que a trouxe ser o que é nos dias atuais. Refletindo sobre a origem da área de Engenharia de Software, pode-se iniciar a partir de seu nascimento formal que ocorreu no início da década de 1970 ou buscarmos raízes mais profundas lá no século XIX.



PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE• Em 1843, Lady Ada, uma condessa considerada

gênio na área da matemática trabalhou com Charles Babbage no desenvolvimento da máquina analítica, tratando dos conceitos relacionados às instruções que deveriam ser executadas. Na época, este conjunto de instruções era conhecido como sub-rotina. Nascia então o conceito das instruções de sequência, seleção e repetição. Estes conceitos podem ser considerados as raízes mais profundas do que conhecemos atualmente por software.



PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWAREMAQUINA ANALÍTICA DE CHARLES BABBAGE




MAQUINA ANALÍTICA DE CHARLES BABBAGE• A máquina proposta do Babbage foi concebida

em uma época que a tecnologia disponível era apenas dispositivos mecânicos. Por conta dessa limitação tecnológica não foi possível concluir o projeto que ficou inacabado. Independente disso, os conceitos de Babbage e Ada foi de grande valia para a evolução tecnológica para chegarmos ao estágio atual.




• A partir destes conceitos fundamentais, foram construídos os alicerces do funcionamento dos softwares. A primeira aplicação de processamento de dados em grande escala foi realizada no final do século XIX. Na oportunidade foram tabulados os dados do censo americano de 1890 através de máquinas concebidas por Herman Hollerith.




• Neste momento da história não se diferenciava com clareza o que era hardware e o que era software, pois os equipamentos eram basicamente eletromecânicos. Na realidade o termo software foi criado apenas na década de 1940 como forma de diferenciar a parte lógica da física de um sistema computacional.Profº Ricardo luiz 14


PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWAREMÁQUINA TABULADORA DE HOLLERITH




• O terceiro grande marco fundamental para a área é plantado por Alan Turing no ano de 1937 ao propor um modelo de ações a serem realizadas por um tipo especial de máquina. “A Máquina Universal de Turing é capaz de calcular qualquer coisa que seja calculável”.



PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE• Computadores Eletromecânicos;• Eletrônicos (ENIAC);• Linguagem de programação;– 1949 – Short Order Code;– Década de 50 APT, FORTRAM e FLOW-MATIC;– COBOL (Baseado no Flow Matic)– Crescimento das funcionalidades;– Crize do Software (1960);



PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE• Ao examinarmos algumas possíveis causas da crise

de software podemos nos deparar com diversas. A cada dia que passa é crescente a necessidade de soluções de software mais eficientes. Além disso, a velocidade que os requisitos dos usuários mudam é tipicamente maior do que a equipe de desenvolvimento é capaz de atender. Pfleeger (2004, p. 111) nos ensina que “um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos”. Profº Ricardo luiz 18



• A velocidade de mudança nos requisitos, muitas vezes, vem de origens não controladas, como mudanças de legislação, normas ou processos aos quais as empresas estejam subordinadas. Neste caso podemos compreender que a crise de software pode ocorrer por fatores internos e teoricamente controláveis, bem como externos, ou seja, sobre os quais não exercemos qualquer controle. Profº Ricardo luiz 19



• É possível ainda que a complexidade da mudança imposta seja alta, requerendo maior tempo para sua realização. Muitos projetos de software nascem com prazos definidos antes mesmo de se ter os principais requisitos levantados.



PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE• O que pode ser observado em parcela significativa de

equipes de desenvolvimento de software é a adoção de práticas absurdamente obsoletas. Aliado a estas práticas, tipicamente se encontra uma grande desigualdade na distribuição do tempo dedicado às fases do ciclo de vida de software. É muito comum reduzir requisitos em função da falta de tempo ou eliminar atividades do processo de desenvolvimento com o objetivo de reduzir o tempo total do processo.




• As atividades que tipicamente são mais sacrificadas são a análise, design e testes. Um agravante é a inexistência da definição de um padrão de processo a ser seguido. Padrões desenvolvidos e publicados não faltam, porém a adoção destes é que não se observa em muitas equipes de desenvolvimento. A inexistência de padrão de processo de software multiplica a dificuldade de realizar manutenção. Profº Ricardo luiz 22


PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE• Muitos ainda subestimam a atividade de

desenvolvimento de software, acreditando ser simples e fácil iniciar um software sem a definição de uma estrutura e arquitetura adequadas e evoluir este software até ele se tornar um produto com um conjunto significativo de funcionalidades. Desenvolver software não é uma atividade simples, logo, requisitos, arquitetura e estruturas de programas e dados não podem ser colocadas em segundo plano.




• Encontra-se também a ausência de valorização da fase de análise, na qual os requisitos são obtidos e especificados. Muitos dos softwares que há em uso mundo afora não precisariam existir se as necessidades tivessem sido devidamente entendidas e o processo de trabalho adequadamente analisado e modelado. Muitas vezes implementamos softwares para solucionarmos problemas que sequer existem. Profº Ricardo luiz 24



• Com toda evolução tecnológica ocorrida desde a década de 1970, será que ainda enfrentamos estes problemas? A resposta é sim. Na verdade, atualmente estamos enfrentando uma crise ainda maior, pois a natureza dos problemas com os quais lidamos também evoluiu e a complexidade dos processos cresceu.




• Com o crescimento da complexidade dos problemas de negócio a serem resolvidos, cresceu também a necessidade de crescimento da equipe de desenvolvimento. O crescimento da equipe de desenvolvimento adiciona força de trabalho, porém traz desafios gerenciais. A partir daí começa a entrar em cena a importância dos aspectos gerenciais da Engenharia de Software.




• Embora tenham se passado várias décadas desde que a existência de uma crise de software tenha sido reconhecida, ainda hoje enfrentamos muitos dos problemas identificados lá no final da década de 1960.




• Ainda hoje enfrentamos problemas no processo de análise, no processo de construção, na forma como o software é implantado e mantido e nas consequências geradas aos usuários finais. As atuais exigências de disponibilidade de funções executadas por software requerem que os profissionais de software melhorem continuamente os processos de Engenharia de Software. Mas afinal o que é Engenharia de Software? Profº Ricardo luiz 28



• O Termo Nasceu em 1960;• Em 1968 Flitz Bauer definiu o termo

“o estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais”;




• O objetivo da Engenharia de Software é prover soluções de software aplicáveis às necessidades para as quais foi concebido, construídos de forma produtiva e entregando alto grau de qualidade. O engenheiro de software ao aplicar de forma adequada os métodos, ferramentas e procedimentos da Engenharia de Software torna-se um criador de soluções que atendam as necessidades do mundo real.




• Em 1990 imaginou-se que no futuro programadores não seriam mais necessários;

• Felizmente as previsões não se confirmaram;• Poderíamos caracteriza o desenvolvimento de

software como artesanal;




• Diante desse contexto, a Engenharia de Software é uma área que ganha importância a cada dia, pois a dependência humana de softwares é cada vez maior. Dependemos de softwares para nos comunicarmos, nos informarmos, fazermos operações bancárias, fazermos compras num supermercado, escritórios, contas do dia a dia.




• Os processos precisam ser cada vez mais eficientes e ágeis para que as empresas possam se manter competitivas, gerar empregos e renda para os colaboradores. Porém, toda essa dependência pode aumentar também as consequências do funcionamento inadequado destes softwares.



ENGENHARIA DE SOFTWARE• Engenharia de Software está focada em todos os

aspectos relacionados à construção de software. É uma disciplina de engenharia cujo objetivo é tratar das questões ligadas ao processo de software. Na verdade estamos utilizando o software como elemento base, mas a Engenharia de Software abrange também todos os artefatos relacionados ao processo de software, como documentação, gestão e muitos outros.



ENGENHARIA DE SOFTWARE• Segundo Pfleeger (2004) é que a Engenharia de Software

é um meio para solucionar problemas de forma adequada. Isso pode implicar inclusive a decisão de que eventualmente a melhor solução seja não implementar um software para realização da atividade em questão. Devemos empregar as ferramentas, técnicas e procedimentos da Engenharia de Software para a solução de problemas e/ou necessidades.



ENGENHARIA DE SOFTWARE• Embora tenhamos disponíveis diversas ferramentas

sofisticadas para apoiar o processo de software a Engenharia de Software ainda tem forte dependência do fator humano. O desenvolvimento de software pode ser considerado como uma forma sistemática de fazer arte. E o que confere beleza a esta arte é quanto ela auxilia na solução de problemas impostos.



ENGENHARIA DE SOFTWARE• Pelo fato do processo de software ter forte dependência do

fator humano, a Engenharia de Software lida também com a questão da produtividade. As questões de produtividade envolvem medição de software, estimativas de esforço, definição de indicadores, desenvolvimento de cronograma, coleta de dados de produtividade, análise dos dados de produtividade, entre outras atividades. O processo requer planejamento, organização, controle, além dos aspectos de motivação e liderança..




• Elemento fundamentais: métodos, ferramentas e procedimentos.

• Os métodos podem ser entendidos como os roteiros a serem seguidos para realização de determinada atividade. Exemplos são as atividades de planejamento, realização de estimativas, design de sistemas, definição de arquitetura de software, técnicas de programação, formas de realização de testes e manutenção de softwares, entre outros.Profº Ricardo luiz 38



• As ferramentas podem ser entendidas como o meio para realização das atividades. Elas servem de apoio aos métodos, permitindo que as atividades sejam desenvolvidas de forma mais eficiente e eficaz. Exemplos são as linguagens de programação, bancos de dados, softwares de modelagem de dados, softwares para modelagem de projetos, entre outros.

• Os procedimentos podem ser entendidos como as ações realizadas, ou seja, a aplicação dos métodos e das ferramentas. Profº Ricardo luiz 39



• Em 1990 iniciou o paradigma de orientado a objetos.

• Opinião dividida em permanecer no estruturado ou não.

• A partir de 2000 que começou a ser mais difundido.

• Mas ainda hoje existe programadores utilizando estruturado.


TÓPICO 2: PROCESSOS DE SOFTWARE

• Numa atividade de engenharia é necessário que se defina o método de construção que será adotado. No momento em que se decide construir um software para atender a uma necessidade de negócio ou entregar alguma ferramenta, recurso ou opção de entretenimento é importante que se decida qual o processo que será seguido.



• A criação de um software é uma atividade intelectual de alto nível de complexidade. E é justamente por se tratar de uma atividade complexa que é fundamental que se saiba quais são as etapas que comporão tal processo. A adoção de processos bem definidos melhora a visibilidade da construção de software.



• No desenvolvimento profissional de software é altamente desejável que se siga um processo que reduza, dentro do possível, o desperdício de tempo e maximize os resultados obtidos. Os resultados esperados são tipicamente funcionalidades de software com alta qualidade.



• Todo produto de software é construído com base em um modelo de processo, também conhecido como paradigma de desenvolvimento ou ainda ciclo de vida. Um ciclo de vida de software compreende um conjunto de etapas envolvendo métodos, ferramentas e procedimentos para a obtenção do produto de software desejado (PRESSMAN, 1995).



• O ciclo de vida de software é um processo de engenharia que notadamente requer que algumas etapas sejam seguidas em determinada ordem para que se possa obter um produto final com o grau de qualidade desejado.



• Não é necessário seguir na íntegra um modelo de ciclo de vida proposto por algum pesquisador da área de Engenharia de Software. O ciclo de vida adotado pode ser adaptado de algum modelo anteriormente proposto por algum pesquisador ou totalmente personalizado de acordo com as necessidades e realidade da equipe e natureza do software a ser desenvolvido. Um ciclo de vida de software também pode ser construído através de melhores práticas de diversos modelos amplamente conhecidos.



• De uma forma geral, qualquer processo de software ou ciclo de vida possui três fases que são comuns a qualquer abordagem adotada. Estas três fases são: definição, desenvolvimento e manutenção.



CICLOS DE VIDA DE SOFTWARE• Existem diversos modelos de processo de

software propostos. Alguns apresentam superficialmente a concepção do modelo e outros detalham exaustivamente as fases e subfases do processo. É importante que cada equipe de desenvolvimento se inspire no modelo de processo que esteja mais aderente à sua realidade, customize e promova melhorias contínuas neste modelo.



CICLOS DE VIDA DE SOFTWARE• Melhora o entendimento do processo para a

equipe de desenvolvimento;• Permite a melhoria do processo pela equipe

envolvida;• O modelo reflete os objetivos do

desenvolvimento de software;• Proporciona visibilidade sobre necessidades de

adequação em função da natureza do projeto.Profº Ricardo luiz 49


CICLOS DE VIDA DE SOFTWARE• Todo software possui um ciclo de vida através do

qual ele é ou será construído, logo, compreender os aspectos dos principais modelos de ciclo de vida pode auxiliar na adoção de um dos modelos. Também servirá de importante embasamento teórico para a construção de um ciclo de vida mais adequado à realidade e necessidade da organização. Os ciclos de vida de software podem ser categorizados como, linear, incremental ou iterativo.Profº Ricardo luiz 50


CICLOS DE VIDA DE SOFTWARE• No modelo linear, o software será entregue

com todas suas funcionalidades em apenas uma fase. Este ciclo de vida é mais simples de entender, pois segue o fluxo natural do desenvolvimento de qualquer outro tipo de produto. Este ciclo de vida entra na fase de manutenção quando todas as funcionalidades definidas estiverem concluídas e entregues.



CICLOS DE VIDA DE SOFTWARE• No modelo incremental uma versão básica é

disponibilizada ao final do primeiro ciclo e nos ciclos seguintes novas funcionalidades são agregadas até que se tenha o produto completo. Este modelo pode ser utilizado de forma independente ou em conjunto com o iterativo.



CICLOS DE VIDA DE SOFTWARE• Já no modelo iterativo uma versão básica de

boa parte das funcionalidades é disponibilizada no primeiro ciclo e funções mais aperfeiçoadas são disponibilizadas em ciclos posteriores. A cada ciclo são realizados aperfeiçoamentos nas funcionalidades até que todas as funcionalidades estejam completas.



CICLOS DE VIDA DE SOFTWARE• Para cada uma destas categorias de ciclos de

vida de software há um ou mais modelos formais disponíveis para adoção. Entre os modelos de ciclo de vida de software mais conhecidos está o clássico, também conhecido como modelo cascata (waterfall), espiral e prototipação. Além deste, há os modelos RAD, modelo de quarta geração ou técnicas de quarta geração, modelo em V, modelo transformacional, modelo evolucionário, entre outros.Profº Ricardo luiz 54


CICLOS DE VIDA DE SOFTWARE• Independente do ciclo de vida que seja

adotado é muito importante que se tenha clareza do que deve ser realizado em cada fase do referido ciclo de vida.



CICLOS DE VIDA DE SOFTWARE



CICLOS DE VIDA DE SOFTWARE• A falta de valorização das fases de análise e

design tipicamente geram sérias consequências no processo de manutenção. Não é incomum ver softwares entrando em manutenção antes mesmo de serem concluídos. Se analisarmos a distribuição de tempo investido em cada fase do ciclo de vida poderemos observar que a manutenção é a mais longa e tipicamente a que mais consome recursos (humanos e financeiros). Profº Ricardo luiz 57



MODELO CLÁSSICO


MODELO CLÁSSICO• O ciclo de vida clássico, também muito

conhecido como modelo cascata (waterfall), é uma abordagem sequencial sistemática do desenvolvimento de software. Este ciclo de vida foi modelado com base no ciclo da engenharia convencional (PRESSMAN, 1995). O conjunto de fases que o compõe pode variar conforme a necessidade da equipe em questão.



MODELO CLÁSSICO• O ciclo de vida clássico foi proposto por

Winston W. Royce no ano de 1970 como um conjunto de estágios a serem seguidos para a obtenção de um produto de software. Posteriormente diversas variações do modelo foram propostas. Cada uma com o objetivo de eliminar fragilidades ou promover adaptações para melhorar a utilização do modelo.



MODELO CLÁSSICO



MODELO CLÁSSICO• O modelo clássico tem como potencialidade a

visibilidade da fase em que o projeto se encontra. O que também favorece o modelo é a necessidade de conclusão de uma fase para iniciar a seguinte. Ao seguir tal premissa do modelo, podemos nos beneficiar da existência de artefatos completos para subsidiar a fase seguinte.



MODELO CLÁSSICO• O que conspira contra o modelo clássico é que

geralmente é difícil poder seguir um fluxo sequencial no desenvolvimento de software. Outra dificuldade é conseguir que o usuário detalhe todas as suas necessidades no início do projeto. O que é relativamente natural, pois na medida em que o projeto avança e os requisitos são transformados em funcionalidades de software, novas possibilidades e funcionalidades poderão ser percebidas. Ameaça o uso do modelo também, o fato de que o usuário só terá algo para utilizar quando todo o processo estiver concluído.




MODELO DE PROTOTIPAÇÃO


MODELO PROTOTIPAÇÃO• Dentre o grande conjunto de desafios que

representam os processos de Engenharia de Software está a dificuldade em certificar-se de que os requisitos definidos são efetivamente o que o usuário/cliente necessita. Para reduzir a lacuna de entendimento foi criada a técnica de prototipação.



MODELO PROTOTIPAÇÃO• A prototipação é uma técnica em que são

produzidas versões iniciais ou modelos visuais que representam como o software ficará depois de pronto. A idéia dessa representação é permitir avaliar as características do software antes que ele seja efetivamente desenvolvido. Um modelo visual permite melhorar o entendimento dos requisitos que se pretende implementar no software.



MODELO PROTOTIPAÇÃO• No modelo de prototipação é elaborada uma

representação do modelo do produto através de suas principais funcionalidades. O modelo permite realizar a validação de um conjunto de requisitos que deverão ser implementados. A prototipação é um modelo utilizado com grau de sucesso satisfatório, pois permite ao usuário compreender com mais clareza como o software ficará depois de pronto.



MODELO PROTOTIPAÇÃO



MODELO PROTOTIPAÇÃO• A característica fundamental do modelo de

prototipação é a representação do produto através de suas funcionalidades. A idéia chave deste ciclo de vida é a criação de um modelo para validar o conjunto de requisitos a serem atendidos.



MODELO PROTOTIPAÇÃO• Ele pode ser entendido como uma técnica para

a identificação de requisitos de entrada e saída por parte dos usuários, representando aspectos visíveis a ele, o que permite melhor entendimento daquilo que será entregue no final do projeto. Ele permite ainda a verificação da eficiência de determinadas rotinas ou fluxos de atividades.



MODELO PROTOTIPAÇÃO• Este modelo de ciclo de vida devidamente

utilizado pode auxiliar significativamente o processo de desenvolvimento de software, reduzindo retrabalho e principalmente gerenciando adequadamente a expectativa dos usuários/clientes. No momento que o software funcional é entregue ao usuário/cliente não deverá haver diferenças significativas entre o que foi validado em termos de protótipo e o software construído.Profº Ricardo luiz 71


MODELO PROTOTIPAÇÃO• Uma das fragilidades do ciclo de prototipação é

a dificuldade do usuário/cliente compreender que o software apresentado é apenas um modelo e não possui as funcionalidades que apresenta nas interfaces que ele vê. O usuário imagina que o protótipo é uma versão que ele poderá utilizar imediatamente e não sabe que o protótipo foi construído sem levar em consideração requisitos de qualidade, manutenção e usabilidade.Profº Ricardo luiz 72


MODELO PROTOTIPAÇÃO• Em geral o que ocorre é grande pressão por

parte do usuário em tornar o protótipo a versão de trabalho, efetuando apenas pequenos ajustes. O risco neste caso é de fragilizar o software pela falta de um processo de desenvolvimento adequado.




MODELO ESPIRAL


MODELO ESPIRAL• O modelo espiral foi proposto por Barry Boehm

no ano de 1988 como uma abordagem para contribuir na melhoria da situação dos processos de software da época. O maior diferencial está na abordagem orientada a riscos, ao invés das abordagens orientadas à documentação e codificação.



MODELO ESPIRAL• O ciclo de vida espiral permite acompanhar a

evolução dos requisitos, disponibilizando os segundo a prioridade das necessidades do usuário. Este modelo facilita a incorporação de novos requisitos de forma evolutiva. Ele combina características do ciclo de vida clássico e da prototipação.



MODELO ESPIRAL• No modelo espiral, o desenvolvimento é

progressivo a cada ciclo, sendo que em uma ou mais fases de engenharia e protótipos podem ser desenvolvidos para definir melhor o problema e refinar os requisitos. A técnica de prototipação é utilizada como um mecanismo de redução dos riscos.



MODELO ESPIRAL



MODELO ESPIRAL• O que conspira contra o modelo espiral é a

dificuldade de convencer os usuários das vantagens do uso do modelo evolutivo. Este modelo exige que a equipe de desenvolvimento tenha experiência na avaliação dos riscos. Caso um grande risco seja descoberto, este fato poderá inviabilizar o produto. Contribui também o fato de não haver um histórico suficiente de projetos desenvolvidos nesse modelo para que possa ser determinada sua real eficácia.Profº Ricardo luiz 79



MODELO RAD


MODELO RAD• Com a crescente necessidade de modelos de

processos de software mais ágeis, no início da década de 1990, James Martin propôs o Modelo de Desenvolvimento Rápido de aplicações. Este modelo é conhecido como RAD (Rapid Application Development) e é um processo interativo e incremental que possui tipicamente um ciclo bastante curto.



MODELO RAD• O tempo deste ciclo pode variar de equipe para

equipe, porém é recomendado que ele não seja superior a 90 dias. Este modelo pode ter diversas fases e estas variam de acordo com o autor consultado. De forma genérica, ele possui as fases de definição, desenvolvimento e manutenção.



MODELO RAD• Este modelo é recomendado para o

desenvolvimento de software com pequena distribuição. Ele é apropriado para ambientes em que se possa fazer uso de componentes visuais ou classes pré-existentes como APIs (Application Programming Interface ou Interface de Programação de Aplicativos).



MODELO RAD• O modelo RAD pode ser eficientemente

utilizado em projetos cujo escopo seja restrito e que o desempenho não seja requisito determinante. Também pode ser utilizado em projetos em que o software pode ser dividido em diversos módulos independentes.




MODELO DE QUARTA

GERAÇÃO


MODELO DE QUARTA GERAÇÃO • À medida que as ferramentas de

desenvolvimento passaram a oferecer novos recursos aos profissionais de software, novos modelos de processos também foram desenvolvidos. E o momento em que surgiram as ferramentas de quarta geração foi marcante para a Engenharia de Software, pois se vislumbrou um possível divisor de águas em relação à como softwares eram especificados e desenvolvidos. Profº Ricardo luiz 86


MODELO DE QUARTA GERAÇÃO • O modelo de quarta geração, também

conhecido como técnica de quarta geração, é baseado na utilização de ferramentas de alto nível para especificação e desenvolvimento de softwares. Este modelo visa permitir ao desenvolvedor especificar software de uma forma que esteja próxima à linguagem natural. É uma técnica adequada para desenvolvimento de aplicações pequenas e intermediárias.



MODELO DE QUARTA GERAÇÃO • A técnica de quarta geração pode abranger

as ferramentas de consulta a bancos de dados, geração de relatórios, manipulação de dados, interação e definição de telas, geração de códigos e capacidade gráfica de alto nível.



MODELO DE QUARTA GERAÇÃO



MODELO DE QUARTA GERAÇÃO• O que conspira contra o modelo de quarta

geração é que cada ferramenta permite o desenvolvimento de produtos para domínios de aplicações muito específicos. Além disso, ainda não há ambientes de quarta geração que possam ser utilizados com igual facilidade para todas as categorias de software.



MODELO DE QUARTA GERAÇÃO• Registrem-se ainda dificuldades de utilização

das ferramentas, ineficiência do código gerado a manutenção e usabilidade é questionável. Por estes motivos, em geral o uso da técnica de quarta geração é limitado ao desenvolvimento de um universo restrito de sistemas.




MODELO ALTERNATIVO


MODELO ALTERNATIVO • O modelo alternativo incorpora as

características dos demais modelos, utilizando em maior grau, os processos mais adequados para a aplicação a ser desenvolvida. Além disso, podem-se adotar boas práticas de metodologias de desenvolvimento de software clássicas ou ágeis.



MODELO ALTERNATIVO • O modelo alternativo é o modelo que

permite à equipe de desenvolvimento realizar suas atividades de maneira organizada e com bom nível de qualidade nas entregas. Se analisarmos o ciclo de vida de um software qualquer, concluiremos que dificilmente se adota um modelo na íntegra.



MODELO ALTERNATIVO • Na Engenharia de Software lidamos

fortemente com processos e precisamos estar com a mente aberta para aprender sempre.


TÓPICO 3: REQUISITOS DE SOFTWARE

• Requisitos são características que o software deverá ter capacidade para realizar objetivando resolver algum problema, dar suporte a alguma oportunidade ou atender a necessidades de negócio.

• Os requisitos são a base sobre a qual se apoiará todo o restante do processo de software. Falhas nesta atividade poderão ter consequências catastróficas nas fases posteriores do processo.



POR QUE REQUISITOS SÃO IMPORTANTES?• Em 1994, o Standish Group pesquisou mais de 350

empresas sobre os seus mais de 8.000 projetos de software, para descobrir como eles estavam se saindo. Os resultados são esclarecedores. Trinta e um por cento dos projetos de software foram cancelados antes de serem concluídos. Além disso, em grandes empresas, somente nove por cento dos projetos foram entregues dentro do prazo e do valor estimado no orçamento, e dezesseis por cento satisfizeram estes critérios nas pequenas empresas.



• Para entender o porquê disso, Standish (1995) pediu aos entrevistados para explicarem as causas dos projetos terem falhado. Os fatores principais são relatados a seguir:– 1. Requisitos incompletos (13,1%).– 2. Falta de envolvimento por parte do usuário (12,4%).– 3. Falta de recursos (10,6%).– 4. Expectativas não realistas (9,9%).– 5. Falta de apoio dos executivos (9,3%).– 6. Modificações nos requisitos e nas especificações

(8,7%).– 7. Falta de planejamento (8,1%).– 8. O sistema não era mais necessário (7,5%).Profº Ricardo luiz 98


• Boehm e Papaccio (1988) relataram que, se custa US$ 1,00 identificar e resolver um problema referente aos requisitos durante o processo de definição de requisitos, essa identificação e solução poderão custar US$ 5,00 durante o projeto; US$ 10,00 durante a codificação, US$ 20,00 durantes os testes de unidade e US$ 200,00, depois que o sistema tiver sido entregue! Assim, vale a pena utilizar algum tempo para entender o problema e seu contexto, e obter os requisitos certos na primeira vez.



• Conforme pode ser observado anteriormente, o adequado entendimento dos requisitos de software, além de evitar retrabalho pode aumentar significativamente a probabilidade de sucesso em projetos de desenvolvimento de software. Embora a pesquisa do Standish Group seja de 1994, os resultados apresentados não mudaram significativamente até os dias atuais.



• Uma recomendação básica feita por Pfleeger (2004) para obtenção de requisitos e descobrir o que o usuário/cliente quer é observar os seguintes itens:– Analisar a situação atual.– Fazer com que o usuário aprenda a entender o contexto, os

problemas e os relacionamentos.– Entrevistar os usuários atuais e potenciais.– Produzir um modelo para mostrar como o novo sistema

deverá operar;– Pesquisar a documentação existente.– Realizar um brainstorming com os usuários atuais e

potenciais.– Observar as estruturas e os padrões.Profº Ricardo luiz 101

engenharia de software turma lin-0154. objetivo da disciplina compreender os conceitos fundamentais...

Documents