Aula 1

Introduo engenharia de software

Objetivos
Ao nal desta aula, esperamos que voc seja capaz de:

Pr-requisitos
Para poder ter xito na disciplina de Engenharia de Software e entender melhor esta aula em particular, necessrio que voc tenha tido bastante entendimento de disciplinas de mdulos anteriores, como Programao e Computao Bsica. importante que voc revise, em especial, os principais conceitos da programao orientada a objetos, como objeto e herana. Alm disso, voc deve estar disposto a enxergar o software sob uma nova perspectiva: a de analista de sistemas.

Introduo
Nas disciplinas vistas at agora no curso, o foco era conhecer os conceitos bsicos de computao, sistemas de informao e programao. As funcionalidades eram previamente denidas e cabia a voc realizar a implementao. Na disciplina de Engenharia de Software, voc far o trabalho de observar um determinado problema e determinar o que deve ser feito e como deve ser feito, de acordo com as necessidades do cliente e as caractersticas do projeto. Para iniciar a nossa viagem pelo rico mundo da Engenharia de Software, a aula de hoje tratar sobre o conceito de software e problemas com o seu desenvolvimento. Tambm conceituar Engenharia de Software e apresentar alguns modelos de processo. Pronto para dar incio nossa primeira aula? Vamos l!

UNIVALI/UNITINS SUPERIOR DE TECNOLOGIA 3 PERODO

Engenharia Software.indb 9

17/12/2007 18:36:39

AULA 1 ENGENHARIA DE SOFTWARE

1.1 O Software
Voc j viu o conceito de software na aula 4 da disciplina de Computao Bsica do primeiro mdulo. Para comear a nossa aula, vamos revisar este conceito, mas considerando uma abordagem de Engenharia de Software. Segundo Pressman (2006), sob o ponto de vista da Engenharia de Software, um software um conjunto composto por instrues de computador, estruturas de dados e documentos. As instrues (ou cdigo) produzem os resultados esperados, de acordo com os requisitos denidos. J as estruturas de dados so as responsveis por permitir a manipulao e armazenamento das informaes. E por m, os documentos iro conter uma descrio das funcionalidades previstas no software e da forma como elas foram implementadas. Fazem parte da documentao, ainda segundo Pressman (2006) um plano de projeto, uma especicao dos requisitos necessrios, o projeto do sistema e a especicao de testes. Estes diferentes documentos so artefatos produzidos no processo de desenvolvimento do software. Voc ir aprender como produzir cada um destes artefatos no decorrer desta disciplina e da disciplina de Engenharia de Software do 4 mdulo. Por enquanto, concentre-se na viso geral destes elementos.

1.1.1 A histria do software e o surgimento da Engenharia de Software Agora que j temos uma noo do que um software e de quais so seus elementos, vamos entender um pouco sobre a sua histria. Os primeiros softwares surgiram na dcada de 50. Nesta poca, todo o foco dos pesquisadores estava concentrado no hardware. O software era desenvolvido sem nenhuma tcnica de engenharia e a sua distribuio era bastante limitada. O hardware estava disponibilizado apenas em grandes centros de pesquisa, e por este motivo, o software era pouco conhecido. Em meados dos anos 60, a situao comeou a se modicar. Com o surgimento dos microprocessadores, o hardware deixou de representar um problema e, conseqentemente, deixou de ser o foco dos pesquisadores, que passaram a investir mais em software. Assim, as organizaes comearam a desenvolver grandes sistemas, dando origem ao conceito de produto de software, que passou a ser comercializado. Entretanto, manteve-se a metodologia de se desenvolver os sistemas sem nenhuma metodologia, ou seja, desenvolver sem nenhum planejamento. As

10

3 PERODO SUPERIOR DE TECNOLOGIA UNIVALI/UNITINS

Engenharia Software.indb 10

17/12/2007 18:36:39

AULA 1 ENGENHARIA DE SOFTWARE

