18
Sete Lagoas - MG 2011 WLADMIR MORENO OLIVEIRA SISTEMA DE ENSINO PRESENCIAL CONECTADO  ANÁLISE E DESENV OLVIMENTO DE SISTEMAS TÍTULO DO TRABALHO: 2º Semestre do curso Análise e Desenvolvimento de Sistemas

68626417-PORTFOLIO

Embed Size (px)

Citation preview

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 1/18

Sete Lagoas - MG2011

WLADMIR MORENO OLIVEIRA

SISTEMA DE ENSINO PRESENCIAL CONECTADO ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

TÍTULO DO TRABALHO:2º Semestre do curso Análise e Desenvolvimento de Sistemas

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 2/18

Sete Lagoas - MG2011

TÍTULO DO TRABALHO:2º Semestre do curso Análise e Desenvolvimento de Sistemas

Trabalho apresentado as disciplina do 2º Semestre docurso Análise e Desenvolvimento de Sistemas daUniversidade Norte do Paraná - UNOPAR

Professores:Fábio ZanellatoLuis Claudio PeriniRoberto NishimuraSimone Tanaka

WLADMIR MORENO OLIVEIRA

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 3/18

SUMÁRIO

1 INTRODUÇÃO ...................................................................................... 3

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 4/18

1 INTRODUÇÃO

Esse portfólio tem como objetivoaprimorar o conhecimento obtido no curso Análise eDesenvolvimento de Sistemas referente ao 2ºsemestre do curso, no qual são estudadas asdisciplinas Engenharia de software, Banco de dadose Linguagens e Técnicas de Programação, partindode uma demonstração de caso de uso ilustrado comuma imagem de diagrama, passando por algunsconceitos de bancos de dados como entidade erelacionamento, sendo encerrado com modelos deprocessos, explicando um pouco sobre processo ágile evolutivo, onde estaremos demonstrando os maisconhecidos e suas principais características.

3

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 5/18

2. Documentação do caso de uso

Nesse diagrama Controlar matricula, teremos a seguintesituação um aluno quer se matricular em uma escola paraestudar, que poderá ser feita de duas maneiras. Ele podefazer pelo site da instituição ou poderá fazer pessoalmente através de um atendente. Como veremosno diagrama seguinte seguido do detalhamento de cadaação de quem faz o que.

2.1 Imagens do diagrama

4

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 6/18

2.2 Descrições do caso de uso

Número do caso deuso

UC 001

Nome do caso deuso

Registrar matrícula.

Atores Aluno, atendente.Descrição Esse caso de uso e responsável por registrar o aluno,

onde solicita a verificação se o aluno já é cadastradopara prosseguir.

Pré-condição Não háPós-condição Só fará o cadastro se o aluno não for cadastrado.Cenário principal 1. O sistema verifica se o aluno esta matriculado.

1. Ele esta matriculado.

2. O sistema lhe oferta a opção de mais um curso.

2. Ele não é matriculado

3. Efetua o registro.

Cenário alternativo Não há

Exceções Não háIncludes Uc 002- verifica se o aluno é matriculado.Uc 004 escolhe o curso.

Extend Não háRegra de negócios Não há

Número do caso deuso

Uc 002

Nome do caso deuso

Verificar se o aluno é matriculado.

Atores Atendente, aluno.Descrição Esse caso de uso e responsável pela verificação se o

aluno já é matriculado em algum curso.Pré-condição Ter iniciado o uc 001Pós-condição Não háCenário principal 1.verifica se o aluno é matriculado.

2. Aluno matriculado.2.1 Envia uma mensagem como o aluno estamatriculado em determinado curso.2.2 Lhe oferece uma lista de outros curso para sematricular.

3. Aluno não matriculado.3.1 Lhe oferece uma lista de curso para se matricular.4. Retorna ao caso de uso 001 para efetua a matricula

5

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 7/18

Cenário alternativo Não háExceções Não háIncludes Não háExtend Uc003 Escolher mais um cursoRegra de negócios Não há

Número do caso deuso

Uc 003

Nome do caso deuso

Escolher mais um curso

