Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 1...
-
Upload
jessie-fleming -
Category
Documents
-
view
212 -
download
0
Transcript of Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 1...
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 1
Software Processes(Chapter 4 from the textbook)
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 2
Objectives
To introduce software process models To describe Some generic process models
and when they may be used To describe outline process models for
requirements engineering, software development, testing and evolution
To explain the Rational Unified Process model
To introduce CASE technology to support software process activities
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 3
Topics covered
Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering Agile development methods and processes.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 4
The software process
A structured set of activities required to develop a software system. Major activities or stages include: Requirements, Design, Implementation, Testing, and Deployment.
Each stage of those listed may have one or more sub stages. For example, Requirement may include: communication, elicitation, specification, and verification. Design may include architectural and detail design.
In some projects, a stage maybe shortened, but it can never be ignored.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 5
Framework Activities; different terminologies
In different books or references, some of those processes may be mixed, combined, or have different names.
Communication Planning Modeling (Design and specs)
• Analysis of requirements• Design
Construction (Implementation and testing)• Code generation• Testing
Deployment
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 6
Umbrella Activities
Those are considered as – secondary processes. Some projects may or may not include them.
Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 7
Generic software process models The waterfall model : Separate and distinct phases of
specification and development. Does not go to the next phase until completing the current phase.
Evolutionary development ( Prototyping).•Specification, development and validation are interleaved.
Develop “prototypes” for customers to see and verify. Component-based software engineering
•The system is assembled from existing components off-shelf components.
There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implement-able design.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 8
The Waterfall Model
Communication Planning
ModelingConstruction
Deployment analysis design code
test
project initiation requirement gathering estimating
scheduling tracking
delivery support feedback
We don’t go back to a stage once it is completed, and “usually” we don’t start a stage until the previous stage is completed.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 9
Waterfall model phases Requirements analysis and definition System and software design Implementation and unit testing – developers tasks. Integration and system testing- testers tasks. Operation and maintenance. Customer support and
Customer service tasks. We use the waterfall model when we have fixed,
stable and known requirements. The main drawback of the waterfall model is the
difficulty of accommodating changes after the process is underway. One phase has to be completed before moving to the next phase.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 10
Waterfall model problems
Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements (not suitable for unstable requirements).
Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.
Few business systems have stable requirements. The waterfall model is mostly used for large systems
engineering projects where a system is developed at several sites. (such as space or govt projects).
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 11
Evolutionary development We want the software to “evolve” to its final form
“requirements are not completely known, or we need to verify them with the customers.
Exploratory development : The Objective is to work with customers and to evolve a final system from an initial outline specification.• We should start with those requirements that are well-understood and agreed upon and then add new features as proposed by the customer.
Throw-away prototyping : The objective is to understand the system requirements.
We may start with poorly understood requirements, then build prototypes to clarify what is really needed.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 12
Evolutionary Models: Prototyping
Communication
Quick plan
Construction of prototype
Modeling Quick design
Delivery & Feedback
Deployment
communication
Quickplan
ModelingQuick design
Constructionof prototype
Deploymentdelivery &feedback
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 13
Evolutionary development
Problems• Lack of process visibility ( We don’t have the complete
requirements and hence we are not sure how much resources we may need, or of the project will be a successful one);
• Systems are often poorly structured (because they evolve and change continuously);
• Special skills (e.g. in languages for rapid prototyping) may be required.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 14
Evolutionary development
Applicability• For small or medium-size interactive systems;• For parts of large systems (e.g. the user
interface);• For short-lifetime systems.• Prototyping can be used in initial stages as a
way of collecting requirements. (Customers may find it easier to make comments on actual product and not just papers or documents).
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 15
Process iteration
System requirements ALWAYS evolve in the course of a project. As a result, process iteration where earlier stages are reworked is always part of large systems’ processes. (MS Windows & Office continuously have updates, newer versions, batches and bug fixes).
Iteration can be applied to any of the generic process models.
Two (related) approaches• Incremental delivery;• Spiral development.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 16
Incremental delivery
Rather than delivering the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.
User requirements are prioritised and the highest priority requirements are included in early increments.
Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 17
The Incremental Model
C o m m u n i c a t i o n
P l a n n i n g
M o d e l i n g
C o n s t r u c t i o n
D e p l o y m e n t
d e l i v e ry f e e d b a c k
analys is
des ign code
t es t
increment # 1
increment # 2
delivery of 1st increment
delivery of 2nd increment
delivery of nth increment
increment # n
project calendar time
C o m m u n i c a t i o nP l a n n i n g
M o d e l i n g
C o n s t r u c t i o n
D e p l o y m e n t
d e l i v e r y
f e e d b a c k
analys is
des ign code
t es t
C o m m u n i c a t i o nP l a n n i n g
M o d e l i n g
C o n s t r u c t i o n
D e p l o y m e n t
d e l i v e r y
f e e d b a c k
analys is
des igncode t es t
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 18
Incremental development advantages
Customer value can be delivered with each increment so system functionality is available earlier.
Early increments act as a prototype to help elicit requirements for later increments.
Lower risk of overall project failure. The highest priority system services tend to
receive the most testing.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 19
Spiral development
Process is represented as a spiral rather than as a sequence of activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process. (This is the main difference from the Incremental model).
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 20
Spiral model of the software process
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2
Prototype 3Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
Code
Unit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternatives,identify, resolve risks
Determine objectives,alternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 21
Evolutionary Models: The Spiral
communication
planning
modeling
constructiondeployment delivery feedback
start
analysis design
code test
estimation scheduling risk analysis
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 22
Spiral model sectors
Objective setting• Specific objectives for the phase are identified.
Risk assessment and reduction• Risks are assessed and activities put in place to
reduce the key risks. Development and validation
• A development model for the system is chosen which can be any of the generic models.
Planning• The project is reviewed and the next phase of the
spiral is planned.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 23
General process activities
Software specification Software design and implementation Software validation Software evolution
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 24
Software specification
The process of establishing what services are required and the constraints on the system’s operation and development.
Requirements engineering process• Feasibility study;• Requirements elicitation and analysis;• Requirements specification;• Requirements validation.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 25
The requirements engineering process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 26
Software design and implementation
Software design : To design a software structure or model that realises the specification; The design is the link between the requirements and the code (The blueprint such as the one used in buildings).
Implementation : The process of converting the system specification into an executable system (i.e. the code or the software).
The activities of design and implementation are closely related and may be inter-leaved.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 27
Design process activities
Architectural design Abstract specification Interface design Component or detail design Data structure design Algorithm design
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 28
The software design process
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 29
Programming and debugging
Translating a design into a program and removing errors from that program.
We use programming or developing to refer to the implementation stage.
Programming is a personal activity - there is no generic programming process, but there are coding standards (such as naming conventions).
Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process (i.e. unit testing).
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 30
The debugging process
Locateerror
Designerror repair
Repairerror
Re-testprogram
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 31
Software validation
Verification and validation (V & V) are intended to show that a system conforms to its specification and meets the requirements of the system customer.
Involves checking and review processes and system testing.
System testing involves executing the system with test cases that are derived from the specification in order to be processed by the system.
Validation and verification occurs in the requirement stage while testing occurs within or after the implementation stage.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 32
Testing stages
Component or unit testing : Individual components are tested independently; • Components may be functions or objects or
coherent groupings of these entities. Usually done by developers.
System testing: Testing of the system as a whole. Testing of emergent properties is particularly important. Usually done by local company testers.
Acceptance testing: Testing with customer data to check that the system meets the customer’s needs. Usually done by customers or independent testers.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 33
The testing process
Componenttesting
Systemtesting
Acceptancetesting
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 34
Testing phases
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand test
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
ServiceAcceptance
testSystem
integration testSub-system
integration test
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 35
Other types of testing
Unit or white box testing (i.e. component testing). Black box testing (can be part of system testing). Integration testing (related to system testing). User Interface testing (can be part of system
testing). Alpha and Beta testing (can be part of
acceptance testing).
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 36
Software evolution or maintenance
Software is inherently flexible and can change. As requirements change, through changing
business circumstances, the software that supports the business must also evolve and change.
Although there has been a mixing between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 37
System evolution
Assess existingsystems
Define systemrequirements
Propose systemchanges
Modifysystems
Newsystem
Existingsystems
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 38
The Rational Unified Process
A modern process model derived from the work on the UML and associated process.
Normally described from 3 perspectives• A dynamic perspective that shows phases over
time;• A static perspective that shows process
activities;• A proactive perspective that suggests good
practices.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 39
RUP phase model
Phase iteration
Inception Elaboration Construction Transition
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 40
RUP phases
Inception• Establish the business case for the system.
Elaboration• Develop an understanding of the problem
domain and the system architecture. Construction
• System design, programming and testing. Transition
• Deploy the system in its operating environment.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 41
RUP good practice
Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 42
Static workflows
Workflow Description
Business modelling The business processes are modelled using business use cases.
Requirements Actors who interact with the system are identified and use cases aredeveloped to model the system requirements.
Analysis and design A design model is created and documented using architecturalmodels, component models, object models and sequence models.
Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from designmodels helps accelerate this process.
Test Testing is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.
Deployment A product release is created, distributed to users and installed in theirworkplace.
Configuration andchange management
This supporting workflow managed changes to the system (seeChapter 29).
Project management This supporting workflow manages the system development (seeChapter 5).
Environment This workflow is concerned with making appropriate software toolsavailable to the software development team.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 43
Computer-aided software engineering CASE
Computer-aided software engineering (CASE) is a software to support software development and evolution processes (Example, .NET IDE).
Activity automation• Graphical editors for system model development (such as
UML, .NET, Eclipse, etc);• Data dictionary to manage design entities (OO design
tools);• Graphical UI builder for user interface construction (.NET,
Eclipse, etc.);• Debuggers to support program fault finding;• Automated translators to generate new versions of a
program (such as Installers).
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 44
CASE technology
CASE technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted• Software engineering requires creative thought - this
is not readily automated;• Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE technology does not really support these. (i.e. the personal activities, Some tools can be used to work as a communication media between project team members, project or defect tracking tools).
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 45
CASE classification
Classification helps us understand the different types of CASE tools and their support for process activities.
Functional perspective• Tools are classified according to their specific function.
Process perspective• Tools are classified according to process activities that
are supported. Integration perspective
• Tools are classified according to their organisation into integrated units.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 46
Functional tool classification
Tool type Examples
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems
Configuration management tools Version management systems, system building tools
Prototyping tools Very high-level languages, user interface generators
Method-support tools Design editors, data dictionaries, code generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 47
Activity-based tool classification
Specification Design Implementation Verificationand
Validation
Re-engineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processingtools
Method support tools
Prototyping tools
Configurationmanagement tools
Change management tools
Documentation tools
Editing tools
Planning tools
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 48
CASE integration
Tools• Support individual process tasks such as design
consistency checking, text editing, etc. Workbenches
• Support a process phase such as specification or design, Normally include a number of integrated tools.
Environments• Support all or a substantial part of an entire
software process. Normally include several integrated workbenches.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 49
Tools, workbenches, environments
Single-methodworkbenches
General-purposeworkbenches
Multi-methodworkbenches
Language-specificworkbenches
Programming TestingAnalysis and
design
Integratedenvironments
Process-centredenvironments
Filecomparators
CompilersEditors
EnvironmentsWorkbenchesTools
CASEtechnology
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 50
The Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
•Individuals and interactions over processes and tools •Working software over comprehensive documentation •Customer collaboration over contract negotiation •Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Kent Beck et alKent Beck et al
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 51
What is “Agility”?
Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team Organizing a team so that it is in control of
the work performed
Yielding … Rapid, incremental delivery of software
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 52
An Agile Process
Is driven by customer descriptions of what is required (scenarios)
Recognizes that plans are short-lived Develops software iteratively with a heavy
emphasis on construction activities Delivers multiple ‘software increments’ Adapts as changes occur
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 53
Extreme Programming (XP)
The most widely used agile process, originally proposed by Kent Beck
XP Planning• Begins with the creation of “user stories”• Agile team assesses each story and assigns a cost• Stories are grouped to for a deliverable increment• A commitment is made on delivery date• After the first increment “project velocity” is used to help
define subsequent delivery dates for other increments
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 54
Extreme Programming (XP)
XP Design• Follows the KIS principle• Encourage the use of CRC cards .• For difficult design problems, suggests the creation of “spike
solutions”—a design prototype• Encourages “refactoring”—an iterative refinement of the internal
program design XP Coding
• Recommends the construction of a unit test for a store before coding commences (Test driven development).
• Encourages “pair programming” XP Testing
• All unit tests are executed daily• “Acceptance tests” are defined by the customer and executed to
assess customer visible functionality
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 55
Extreme Programming (XP)
unit test continuous integration
acceptance testing
pair programming
Release
user stories values acceptance test criteria iteration plan
simple design CRC cards
spike solutions prototypes
refactoring
software incrementproject velocity computed
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 56
Scrum
Originally proposed by Schwaber and Beedle Scrum—distinguishing features
• Development work is partitioned into “packets”• Testing and documentation are on-going as the
product is constructed• Work occurs in “sprints” and is derived from a
“backlog” of existing requirements• Meetings are very short and sometimes conducted
without chairs• “demos” are delivered to the customer with the time-
box allocated
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 57
Scrum
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 58
Crystal
Proposed by Cockburn and Highsmith Crystal—distinguishing features
• Actually a family of process models that allow “maneuverability” based on problem characteristics
• Face-to-face communication is emphasized• Suggests the use of “reflection workshops” to
review the work habits of the team
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 59
Key points
Software processes are the activities involved in producing and evolving a software system.
Software process models are abstract representations of these processes.
General activities are specification, design and implementation, validation and evolution.
Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and agile development.
Iterative process models describe the software process as a cycle of activities.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 60
Key points
Requirements engineering is the process of developing a software specification.
Design and implementation processes transform the specification to an executable program.
Validation involves checking that the system meets to its specification and user needs.
Evolution is concerned with modifying the system after it is in use.
The Rational Unified Process is a generic process model that separates activities from phases.
CASE technology supports software process activities.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 61
Key Points
Agile development methodologies are suggested to deal with the continuously evolving requirements and the need of company to deliver software in a reasonable time.
Agile development accept changes on requirements and deal with them continuously. They focus on the product rather than the documents. They focus on customer satisfaction rather than contracts.
Dr Izzat M Alsmadi Edited from ©Ian Sommerville & others Software Engineering, Chapter 2 Slide 62
Key Points
The 2 factors that affect the software process is the stability of the requirements and the flexibility to change requirements. We need to keep a balance between those 2 factors because instable requirements causes a lot of troubles for the project management, while inflexible project may have problems with customers and come up to a complete failure.