ENGENHARIA DE SOFTWARE I

INSTITUTO SUPERIOR POLITÉCNICO DE TECNOLOGIAS E CIÊNCIAS

ENGENHARIA DE SOFTWARE I

CAPÍTULO I. INTRODUÇÃO À ENGENHARIA DE SOFTWARE

Ladislau Lutete
 SUMÁRIO 2

Capítulo 1. Introdução à Engenharia de Software

1.1 Conceitos básicos de Engenharia de Software
1.2 Processo de Software
1.3 Modelos de Processo
1.3.1 Modelo Cascata
1.3.2 Modelo V
1.3.2 Modelo Incremental
1.3.3 Modelos Evolucionários
1.3.3.1 Modelo de Prototipagem
1.3.3.2 Modelo emespiral
1.3.5 Modelo Concorrente
1.3.5 Modelos Especializados
 BIBLIOGRAFIA 3

Part I. Introduction to SoftwareEngineering

Chapter 1. Introduction
Chapter 2. SoftwareProcess
2.1. Software Process Model
2.2 Process activities

Capítulo 1. Software e Engenharia de Software

Parte 1. Processos de Software
Capítulo 2. Modelos de Processos
INTRODUÇÃO À ENGENHARIA DE 4

SOFTWARE
 INTRODUÇÃO À ENGENHARIA DE 5

SOFTWARE

Programa de computador
vs.
Software

Desenvolvimento de sofware
vs.
Desenvolvimento Profissional de software
 INTRODUÇÃO À ENGENHARIA DE 6

SOFTWARE

• As abordagens individuais para o desenvolvimento de software não

agregavam valor positivo aos grandes e complexos sistemas de software.
Estes não eram confiáveis, custavam mais do que o esperado e eram
entregues com atraso.
• A noção de "engenharia de software" foi proposta pela primeira vez em
1968 numa conferência realizada para discutir o que foi chamado de
"crise do software" (Naur e Randell, 1969).
 INTRODUÇÃO À ENGENHARIA DE 7

SOFTWARE

• A ESOFT permitiu que ao longo dos anos 1970 e 1980, fossem

desenvolvidas diversas técnicas, métodos e ferramentas e notações
padrão de engenharia de software, tais como, Especificação de
requisitos e Modelação do software, padrões de desenho, SysUML,
UML e outros, que melhoravam consideravelmente a qualidade dos
softwares, passando a ser amplamente utilizadas para o desenvolvimento
profissional de software.
 INTRODUÇÃO À ENGENHARIA DE 8

SOFTWARE

Segundo a IEEE (IEEE,1993) a Engenharia de Software (ESW)

consiste na aplicação de uma abordagem sistemática,
disciplinada e quantificável no desenvolvimento e na
manutenção de software, isto é, a aplicação de
ENGENHARIA ao SOFTWARE.
 INTRODUÇÃO À ENGENHARIA DE 9

SOFTWARE

Tipos de Software:

1. Aplicações stand-alone
2. Aplicações baseadas em interações Iteractivas
3. Software Embutido
4. Sistemas de processamneto em massa
5. Sistemas de entretimento
6. Sistemas para modelção e simulação
7. Sistemas de colecção de dados
8. Sistemas de sistemas
Referência:
1.1.2 Software engineering diversity
(Sommervile,2011)
CONCEITOS BÁSICOS DE ESW 10
CONCEITOS BÁSICOS DE ESW 11
CONCEITOS BÁSICOS DE ESW 12

ENGENHARIA DE
SOFTWARE
 PROCESSO DE SOFTWARE 13

• Processo de software é a sequência de actividades que se ocupam da

produção de um produto de software.
• Existem 4 (quatro) actividades fundamentais que são comuns em todos os
processo de software, nomeadamente:

• Especificação
• Desenvolvimento
• Validação
• Evolução
(Sommervile,2011)
FLUXOS DE PROCESSO 14
FLUXOS DE PROCESSO 15
 MODELOS DE SOFTWARE 16

• Modelo de software é uma representação simplificada de

um processo de software.

• Cada modelo de processo representa um processo a