Atores Aluno, atendenteDescrição Esse caso de uso fica responsável por ofertar os

cursos adicionais.Pré-condição Se o aluno estiver matriculado em algum curso.

Pós-condição Ter escolhido um cursoCenário principal 1.listar os cursos ofertado2.O aluno escolhe o curso.3. Retorna para o uc001 para completar o registro.

Cenário alternativo Não háExceções Não háIncludes Não háExtend Não háRegra de negócios Não há

Número do caso deuso

Uc004

Nome do caso deuso

Escolher o curso

Atores Aluno, atendenteDescrição Fica responsável por listar os cursos ofertados.Pré-condição Não háPós-condição Ter escolhido um cursoCenário principal 1.O sistema lista os cursos oferecidos

1.1 escolher o curso desejado

2. Retorna para registrar a matrícula.Cenário alternativo Não háExceções Não háIncludes Não háExtend Não háRegra de negócios Não há

Número do caso deuso

Uc005

Nome do caso deuso

Excluir matrícula

Atores Aluno, atendenteDescrição Esse caso de uso fica responsável por efetuar e

exclusão da matrícula.

6

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 8/18

Pré-condição Estar matriculadoPós-condição Não háCenário principal 1. Aciona o caso de uso 002

1.1Lista os cursos1.2Seleciona o curso

2. Executa a exclusão.

Cenário alternativo Não háExceções Não háIncludes Uc 002 verificar se o aluno é matriculado.Extend Não háRegra de negócios Não há

3. Conceitos de banco de dados

3.1Entidade

Entidade pode ser entendida como uma “coisa” ou algo darealidade modelada onde se deseja manter informaçõesno banco de dados (BD). Por exemplo, em um sistemaescolar, algumas entidades podem ser os alunos,professores, horário, disciplinas e avaliações.

3.2 Relacionamento

O relacionamento existe quando um ou mais dados deuma tabela estão relacionados de alguma forma com umou mais dados de outra tabela. Por exemplo, temos umatabela d usuários (users) e uma tabela de posts (posts),cada usuário pode publicar infinitos posts porém cadapost poderá ter apenas um usuário. Estas tabelas estãorelacionadas.Existe também relacionamento de dados de uma tabelacom outros dados desta mesma tabela. Um usuário (user)pode ter vários amigos da mesma tabela (user), então osdados estão relacionados com dados da mesma tabela.3.3 Atributos Um atributo é tudo o que se pode relacionar comopropriedade da entidade. ( coluna , campo , etc,.. ).Exemplos de atributos: Código do Produto (EntidadeProduto) , Nome do Cliente (Entidade Cliente).

3.4 Modelos conceituais

7

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 9/18

Representa as regras de negócio sem limitaçõestecnológicas ou de implementação por isto é a etapa maisadequada para o envolvimento do usuário que nãoprecisa ter conhecimentos técnicos. Neste modelo temos:Visão Geral do negócio, Facilitação do entendimentoentre usuários e desenvolvedores, Possui somente asentidades e atributos principais Pode conter relacionamentos n para m.

3.5 Modelos Lógicos

Leva em conta limites imposto por algum tipo detecnologia de banco de dados. (banco de dadoshierárquico, banco de dados relacional, etc.). Suascaracterísticas são:Deriva do modelo conceitual e via a representação donegócio.Possui entidades associativas em lugar derelacionamentos n:m.

3.6 Modelos Físicos

Leva em consideração limites imposto pelo SGBD(Sistema Gerenciador de Banco de dados) e pelosrequisitos não funcionais dos programas que acessam osdados. Características:Elaborado a partir do modelo lógicoPode variar segundo o SGBDPode ter tabelas físicas (log , lider , etc.)Pode ter colunas físicas (replicação)3.7 Administrador de bancos de dados

O administrador de bancos de dados (DBA) executa umafunção estratégica na empresa, considerando que o maior bem de uma organização hoje são os dados, que estãosobre sua gerência. Para se entender o tamanho daresponsabilidade do DBA com os dados da organização,perdas ocasionais de dados, dependendo de seu volumee importância, podem causar sérios prejuízos à empresae inclusive levá-la à falência.

3.8 a escolha do projeto.