equipes de trabalho no tinham nenhuma orientao sobre como desenvolver e nenhum processo de desenvolvimento para seguir. No havia uma documentao adequada do que estava sendo feito. Com a maior demanda e, conseqentemente, um maior nmero de usurios do sistema, as manutenes tambm cresceram. E como fazer para dar manuteno a um sistema que no tem um projeto? Analogamente, como saber se possvel derrubar a parede de uma casa, sem conhecer onde esto as vigas, as estruturas fundamentais? Pensando assim, podemos deduzir que o processo de manuteno destes sistemas se tornou impraticvel. Os programadores gastavam horas tentando descobrir como realizar a manuteno, e no se sabia exatamente quais seriam os efeitos colaterais provocados. Por todos estes motivos, os custos dos produtos se tornavam muito altos. Os recursos destinados ao projeto nunca eram sucientes. As solues propostas no agradavam aos clientes. Um novo desao estava surgindo para as empresas (e um desao presente ainda hoje) que no era mais o hardware, e sim reduzir o custo e melhorar a qualidade dos softwares produzidos. Em virtude do caos que havia se instaurado nas empresas, alguns questionamentos surgiram: por que o software era desenvolvido sem planejamento? Por que no aplicar uma abordagem prtica, organizada e ordenada no desenvolvimento dos projetos? Na verdade, quando o software comeou a ser desenvolvido, ele era tido como um tipo de arte, mas com o tempo, observou-se que era perfeitamente possvel aplicar ao software uma abordagem de engenharia, dando origem Engenharia de Software.

1.1.2 Caractersticas do software Como vimos no item anterior, existem diculdades no processo de desenvolvimento de software. Devemos entender que o software um produto abstrato e que apresenta caractersticas diferentes de um produto comum, como um televisor. Isto acaba tornando o seu processo de desenvolvimento mais complexo. Alm disto, ele apresenta outras caractersticas que o diferenciam de um produto manufaturado comum (PRESSMAN, 2006): 1. O software desenvolvido ou projetado por engenharia, no manufaturado no sentido clssico, sendo que o desenvolvimento de software fundamentalmente diferente do desenvolvimento de hardware;

UNIVALI/UNITINS SUPERIOR DE TECNOLOGIA 3 PERODO

11

Engenharia Software.indb 11

17/12/2007 18:36:39

AULA 1 ENGENHARIA DE SOFTWARE

2. O software no se desgasta, mas se deteriora devido s diversas manutenes que pode sofrer. Teoricamente, o software inicia com um alto ndice de falhas, mas as falhas so corrigidas e ele atinge a estabilidade, no sofrendo com desgaste, como ocorre com um produto comum, que se desgasta medida que o tempo passa. Entretanto, na prtica, manutenes so introduzidas no projeto, e juntamente com estas manutenes so introduzidos novos erros. Desta forma, o software acaba se deteriorando frente a sucessivas mudanas. 3. Embora j se observe que a indstria est se preocupando com a montagem de softwares baseada em componentes (reusabilidade), a maioria ainda feita sob medida, em vez de ser montada a partir de componentes existentes.

1.1.3 Problemas com o desenvolvimento de software Como as caractersticas do software so bastante particulares, acabamos encontrando diversos problemas associados ao software, e que podemos observar na realidade das mais diversas empresas, tanto maiores, quanto menores. Para comear, uma das principais queixas existentes a de que custos e prazos no so respeitados, sendo que as estimativas feitas so bem diferentes da realidade. Existem diversos motivos para que isso ocorra, principalmente, o fato de no termos tempo suciente para coletar os dados sobre o software que o cliente deseja. Ou at mesmo, no termos um processo de estimativa de tempo adequado. Tambm observamos que a identicao dos requisitos ineciente, resultando em produtos que no atendem necessidade dos clientes nais. Como falta utilizao de tcnicas adequadas para a coleta dos requisitos, os softwares produzidos no so conveis e no tm a robustez necessria. A interao entre os analistas de sistemas e os clientes difcil. Falta foco no problema que realmente se quer resolver. Quando estamos lidando com o desenvolvimento de software, devemos ter em mente que, normalmente, no desenvolveremos um software para um problema da rea da computao, mas temos que desenvolver um sistema que atenda a uma outra rea de conhecimento. Ou seja, de extrema importncia a boa comunicao entre analista de sistemas e cliente. Existe um alto custo de manuteno envolvido, pois a tarefa de manuteno toma muito do oramento destinado ao software. Um outro ponto que ocorre

