Presentation on theme: 'Rekayasa Perangkat Lunak'— Presentation transcript:
1 Rekayasa Perangkat Lunak
Kuliah 06
Kuliah 06
2 Outline of this presentation
The Generic Software Process ModelPrototyping ModelIncremental Model
The Generic Software Process ModelPrototyping ModelIncremental Model
3 Generic Software Process Model
Prototyping modelPrototyping is the rapid development of a systemUse ifOnly general objectives availableBeing unsure aboutSoftware requirementEfficiency of an algorithmHuman-computer interaction
Prototyping modelPrototyping is the rapid development of a systemUse ifOnly general objectives availableBeing unsure aboutSoftware requirementEfficiency of an algorithmHuman-computer interaction
“Penerapan dan pemanfaatan prinsip-prinsip rekayasa untuk menghasilkan perangkat lunak yang ekonomis, andal dan bekerja secara efisien pada mesin-mesin yang nyata” 4.2. Tujuan Rekayasa Perangkat Lunak Tujuan Rekayasa Perangkat Lunak dapat dijelaskan sebagai berikut: a. Memperoleh biaya produksi perangkat lunak yang rendah.
4 Generic Software Process Model
Prototyping modelUses of system prototypesto help customers and developers understand the requirements for the systemRequirements elicitation.Users can experiment with a prototype to see how the system supports their workContinue …
Prototyping modelUses of system prototypesto help customers and developers understand the requirements for the systemRequirements elicitation.Users can experiment with a prototype to see how the system supports their workContinue …
5 Generic Software Process Model
Prototyping modelUses of system prototypesto help customers …Requirements validation.The prototype can revealerrors and omissions in the RequirementsPrototyping can be considered as a risk reduction activity which reduces requirements risks
Prototyping modelUses of system prototypesto help customers …Requirements validation.The prototype can revealerrors and omissions in the RequirementsPrototyping can be considered as a risk reduction activity which reduces requirements risks
6 Generic Software Process Model
Prototyping modelPrototyping benefitsMisunderstandings between software users and developers are exposedMissing services may be detected and confusing services may be identifiedContinue …
Prototyping modelPrototyping benefitsMisunderstandings between software users and developers are exposedMissing services may be detected and confusing services may be identifiedContinue …
7 Generic Software Process Model
Prototyping modelPrototyping benefitsA working system is available early in the processThe prototype may serve as a basis for deriving a system specification
Prototyping modelPrototyping benefitsA working system is available early in the processThe prototype may serve as a basis for deriving a system specification
8 Generic Software Process Model
Prototyping modelOther Prototyping benefitsThe system can support user training and system testingImproved system usabilityCloser match to the system neededImproved design qualityImproved maintainabilityReduced overall development effort
Prototyping modelOther Prototyping benefitsThe system can support user training and system testingImproved system usabilityCloser match to the system neededImproved design qualityImproved maintainabilityReduced overall development effort
9 Generic Software Process Model
Prototyping modelApproaches to PrototypingEvolutionary prototypingThrow-away prototyping
Prototyping modelApproaches to PrototypingEvolutionary prototypingThrow-away prototyping
10 Generic Software Process Model
Prototyping modelApproaches to PrototypingEvolutionary prototypingAn approach to system development where an initial prototype is produced and refined through a number of stages to the final system
Prototyping modelApproaches to PrototypingEvolutionary prototypingAn approach to system development where an initial prototype is produced and refined through a number of stages to the final system
11 Generic Software Process Model
Prototyping modelPrototyping ObjectivesThe objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood.
Prototyping modelPrototyping ObjectivesThe objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood.
12 Generic Software Process Model
Prototyping modelApproaches to PrototypingThrow-away prototypingA prototype which is usually a partial implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process
Prototyping modelApproaches to PrototypingThrow-away prototypingA prototype which is usually a partial implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process
13 Generic Software Process Model
Prototyping modelPrototyping ObjectivesThe objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood
Prototyping modelPrototyping ObjectivesThe objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood
14 Generic Software Process Model
Prototyping modelEvolutionary PrototypingMust be used for systems where the specification cannot be developed in advance, e.g.Artificial Intelligent Systemsand user interface systemsBased on techniques which allow rapid system iterations
Prototyping modelEvolutionary PrototypingMust be used for systems where the specification cannot be developed in advance, e.g.Artificial Intelligent Systemsand user interface systemsBased on techniques which allow rapid system iterations
15 Generic Software Process Model
Prototyping modelEvolutionary PrototypingVerification is impossible as there is no separate specification.Validation means demonstrating the adequacy of the system
Prototyping modelEvolutionary PrototypingVerification is impossible as there is no separate specification.Validation means demonstrating the adequacy of the system
16 Generic Software Process Model
Prototyping modelEvolutionary Prototyping
Prototyping modelEvolutionary Prototyping
17 Generic Software Process Model
Prototyping modelEvolutionary PrototypingSpecification, design, and implementation are inter-twinedThe system is developed as a series of increments that are delivered to the customer
Prototyping modelEvolutionary PrototypingSpecification, design, and implementation are inter-twinedThe system is developed as a series of increments that are delivered to the customer
18 Generic Software Process Model
Prototyping modelEvolutionary PrototypingTechniques for rapid system development are used such as CASE tools and 4GLsUser interfaces are usually developed using a GUI development toolkit
Prototyping modelEvolutionary PrototypingTechniques for rapid system development are used such as CASE tools and 4GLsUser interfaces are usually developed using a GUI development toolkit
19 Generic Software Process Model
Prototyping modelEvolutionary Prototyping AdvantagesAccelerated delivery of the systemRapid delivery and deployment are sometimes more important than functionality or long-term software maintainability
Prototyping modelEvolutionary Prototyping AdvantagesAccelerated delivery of the systemRapid delivery and deployment are sometimes more important than functionality or long-term software maintainability
20 Generic Software Process Model
Prototyping modelEvolutionary Prototyping AdvantagesUser engagement with the systemNot only is the system more likely to meet user requirements, but users are more likely to commit to the use of the system
Prototyping modelEvolutionary Prototyping AdvantagesUser engagement with the systemNot only is the system more likely to meet user requirements, but users are more likely to commit to the use of the system
21 Generic Software Process Model
Prototyping modelEvolutionary Prototyping ProblemsManagement problemsExisting management processes assume a waterfall model of developmentSpecialist skills are required which may not be available in all development teams
Prototyping modelEvolutionary Prototyping ProblemsManagement problemsExisting management processes assume a waterfall model of developmentSpecialist skills are required which may not be available in all development teams
22 Generic Software Process Model
Prototyping modelEvolutionary Prototyping ProblemsMaintenance problemsContinual change tends to corrupt system structure so long-term maintenance is expensiveContractual problemsNo requirement document
Prototyping modelEvolutionary Prototyping ProblemsMaintenance problemsContinual change tends to corrupt system structure so long-term maintenance is expensiveContractual problemsNo requirement document
23 Generic Software Process Model
Prototyping modelThrow-away PrototypingUsed to reduce requirements riskThe prototype is developed from an initial specification, delivered for experiment then discarded
Prototyping modelThrow-away PrototypingUsed to reduce requirements riskThe prototype is developed from an initial specification, delivered for experiment then discarded
24 Generic Software Process Model
Prototyping modelThrow-away PrototypingThe throw-away prototype should NOT be considered as a final systemSome system characteristics may have been left outContinue ...
Prototyping modelThrow-away PrototypingThe throw-away prototype should NOT be considered as a final systemSome system characteristics may have been left outContinue ...
25 Generic Software Process Model
Prototyping modelThrow-away PrototypingThe throw-away prototype should NOT be considered as a final systemThere is no specification for long-term maintenanceThe system will be poorly structured and difficult to maintain
Prototyping modelThrow-away PrototypingThe throw-away prototype should NOT be considered as a final systemThere is no specification for long-term maintenanceThe system will be poorly structured and difficult to maintain
26 Generic Software Process Model
Prototyping modelThrow-away Prototyping
Prototyping modelThrow-away Prototyping
27 Generic Software Process Model
Prototyping modelThrow-away PrototypingDevelopers may be pressured to deliver a throw-away prototype as a final system
Prototyping modelThrow-away PrototypingDevelopers may be pressured to deliver a throw-away prototype as a final system
28 Generic Software Process Model
Prototyping modelThrow-away PrototypingThis is not recommendedIt may be impossible to tune the prototype to meet non-functional requirementsThe prototype is inevitably undocumentedContinue…
Prototyping modelThrow-away PrototypingThis is not recommendedIt may be impossible to tune the prototype to meet non-functional requirementsThe prototype is inevitably undocumentedContinue…
29 Generic Software Process Model
Prototyping modelThrow-away PrototypingThis is not recommendedThe system structure will be degraded through changes made during developmentNormal organisational quality standards may not have been applied
Prototyping modelThrow-away PrototypingThis is not recommendedThe system structure will be degraded through changes made during developmentNormal organisational quality standards may not have been applied
30 Generic Software Process Model
Prototyping TechniquesVarious techniques may be used for rapid developmentPaper Prototyping- Scratch Art WorkPresentation Software Prototyping- Power Point (Microsoft)- Freelance Graphics (Lotus)- etc
Prototyping TechniquesVarious techniques may be used for rapid developmentPaper Prototyping- Scratch Art WorkPresentation Software Prototyping- Power Point (Microsoft)- Freelance Graphics (Lotus)- etc
31 Generic Software Process Model
Prototyping TechniquesVarious techniques may be used for rapid developmentDynamic high-level language developmentDatabase programming- SQLComponent and application assembly
Prototyping TechniquesVarious techniques may be used for rapid developmentDynamic high-level language developmentDatabase programming- SQLComponent and application assembly
32 Generic Software Process Model
Prototyping TechniquesThese are not mutually exclusive techniques – they are often used togetherVisual programming is an inherent part of most prototype development systems
Prototyping TechniquesThese are not mutually exclusive techniques – they are often used togetherVisual programming is an inherent part of most prototype development systems
33 Generic Software Process Model
User interface prototypingIt is impossible to pre-specify the look and feel of a user interface in an effective way. Prototyping is essentialUI development consumes an increasing part of overall system development costs
User interface prototypingIt is impossible to pre-specify the look and feel of a user interface in an effective way. Prototyping is essentialUI development consumes an increasing part of overall system development costs
34 Generic Software Process Model
User interface prototypingUser interface generators may be used to ‘draw’ the interface and simulate its functionality with components associated with interface entitiesWeb interfaces may be prototyped using a web site editor
User interface prototypingUser interface generators may be used to ‘draw’ the interface and simulate its functionality with components associated with interface entitiesWeb interfaces may be prototyped using a web site editor
35 Generic Software Process Model
Prototyping modelKey PointA prototype can be used to give end-users a concrete impression of the system’s capabilitiesPrototyping is becoming increasingly used for system development where rapid development is essentialContinue…
Prototyping modelKey PointA prototype can be used to give end-users a concrete impression of the system’s capabilitiesPrototyping is becoming increasingly used for system development where rapid development is essentialContinue…
36 Generic Software Process Model
Prototyping modelKey PointThrow-away prototyping is used to understand the system requirementsIn evolutionary prototyping, the system is developed by evolving an initial version to the final versionContinued …
Prototyping modelKey PointThrow-away prototyping is used to understand the system requirementsIn evolutionary prototyping, the system is developed by evolving an initial version to the final versionContinued …
37 Generic Software Process Model
Prototyping modelKey PointRapid development of prototypes is essential. This may require leaving out functionality or relaxing non-functional constraintsPrototyping techniques include the use of very high-level languages, database programming and prototype construction from reusable components
Prototyping modelKey PointRapid development of prototypes is essential. This may require leaving out functionality or relaxing non-functional constraintsPrototyping techniques include the use of very high-level languages, database programming and prototype construction from reusable components
38 Generic Software Process Model
Prototyping modelKey PointPrototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified. Users must be involved in prototype evaluation
Prototyping modelKey PointPrototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified. Users must be involved in prototype evaluation
39 Prototyping ModelPendekatan prototyping model digunakan jika pemakai hanya mendefinisikan objektif umum dari perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya,sementara pengembang tidak begitu yakin akan efisiensi algoritma, adaptasi sistem operasi, atau bentuk interaksi manusia-mesin yang harus diambil.Cakupan aktivitas prototyping model terdiri dari:Mendefinisikan objetif secara keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.Melakukan perancangan secara cepat sebagai dasar untuk membuat prototypeMenguji coba dan mengevaluasi prototype dan kemudian melakukan penambahan dan perbaikan-perbaikan terhadap prototype yang sudah dibuat.
40 Kelemahan prototyping model:
Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang.Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien.
Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang.Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien.
41 Generic Software Process Model
Incremental ModelFact: Software evolves over timeStraight path to an end product is unrealisticTight market deadlinesDeliver limited versionCore product requirements well understoodNeed for extensions foreseeable
Incremental ModelFact: Software evolves over timeStraight path to an end product is unrealisticTight market deadlinesDeliver limited versionCore product requirements well understoodNeed for extensions foreseeable
42 Generic Software Process Model
Incremental ModelRequirementsdesigncodetestintegrateO&MRelease 1release 2release 3release 4Incremental development(each release adds more functionality)
Incremental ModelRequirementsdesigncodetestintegrateO&MRelease 1release 2release 3release 4Incremental development(each release adds more functionality)
43 Generic Software Process Model
Incremental ModeldesigncodetestintegrateO&Mreqtsversion 1version 2version 3lessons learntEvolutionary development(each version incorporates new requirements)
Incremental ModeldesigncodetestintegrateO&Mreqtsversion 1version 2version 3lessons learntEvolutionary development(each version incorporates new requirements)
44 Generic Software Process Model
Incremental ModelCombines elements of the linear model and prototypingProduces “deliverable” incrementsFirst increment often core productFocuses on operational product(not throw-away prototype)
Incremental ModelCombines elements of the linear model and prototypingProduces “deliverable” incrementsFirst increment often core productFocuses on operational product(not throw-away prototype)
45 Generic Software Process Model
Incremental ModelUsed when not enough resources are available to deliver the complete product in timeIncrements help to manage technical risks(e.g. currently unavailable hardware)
Incremental ModelUsed when not enough resources are available to deliver the complete product in timeIncrements help to manage technical risks(e.g. currently unavailable hardware)
46 Generic Software Process Model
Incremental ModelFocuses attention on reuse optionsFocuses attention on early error eliminationPuts quality objectives up frontIntegrates development and maintenanceProvides a framework for hardware/software development
Incremental ModelFocuses attention on reuse optionsFocuses attention on early error eliminationPuts quality objectives up frontIntegrates development and maintenanceProvides a framework for hardware/software development
47 Generic Software Process Model
Incremental ModelContractual development often specifies process model and deliverables in advanceRequires risk assessment expertiseNeeds refinement for general use
Incremental ModelContractual development often specifies process model and deliverables in advanceRequires risk assessment expertiseNeeds refinement for general use
48 Incremental ModelMerupakan kombinasi linear sequential model (diaplikasikan secara berulang) dan filosofi pengulangan dari prototyping model.Setiap tahapan linear sequential menghasilkan deliverable increment bagi perangkat lunak, dimana increment pertamanya merupakan sebuah produk inti yang mewakili kebutuhan dasar sistem.Produk inti ini nantinya dikembangkan menjadi increment-increment selanjutnya setelah digunakan dan dievaluasi sampai didapat produk yang lengkap dan memenuhi kebutuhan pemakai.
49 Kelemahan incremental model:
1. Hanya akan berhasil jika tidak ada staffing untuk penerapan secara menyeluruh.2. Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut.
1. Hanya akan berhasil jika tidak ada staffing untuk penerapan secara menyeluruh.2. Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut.
50 Finished,Questions?
Presentasi berjudul: 'REKAYASA PERANGKAT LUNAK (IF 1483)'— Transcript presentasi:
1 REKAYASA PERANGKAT LUNAK (IF 1483)
Pertemuan 3 & 4Siklus Hidup Perangkat Lunak(Software Lifecycle )Model Proses PL(Software Process Models )IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Pertemuan 3 & 4Siklus Hidup Perangkat Lunak(Software Lifecycle )Model Proses PL(Software Process Models )IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
2 IF 1483 - RPL TEKNIK INFORMATIKA
DeskripsiMenjelaskan siklus hidup PLMenjelaskan model proses PLIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
DeskripsiMenjelaskan siklus hidup PLMenjelaskan model proses PLIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
3 Tujuan Instruksional Umum (TIU)
Mahasiswa mampu menjelaskan konsep Siklus hidup perangkat lunakMahasiswa mampu menjelaskan model proses pembangunan perangkat lunakIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Mahasiswa mampu menjelaskan konsep Siklus hidup perangkat lunakMahasiswa mampu menjelaskan model proses pembangunan perangkat lunakIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
4 Software Engineering / RPL
Layered TechnologyKey Process AreasMenyediakan tools utk membangun swBgmn membangun SWToolsKerangka kerja KPAMethodsEngineering needs organizational commitment to qualityTQM, et al, continuous process improvement cultureLeads to more mature approaches to software engineeringProcessFoundationGlue that holds the technology layers togetherFramework for Key Process AreasKPAsmust be established for effective delivery of software technologyBasis for management control of software projectsContext:technical methods appliedwork products are producedmilestones establishedquality assuredchange managedMethodsTechnical “how-to’s”ToolsAutomated or semi-automated support for process or methodSE focus pada qualityProcessQuality[Pressman 97]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Layered TechnologyKey Process AreasMenyediakan tools utk membangun swBgmn membangun SWToolsKerangka kerja KPAMethodsEngineering needs organizational commitment to qualityTQM, et al, continuous process improvement cultureLeads to more mature approaches to software engineeringProcessFoundationGlue that holds the technology layers togetherFramework for Key Process AreasKPAsmust be established for effective delivery of software technologyBasis for management control of software projectsContext:technical methods appliedwork products are producedmilestones establishedquality assuredchange managedMethodsTechnical “how-to’s”ToolsAutomated or semi-automated support for process or methodSE focus pada qualityProcessQuality[Pressman 97]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
5 IF 1483 - RPL TEKNIK INFORMATIKA
Software QualityCritical Quality Attributes[Sommerville 96]MaintainabilityDependabilityEfficiencyUsabilityOther AttributesCompletenessCompatibilityPortabilityInternationalizationUnderstandabilityScalabilityRobustnessTestabilityReusabilityCustomizabilityDefinition of Critical Attributes:Maintainability - possible to evolve software to meet changing needsDependability - includes range of characteristics: reliability, security and safety; should not cause physical or economic damage in the event of system failureEfficiency - should not make wasteful use of system resources such as memory and process cyclesUsability - should have appropriate user interface and adequate documentationOther Attributes:SafetySecurityReliabilityResilienceRobustnessUnderstandabilityTestabilityAdaptabilityModularityComplexityPortabilityReusabilityLearnabilityIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Software QualityCritical Quality Attributes[Sommerville 96]MaintainabilityDependabilityEfficiencyUsabilityOther AttributesCompletenessCompatibilityPortabilityInternationalizationUnderstandabilityScalabilityRobustnessTestabilityReusabilityCustomizabilityDefinition of Critical Attributes:Maintainability - possible to evolve software to meet changing needsDependability - includes range of characteristics: reliability, security and safety; should not cause physical or economic damage in the event of system failureEfficiency - should not make wasteful use of system resources such as memory and process cyclesUsability - should have appropriate user interface and adequate documentationOther Attributes:SafetySecurityReliabilityResilienceRobustnessUnderstandabilityTestabilityAdaptabilityModularityComplexityPortabilityReusabilityLearnabilityIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
6 Capability Maturity Model
Dikembangkan oleh Software Engineering Institute (SEI)Untuk mengetahui level kemampuan perusahaan pengembang S/WLima Level Process MaturityLevel 0: Chaos, kacauLevel 1: Initialdikerjakan secara khusus, kadang masih kacau , keberhasilan project ditentukan oleh usaha individuLevel 2: Repeatable,proses manajemen project sudah ada untuk melacak beaya, jadwal, fungsi,keberhasilan project sebelumnya bisa diterapkan pada project lain yang miripEmphasis on Process MaturityProvides a measure of global effectiveness of a company’s software engineering practicesLevel 0:Level 1: ad hoc, occasionally chaotic; few defined processes and success depends on individual effortLevel 2: Repeatable: basic PM processes are established to track cost, schedule, and functionality. Necessary process discipline is in place to repeat earlier successes on projects with similar applications(configuration MGT, SQA, subcontract MGT, project planning, tracking & oversight, Requirements MGT)Level 3: process for management and engineering is documented, standardized, and integrated into an organization wide software process; all projects use a documented and approved version of the organization’s process for development and maintenance(Peer reviews, intergroup coordination, software product engineering, integrated software MGT, training program, organization process definition, organization process focus)Level 4: detailed measures of software process and quality are collected; both process and products are quantitatively understood and controlled using detailed measures(Software quality MGT, quantitative process MGT)Level 5: continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies.(Process change MGT, technology change MGT, defect prevention)IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Dikembangkan oleh Software Engineering Institute (SEI)Untuk mengetahui level kemampuan perusahaan pengembang S/WLima Level Process MaturityLevel 0: Chaos, kacauLevel 1: Initialdikerjakan secara khusus, kadang masih kacau , keberhasilan project ditentukan oleh usaha individuLevel 2: Repeatable,proses manajemen project sudah ada untuk melacak beaya, jadwal, fungsi,keberhasilan project sebelumnya bisa diterapkan pada project lain yang miripEmphasis on Process MaturityProvides a measure of global effectiveness of a company’s software engineering practicesLevel 0:Level 1: ad hoc, occasionally chaotic; few defined processes and success depends on individual effortLevel 2: Repeatable: basic PM processes are established to track cost, schedule, and functionality. Necessary process discipline is in place to repeat earlier successes on projects with similar applications(configuration MGT, SQA, subcontract MGT, project planning, tracking & oversight, Requirements MGT)Level 3: process for management and engineering is documented, standardized, and integrated into an organization wide software process; all projects use a documented and approved version of the organization’s process for development and maintenance(Peer reviews, intergroup coordination, software product engineering, integrated software MGT, training program, organization process definition, organization process focus)Level 4: detailed measures of software process and quality are collected; both process and products are quantitatively understood and controlled using detailed measures(Software quality MGT, quantitative process MGT)Level 5: continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies.(Process change MGT, technology change MGT, defect prevention)IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
7 IF 1483 - RPL TEKNIK INFORMATIKA
CMM (lanjutan)Level 3: DefinedProses manajement dan aktifitas rekayasa sudah terdokumentasi, terstandarisasi dan terintegrasi pada organisasi pengembangan software.Termasuk seluruh karakteristik di level 2Level 4: Managed :Detil measurement/pengukuran dari proses sw dan kualitas product dikumpulkanTermasuk seluruh karakteristik di level 3Level 5: OptimizingPengembangan proses yang berkelanjutan dengan memanfaatkan feedback dari proses , testingyang telah dilakukanTermasuk seluruh karakteristik di level 4IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
CMM (lanjutan)Level 3: DefinedProses manajement dan aktifitas rekayasa sudah terdokumentasi, terstandarisasi dan terintegrasi pada organisasi pengembangan software.Termasuk seluruh karakteristik di level 2Level 4: Managed :Detil measurement/pengukuran dari proses sw dan kualitas product dikumpulkanTermasuk seluruh karakteristik di level 3Level 5: OptimizingPengembangan proses yang berkelanjutan dengan memanfaatkan feedback dari proses , testingyang telah dilakukanTermasuk seluruh karakteristik di level 4IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
8 Prinsip-Prinsip Proses
Menentukan seluruh aktivitas utamaMenggunakan sumber daya, dengan batasan tertentu, untuk menghasilkan produk antara dan produk akhirTersusun dari beberapa sub prosesSetiap aktivitas mempunyai kriteria masukan dan keluaranAktivitas diorganisasikan secara teraturMempunyai panduan yang menjelaskan tujuanAturan dipakai pada aktivitas,sumberdaya & produkDefinition of Process: a series of steps involving activities, constraints, and resources that produce an intended output of some kindProcess Attributes:Understandability - To what extent is the process explicitly defined and how easy is it to understand?Visibility - Do the process activities culminate in clear results so that the progress of the process is externally visible?Supportability - To what extent can the process activities be supported by CASE tools?Acceptability - acceptable and usable by engineers?Reliability - Is the process designed in such a way that process errors are avoided or trapped before they result in product errors?Robustness - Can the process continue in spite of unexpected problems?Maintainability - Can the process evolve to reflect changing organizational requirements or identified process improvements?Rapidity - How fast can the process of delivering a system from given specification be completed?IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Menentukan seluruh aktivitas utamaMenggunakan sumber daya, dengan batasan tertentu, untuk menghasilkan produk antara dan produk akhirTersusun dari beberapa sub prosesSetiap aktivitas mempunyai kriteria masukan dan keluaranAktivitas diorganisasikan secara teraturMempunyai panduan yang menjelaskan tujuanAturan dipakai pada aktivitas,sumberdaya & produkDefinition of Process: a series of steps involving activities, constraints, and resources that produce an intended output of some kindProcess Attributes:Understandability - To what extent is the process explicitly defined and how easy is it to understand?Visibility - Do the process activities culminate in clear results so that the progress of the process is externally visible?Supportability - To what extent can the process activities be supported by CASE tools?Acceptability - acceptable and usable by engineers?Reliability - Is the process designed in such a way that process errors are avoided or trapped before they result in product errors?Robustness - Can the process continue in spite of unexpected problems?Maintainability - Can the process evolve to reflect changing organizational requirements or identified process improvements?Rapidity - How fast can the process of delivering a system from given specification be completed?IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
9 Tahapan Pengembangan PL Software Development Stages
Requirements Analysis & SpecificationConceptual/System DesignDetailed/Program DesignImplementation/CodingUnit & Integration TestingSystem TestingSystem DeliveryMaintenanceRequirements analysis & specificationConceptual/System designDetailed/Program designCoding/ImplementationUnit Testing & IntegrationSystem TestingSystem DeliveryMaintenanceIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Requirements Analysis & SpecificationConceptual/System DesignDetailed/Program DesignImplementation/CodingUnit & Integration TestingSystem TestingSystem DeliveryMaintenanceRequirements analysis & specificationConceptual/System designDetailed/Program designCoding/ImplementationUnit Testing & IntegrationSystem TestingSystem DeliveryMaintenanceIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
10 Model Siklus Hidup PL Software Lifecycle Models
Waterfall ModelV ModelPrototyping ModelOperational Specification ModelPhased Development ModelSpiral ModelIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Waterfall ModelV ModelPrototyping ModelOperational Specification ModelPhased Development ModelSpiral ModelIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
11 IF 1483 - RPL TEKNIK INFORMATIKA
Waterfall Model[Royce 1970] - DoD contractsPROS:Focuses attentionEasy to explain to customersIntermediate products are made explicitCONS:Does not really reflect how software is producedImposes PM structure - no explanation of how artifact from one stage is transformed in the nextFailure to treat software as problem-solving process[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Waterfall Model[Royce 1970] - DoD contractsPROS:Focuses attentionEasy to explain to customersIntermediate products are made explicitCONS:Does not really reflect how software is producedImposes PM structure - no explanation of how artifact from one stage is transformed in the nextFailure to treat software as problem-solving process[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
12 IF 1483 - RPL TEKNIK INFORMATIKA
V Model[German Ministry of Defense 1992]Variation that shows how testing activities relate to analysis and designMakes more explicit the iteration and rework that are hidden in waterfall[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
V Model[German Ministry of Defense 1992]Variation that shows how testing activities relate to analysis and designMakes more explicit the iteration and rework that are hidden in waterfall[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
13 IF 1483 - RPL TEKNIK INFORMATIKA
Prototyping ModelListen toCustomerBuild/ReviseMock-UpCustomerTest-drivesMock-up[Pressman 97]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Prototyping ModelListen toCustomerBuild/ReviseMock-UpCustomerTest-drivesMock-up[Pressman 97]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
14 IF 1483 - RPL TEKNIK INFORMATIKA
Prototyping ModelAll or part of a system constructed quickly to understand or clarify issuesOverall goal: reducing risk and uncertainty in developmentExplore alternative designs[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Prototyping ModelAll or part of a system constructed quickly to understand or clarify issuesOverall goal: reducing risk and uncertainty in developmentExplore alternative designs[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
15 Operational Specification Model
[Pfleeger 98]System requirements are evaluated/executed in a way that demonstrated behavior of a systemFull specification that can then be enacted using a automated software toolMerges functionality with designIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
[Pfleeger 98]System requirements are evaluated/executed in a way that demonstrated behavior of a systemFull specification that can then be enacted using a automated software toolMerges functionality with designIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
16 Phased Development Model
Iterative vs. Incremental DevelopmentIterative - full system at beginning, changes functionality with each releaseIncremental - subsystems are added & functionality builds with each releaseADVANTAGES:Early training on early releaseCreate markets for non-existing functionalityBundle patches in with frequent releasesDevelopment team can focus on different areas with each release[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Iterative vs. Incremental DevelopmentIterative - full system at beginning, changes functionality with each releaseIncremental - subsystems are added & functionality builds with each releaseADVANTAGES:Early training on early releaseCreate markets for non-existing functionalityBundle patches in with frequent releasesDevelopment team can focus on different areas with each release[Pfleeger 98]IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
17 IF 1483 - RPL TEKNIK INFORMATIKA
Boehm’s Spiral ModelEVALUATE ALTERNATIVESDETERMINE GOALS,AND RISKSALTERNATIVES,[Pfleeger 98]CONSTRAINTSConstraints4Risk analysis4Constraints3Risk analysis43Alternatives3Constraints2Risk analysisAlternatives22AlternativesConstraintsRisk analysis1Proto-Proto-Proto-BudgetAlternatives4BudgetBudgetPrototypetypetypetype32Budget123411start1Requirements,Concept ofDetailedlife-cycle planoperationSoftware[Boehm 88]Viewed in light of risks involvedCombine development with risk MGTdesignSoftwarerequirementsdesignDevelopmentIntegrationplanValidatedCodeand test planrequirementsValidated,verified designUnit testSystemImplementationAcceptancetestplantestPLANDEVELOP AND TESTIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Boehm’s Spiral ModelEVALUATE ALTERNATIVESDETERMINE GOALS,AND RISKSALTERNATIVES,[Pfleeger 98]CONSTRAINTSConstraints4Risk analysis4Constraints3Risk analysis43Alternatives3Constraints2Risk analysisAlternatives22AlternativesConstraintsRisk analysis1Proto-Proto-Proto-BudgetAlternatives4BudgetBudgetPrototypetypetypetype32Budget123411start1Requirements,Concept ofDetailedlife-cycle planoperationSoftware[Boehm 88]Viewed in light of risks involvedCombine development with risk MGTdesignSoftwarerequirementsdesignDevelopmentIntegrationplanValidatedCodeand test planrequirementsValidated,verified designUnit testSystemImplementationAcceptancetestplantestPLANDEVELOP AND TESTIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
18 IF 1483 - RPL TEKNIK INFORMATIKA
Ringkasan MateriLayer TeknologiSoftware QualityTahapan Pengembangan PLSiklus Hidup Perangkat LunakIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
Ringkasan MateriLayer TeknologiSoftware QualityTahapan Pengembangan PLSiklus Hidup Perangkat LunakIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
19 IF 1483 - RPL TEKNIK INFORMATIKA
TugasIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
TugasIF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
20 IF 1483 - RPL TEKNIK INFORMATIKA
ReferensiSoftware Engineering: A Practitioner's Approach (Bab 4)Pengarang : Roger S. PressmanPenerbit: Fourth Edition, McGraw-Hill, 1997IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK
ReferensiSoftware Engineering: A Practitioner's Approach (Bab 4)Pengarang : Roger S. PressmanPenerbit: Fourth Edition, McGraw-Hill, 1997IF RPL TEKNIK INFORMATIKAUPN “VETERAN” YK