Rekayasa Perangkat Lunak

Size: px

Start display at page:

Download "Rekayasa Perangkat Lunak"

Kristin Warner
5 years ago
Views:

1 Rekayasa Perangkat Lunak Untuk SISTEM KOMPUTER Kuliah 4: Memahami Masalah dan Membagi Pekerjaan Mohammad Iqbal Based-on slide Ivan Marsic

2 Topik Dekomposisi : Partitioning vs. Projection Divisi pekerja Mengurangi komunikasi intra-team Permasalahan umum Software Engineering 2

3 Mengapa Harus membagi Problem/Proyek main value [of social skills] lies in the relationship between colleagues: people who can divide up tasks quickly and effectively between them form more productive teams. David Deming (Harvard U. & NBER) Strategi umum problem-solving : divide-and-conquer Divisi pekerja pada tim developer Mendukung fleksibilitas dan evolusi masa datang dengan memisah-kan bagian yang tidak berhubungan, sehingga dapat diselesaikan secara individual ( Pemisahan konsentrasi pekerjaan ) Different team members can focus on different sub-problems and not worry about everything 3

4 4

5 Bagaimana Pemula membagi Pekerjaannya List the components of the system-to-be Each sub-group of one or more team members is assigned a different component to develop One or more team members is assigned to write documentation User Interface Business Logic and Algorithms Database/ Network Documentation Chain organization every link is critical If any link fails, the whole project fails Separation of concerns is impossible 5

6 Dekomposisi: Projection vs. Partitioning Projection: :Partitioning Projection-based decomposition helps us understand the components in the context of their use, relative to other parts of the system. 6

7 Contoh : Otomatisasi Dekomposisi Restoran dengan Teknik Partitioning Developer Team α Developer Team Φ Subgroup α-red Subgroup α-green Subgroup α-blue Subgroup α-purple User Interface Business Logic and Algorithms Database/ Network Documentation 7

8 Contoh : Otomatisasi Restoran Beban Komunikasi Developer Team α Developer Team Φ Interface for what functions? Function-1: description Function-2: description Tables for what data? What to write about? User Interface Business Logic and Algorithms Database/ Network Documentation 8

Contoh : Otomatisasi Restoran Kekurangan Pendekatan Team α Communication overhead: Most time spent in communication and documentation writing No time for creative software development

9 Contoh : Otomatisasi Restoran Kekurangan Pendekatan Team α Communication overhead: Most time spent in communication and documentation writing No time for creative software development Failure-prone: If any sub-group doesn t deliver, the whole project fails Each student learns only one aspect of software development Ownership fuzzy or one leader claims all the credit I did all coding! Superhero

10 Contoh : Otomatisasi Dekomposisi Restoran dengan Teknik Projection Developer Team α Developer Team Φ Different way of slicing the project: Instead of horizontal slicing, we have vertical slicing stacks Customer-related functions Subgroup Φ-RED Subgroup Φ-GREEN Subgroup Φ-BLUE Each stack can be done independently of other stacks, as a mini-project Separation of concerns! Kitchen-related functions Managementrelated functions Shared Infrastructure 10

11 Contoh : Otomatisasi Dekomposisi Restoran dengan Teknik Projection Developer Team α Developer Team Φ Team communication is simple: What do we have in common? Subgroup Φ-RED Subgroup Φ-GREEN Subgroup Φ-BLUE They only need to define shared interfaces ( APIs ) and can focus on creative software development Customer-related functions What is inside of each stack is not discussed Kitchen-related with other sub-teams functions for others, the contents of your stack is hidden they see a black box with Managementrelated defined interface / APIs ( information hiding ) functions 11 Shared Infrastructure

12 Contoh : Otomatisasi Restoran Kelebihan Pendekatan Team Φ Increased productivity: Minimizes the amount of communication needed to coordinate the work more time to focus on creative software development Failure resilience: Reduces the dependency on other team members if they fail to deliver, you can still succeed and demonstrate your mini-project (Unlike chain-organization, where a link failure leads to project failure, each stack can succeed independently of others) Each student learns all aspects of software development Ownership visibility: Each mini-project can be demonstrated alone (If expert-based, who demonstrates UI, or dbase, or?) Customer friendly: The customer (or class instructor) knows whom to talk about every aspect of a given functional feature Requirements traceability, from inception to implementation 12

13 Apakah Shared Infrastructure? Needs to be discovered, as we will learn in subsequent lectures May be a relational database, so whole team needs to discuss together the design of the shared tables May be data items communicated via messages May be services accessed by method calls 13