12

3 PERODO SUPERIOR DE TECNOLOGIA UNIVALI/UNITINS

Engenharia Software.indb 12

17/12/2007 18:36:39

AULA 1 ENGENHARIA DE SOFTWARE

que no se pensa na qualidade e facilidade da manuteno quando se est construindo o software. E alm de todos estes problemas, os gerentes e coordenadores de projetos se encontram, em muitos casos, despreparados para controlar adequadamente o desenvolvimento de um software. Desta forma, a produtividade das equipes baixa frente quantidade crescente de demandas de software.

1.2 Engenharia de Software Neste momento, voc j tem uma noo do que um software e conhece mais sobre os problemas envolvidos no seu desenvolvimento. Deve, tambm, estar atento ao fato de que a Engenharia de Software tem por objetivo auxiliar o processo de desenvolvimento de software. Ento, podemos passar denio do que Engenharia de Software. A Engenharia de Software pretende introduzir no desenvolvimento de software as sistemticas j utilizadas em outras reas da Engenharia. Pretende levar os custos a nveis aceitveis, gerenciar o processo de desenvolvimento, permitir o trabalho em grupo, com uma maior produtividade, alm de permitir desenvolver softwares de qualidade. Uma denio formal de Engenharia de Software a criao e a utilizao de slidos princpios de engenharia a m de obter software econmicos que sejam conveis e que trabalhem ecientemente em mquinas reais (BAUER, 1969 apud PRESSMAN, 2006, p.17). Para alcanar estes objetivos, a Engenharia de Software usa de planejamento, processos sistemticos, gerenciamento e controle. Podemos dizer que a Engenharia de Software composta pelos seguintes elementos: Mtodos, Ferramentas e Processos, tal como ilustrado na Figura 1.

Mtodo Ferramentas Processos

Como fazer Fornece apoio automatizado aos mtodos Organiza mtodos e ferramentas

Figura 1 - Elementos da Engenharia de Software Fonte - Adaptado de Pressman (2006)

UNIVALI/UNITINS SUPERIOR DE TECNOLOGIA 3 PERODO

13

Engenharia Software.indb 13

17/12/2007 18:36:39

AULA 1 ENGENHARIA DE SOFTWARE

Os mtodos indicam como fazer. Desta forma, existem diferentes mtodos para as diferentes etapas do desenvolvimento de um software. Ou seja, existem mtodos que podem ser aplicados anlise de requisitos de software e projeto, codicao, aos testes e manuteno. As ferramentas, como a prpria gura mostra, iro fornecer apoio automatizado aos mtodos. So as ferramentas CASE (Computer Aided Software Engineering Ferramentas Automatizadas para Engenharia de Software). Como ponto de partida, voc pode pesquisar diferentes ferramentas CASE, proprietrias ou de software livre. Ao longo da disciplina, iremos indicar algumas. E por m, temos os processos, que unem os mtodos e as ferramentas. Os processos iro indicar como aplicar os mtodos e ferramentas escolhidos, ou seja, a seqncia em que estes devem ser aplicados. Tambm iro denir os artefatos que devem ser produzidos, sendo que artefatos so produtos obtidos a partir das tarefas de um projeto, que podem ser avaliados, medidos. Alm disso, iro permitir denir marcos que possibilitem que o progresso do software seja avaliado. Pode-se dizer que o processo funciona como uma receita, indicando a combinao de ferramentas e tcnicas que iro produzir um resultado especco. O processo fundamental para que se tenha consistncia e coerncia no desenvolvimento de um software, por isso, veremos mais detalhes sobre isso no prximo item.

