Chapter 2 The Process 1 A Layered Technology
- Slides: 40
Chapter 2 The Process 1
A Layered Technology Software Engineering tools methods process model a “quality” focus 2
A Common Process Framework Common process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities 3
Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management 4
The Process Model: Adaptability the framework activities will always be applied on every project. . . BUT the tasks (and degree of rigor) for each activity will vary based on: the type of project (an “entry point” to the model) characteristics of the project common sense judgment; concurrence of the project team 5
Linear Models 6
Waterfall Model SSR - System Software Review PDR - Preliminary Design Review CDR - Critical Design Review TRR - Test Rediness Review FCA - Functional Configuration Audit PCA - Physical Configuration Audit ORR - Operational Rediness Review Software Requirements Analysis SRS Software Design SDS Code and Unit Testing STP Software Integration and Test SIP SSR PDR CDR TRR FCA PCA Software Acceptance Test CRR 7
Waterfall - DOD Model Hardware Implementation Hardware System Design PP Software Requirements Analysis SRS NASA Model) Operational Timelines Preliminary Software Design PDD Detailed Software Design SDS Code and Unit Testing STP Software Integration and Test SIP SDR SSR PDR CDR TRR Software Acceptance Test FCA PCA 8
Rapid Application Development Model Rapid Throwaway Prototype Model Software Requirements Analysis SRS Build Prototype PDD Software Design Code and Unit Testing SDS STP Software Integration and Test SIP SSR PR PDR CDR TRR FCA PCA Software Acceptance Test CRR 9
RAD Characteristics High speed adaptation of the linear model Based on Component-based construction Has incremental flavor Not well- suited where precision is required, e. g. high risk systems not easily modularized systems Have rigid performance requirements 1. Model the Information Flow 2. Refine the flows into Data elements 3. Model the data transformations 4. Generate the code 4 GLs, component reuse, CASE 5. Test and integration 10
Reuse and Automated Development Models/Component Assembly Model Software Requirements Analysis SRS Software Design SDS Code and Unit Testing STP Software Integration and Test SIP SSR PDR CDR TRR FCA PCA Software Acceptance Test CRR Identify Reusable Components Informal Specification Formal Specifications Code 11
Component Based Development Architecture for Software Reuse Based on Object Orientation Classes are stored in a library When requirements are received, the first stop is the library 12
Linear Model Characteristics Documentation driven model l systematic and requires rigor. l Inflexible partitioning of project into distinct stages l difficult to respond to changes in customer requirements l Model appropriate when requirements are well-understood. l Programmers HATE to create documentation. l Users HATE to read documentation. l If users read, they rarely understand documentation. l Programmers don't understand other programmers documentations. l Standards for documentation not clear although UML ordained. 13
Iterative Models Prototyping 14
Evolutionary (Prototype) Model ONLY A PART OF THE FULL SYSTEM Software Requirements Analysis SRS Build Prototype PDD Software Design Code and Unit Testing SDS STP Software Integration and Test SIP SSR PR PDR CDR TRR FCA PCA Series of Implementations of each PART Software Acceptance Test CRR 15
Evolutionary/Prototype Model Issues Process is not visible--Lack of process visibility Systems are often poorly structured—Change tends to corrupt the structures Special tools and techniques may be required—Special skills (e. g. in languages for rapid prototyping) may be required Applicability For small or medium-size interactive systems For parts of large systems (e. g. the user interface) For short-lifetime systems 16
Iterative Models team #3 team #2 team #1 b u s in e s s m o d e l in g b u s in e s s m o d e lin g business modeling d a t a m o d e l in g p r o c e s s m o d e l in g d a ta m o d e lin g a p p l i c a tio n g e n e r a t io n te s tin g & tu rn o v e r p ro cess m o d e lin g data modeling a p p lic a t io n g e n e ra tio n process modeling te s tin g & tu r n o v e r application generation testing & turnover 60 - 90 days RAD 17
The Incremental Model increment 1 System/information engineering analysis design code increment 2 analysis test design analysis increment 3 delivery of 1 st increment code test design increment 4 analysis delivery of 2 nd increment code delivery of 3 rd increment test design code test delivery of 4 th incremen calendar time 18
Incremental Development Model ONLY A PART OF THE FULL SYSTEM Software Requirements Analysis SRS Software Design SDS Code and Unit Testing STP Software Integration and Test SIP SSR PDR CDR TRR Can Determine a PART at any phase. FCA PCA Software Acceptance Test CRR 19
Characteristics of Incremental Model Same Requirements, specification, maintenance, and requirement phases as in Waterfall The systems is partitioned into builds where each build is independently designed and scheduled "incrementally“ The 1 st build gives some "production"functionality Subsequent builds add functionality User perspective Get some results quickly Reduces new system "culture shock" 20
Characteristics of Incremental Model Costs easily prorated over the development cycle It employs the systems approach Changes are easier to implement (e. g. design of later builds may not start until some phases are complete and all their changes well known). Problems - May degenerate into "Build and Fix“ May result in builds that cannot integrate with one another 21
Spiral Model Planning Risk Analysis Prototyping Simulation Client Evaluation and Input Operational Prototype Verification for Next Level Developing 22
An Evolutionary (Spiral) Model Planning Customer Communication Risk Analysis Prototyping Engineering Customer Evaluation And input Construction & Release Simulation/ Operational Prototype/Verification for the Next Level/Development 23
Clean. Room Approach Specification Incremental Development Planning Specification and Design Usage Design Statistical Testing Certification 24
V Model REQUIREMENTS ANALYSIS ACCEPTANCE TESTING SYSTEM DESIGN Verify design PROGRAM DESIGN [Pfleeger 98] OPERATION & MAINTENANCE Validate requirements SYSTEM TESTING UNIT & INTEGRATION TESTING CODING 25
Operational Specification Model [Pfleeger 98] Execute and Revise OPERATIONAL SPECIFICATION (problem-oriented) SYSTEM REQUIREMENTS (sometimes informal or incomplete) TRANSFORMED SPECIFICATION (implementation- TEST oriented) DELIVERED SYSTEM 26
Still Other Process Models Concurrent process model—recognizes that different part of the project will be at different places in the process Formal methods—the process to apply when a mathematical specification is to be developed 27
Formal Method Characteristics Formal Methods Model Specifications produce proofs Required rigorous notation Enhances accuracy Reduces flexibility Some Formal Methods Petri Nets, Zed, Hoare Logic, CSP, Weakest Preconditions Formal Methods Abstraction Add formality to reduce ambiguity Use graphical representations Describe the possible system states, transitions, and triggers 28
Capability Maturity Model Organizations are not born using a mature process model. Most organizations use NO known process model Watts Humphrey wrote a book to lay out a plan for improving the process model within organizations. His book “Managing the Software Process” and other research has greatly improved the software engineering process. The SEI Developed a capability maturity model which proposes a model for maturing an organizations process model. 29
Capability Maturity Model Five Process Maturity Levels Level 0: Level 1: Level 2: Level 3: Level 4: Level 5: Chaos Initial Repeatable Defined Managed Optimizing 30
Level 1: Initial The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort. 31
Level 2: Repeatable Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications 32
Process Maturing to Level 2 Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirement management 33
Level 3: Defined The software process for both management and engineering activities 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 developing and maintaining software. This level includes all characteristics defined for level 2. 34
Process Maturing Level 3 Peer Reviews Inter-group coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus 35
Level 4: Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled using detailed measures. This level includes all characteristics defined for level 3. 36
Process Maturing Level 4 Software quality management Quantitative process management 37
Level 5: Optimizing Continuous process improvement is enables by quantitative feedback from the process and from testing innovative ideas and technologies This level includes all characteristics defined for level 5. 38
Process Maturing Level 5 Process change management Technology change management Defect prevention 39
CMM Issues focuses on project management rather than product development. ignores the use of technologies such as rapid prototyping. does not incorporate risk analysis as a key process area does not define its domain of applicability 40
- Generic view of process
- Layered model in software engineering
- Metamorphic rocks with a layered or banded look are called
- The following are hot sandwiches except
- Process abstraction in os
- Layered structure in os
- Monolithic structure in os
- Layered structure in os
- Layered structure in os
- Cloud responsibility
- Gartner pace layering
- The double layered protective membrane of the lungs
- Cs 363
- Inflation algorithm pre post
- Device management system calls
- Layered tasks
- Layered tasks in computer network
- Layered tasks
- Milady chapter 16 haircutting review questions
- A robust layered control system for a mobile robot
- Layered architecture for web services and grids
- Flexible pavement cross section
- Layered curriculum
- Layered curriculum template
- What is jini
- Layered curriculum
- Causal layered analysis
- Milady chapter 16 haircutting
- Risitic layering
- Layered operating system
- A robust layered control system for a mobile robot
- Reasons for using layered protocols
- C&c pattern
- Layered architecture
- Layered architecture
- Layered statistics
- Hình ảnh bộ gõ cơ thể búng tay
- Lp html
- Bổ thể
- Tỉ lệ cơ thể trẻ em
- Voi kéo gỗ như thế nào