UMA PASSAGEM PELA ENGENHARIA DE SOFTWARE, PELO PROCESSO RUP

Inicialmente, é necessário compreender que, o software70 _{trabalhado aqui tem como} base a engenharia de software71 em que o desenvolvimento profissional difere-se de um feito para uso individual. Isto significa que, o software profissional vai além de simplesmente um programa de computador. Conforme Sommerville (2011, p. 3):

Quando falamos de engenharia de software, não se trata apenas do programa em si, mas de toda a documentação associada e dados de configurações necessários para fazer esse programa operar corretamente. Um sistema de software desenvolvido profissionalmente é, com frequência, mais do que apenas um programa; ele normalmente consiste em uma série de programas separados e arquivos de configuração que são usados para configurar esses programas. Isso pode incluir documentação do sistema, que descreve a sua estrutura; documentação do usuário, que explica como usar o sistema; e sites, para usuários baixarem a informação recente do produto.

Diante disso, percebe-se a complexidade na elaboração dos atributos72 para um software por isso, optou-se por utilizar o modelo de processo73 chamado de Rational Unified

70 _{São programas de computador e documentação associada. Produtos de software podem ser desenvolvidos para} um cliente específico ou para o mercado em geral (SOMMERVILLE, 2011, p. 4).

71 _{É uma disciplina de engenharia cujo foco está em todos os aspectos da produção de software, desde os} estágios iniciais da especificação do sistema até sua manutenção, quando o sistema já está sendo usado (SOMMERVILLE, 2011, p. 5).

Process (RUP)74 sendo “um produto que, entre outras coisas, inclui uma base de dados com hiperlinks com vários artefatos e templates necessários para usar bem o modelo (WAZLAWICK, 2013, p. 80). Vale lembrar que, o RUP é uma implementação mais pormenorizada e antiga do UP75 visando boas práticas para o desenvolvimento de sistemas. O RUP é constituído pelas seguintes fases76: a concepção, a elaboração, a construção e a transição. O Stood-On encontra-se na fase de concepção, ou seja, de detecção das informações acerca das pessoas e sistemas que irão interagir com o programa e delimitar as iterações77. Para Wazlawick (2013, p. 77):

Concepção (inception): trata-se da elaboração de uma visão de abrangência do sistema. Nessa fase são levantados os principais requisitos, um modelo conceitual preliminar é construído, bem como são identificados os casos de uso de alto nível (Wazlawick, 2011), que implementam a funcionalidade requerida pelo cliente. Na fase de concepção calcula-se o esforço de desenvolvimento dos casos de uso e constrói-se o plano de desenvolvimento, composto por um conjunto de ciclos iterativos nos quais são acomodados os casos de uso. Pode haver alguma implementação e teste, caso seja necessário elaborar protótipos para redução de risco.

Vale ressaltar que, cada fase pode possuir uma quantidade ilimitada de iterações sendo estas definidas pelo responsável do desenvolvimento do sistema. Ao final de cada iteração pode ser gerado de um a vários artefatos e o ato de se concluir todas as iterações é chamado de marco, fato esse que possibilita o andamento do desenvolvimento do software, como podemos observar na figura a seguir.

73 _{Um processo de software é um conjunto de atividades relacionadas que levam à produção de um produto de} software (SOMMERVILLE, 2011, p. 18).

74 _{É um exemplo de um modelo de processo moderno, derivado de trabalhos sobre UML e o Unified Software} Development Process associado (RUMBAUGH, et al., 1999; ARLOW e NEUSTADT, 2005) [...] exemplo de processo híbrido (SOMMERVILLE, 2011, p. 34)

75 _{É o primeiro modelo de processo inteiramente adaptado ao uso com a UML (Unified Modeling Language),} desenvolvida pelo mesmo grupo. Sua concepção foi baseada nas práticas de maior retorno de investimento (ROI) do mercado (WAZLAWICK, 2013, p. 75).

76 _{Embora, a nomenclatura possa variar de um modelo de processo para outro, usualmente se considera que a} primeira grande divisão de um processo é a fase. Uma fase é o período de tempo no qual determinadas atividades com objetivos específicos são realizadas. As fases são, então, as grandes divisões dos processos, e normalmente sua quantidade é pequena (WAZLAWICK, 2013, p. 77).

77 _{Cada ciclo iterativo produz um incremento no design do sistema, seja produzindo mais conhecimento sobre} seus requisitos e arquitetura, seja produzindo um código executável (WAZLAWICK, 2013, p. 77).

Figura 5 - Diagrama de baleia RUP

Constata-se, dessa forma, que o desenvolvimento do software, utilizando o processo RUP, é baseado em 4 marcos que através das iterações agregam novos incrementos, denominados artefatos. De acordo com Wazlawick (2013, p. 13), os artefatos são “quaisquer documentos que puderem ser produzidos durante um projeto de desenvolvimento de software, incluindo diagramas, programas, documentos de texto, desenhos, contratos, projetos, planos”. Mas é necessário que, eles estejam subordinados a um sistema de controle de versão para invalidar possíveis mudanças equivocadas.

Nesse sentido, para auxiliar na compreensão de como será o desenvolvimento do Stood-On, foi utilizado o modelo de casos de uso78 que é um exemplo do grupo de artefatos requisitos79. Vale destacar que, devido a dimensão do diagrama de casos de uso principal foi necessário dividi-lo em partes lógicas para facilitar a visualização e o entendimento. Sobre esses diagramas, Guedes (2011) afirma que, oferecem um panorama mais geral e informal da UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) que é “uma linguagem visual utilizada para modelar softwares baseados no paradigma de orientação a

78 _{Um caso de uso pode ser tomado como um cenário simples que descreve o que o usuário espera de um sistema} (SOMMERVILLE, 2011, p. 35).

79 _{De acordo com Wazlawick (2013, p. 84) no RUP os artefatos estão divididos em grupos e dentre eles estão os} artefatos de requisitos que, estão relacionados à descrição do sistema a ser desenvolvido.

objetos [...] a linguagem-padrão de modelagem adotada internacionalmente pela indústria de engenharia de software” (p. 19). Os diagramas de casos de uso permitem identificar os atores80 que irão interagir com o sistema e os serviços, ou seja, “representam os papéis desempenhados pelos diversos usuários que poderão utilizar, de alguma maneira, os serviços e funções do sistema” (GUEDES, 2011, p. 53). Finalmente, evidencia-se que, os diagramas de casos de uso desenvolvidos para modelar os requisitos81 do Stood-On serão apresentados entremeados com as discussões acerca das mídias comunicacionais e educacionais na