1.2.1 Viso genrica de processo de software Pressman (2006) dene um arcabouo de processo genrico. Seriam atividades fundamentais que os processos deveriam contemplar e que poderiam ser aplicadas a diversos tipos de software, tanto grandes quanto pequenos. Entre estas atividades, temos a comunicao, o planejamento, a modelagem, a construo e a implantao. A comunicao compreende atividades que envolvem interao com o usurio, como o levantamento de requisitos. J o planejamento envolve a elaborao de um plano de trabalho, onde estaro descritos riscos, recursos necessrios, cronogramas. Na atividade de modelagem, feito um detalhamento dos requisitos obtidos de maneira que tanto o cliente quanto o desenvolvedor possam entend-los adequadamente. A construo prev tanto a codicao do projeto elaborado, quanto os testes para garantir que o que foi produzido atende o que era esperado. E

14

3 PERODO SUPERIOR DE TECNOLOGIA UNIVALI/UNITINS

Engenharia Software.indb 14

17/12/2007 18:36:39

AULA 1 ENGENHARIA DE SOFTWARE

por m, na implantao, o produto desenvolvido entregue ao cliente para sua avaliao. Um processo estabelece, ento, uma seqncia de atividades, e cada atividade produz uma variedade de artefatos (ou documentos), e com isso, pretende-se chegar a um programa resultante satisfatrio, que atenda s necessidades dos clientes, respeitando prazos e custos estabelecidos. O processo, por si s, no suciente para garantir que a empresa consiga produzir tais softwares. necessrio que tal processo seja efetivamente aplicado, que seja seguido por analistas e desenvolvedores e que atenda s normas de qualidade de processo. O CMMI (Capability Maturity Model Integration) (CMMI, 2002) um metamodelo de processo que dene as caractersticas de processo que devem existir quando uma organizao deseja estabelecer um processo de software que seja completo. O CMMI dene nveis de maturidade que uma empresa pode conseguir medida que avana no processo de software que tem implantado. Isto quer dizer que o CMMI descreve metas, prticas e capacidades especcas que devem estar presentes em um processo de software maduro. Entretanto, existem diculdades para as pequenas e mdias empresas conseguirem esta certicao, como os custos elevados para sua obteno. Desta forma, no Brasil, temos o MPS-BR (MPS-BR, 2007), que tem foco nas pequenas e mdias empresas e tambm apresenta diferentes nveis de maturidade para o processo.

Saiba mais
Para voc conhecer mais sobre os modelos MPS-BR e CMMI, acesse os sites informados nas Referncias desta aula. L voc encontrar todos os detalhes referentes a estes modelos.

1.2.2 Modelos de Processos Agora, voc j sabe o que um processo de software e quais so os seus objetivos, bem como conhece um arcabouo genrico de processo. Vamos, ento, conhecer alguns modelos mais populares. Os modelos de processo de software so tambm conhecidos como modelos de ciclo de vida de software, pois ele descreve a vida do produto de software desde a concepo at a implementao, entrega, utilizao e manuteno.

UNIVALI/UNITINS SUPERIOR DE TECNOLOGIA 3 PERODO

15

Engenharia Software.indb 15

17/12/2007 18:36:40

AULA 1 ENGENHARIA DE SOFTWARE

1.2.2.1 Modelo Cascata O ciclo de vida em cascata, ou ciclo de vida clssico, um dos primeiros modelos propostos. Ele sugere uma abordagem sistemtica e seqencial, ou seja, para poder iniciar a prxima atividade, a anterior deve estar totalmente terminada. Conforme podemos observar na Figura 2, o modelo cascata prope as fases de anlise de viabilidade, anlise de requisitos, projeto, implementao, testes, implantao e manuteno. Observe que estas fases do modelo cascata se encaixam no arcabouo genrico que vimos na seo anterior.
Anlise de viabilidade Anlise de requisitos Projeto Cofificao Testes Manuteno Figura 2 - Modelo cascata Fonte - Adaptado de Pressman (2006)