partir de uma prespectiva particular

• Disponibilizam informação parcial sobre o processo.

Geralmente definem as actividades do processo e a sua
sequência, mas não especificam os papeis
(responsabilidades) das pessoas envovidades nas
actividades definidas
MODELOS DE SOFTWARE 17

Estrutura básica
 MODELO CASCATA (original) 18

• Herbert D. Benington - Symposium on

advanced programming methods for
digital computers - 29 Junho de 1956.
Apresentação sobre o desenvolvimento
do SAGE.
• A primeira descrição formal do Modelo
Cascata foi em 1970 no artigo
de Winston W. Royce
• Em 1976 Bell e Thayer também
“cascata”.
• Em 1985, United States Department of
esta abordagem na norma DOD-STD-
MODELO V 19
MODELO INCREMENTAL 20
MODELO DE PROTOTIPAGEM 21
MODELO ESPIRAL 22
MODELOS CONCORRENTES 23
MODELO ISO/IEC 12207:2008 24
 MODELOS DE PROCESSOS 25
ESPECIALIZADOS

• Desenvolvimento baseado em componentes

• Desenvolvimento orientado a serviços

• Desenvolvimento orientado a aspectos

 A RETER... 26

1. O que entedes por Engenharia de Software?

2. Defina Processo de Software. Cite as actvidades do ciclo básico do
Software
3. Apresente a diferença entre os diferentes fluxo de processo
4. Cite os modelos de processo que conheces. Explique de forma breve
cada um deles
 BOM TRABALHO! 27

LEMA INSTITUCIONAL

Volente Nihil Difficile - “A quem quer nada é dificil”

"Se quiseres um ano de prosperidade, semeia cereais. Se quiseres dez anos de

prosperidade, planta árvores. Se quiseres cem anos de prosperidade, educa os
homens”. Guanzi (645 a.C.)
 SUMÁRIO 28

Capítulo 1. Introdução à Engenharia de Software

1.4 Métodos de desenvolvimentos de software.
1.4.1 Métodos Tradicionais/convencionais
1.4.2 Métodos Ágeis
1.4.3 Métodos Especializados
 BIBLIOGRAFIA 29

Part I. Introduction to Software Engineering

Chapter 2. Software Process

Capítulo 1. Software e Engenharia de

Software
Parte 1. Processos de Software
Capítulo 2. Modelos de Processos
 MÉTODOS CONVECIONAIS VS MÉTODOS 30
ÁGEIS

Métodos Convencioanis
• Identificam estágios separados
no processo de software com
saídas associadas a cada
estágio

• Orientados a documentação e
comunicação formal

Métodos Ágeis

• Desenho e implementação
são as actividades centrais

• A comunicação é informal
 MÉTODOS CONVECIONAIS VS MÉTODOS 31
ÁGEIS

Métodos Convencionais

• Análise Estructurada (DeMarco,97)

• Análise Essencial de sistema - Essential Systems Analysis (McMenamim,1984)
• Desenho Orientado a objecto - Object-Oriented Design (OOD) – (Booch, 1990)
• Desenho e Análise orientado a Objecto. Object-Oriented Analysis and Design
(OADD). (Coad, 1990; Coad,92)
• Desenho e Modelagem Orientado a Objecto. Object-Oriented Modelling and
Design (OMT). (Rumbaugh,90)
• Engenharia de Software Orientada a Objetos. (OOSE), também conhecido como
“Objectory”. (Jacobson,92)
 MÉTODOS CONVECIONAIS VS MÉTODOS 32
ÁGEIS

Métodos Ágeis
• Programação Extrema - Extreme Programming – XP (Beck, 1999; Beck, 2000)
• Scrum (Cohn, 2009; Schwaber, 2004; Schwaber and Beedle, 2001)
• Crystal (Cockburn, 2001; Cockburn, 2004)
• Desenvolvimento de Software Adaptativo - Adaptive Software Development –
ADS (Highsmith,2000),
• Método de Desenvolvimento de Sistemas Dinâmicos - Dynamic Systems
Development Method - DSDM (Stapleton, 1997; Stapleton, 2003)
• Desenvolvimento Guiado por Funcionalidades - Feature Driven Development
(Palmer and Felsing, 2002)
 MÉTODOS CONVECIONAIS VS MÉTODOS 33
