Escolar Documentos
Profissional Documentos
Cultura Documentos
Modelo Waterfall
Vantagens Desvantagens
Usuário Desenvolvedores Usuário Desenvolvedores
- Maior gasto para - Requer intensa pesquisa na
- Documentação completa - Menor necessidade de efetuar
manter/atualizar definição das necessidades
de todas as fases. suporte.
o software do usuário.
- Conhece todas as necessidades
- Estrutura Simples. - Mais difícil de utilizar - Dificuldade de costumização.
e requerimentos do projeto.
Mais Flexível ( menor atuação - Transferência de informações -Exclui o cliente e - Requer equipe capacitada e
durante o desenvolvimento) entre as fases. usuário final. experiente.
- Dificuldades de efetuar mudanças
- Determina o objetivo final na etapa inicial.
de requisitos e funcionalidades.
- Atraso nos testes (desenvolvimento de software)
Este método vem sido utilizado desde 1958 em projetos de software e SE. O
modelo espiral (Boehm, 1986) é um exemplo de MII, introduzido em 1986 por Boehm
e evoluiu durante vários anos baseado na experiência e refinamentos dos modelo wa-
terfall e vee, tendo como objetivo propor uma estrutura de processos em espiral capaz
de mensurar a maturidade e riscos na definição dos requisitos do sistema. Nos dias
de hoje, o modelo evoluiu para modelo espiral de compromisso incremental (Boehm &
Lane, 2007; Boehm & Turner, 2015), do inglês Incremental Commitment Spiral (ICSM).
O ICSM combina os pontos positivos do modelo Vee, processo de verificação e
validação interativo e concorrente, agil e enxuto estabelecendo critérios de viabilidade
e resultados utilizando conceitos orientados/dirigidos por risco em conjunto com o mo-
delo Rational criado pela empresa IBM chamado de Unified Process (RUP), bastante
conhecido na engenharia de software (ESw)(Kruchten, 2003).
O MII representam uma abordagem prática e útil que permite que um projeto
forneça uma capacidade inicial seguida de entregas sucessivas para alcançar o sis-
tema de interesse desejado onde os requisitos ainda não estão completamente de-
finidos na fase inicial do projeto, ou quando as partes interessadas desejam fazer
mudanças durante o desenvolvimento, incluindo funcionalidades ou inserindo novas
tecnologias ao projeto.
Em (INCOSE, 2015) afirma-se que muitos artigos científicos concordam que os
MII apresentaram melhores resultados ao serem aplicados em projetos de sistemas
menores e menos complexos, contendo poucos elementos.
Publicações científicas da NASA (Kapurch, 2010) e DoD (Roadmap, 2005) re-
latam a utilização dos métodos ICSM, Vee e waterfall de forma integrada baseada
nas boas práticas de projetos de SE. O modelo de ciclo de vida utilizado por eles,
demonstra o uso de um conjunto de abordagens diferentes aplicadas a cada fase do
desenvolvimento do projeto combinando os pontos fortes de cada abordagem.
Uma nova linha de pesquisa propõe o uso da metodologia Agile , comumente
utilizada em ESw, em projetos de SE complexos denominado Agile systems enginee-
ring.
previous
Now or under development
Will be replaced by
ISO/IEC/IEEE 24748
ISO/IEC/IEEE 24748-5:2017
ISO/IEC 12207:1995 ISO/IEC 12207:1995/Amd 1:2002
Embora os níveis de TRL sejam métodos úteis para medir a prontidão tecno-
lógica, eles não levam em conta os aspectos negativos que as tecnologias imaturas
e sua integração podem introduzir aos SE. Aspectos negativos como a obsolescência
tecnológica podem ser combinados com os aspectos positivos destacados nos TRLs
para formar uma medida de risco tecnológico que reflita mais precisamente a influên-
cia de uma determinada tecnologia (Valerdi & Kohl, 2004).
Outras pesquisas apresentam critérios diferentes de definir a forma de calcular
o TRL dos elementos. Li et al. apresenta um sistema de avaliação para calcular os
níveis de prontidão de tecnologia de sete dimensões, incluindo requisito, projeto, im-
plementação, verificação, configuração, risco e segurança. Este método indica mais
detalhes de maturidade tecnológica além de escalares definidas por TRL demons-
trando a possibilidade de determinar métricas em estágios diferentes do ciclo de vida
de um projeto (Li et al., 2017).
Olechowski et.all em (Olechowski et al., 2015) apresentou um estudo descre-
vendo os 15 maiores desafios da avaliação de prontidão de sistemas, um dos pontos
críticos discutidos é o desafio da “integração e conectividade” entre os componentes
de um sistema. Embora os TRLs sejam principalmente avaliados em um nível de
componente, qualquer gerente de engenharia pode atestar que as interfaces preci-
sam ser levadas em conta para avaliar adequadamente a prontidão da tecnologia e as
definições de TRL não fornecem orientação suficiente sobre esse ponto (Garg et al.,
2017).
O TRL não capta com precisão o risco envolvido na adoção de uma tecnolo-
gia, e qualquer tecnologia pode ter uma desigualdade de arquitetura relacionada à
integração (Smith, 2005). Como o TRL não pode avaliar interconexões de sistemas
complexos (Mankins, 2002; Sauser et al., 2008, 2010), uma métrica de sete níveis de
prontidão de integração (IRL) foi sugerida por Sauser et al. (Sauser et al., 2006). Após
mais pesquisas, os IRLs avançou para uma escala de nove níveis com fundamentos
teóricos alinhados com os níveis de TRLs (Sauser et al., 2010) e baseados também
nas sete camadas do modelo OSI (Open Systems Interconnection)(Jimenez & Mavris,
2014).
IRLs descrevem a maturidade da integração de uma tecnologia em desenvol-
vimento com outra tecnologia. A adição de IRLs não apenas fornece uma verificação
para onde a tecnologia está em uma escala de prontidão de integração, mas também
uma direção para melhorar a integração com outras tecnologias.
Brian et. all (Brian, 2009) apresentou um estudo de verificação e validação do
IRL atribuído aos elementos através de uma lista de verificação de critérios críticos de
12
O nível de prontidão de sistemas, do inglês system readiness level (SRL), foi de-
senvolvido para avaliar o risco de desenvolvimento de todo o sistema e para suporte
a aquisição de SE de programas organizacionai. Os SRLs combinaram matematica-
mente os valores de TRL do componente com a integração do sistema IRL e criaram
uma medida separada do progresso técnico dos sistemas (Sauser et al., 2008).
Os SRLs foram inicialmente desenvolvidos no Laboratório de Maturidade de
Desenvolvimento de Sistemas (SysDML) e foram expandidos em numerosos trabalhos
subsequentes (Ramirez-Marquez & Sauser, 2009; Sauser & Ramirez-Marquez, 2012).
A motivação subjacente do SRL era que os sistemas complexos e o SoS exigem uma
avaliação de prontidão mais robusta do que a avaliação isolada do componente de
TRL poderia fornecer.
(Sauser et al., 2008) relata o processo de aquisição utilizado pelo DoD com
base na utilização dos índices de maturidade TRL, IRL e SRL, relacionando direta-
mente com os estágios de ciclo de vida do projeto, tendo como referência a estrutura
comum de ciclo de vida de projeto definido no padrão ISO/IEC/IEEE 15288:2105,sendo
13
representado em 5 faixas de valores (London, 2015). De acordo com (Austin & York,
2015) podemos definir três métricas de compõem a prontidão de sistemas.