Este modelo pode ser utilizado em projetos onde os requisitos do sistema so claros e bem denidos, j que o modelo no prev retornos para a fase de levantamento de requisitos. Entretanto, voc acha que ser comum encontrar sistemas com requisitos bem definidos logo no incio do projeto? Infelizmente, pode-se dizer que isto muito raro, sendo que esta caracterstica se torna uma fraqueza do mtodo. Um outro problema deste mtodo que o cliente s ver o sistema funcionando depois que ele estiver completamente pronto. Ou seja, qualquer solicitao de alterao no sistema pode se tornar um trabalho difcil. Mas vale destacar que o modelo cascata bastante simples, no sentido de que as atividades so bem denidas e claras. Este modelo tem sido base para outros modelos mais complexos, que o utilizam incorporando atividades extras ou ciclos iterativos.

16

3 PERODO SUPERIOR DE TECNOLOGIA UNIVALI/UNITINS

Engenharia Software.indb 16

17/12/2007 18:36:40

AULA 1 ENGENHARIA DE SOFTWARE

1.2.2.2 Prototipao Neste modelo de processo, pretende-se utilizar prottipos do sistema para auxiliar na denio dos requisitos, possibilitando aos clientes e desenvolvedores examinarem certos aspectos do software, denindo se eles so, ou no, apropriados ao produto nal. Alm disso, o prottipo deve ser construdo de forma rpida, sem preocupao com detalhes de modelagem, desempenho e manutenibilidade. O prottipo produzido deve focar em aspectos que interessam ao cliente, como o desenho de interface. Conforme podemos observar na Figura 3, o primeiro passo uma reunio com os clientes, para que o analista possa ter uma primeira idia daquilo que eles desejam para o sistema. A partir disso, feito um projeto rpido do software. O objetivo produzir algo que possa ser utilizado para discutir melhor o requisito com o cliente. Depois que o requisito bem denido, ou seja, depois que analista e cliente chegam a um consenso, ento, feito o projeto detalhado do software, a codicao, testes e implantao. A prototipao se mostra bastante til. Deve-se, entretanto, ter em mente que o prottipo precisa ser descartado ao nal do processo, e que a modelagem adequada da funcionalidade deve ser feita. O prprio cliente precisa estar bem ciente de que o produto dever ser refeito, para que ele no imagine que tem uma verso nal nas mos. Os desenvolvedores envolvidos no processo devem tomar muito cuidado para no se sentirem tentados a adicionar o cdigo feito sem planejamento ao sistema.

Coleta e Refinamento dos Requisitos

Projeto Rpido

Engenharia do Produto

Construo do Prottipo

Refinamento do Prottipo

Avaliao do Prottipo pelo Cliente

Figura 3 - Modelo prototipao Fonte - Adaptado de Pressman (2006)

UNIVALI/UNITINS SUPERIOR DE TECNOLOGIA 3 PERODO

17

Engenharia Software.indb 17

17/12/2007 18:36:40

AULA 1 ENGENHARIA DE SOFTWARE

1.2.2.3 Modelo Iterativo O modelo iterativo prope usar o modelo cascata iterativamente, de forma que testes e integraes sejam aplicados desde o incio do projeto. Assim, o software desenvolvido incrementalmente, e a cada incremento, uma funcionalidade adicionada ao sistema, conforme pode ser observado na Figura 4. Desta forma, o modelo permite o feedback do cliente desde o incio do projeto. Trabalhando com pequenos objetivos e com foco no curto-prazo, o progresso pode ser medido de forma mais concreta. A diferena fundamental deste modelo em relao prototipao que o modelo iterativo fornece um produto operacional a cada incremento, ou seja, quando o cliente v a funcionalidade, ela j est pronta para a implantao, porque foi desenvolvida respeitando todas as etapas do processo.
Incremento 01 Comunicao Incremento 02 Comunicao Incremento N Comunicao