ÁGEIS

Métodos Especializados

 OOHDM(Object Oriented Hypermedia Design Method)

 WebML(Web Model Language:WebML)

 WSDM(Website Design Method)

 UWE(UML-based Web Engineering)

 UWA(Ubiquitous WebApplications design framework)

 MÉTODOS CONVECIONAIS VS MÉTODOS 34
ÁGEIS

Aspectos a ter conta para escolher entre métdos convecionais e ágeis

1. É importante ter especificações e desenho muito detalhados antes de passar para a
implementação? Se assim for, o mais aconselhável é usar a abordagem orientada por
plano (métodos convencionais).
2. É uma estratégia de entrega incremental, onde se entrega o software aos clientes e
obtém feedback rápido deles, realista? Em caso afirmativo, considera-se usar métodos
ágeis.
3. Quão grande é o sistema que está sendo desenvolvido? Os métodos ágeis são mais
eficazes quando o sistema pode ser desenvolvido com uma pequena equipe situada no
mesmo local que pode se comunicar de forma informal. Isso pode não ser possível para
grandes sistemas que exigem equipes de desenvolvimento maiores pelo que uma
abordagem orientada por plano possa ser a mais adequada.
 MÉTODOS CONVECIONAIS VS MÉTODOS 35
ÁGEIS

4. Que tipo de sistema está sendo desenvolvido? Sistemas que exigem muita análise antes
da implementação (por exemplo, sistema em tempo real com requisitos de tempo
complexos) geralmente precisam de um desenho bastante detalhado para realizar essa
análise. Uma abordagem orientada por plano pode ser melhor nessas circunstâncias.
5. Qual é a expectativa de vida útil do sistema? Os sistemas de longa duração podem
exigir mais documentação de projeto para comunicar as intenções originais dos
desenvolvedores de requisitos do sistema para a equipe de suporte. No entanto, os
defensores de métodos ágeis argumentam com razão que a documentação não é mantida
atualizada e não é muito útil para a manutenção do sistema a longo prazo.
 MÉTODOS CONVECIONAIS VS MÉTODOS 36
ÁGEIS

6. Quais tecnologias disponíveis para apoiar o desenvolvimento do sistema? Métodos

ágeis muitas vezes dependem de boas ferramentas para acompanhar o desenvolvimento
de um desenho. Se você estiver desenvolvendo um sistema usando um IDE que não tenha
boas ferramentas para a visualização e análise de programas, talvez seja necessária mais
documentação de desenho.
7. Como é organizada a equipe de desenvolvimento? Se a equipe de desenvolvimento for
distribuída ou se parte do desenvolvimento for tercerizada, talvez seja necessário
desenvolver documentos de desenho para se comunicar entre as equipes de
desenvolvimento. Talvez seja necessário planejar antecipadamente quais são esses
documentos.
 MÉTODOS CONVECIONAIS VS MÉTODOS 37
ÁGEIS

8. Existem problemas culturais que podem afectar o desenvolvimento do sistema?

Organizações de engenharia tradicionais têm uma cultura de desenvolvimento baseado
em planos, pois esta é a norma na engenharia. Isso geralmente requer uma extensa
documentação de desenho, em vez do conhecimento informal usado em processos ágeis.
9. Quão bons são os designers e programadores na equipa de desenvolvimento? Às vezes,
argumenta-se que os métodos ágeis exigem níveis de habilidade mais altas do que
abordagens baseadas em planos em que os programadores simplesmente traduzem um
desenho detalhado em código. Se você tem uma equipa com níveis de habilidade
relativamente baixos, talvez seja necessário usar as melhores pessoas para desenvolver o
desenho, e outros responsáveis pela programação.
 MÉTODOS CONVECIONAIS VS MÉTODOS 38
ÁGEIS