Para esse tipo de projeto, o qual estamos nos referindo aoitem um, que foi criado um caso de uso controlar

8

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 10/18

matrícula, onde o usuário pode ter acesso pela internet oupresencial. O ideal é usar um sistema web. Hoje temos nomercado uma ferramenta poderosa que é o visual estúdioda Microsoft no qual tem suporte para a linguagem

Asp.net .podendo ser criado uma aplicação de altíssimonível no qual fica hospedado em um servidor e pode ser acessado via browser com segurança e confiabilidade,definindo o nível de acesso de cada usuário.

4. Engenharia de Software

4.1 Modelos evolucionários

Modelo incremental

Este modelo é uma extensão do modelo espiral sendo,porém mais formal e rigoroso. O desenvolvimento de umproduto comercial de software é uma grande tarefa quepode ser estendida por vários meses, possivelmente umano ou mais.Por isso, é mais prático dividir o trabalho em partesmenores ou iterações. Cada iteração resultará numincremento. Iterações são passos em fluxo de trabalhoe incrementos são crescimentos do produto.O princípio subjacente ao processo incremental e iterativoé que a equipe envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e âmbito do sistemaenvolvido.Por exemplo, numa primeira iteração deve-se identificar avisão global e determinar a viabilidade econômica dosistema, efetuar a maior parte da anális e e um pouco dedesenho e implementação. Numa segunda geração,deve-se concluir a análise, fazer uma parte significativa dodesenho e um pouco mais de implementação. Numaterceira iteração, deve-se concluir o desenho, fazer-se parte substancial da implementação, testar e integrar um pouco, etc. Ou seja, a principal consequência daaproximação iterativa é que os produtos finais de todo oprocesso vão sendo amadurecidos e completados aolongo do tempo, mas cada iteração produz sempre umconjunto de produtos finais.

A cada iteração são realizadas as seguintes tarefas:

Análise. Refinamento de requisitos, refinamento do

modelo conceitual.

Projeto. Refinamento do projeto arquitetural, projeto de

9

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 11/18

baixo nível.

Implementação. Codificação e testes.

Transição para produto. Documentação, instalação...

Vantagens do processo incremental e iterativo:

• Possibilidade de avaliar mais cedo os riscos e pontoscríticos do projeto, e identificar medidas para eliminá-losou controlar.• Redução dos riscos envolvendo custos a um únicoincremento. Se a equipe que desenvolve o softwareprecisar repetir a iteração, a organização perde somente oesforço mal direcionado de uma iteração, não o valor deum produto inteiro.• Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento.• Disponibilização natural de um conjunto de regras paramelhor controlar os inevitáveis pedidos de alteraçõesfuturas.• Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação e partilha decomunicação daí resultante.

Modelo espiral

O modelo original em espiral organiza o desenvolvimentocomo um processo iterativo em que vários conjuntos defases se sucedem até se obter o sistema final. Um ciclose inicia com a determinação de objetivos, alternativas erestrições (primeira tarefa) onde ocorre ocomprometimento dos envolvidos e o estabelecimento deuma estratégia para alcançar os objetivos. Na segundatarefa, análise e avaliação de alternativas, identificação esolução de riscos, executa-se uma análise de risco.Prototipação é uma boa ferramenta para tratar riscos. Seo risco for considerado inaceitável, pode parar o projeto.Na terceira tarefa ocorre o desenvolvimento do produto.Neste quadrante pode-se considerar o modelo cascata.Na quarta tarefa o produto é avaliado e se prepara parainiciar um novo ciclo.Variações do modelo espiral consideram entre três e seis

tarefas ou setores da espiral, que podem ser:Comunicação com o cliente;Planejamento;

10

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 12/18

Análise de risco;Engenharia;Construção e liberação;

Avaliação do cliente.O modelo espiral é, atualmente a abordagem maisrealística para desenvolvimento de software em grandeescala, e usa uma abordagem que capacita a empresaque presta o serviço, e o cliente a entender e reagir aosriscos em cada etapa evolutiva. Este tipo de modelo exigeconsiderável experiência na determinação de riscos edepende dessa experiência para ter sucesso.