Planejamento

Planejamento

Planejamento

...
... ... ...

Implantao
Entrega de incremento 01

Implantao
Entrega de incremento 02

Implantao
Entrega de incremento N

Figura 4 - Modelo iterativo Fonte - Adaptado de Pressman (2006)

1.2.2.4 Qual o melhor modelo? Alm dos modelos apresentados nesta aula, existem outros modelos que propem a combinao e variaes de modelos existentes. Existem, ainda, modelos que propem a insero de anlise de riscos ao processo, como o caso do modelo espiral. Entretanto, no existe um modelo que se encaixe em todas as situaes, ou seja, no existe o modelo perfeito. Caber ao engenheiro de software denir qual o modelo mais adequado, considerando fatores como o tipo de software a ser desenvolvido, equipe disponvel e tambm com base na disponibilidade do cliente. Alm disso, o engenheiro de software pode, e deve, adaptar os modelos existentes de acordo com as suas necessidades.

18

3 PERODO SUPERIOR DE TECNOLOGIA UNIVALI/UNITINS

Engenharia Software.indb 18

17/12/2007 18:36:42

AULA 1 ENGENHARIA DE SOFTWARE

Concluso
Um projeto de software, que inicialmente poderia ser considerado simples, quando mal planejado, pode gerar diversos problemas, e realmente geram, como podemos observar na realidade de muitas empresas que encontramos. neste sentido que percebemos a importncia da Engenharia de Software, que ir permitir que o processo de software seja disciplinado e bem executado.

Sntese da aula
Na aula de hoje, vimos o conceito de software. Aprendemos que um software no apenas um conjunto de linhas de cdigo. Por se tratar de um produto complexo, existem diversos problemas envolvidos no seu desenvolvimento. Para solucionar, ou melhor, minimizar estes problemas, temos a Engenharia de Software, que ser nosso objeto de estudo nesta disciplina. Ela fornece tcnicas, ferramentas e processos que podem ser usados no desenvolvimento para torn-lo mais objetivo e organizado. Vimos tambm alguns modelos de processo, incluindo um arcabouo de modelo genrico.

Atividades
1. Um software pode ser denido como: a) Um conjunto de programas, que so entendidos e executados por um computador, estrutura de dados e documentao associada. b) Documentao e estrutura de dados. c) Anlise de requisitos, projeto e especicao de testes. d) Um conjunto de programas, que implementam os requisitos solicitados pelo cliente. e) Um conjunto de programas e especicao de testes. 2. Sobre a Engenharia de Software, correto armar: a) A Engenharia de Software visa apenas um produto de qualidade, independente das necessidades do cliente. b) A Engenharia de Software visa uma maior produtividade, e para isto, no inclui qualquer tipo de documentao nos seus processos, focando apenas na implementao. c) A Engenharia de Software visa utilizar princpios de engenharia para produzir e manter softwares de qualidade, respeitando custos e prazos inicialmente estimados.

UNIVALI/UNITINS SUPERIOR DE TECNOLOGIA 3 PERODO

19

Engenharia Software.indb 19

17/12/2007 18:36:42

AULA 1 ENGENHARIA DE SOFTWARE