10. O sistema está sujeito a regulação externa? Se um sistema deve ser aprovado por um
regulador externo (por exemplo, a Autoridade Federal de Aviação [FAA]), você
provavelmente será obrigado a produzir documentação detalhada como parte do caso de
segurança do sistema .
PRINCÍPIOS DA AGILIDADE 39
PRINCÍPIOS DA AGILIDADE 40
 RATIONAL UNIFIED PROCESS - RUP 41

• Criado por (Krutchen*, 2003)

• Baseado em UML e no Processo
Unificado (Rumbaugh, et al., 1999;
Arlow and Neustadt, 2005)
• Inclui elementos de modelos de
processos genéricos como a
especificação e desenho detalhado,
e suporta prototipação e entrega
incremental

*IBM rational Software - https://www-01.ibm.com/software/uk/rational/

 RATIONAL UNIFIED PROCESS - RUP 42

Melhores Prácticas (Best practices) recomendadas pelo RUP- Fundamentos do RUP:

 Desenvolve o Software Iterativamente (Develop Software iteratively)
 Gere os Requisitos (Manage requirements)
 Utilize arquitecturas baseada em componentes (Use component architectures)
 Modele o software visualmente (visually Model Software)
 Verifique a qualidade do software (Verify software quality)
 Controle os cambios no software (Control change to software)
 RATIONAL UNIFIED PROCESS – RUP. 43

CONCEITOS CHAVES

Um efectivo processo de desenvolvimento de software deve descrever Quem

faz o Que, Como e Quando.
O RUP faz exactemente isso a partir dos seguintes conceitos chaves:
Papeis (Roles): Quem
Artefactos (Artfacts): Que
Actividades (Activities): Como
Fases, iterações, disciplinas e fluxos de trabalho (phases, iterations, disciplines
and workflow): Quando
 RATIONAL UNIFIED PROCESS – RUP. 44

CONCEITOS CHAVES

Algumas definições
• Ciclos : cada ciclo do desenvolvimento resulta numa nova geração do produto
• Fases: cada ciclo divide-se em fases; cada fase divide-se em iterações a definir
em cada projecto concreto
• Trabalhadores (workers): são perfis a que correspondem competências para a
realização de actividades
• Actividades: são tarefas que podem ser entregues a trabalhadoresindividuais
• Artefactos:são inputs e outputs de actividades
• Workflows: agrupam actividades relacionadas; genéricos ou especializados por
fases
• Modelos:agrupam artefactos desenvolvidos num workflow
RATIONAL UNIFIED PROCESS – RUP. 45

CONCEITOS CHAVES
RATIONAL UNIFIED PROCESS – RUP. 46

FASES, DISCIPLINAS E ITERAÇÕES

RATIONAL UNIFIED PROCESS – RUP. EXEMPLOS DE 47
ARTFACTOS, PAPEIS, ACTIVIDADES E FLUXO DE
TRABALHO
RATIONAL UNIFIED PROCESS – RUP. EXEMPLO DE 48
FLUXO DE TRABALHO DETALHADO
RATIONAL UNIFIED PROCESS – RUP. 49

EXEMPLO DE ITERAÇÕES
 EXTREMME PROGRAMMING - XP 50

• XP – Extreme Programming é um
processo de desenvolvimento de
software que utliza amplamente a
abordagem ágil.
• É considerado o método ágil mais
conhecido e mais utilizado
XP: DESCRIÇÃO DO PROCESSO 51
 XP: ARCTEFACTOS 52

História de utilizadores
 XP: ARCTEFACTOS 53

CARTÕES CRC – Classe Responsabilidade e Colaboração

 EXTREMME PROGRAMMING – XP. 54

VARIÁVEIS DE CONTROLO DE
PROCESSO
A RETER... 55
 EXERCÍCIO 1

ENUNCIADO DO PROBLEMA 1 EM ANEXO

ISPTEC
 BOM TRABALHO! 57

LEMA INSTITUCIONAL

Volente Nihil Difficile - “A quem quer nada é dificil”

"Se quiseres um ano de prosperidade, semeia cereais. Se quiseres dez anos de

prosperidade, planta árvores. Se quiseres cem anos de prosperidade, educa os
homens”. Guanzi (645 a.C.)