Vantagens deste modelo:

• O modelo em espiral permite que ao longo de cadaiteração se obtenham versões do sistema cada vez maiscompletas, recorrendo à prototipagempara reduzir os riscos.• Este tipo de modelo permite a abordagem dorefinamento seguido pelo modelo em cascata, mas queincorpora um enquadramento iterativo quereflete, de uma forma bastante realística, o processo dedesenvolvimento.

Desvantagens:

• Pode ser difícil convencer grandes clientes(particularmente em situações de contrato) de que aabordagem evolutiva é controlável.• A abordagem deste tipo de modelo exige considerávelexperiência na avaliação dos riscos e baseia-se nessaexperiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.• Este tipo de modelo é relativamente novo e não tem sidoamplamente usado.• é importante ter em conta que podem existir diferençasentre o protótipo e o sistema final. O protótipo pode nãocumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectosdo sistema a ser desenvolvido.• O modelo em espiral pode levar ao desenvolvimento emparalelo de múltiplas partes do projeto, cada uma sendoabordada de modo diferenciado, por isso é necessário ouso de técnicas específicas para estimar esincronizar cronogramas, bem como para determinar os

11

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 13/18

indicadores de custo e progresso mais adequados.

Modelo espiral ganha-ganha

As melhores noegociações buscam um resultado ganha-ganha. Isto é, o cliente ganha obtendo um produto ousistema que satisfaz à maior parte das necessidades docliente, e o desenvolvedor ganha trabalhando comorçamentos e prazos de entrega realísticos e possíveis deserem cumpridos.O modelo espiral ganha-ganha define um conjunto deatividades de negocia ção no começo de cada passagem,em torno da espiral. Ao invés de uma única atividade decomunicação com o cliente,as seguintes atividades sãodefinidas:Identificação dos principais interessados do sistema ou dosubsistema.Determinação das condições de lucro do interessado.Negociação das condições de ganho do interessado parareconciliá-las no âmbito das condições ganha-ganha paratodos os envolvidos.

Além da ênfase na negociação inicial, o modelo espiral

ganha-ganha introduz três marcos de processo,chamados pontos de ancoragem, que ajudam aestabelecer quendo um ciclo é completado em torno daespiral e fornecem marcos de decisão antes do projeto desoftware presseguir. Esses pontos de ancoragem são:

Objetivos de ciclo de vida (life cycle objectives, LCO).Define um conjunto de objetivos para cada atividadeprincipal.Arquitetura do ciclo de vida (life cycle architecture,

LCA).Estabelece objetivos que precisam ser satisfeitos, àmedida que a arquitetura do sistema, e do software, édefinida.Capacidade operacional inicial (initial operationalcapability, IOC).Representa um conjunto de objetivos associado com a

preparação do software para instalação e distribuição.

Modelo de desenvolvimento concorrente

O modelo de desenvolvimento concorrente érepresentado como uma série de grandes atividades

12

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 14/18

técnicas, tarefas e seus estados associados. Ele defineuma série de eventos que podem disparar transições deum estado para outro, para cada uma das atividades daengenharia de software. é freqüentemente usado como

um paradigma para o desenvolvimento de aplicaçõesCliente/Servidor.Pode ser aplicado a todo tipo de desenvolvimento desoftware e fornece uma visão exata de como está oestado do projeto.

Desenvolvimento baseado em componentes

O desenvolvimento baseado em componentes incorporacaracterísticas de tecnologias orientadas a objetos nomodelo espiral. A atividade de engenharia começa com aidentificação de classes candidatas. Se a classe existe,ela será reutilizada.Se a classe não existe, ela será desenvolvida nos moldesdo paradigma de orientação a objetos.

Modelo de métodos formais

O modelo de métodos formais compreende um conjunto

de atividades que determinam uma especificaçãomatemática para o software. Uma variantedessa abordagem é denominada engenharia de softwarecleanroon (Sala Simpa). Utilizando métodos formaiseliminam-se muitos problemas encontrados nosoutros modelos, como p.ex., ambigüidade, incompletitudee inconsistência, que podem ser corrigidas maisfacilmente de forma não ad hoc, mas através deanálise matemática.

