02_03PSI_Processo de Desenvolvimento de SI PDF

Direitos de Autor / Copyrights Material adaptado dos conteúdos desenvolvidos inicialmente pelo Prof. Pedro Malta, Prof. Noémia Ferro e Prof. Fábio Sampaio. A maioria dos conteúdos está em Português, todavia alguns materiais são disponibilizados em Inglês por ser o idioma de referência na área onde s...

Direitos de Autor / Copyrights Material adaptado dos conteúdos desenvolvidos inicialmente pelo Prof. Pedro Malta, Prof. Noémia Ferro e Prof. Fábio Sampaio. A maioria dos conteúdos está em Português, todavia alguns materiais são disponibilizados em Inglês por ser o idioma de referência na área onde se enquadra a UC PSI. Os direitos de autor são assegurados com referência à respetiva fonte de informação. 2024/2025  Agenda 2  ISO 42010 & Diagrama de Contexto  O processo de desenvolvimento de software  As fases de um processo de desenvolvimento  Metodologias de desenvolvimento  Introdução ao levantamento e especificação dos processos de Negócio 3 A Conceptual Model of Architecture Description Systems and software engineering — Architecture description ISO/IEC/IEEE 42010 Key definitions of a system Types of systems 4 ISO 42010 - Key Definitions Software, systems and enterprise — Architecture description 4  architecting: the activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture.  architect: the person, team, or organization responsible for systems architecture  architecture: the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.  conceptual model: a model representing concepts and relationships between them.  concern: those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders.  mission: a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives.  model: a purposely abstracted representation of a concern.  modelling: the process of generating models.  modelling language: an artificial language to express models, which is defined by a consistent set of rules (ideally clear, precise and unambiguous) to be used for interpretation of the meaning of the models.  notation: language used to visualise a model.  stakeholder: an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.  system : a collection of software components organized to accomplish a specific function or set of functions.  view: a representation of a whole system from the perspective of a related set of concerns.  viewpoint: a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. 5 ISO 42010 - Definition of a System A system is always a relative concept 5 class Context  A system pursues a common Stakeholder has interests in System goal for a set of stakeholders 1..* 1..* according to their concerns in System Concern 0..* a specific environment. situated in 1..* Env ironment Purpose Source: ISO/IEC/IEEE 42010:2011 (first edition)  An information system is a group of socio-technical entities (technological and human) interacting with the purpose of satisfying all the information needs of an organization. 6 ISO 42010 - Systems are always relative Types of systems: System of Interest (SoI) ISO 42010:2011 | Entity of Interest (EoI) ISO 42010:2022 6  System of Interest (SoI): The system that is being understood, created, utilized or managed due to a specific concern.  Enabling System  Systems that are outside the boundary of the SoI.  Enabling systems are required to complement the functionality of the SoI but are out of the scope of the SoI. The System of Interest (my phone…) Enabling System(s) (the network…) 7 ISO 42010 - Systems are always relative Types of systems: System of Interest (SoI) ISO 42010:2011 | Entity of Interest (EoI) ISO 42010:2022 7 A System of Systems (power supply, RAM, processors, disk  System of Systems (SoS) drives, …)  A “larger” system composed of other systems.  Systems may be independent of one another. The human body is a complex SoS with deep interrelationships and implications between systems. In extreme cases, a malfunction in one system may cause a shutdown of the global SoS. 8 ISO 42010 - Systems are always relative Examples of System of Systems (SoS) 8  Many systems operate various parts of a plane (which itself is also a system), but the plane only flies when all its systems work in tandem. It simply doesn’t fly if the systems (parts) do not work together as a whole. 9 ISO 42010: Systems are always relative Examples of System of Systems (SoS) 9  An airport involves aircraft, support trucks, baggage-handling equipment, control towers, emergency facilities, and many other systems that can and do operate independently of each other. But, for the airport to function, it needs to have the right mix of these independent systems, and these systems need to cooperate with each other. 10 A system is always a relative concept 10  The definitions of system of interest, enabling system and system of systems are always dependent on the concern and of the context related to that (the environment of the system). A system can always be included as part of a “larger” SoS or decomposed as a “smaller” SoS.  The definition of the context of a system depends on the purpose and on the concerns of the stakeholders of the system. ISO/IEC 42010:2011 Conceptual Framework for Architecture Description http://www.iso-architecture.org/42010 11 Context Diagram System of Interest (SoI) ISO 42010:2011 ou Entity of Interest (EoI) ISO 42010:2022 Stakeholders Enabling Systems Actors Project Owner Interface Types (GUI and API) 12 Context Diagram Overview What is a Context Diagram & Why is it relevant? 12 https://www.youtube.com/watch?v=fWNrc6GNK14  The diagram is used to map the interactions of roles and actors with the specified system.  The definition of the context of a system depends on the purpose and on the concerns of the stakeholders who will use that system (ISO 42010). 13 Key Definitions ISO 42010:2022 The system context model | Context diagram 13  The system context model (i.e., context diagram) is a specification of the environment of the system of interest.  Context diagrams describe the following concepts:  The system (of interest), represented as a named black-box entity.  The stakeholders (an individual, team, or organization) that have concerns over the system. Each stakeholder (or class thereof) is uniquely identified by a  The enabling systems that directly exchange information with the system. Each enabling system is uniquely identified by a  Context diagrams describe the following relationships:  Associations between stakeholders and the system of interest describe the concerns of each stakeholder  Associations between enabling systems and the system of interest describe the corresponding directed information flows.  Associations can be described by 14 Diag. de Contexto (com identificação do tipo de interfaces com os atores) Compra de produtos disponíveis num catálogo online 14 O exemplo apresenta apenas um GUI, todavia deve Incluir uma tabela com a ser especificado uma interface GUI para cada tipo de Incluir uma tabela com a descrição do role de interação Ator-SoI, sempre que o layout for especifico descrição do role de cada (i.e., Mockup da Interface) cada ator ator (detalhada por perfil) Indicar/resumir o tipo de interação (e.g., Req. Funcional) SoI: GUI Catalogo API Produtos Indicar/resumir o tipo de interação Entidade de Pagamento (online) (e.g., Req. Funcional) 15 Context Diagram – Describe the Actor 15  The role, concern and interest of the Actors in the context diagram need to be described  Example (Template Table in Portuguese – to be used in class reports) Atores Descrição da função (Role ou Interesse no SoI) Descrever a função (Role) do ator no SoI, nomeadamente qual o interesse do ator em interagir com o sistema, como é que essa interação é iniciada. Descrever de forma sucinta o papel (role) do ator na execução do processo (se for o atro a iniciar o processo - fluxo de Nome do ator 1 informação) ou o papel do ator na interação com processo se apenas receber informação ou tem de responder a notificações (eventos) enviadas pelo processo. Nome do ator 2 Nome do ator 3 … Nome do ator n 16 Arquitetura (Layer vs Tier) 17 Three Tier Architecture 17 / layer Most known approach in which the UI component was separated from the core computing and the / layer database / layer Source: N Tier(Multi-Tier), 3-Tier, 2-Tier Architecture with EXAMPLE 18 Advantages and Disadvantages of Multi- Tier Architectures 18 Advantages Disadvantages Improved Scalability Increase in Effort Data Integrity Increase in Complexity Enhanced Reusability Due to the componentization of the tiers/layers, the complex structure is difficult to implement or Reduced Distribution maintain Improved Security Improved Availability Tiers – in this approach, physical segmentation is based on hardware (e.g., different equipment such as servers, routers, Hidden Database Structure firewalls, etc. o The actual structure of the database often Layers – in this approach, the segmentation is based on remains hidden from requesters enabling any software typically over the same hardware (i.e., a single change of the database to be transparent server with the business applications structured into different layers of software), offering a high degree of flexibility (cost- effectiveness) for system design/implementation. o Mainly the performance is increased due to off- load from the database tier and the client tier 19 What do the 3 Tiers Mean - Technological Perspective 19  Presentation Tier - the front end tier consists of the user interface.  This user interface is often a graphical one accessible through a web browser or web-based / mobile application and which displays content and information useful to an end user.  This tier is often built on web technologies such as HTML5, JavaScript, CSS, or through other popular web/mobile development frameworks and communicates with other layers through API calls. Application Tier- the application tier contains the functional business logic which drives an application’s core capabilities. It’s often written in Python, Java,.NET, C#, C++, etc. Data Tier- the data tier comprises the database/data storage system and data access layer. Data is accessed by the application layer via API calls. Examples of such systems are MySQL, Microsoft SQL Server, Oracle, PostgreSQL, MongoDB (No-SQL database), etc. 20 Architectural Style Distributed Architecture: Multi-Tier Architecture (n-tier Architecture) 20  Presentation Tier The Presentation tier is the topmost level of the application that users can access directly, such as a webpage or Operational System’s GUI (Graphical User Interface). The primary function of this tier is to translate the tasks and results into something that users can understand. It communicates with other tiers so that it sends the results to the browser/client tier and all other tiers in the network.  Application Tier (Business Logic, Logic Tier, or Middle Tier) The Application tier coordinates the application, processes the commands, makes logical decisions, evaluates, and performs calculations. It controls an application’s functionality by performing detailed processing. It also moves and processes data between the two surrounding tiers.  Data Tier This tier stores and retrieves information from the database or file system. The information is then passed back for processing and then back to the user. It includes the data persistence mechanisms (database servers, file shares, etc.) and provides API (Application Programming Interface) to the application tier which provides methods of managing the stored data. 21 Multi-Tier (or N-tier) Architecture 21  A Multi-tier Architecture is a software architecture in which different software components, organized in tiers (layers), provide dedicated functionality.  The most common occurrence of a multi-tier architecture is a three-tier system consisting of a data management tier (mostly encompassing one or several database servers), an application tier (business logic) and a client tier (interface functionality).  Novel deployments have additional tiers. o For instance, web information systems encompass a dedicated tier (web tier) between the client and application layers. o Conceptually, a multi-tier architecture results from a repeated client/server paradigm application. o A component in one of the middle tiers is a client to the next lower tier and, at the same time, acts as a server to the next higher tier. Source: bmc.com 22 Multi-Tier (or N-tier) Architecture “Tier” vs “Layer” 22  A layer is a logic component within a software suite that accomplishes a given functionality, whereas a tier is the logical and hardware platform where such layer runs. Source: bmc.com 23 Desenvolvimento de Sistemas de Informação  Desenvolvimento de Sistemas de Informação 24 Queremos construir/desenvolver Como fazemos? Por onde começamos? Uma nova ponte Um novo modelo de automóvel Um novo Sistema de Informação  Desenvolvimento de Sistemas de Informação 25  Em Engenharia foram desenvolvidas metodologias que guiam os engenheiros na concepção e desenvolvimento de novos produtos.  As diversas metodologias têm como fim garantir uma ótima gestão dos recursos (humanos, materiais e temporais) e a obtenção de um produto final com qualidade, que vá de encontro às expetativas do cliente.  Desenvolvimento de Sistemas de Informação 26  Em Engenharia de software foram desenvolvidas metodologias que guiam os engenheiros no desenvolvimento e manutenção de Sistemas de Informação, de forma a garantir a qualidade do SI desenvolvido. Inúmeros aspetos têm de ser tidos em conta: As funcionalidades requeridas Os custos de desenvolvimento Os custos de operação Os prazos A facilidade de manutenção futura O “gosto” do cliente…  Ciclo de Vida do Software 27  Um sistema de software é desenvolvido gradualmente até ser entregue ao cliente e até depois disso  Ter um processo definido é essencial  O ciclo de vida é um conjunto de passos que o software deve cumprir desde a ideia da conceção até à conclusão  Principais fases do ciclo de vida do Software: ◼ Fase de requisitos ◼ Fase da análise ◼ Fase do desenho ◼ Fase da implementação ◼ Fase de instalação (deployment) ◼ Fase da manutenção  Processo de desenvolvimento 28  Um processo de desenvolvimento de software é uma representação do conjunto de atividades envolvidas no desenvolvimento de um produto de software.  Modelos de Processos de desenvolvimento 29  Existem vários modelos de processos de desenvolvimento de software conhecidos, cascata, iterativo e incremental , v-model, espiral, prototipagem, RAD. Cascata (waterfall) V-Model Incremental  Metodologias de desenvolvimento 30  Metodologia (método) de desenvolvimento de software - Conjunto de princípios, regras e práticas usados para desenvolver produtos de software. Um método de desenvolvimento de software define qual o processo de desenvolvimento a adotar, assim como o conjunto de regras e boas práticas a usar.  Metodologias tradicionais: baseiam-se no principio que é possível capturar a maior parte das necessidades do cliente no inicio do processo de desenvolvimento e só se inicia a implementação quando existe uma especificação abrangente do sistema.  Metodologia ágeis: baseiam-se no principio que os requisitos do sistema estão em constante evolução e que é possível iniciar a implementação do sistema, sem os requisitos estarem na sua maioria definidos. O esforço de documentar o sistema a desenvolver é preterido em função do esforço de implementação e teste. Metodologias de desenvolvimento Tradicionais 31  As Metodologias de desenvolvimento de software tradicionais são abordagens estruturadas e sequenciais para desenvolver software, como o Modelo em Cascata, Modelo em V, RUP e Modelo Espiral.  Fornecem diretrizes e etapas definidas para o desenvolvimento de software, desde a concepção até a entrega final.  Ênfase na documentação detalhada - desenvolvedores e equipes envolvidas criam documentação abrangente, incluindo especificações de requisitos, documentos de design, manuais de usuário e relatórios de teste. Essa documentação ajuda a garantir a rastreabilidade e facilita a manutenção do software no futuro. https://awari.com.br/metodologias-de-desenvolvimento-de-software-tradicionais-um-olhar-detalhado/  Metodologias Ageis 32  Métodos ágeis ou metodologia ágil descrevem abordagens de desenvolvimento de software que enfatizam a entrega incremental, a colaboração da equipe, o planejamento contínuo e o aprendizado contínuo, em vez de tentar entregar tudo de uma vez perto do fim. As metodologias ágeis mais comuns utilizadas em desenvolvimento de softwares são: Kanban; Scrum; Lean; XP e Smart.  A modelação no processo de desenvolvimento 33 Durante as diversas fases de desenvolvimento vários modelos do SI a desenvolver vão sendo construídos. Porque são precisos vários modelos?  É difícil compreender um sistema complexo  um só modelo não é suficiente;  são necessárias perspectivas diferentes, cada uma com o seu modelo;  são necessários modelos com diferentes níveis de granularidade.  Bons modelos são necessários…  para tornar compreensíveis sistemas complexos  para visualizar aspectos essenciais de um sistema  para comunicação entre membros da equipa e com o cliente  para assegurar uma boa arquitetura 34 Gestão de Processos de Negócio Business Process Management (BPM)  Processos de Negócio 35 - Qualquer organização, pequena ou grande, constitui um sistema vivo no qual coexistem e interagem entidades (fornecedores, clientes, funcionários, produtos/serviços) e funções básicas(produção, marketing e venda, contabilidade, finanças, recursos humanos). Cada uma destas funções/departamentos implicam em um ou mais processos de negócios que viabilizam um determinado resultado.  Mais sobre Processos de Negócio 36  Atividades previamente estabelecidas cujo objectivo é determinar como o trabalho será realizado em uma organização.  Constituem um conjunto de ações relacionadas entre si de forma lógica e coerente a fim de promover um output favorável à empresa (qualidade total e satisfação do cliente), tanto a nível interno como externo.  Uma estrutura de processos de negócio mal concebida pode pôr em risco a eficiência e a eficácia da organização através dos produtos e serviços gerados e disponibilizados.  Trata-se da relação coordenada que existe entre o trabalho, as informações e o conhecimento dentro dos processos. Ver https://pt.wikipedia.org/wiki/Processo_de_neg%C3%B3cio  Processos de Negócio 37  Atualmente, os processos de negócio são o núcleo da maioria dos sistemas de informação:  linha de produção de uma fábrica de automóveis;  os procedimentos para a compra de bilhetes on-line;  sistema de gestão de uma cantina escolar,...  Isto requer que as organizações especifiquem os fluxos de trabalho (os seus processos de negócio) para a orquestração dos participantes, informação e tecnologia para a realização/produção de serviçoes e produtos. 38 Business Process Management 38  Organizational design is a function of structure, people, and processes 39 Business Process 39  Set of interrelated activities that transform inputs into outputs in order to produce a service or product to a specific stakeholder (e.g., the customer).  The focus is always on the final product. Inputs Process Outputs Materials Resources Products - People Information Services - Energy - Equipment Information - Infrastructures - Methods 40 Business Process 40 41 Business Process 41 42 Business Process Vs Business Process Management 42  Business Process  Defined as a set of activities or behaviours performed by humans or machines to achieve one or more goal  Triggered by specific events and have one or more outcomes that may result in the termination of the process or a handoff to another process  Composed of a collection of interrelated tasks or activities which solve a particular issue  End-to-end work which delivers value to customers -end-to-end involves crossing any functional boundaries  Business Process Management  Disciplined approach to identify, design, execute, document, measure, monitor and control both automated and non-automated business processes to consistently achieve targeted results aligned with an organisation’s strategic goals  Involves the deliberate, collaborative and increasingly technology-aided definition, improvement, innovation and management of end-to-end business processes that drive business results, create value and enable an organisation to meet its business objectives with more agility  Enables an enterprise to align its business processes to its business strategy, leading to effective overall company performance through improvements of specific work activities either within a specific department, across the enterprise or between organisations 43 Business Process Key Concepts 43  Process Owner - the person (Resource) responsible for the process.  Key Performance Indicators (KPIs) — KPIs are descriptive time, cost, or quality indicators used to capture a process's performance.  Business Process Management (BPM) is a systematic approach that is used to make an organization's workflow effective, efficient and responsive to changing environments.  Purpose of BPM - To reduce human error and avoid miscommunication. Link operational processes to corporate strategies. Measure performance indicators from processes for evaluation of business success.  Business Process Model ◼ Typically consists of workflow diagrams, descriptions, inputs and outputs, KPIs and data that provide both overview and detailed information about an organization’s business processes ◼ The model contains the relationship between activities, processes, sub- processes and information, as well as roles and business rules relevant to the organization’s (operational and decision support) needs and resources.  Porquê modelar os Processos de negócio ? 44  Paraconseguirmos projetar um sistema de informação que suporte corretamente as atividades de uma organização, temos que em primeiro lugar conhecer: ◼ Quais os processos que a organização executa? ◼ Quais as tarefas que compõem cada processo? ◼ Quais as pessoas que executam cada uma das tarefas? ◼ Como é que o processo é iniciado e terminado? Por quem e quando? ◼ Onde é que as tarefas são realizadas?  (1) Análise dos Processos de Negócio 45 (1) Análise dos processos de negócio  Os processos de negócio são o conjunto de tarefas ou Requisitos (Levantamento e especificação, requisitos atividades relacionadas que funcionais e não funcionais) produzem um serviço ou produto específico, para uma Análise (Modelo Informacional, Modelo de concepção) pessoa/cliente ou grupos de Desenho (Arquitetura do software, modelos de sistema) pessoas/clientes. Implementação (Código) Validação, integração e instalação Manutenção  Conclusões 46 A modelação dos processos de negócio permite-nos conhecer corretamente as atividades de uma organização, para, desta forma, desenvolvermos corretamente os SI de suporte às suas atividades.  Na modelação de um processo de negócio deveremos conseguir representar: ◼ As tarefas que compõem cada processo; ◼ Quem participa na execução de cada uma das tarefas; ◼ O inicio e fim de cada processo; ◼ O local onde cada tarefa é realizada.  Um exemplo 47 Aplicação: Web Chat ◼ Objetivo(s): i: troca de mensagens; ii: incluir ficheiros e imagens; iii: utilização de salas privadas ◼ Para suporte a que funções? garantir comunicação; suporte à comunicação com ficheiros, imagem, vídeo; troca de comunicação segura; … ◼ Todos os objetivos listados têm de ter um identificador único (e.g., OB01, OB02, …) ◼ Funcionalidades da aplicação (i.e., Requisitos Funcionais – RF): ◼ RF01: Permitir envio de mensagens; ◼ RF02: Permitir o uso de salas privadas; ◼ RF03: Garantir a inclusão de ficheiros, imagens e vídeos; ◼ … OBS.: Todos os requisitos funcionais listados têm de ter um identificador único ◼ Características do código: ◼ CA01: Garantir segurança dos dados do utilizador; ◼ CA02: Ter métodos de teste ao código para ser eficaz; ◼ CA03: Prever possíveis integrações com outras aplicações/SI existentes OBS.: Todas as características listados têm de ter um identificador único  Desafio Exercício de treino em grupo, apresentar proposta de resolução em aula. 48 Aplicação: ___________________________________________ ◼ Objetivo(s): i: ; ii: ; iii: ◼ Para suporte a que funções? ; ; ; … ◼ Funcionalidades da aplicação: 1. ; 2. ; 3. … ◼ Características do código: 1. ; 2. ; 3. … PSI 2024 - 2025