14 Membagi Pekerjaan dengan Problem atau dengan Solusi By problem: Different team members responsible to solve different sub-problems or develop different features of the system Suitable for any level of expertise, particularly if uncertain about other team members skills and ability to deliver on time ( highly recommended for novices/students) Advantage: dependency on other team members is reduced the development of different features can progress independently, at their own pace Drawback: Potential redundancies because different teammates may need to develop same/similar parts to make their feature work independently of others By solution: Different team members responsible for different parts of the system Advantage: everyone can focus on one area of expertise Drawbacks: Developers need to know a lot about the solution (i.e., parts of the system and their relationships) before detailed analysis of the sub-problems. If solution parts are not precisely specified, there will be a great uncertainty about interfacing the parts and integrating into the whole system. Suitable for highly-experienced specialists, not for beginners (i.e., not for students), working on a familiar problem Always watch for fallback solutions in case some parts are not ready on time or problematic Right now, you have no area of expertise otherwise you wouldn t be a student in this class! 14

15 Contoh Yang Berlawanan Car subsystems -- different companies produce different subsystems! Why cannot we do the same?! but, you are not at this level of understanding of your problem! 15

16 Tanggapan Pada Contoh Yang Berlawanan (1) Actually, you are at this level of understanding of your problem:

17 Tanggapan Pada Contoh Yang Berlawanan (2) Before we could do this there was a lot of trial-and-error and each subsystem evolved independently to solve a different sub-problem Reliable 3 rd -party providers of precisely-defined subsystems! 17

18 Dekomposisi Problem System requirements provide the projection axes for problem decomposition different subsets of requirements identify different sub-systems. 18

19 Dekomposisi Problem We assume that the computer/software helps the user to achieve a business goal in the problem domain Problem domains can be virtual (e.g., text documents, relational databases), or physical world (a device to control, a person to notify and prompt to action) Problem types: 1. Transforming one virtual object to another (document format conversion, e.g., from MS Word to PDF) 2. Modifying a virtual object (e.g., document editing) 3. Automatically controlling behavior of a physical object (e.g., thermostat) 4. Manually controlling behavior of a physical object (e.g., drone flying) 5. Observing behavior of a physical object (e.g., traffic monitoring) 19

20 Kebutuhan Sistem Umum REQ-1: Map input data to output data as said by given rules REQ-2: Allow repository (or document) editing, where repository is a collection of data REQ-3: Automatically control a physical object/device REQ-4: Interactively control a physical object/device REQ-5: Monitor and display information about an object Only a 5-dimensional problem space! (Problem complexity can vary independently along each dimension) Note: These typical requirements will be discussed further under Problem Frames

21 Problem Umum Software Eng. 1. User works with computer system (problem domain is virtual, not physical) REQ-1: Map input data to output data as said by given rules 1.a) System transforms input document to output document IN doc System OUT doc User System 1.b) User edits information stored in a repository System REQ-2: Allow repository editing, where repository is a collection of data User Repository 2. Computer system controls the (physical) problem domain (user not involved) REQ-3: Automatically control a physical object/device System Problem domain 3. Computer system intermediates between the user and the problem domain User System Problem domain 3.a) System observes the problem domain and displays information REQ-5: Monitor and display information about an object User System Problem domain 3.b) System controls the problem domain as commanded by the user REQ-4: Interactively control a physical object/device User System Problem domain 21

22 Contoh : Dekomposisi Problem [ Case Study 1: Safe Home Access ] REQ1: keep door locked and auto-lock Required Behavior REQ2: lock when LOCK pressed REQ3: unlock when valid key provided REQ4: allow mistakes but prevent dictionary attacks Commanded Behavior REQ5: maintain a history log Information Display (database is the display ) REQ6: adding/removing users at runtime Simple Editing REQ7: configuring device activation preferences REQ8: inspecting the access history REQ9: filing inquiries Simple Editing Information Display Simple Editing

23 Contoh : Dekomposisi Problem [ Case Study 2: Investment Fantasy League ] REQ1: view market prices and volumes Domains: exchange, display REQ2: place a trade Domains: investor, tradable-securities, pending-trades REQ3: execute trades when conditions matched Domains: exchange, pending-trades REQ4: generate periodic report Domains: portfolio, report REQ5: generate leaderboard Domains: all-portfolios, leaderboard REQ6: view leaderboard Domains: leaderboard, display REQ7: start a trading group/clique Domains: investor, group Simple Editing REQ8: invite to a trading group/clique Domains: investor, friends, group Transformation Information Display Information Display Transformation Simple Editing Required Behavior Commanded Behavior

Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak Untuk SISTEM KOMPUTER Kuliah 6: Arsitektur Perangkat Lunak Mohammad Iqbal Based-on slide Ivan Marsic Topik Desain Arsitektur Perangkat Lunak Keputusan Arsitektural & Key Concerns