4.2 Modelos ágeis 13

Ecrum

No Scrum, os projetos são dividos em ciclos (tipicamentemensais) chamados de Sprints. O Sprint representa umTime Box dentro do qual um conjunto de atividades deveser executado. Metodologias ágeis de desenvolvimentode software são iterativas, ou seja, o trabalho é divididoem iterações, que são chamadas de Sprints no caso doScrum. As funcionalidades a serem implementadas em umprojeto são mantidas em uma lista que é conhecida comoProduct Backlog. No início de cada Sprint, faz-se um

13

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 15/18

Sprint Planning Meeting, ou seja, uma reunião deplanejamento na qual o Product Owner prioriza os itensdo Product Backlog e a equipe seleciona as atividadesque ela será capaz de implementar durante o Sprint que

se inicia. As tarefas alocadas em um Sprint sãotransferidas do Product Backlog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunião(normalmente de manhã), chamada Daily Scrum. Oobjetivo é disseminar conhecimento sobre o que foi feitono dia anterior, identificar impedimentos e priorizar otrabalho do dia que se inicia. Ao final de um Sprint, a equipe apresenta asfuncionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a

equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo

XP

Extreme Programming (XP) é uma metodologia dedesenvolvimento de software, nascida nos EstadosUnidos ao final da década de 90. Vem fazendo sucessoem diversos países, por ajudar a criar sistemas de melhor

qualidade, que são produzidos em menos tempo e deforma mais econômica que o habitual. Tais objetivos sãoalcançados através de um pequeno conjunto de valores,princípios e práticas, que diferem substancialmente daforma tradicionalde se desenvolver software.Por se tratar de uma programação extrema o XP nãodeve ser aplicado a qualquer tipo de projeto. O grupo dedesenvolvedores deve formar uma equipe de 2 a 10integrantes, que devem estar por dentro de todas as fasesdo desenvolvimento. É necessário realizar vários testes,às vezes, alterar o projeto em decorrência destes. Aequipe tem de ser bastante interessada e pró-ativa, paraassegurar a alta produtividade, e o cliente deve estar sempre disponível para tirar dúvidas e tomar decisões emrelação ao projeto, porém é uma boa opção pois ainclusão do Extreme Programming no dia a dia dodesenvolvimento de software enriquece a comunidade deprogramação independente do segmento das empresasnos quais os profissionais desempenham suas atividades,garantindo a evolução dos negócios e garantindodinamismo na economia atual.

MSDM

14

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 16/18

A DSDM fornece uma framework para uma abordageminterativa e incremental de desenvolvimento de Sistemasde Informação (SI). Desenvolveu-se nos anos 90 naInglaterra e foi aplicado pela primeira vez em 1995. Estametodologia foi desenvolvida por um consórcio devendedores e peritos no campo dos Sistemas deInformação, no qual partilharam e combinaram as suasmelhores técnicas. Assim, a DSDM surge como umaextensão do RAD (Rapid Application Development ),focada em projetos de Sistemas de Informaçãocaracterizados por prazos e orçamentos apertados. A DSDM aborda os problemas que freqüentementeocorrem no desenvolvimento de informação que seprendem essencialmente com a falta de tempo, com

orçamentos mais apertados ou com outro tipo de razõespara que o projeto falhe, tal como a falta de envolvimentodos encarregados do projeto ou dos utilizadores finais.

A DSDM segue alguns princípios chave. Estes princípiosdelimitam as bases do desenvolvimento utilizando DSDM.O ponto fundamental desta metodologia prende-se com aentrega de um sistema que se aproxime das atuaisnecessidades de negócio. Não é uma metodologia tãodireta que forneça todas as necessidades de negócio,mas centraliza todo o potencial na concretização final detodos os objetivo do projeto.Nenhum sistema é completamente construído na primeiratentativa. Num processo de desenvolvimento de umsistema informático 80% da solução pode ser desenvolvida em 20% do tempo necessário paraencontrar a solução perfeita. Para aperfeiçoar a parte finalpoderá ser necessário que o projeto ultrapasse o seutempo e orçamento estipulados. Uma vez que a DSDM écaracterizada por realizar exatamente o que a empresanecessita, é muitas vezes desnecessário chegar à