d) A Engenharia de Software visa utilizao de mtodos e ferramentas de forma aleatria, para o desenvolvimento de software. e) A Engenharia de Software visa apenas facilitar o processo de manuteno de um software. 3. Com relao ao arcabouo genrico de software, incorreto armar: a) A comunicao envolve a interao inicial entre analista e cliente. b) A modelagem prev o detalhamento dos requisitos do sistema. c) O planejamento envolve as estimativas de recursos, riscos e cronogramas. d) O modelo genrico contm fases que podem ser aplicadas a qualquer tipo de software. e) Na implantao, esto previstos os testes e a disponibilizao do software para o cliente. 4. Indique quais armaes so verdadeiras com relao aos modelos de ciclo de vida. Depois, assinale a seqncia correta: I. ( ) O modelo cascata pode ser utilizado para situaes onde os requisitos estejam mal denidos.. II. ( ) O modelo prototipao usa prottipos para facilitar a interao entre clientes, analistas e desenvolvedores. III. ( ) Toda funcionalidade intermediria fornecida pelo modelo iterativo est pronta para ser anexada ao software. IV. ( ) Tanto o modelo de prototipao quanto o modelo iterativo permitem que o usurio acompanhe mais de perto o desenvolvimento do software. a) F; V; F; V b) V; F; V; F c) F; V; V; V d) V; F; F; V e) V; F; V; V

Comentrios das Atividades

Atividade 1 - Conforme descrito logo no incio desta aula, um software muito mais do que um programa funcionando. Um software deve ser analisado, projetado, desenvolvido, testado. Devem ser escolhidas as estruturas de dados que sero usadas para armazenamento e manipulao das informaes. Voc respondeu a esta questo corretamente? Qual foi a alternativa que voc assinalou? A resposta correta da primeira questo a letra (a). Se voc assinalou algo diferente, releia o item 1.1 desta aula.

20

3 PERODO SUPERIOR DE TECNOLOGIA UNIVALI/UNITINS

Engenharia Software.indb 20

17/12/2007 18:36:42

AULA 1 ENGENHARIA DE SOFTWARE

Atividade 2 - A Engenharia de Software visa trazer benefcios para todo o processo de software, procurando deixar clientes e equipe de trabalho mais satisfeitos. O seu objetivo nal produzir software de qualidade, utilizando-se de mtodos e ferramentas, organizados segundo um procedimento. Tambm podemos dizer que a Engenharia de Software quer o aumento da produtividade, mas sempre levando em considerao a documentao. Embora se gaste tempo com documentao, ela sempre trar um ganho para o projeto e minimizar problemas, como a sada de um integrante da equipe, mudanas nos requisitos iniciais, entre outros. Desta forma, a resposta correta para esta atividade a letra (c). Atividade 3 - O modelo genrico pode ser usado para qualquer tipo de software, e ao contrrio do que a alternativa (d) arma, os testes so feitos na fase de construo. Atividade 4 - A resposta correta para esta questo a letra (c), pois o modelo cascata somente pode ser usado em sistemas onde os requisitos estejam bem denidos. Os modelos de prototipao e iterativo tm como principal diferena o fato de que o primeiro usa para discusso com o usurio um prottipo que precisa ser descartado. E o segundo disponibiliza funcionalidades prontas para serem anexadas ao software.

Referncias
CMMI Capability Maturity Model Integration. Verso 1.1, Software Engineering Institute. http://www.sei.cmu.edu/cmmi/. Acesso em: 16 set. 2007. MPS-BR. Guias. Disponvel em: http://www.softex.br/mpsbr/_guias. Acesso em: 16 set. 2007. PAULA FILHO, Wilson de Padua. Engenharia de software: fundamentos, mtodos e padres. Rio de Janeiro: LTC, 2003. PRESSMAN, Roger. Engenharia de software. So Paulo: McGraw-Hill, 2006.

Na prxima aula
Agora que sabemos o que software, o que Engenharia de Software, e conhecemos modelos de processo, poderemos, na prxima aula, tratar de processos de software especcos. Conversaremos sobre o Processo Unicado e tambm sobre Modelos geis de Processo. Ser muito interessante. No perca!

UNIVALI/UNITINS SUPERIOR DE TECNOLOGIA 3 PERODO

21

Engenharia Software.indb 21

17/12/2007 18:36:43

AULA 1 ENGENHARIA DE SOFTWARE

Anotaes

22

3 PERODO SUPERIOR DE TECNOLOGIA UNIVALI/UNITINS

Engenharia Software.indb 22

17/12/2007 18:36:43