solução perfeita. A entrega do projecto deve ser feita na data estipulada,dentro do orçamento previsto e com boa qualidade (Fig.2). As exigências para o Sistema de Informação têm que ser flexíveis. Tal como falaremos mais tarde, exigênciasflexíveis são tópicos importantes daDSDM.Esta metodologia apenas requer que cada etapa dodesenvolvimento seja completada até que seja possíveliniciar o passo seguinte. Isto faz com que cada fase doprojeto possa começar sem ter que esperar que as fasesque começaram anteriormente sejam totalmente

15

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 17/18

terminadas. A comunicação entre todas as partes envolvidas(stakeholders ) é também um pré-requisito bastanteimportante para que o projeto corra com a eficiênciadesejada.O envolvimento dos utilizadores é a chave para estaeficiência. As equipas responsáveis têm que ser dotadas de umsentido de decisão, sendo este também um ponto fulcralna progressão do projeto.Tal como as equipes de desenvolvimento também asequipas de gestão do projeto estão incorporadas naDSDM. Após o desenvolvimento do Sistema de Informação, aDSDM pode tambémSer usado para expandir o Sistema obtido. Apesar da utilização de uma metodologia ágil não ser aconselhada para todos os tipos de projeto, a DSDM éuma ótima e segura base para equipas dedesenvolvimento que têm em mãos projetos comnecessidade de execução rápida e com requisitosflexíveis. A partir desta metodologia, é possível construir um trabalho que agrade ao cliente graças ao cumprimentodos prazos e orçamentos à equipe de desenvolvimento

que terá em mãos um projeto organizado e com obrigaçãode cumprir apenas os requisitos necessários à execuçãodo sistema e aos utilizadores finais que terão aoportunidade de interagir com todo o desenvolvimento dosistema de informação, através das freqüentes fases detestes.

MSF

A MSF foi criado em1994, e originou-se da análise detimes de projetos e grupo de produtos, estas análiseseram constatadas com a indústria de práticas e métodos.Estes resultados combinados eram consolidados emmelhores praticas entre pessoas e processos.O MSF (Microsoft Solutions Framework) tem sido usadopela Microsoft como o seu “método” paradesenvolvimento de soluções de software dentro daMicrosoft e também para os milhares de clientes eparceiros da Microsoft em todo o mundo. A disseminação deste método, agora na versão 5.0,

normalmente induz as pessoas a compará-lo com outros“métodos” da indústria, como o RUP, CMMIou XP, entre

16

7/28/2019 68626417-PORTFOLIO

http://slidepdf.com/reader/full/68626417-portfolio 18/18

outros. É importante entender, entretanto, o que são esteselementos antes de compará-los.O MSF para Desenvolvimento Ágil de Software é um guiade procedimentos, uma coleção de boas práticas paraprojetos de desenvolvimento de softwares.Um projeto MSF é regido por ciclos ou iterações. A cadaciclo, cada componente da equipe executa suas funções eatualiza o resultado do seu trabalho conforme anecessidade. Os ciclos se repetem até que o projeto sejaconcluído ou cada versão seja lançada.Cada componente da equipe será responsável por um oumais papéis, dependendo do tamanho ou dacomplexidade do projeto

5. Referência

Tanaka,Simone Sawasaki Análise de sistema lSão Paulo Pearson Prentice Hall,2009

Perini,Luiz CláudioEngenharia de Software:sistema ll / Luiz CláudioPerini,Marco Ikuro,Hisatomi,Wagner Luiz Berto -- SãoPaulo Pearson Prentice Hall,2009.

PETERS, JAMES F., Engenharia de Software: Teoria ePrática , Rio de Janeiro,Editora Campus, 2001.Nishimura,Roberto yukioBanco de dados l / Roberto yukio Nishimura -- São PauloPearson Prentice Hall, 2009.

Arlow, Jim; Neustadt, Ila.UML and the Unified Process: Pratical Object- Oriented Analysis & Design. Great Britain: Addison-Wesley, 2002.

17