Software Process - Topic 2Lecturer 2 - Software Process.pdf
-
Upload
nazreen-di-awan-biru -
Category
Documents
-
view
228 -
download
0
Transcript of Software Process - Topic 2Lecturer 2 - Software Process.pdf
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
1/54
TK2013
Software Engineering Methodology
Topic 2:Topic 2:
SoftwareSoftware ProcessProcess (I)(I)
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
2/54
ContentsContents• Software Process• Software Process Model• Generic Software Process Models:
– The Waterfall Model
– Incremental Development – Reuse-oriented (component-based) Software Engineering
• Other Process Models: – Software Prototyping – Incremental Delivery – Boehm’s Spiral Model – Rational Unified Process – Formal Methods
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
3/54
IntroductionIntroduction• Software Engineering is a layered technology.
• It encompasses a process , methods and tools , andbased on a quality aspect.
Tools
Methods
Process
A Quality Aspect
How to build thesoftware (i.e. tasks)
Automated or semi-automatedsupport for the process &
methods
Organisation’scommitment on quality
The GLUEThe GLUE
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
4/54
RECAPRECAPWhat are the attributes of good software?What are the attributes of good software? – –
Quality AspectQuality AspectThe software should deliver the required functionality andperformance (efficient) to the user and should be maintainable ,dependable and acceptable .
• Efficiency (Performance) – Software should not make wasteful use of system resources
• Maintainability – Software must evolve to meet changing needs
• Dependability (Reliability) – Software must be trustworthy
• Acceptability (Usability) – Software must be accepted by the users for which it was designed:
understandable, usable and compatible with other systems
(portability).
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
5/54
What is Software Process?What is Software Process?
• A set of activities that leads to the production of asoftware product or system. – Scratch (from nothing to something) – Evolutionary (portion-by-portion)
• Most software is developed by: – Extending and modifying existing systems. – Configurating and integrating “off-the-shelf” software or
components.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
6/54
What is Software Process?What is Software Process?• Software processes are intellectual and creative practice.
Thus, they are complex.
– Rely on people making good judgments and decisions.
• No ideal software process. – Processes are exploited to meet the capabilities of people in
an organisation and the specific characteristics of thesystem.
• E.g. Critical systems need robust processes; Business systems mayneed “quick and dirty” or agile process.
• The objective of any software processes is high quality (i.e.on time, less cost, error-free product, less rework etc.)
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
7/54
What is Software Process?What is Software Process?• Fundamental (common) activities in any software
processes: – Specification
• Define the functionality & constraints of the software.
– Design & Implementation (Development)• Propose the structure/architecture and develop the software
based on the specification.
– Validation
• Developed software is checked to ensure it does what customerwants.
– Evolution• Running software must evolve eventually to meet the changing
customer needs.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
8/54
What is Software Process?What is Software Process?• Supporting activities
– Software project management• Assess progress against the project plan; take actions to maintain schedule.
– Formal technical reviews• Assess intermediate products to uncover and remove errors.
– Software quality assurance• Define and conduct activities to ensure software quality. – Software configuration management
• Manage the effect of changes throughout the process. – Work product preparation and production
• Create work products such as models, documents, logs etc.
– Reusability management• Defines criteria and strategy to reuse components. – Measurement
• Define and collect process, product and project measures for improvement. – Risk management
• Assess risks that may affect the outcomes of the project or quality of theproduct.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
9/54
What is Software Process?What is Software Process?• Plan-driven processes are processes where all of the process
activities are planned in advance and progress is measuredagainst this plan.
• In agile processes, planning is incremental and it is easier tochange the process to reflect changing customerrequirements.
• In practice, most practical processes include elements of bothplan-driven and agile approaches.
• There are no right or wrong software processes.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
10/54
What is a Software Process Model?What is a Software Process Model?
• A software process model is an abstractrepresentation of a process.
• It presents a description of a process from someparticular perspectives (i.e. engineering-oriented;user-oriented; reusability etc.).
• There are 3 generic process models: – Waterfall (the oldest) – Incremental/Iterative/Evolutionary Development – Reuse-oriented/Component-based software engineering
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
11/54
What is a Software Process Model?What is a Software Process Model?
• The waterfall model – Plan-driven model. Separate and distinct phases of specification and
development.
•Incremental development – Specification, development and validation are interleaved. May be
plan-driven or agile.
• Reuse-oriented software engineering – The system is assembled from existing components. May be plan-
driven or agile.
• In practice, most large systems are developed using a processthat incorporates elements from all of these models.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
12/54
What is a Software Process Model?What is a Software Process Model?
• There are many variants of these generic models. – E.g. Formal development (waterfall-like) produces a formal
specification that is refined through several stages
(incremental), which later can be executed directly ascode.
• The models are not mutually exclusive. – In practice, they are combined and used together
especially for large projects.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
13/54
The Waterfall ModelThe Waterfall Model
Requirements
definition
System and software design
Implementa tionand unit testing
Integration and system testing
Oper ation and
maintenanceOperation andmaintenance
Implementationand unit testing
Integration andsystem testing
Requirementsdefinition
System andsoftware design
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
14/54
The Waterfall ModelThe Waterfall Model• Requirements analysis and definition
– Establish system’s services, constraints and goals.
– They are defined in detail as a system specification.
• System and software design – Establish an overall system architecture.
– Distinguish hardware and software requirements.
– Describe the system abstractions and their relationships.
• Implementation and unit testing – Realise the design as a set of programs.
– Verify each program whether it meets the specification.
• Integration and system testing – Individual programs are integrated and tested as a complete system.
• Operation and maintenance – The developed system is installed and put into use.
– Errors found are corrected; improve the implementation; enhance the system when new
requirements are discovered.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
15/54
The Waterfall ModelThe Waterfall Model
• The stages are overlap and feed information to eachother. – Design stage may start when the specification is almost
complete. – Specifications are used for design and testing etc. – Specification errors can be found in design; design problems
can be detected during coding etc.
• Involves a sequence of iterations of activities.
• Making changes may involve repeating/revisitingprevious stages.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
16/54
The Waterfall ModelThe Waterfall Model
PRO:
• Clear-cut (defined) stages. – Design should not start if specification is not ready etc.
• Each phase produces one or more documents thatmust be “signed-off”. – It fits with other engineering process models.
– Managers can view progress and react accordingly.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
17/54
The Waterfall ModelThe Waterfall ModelCON:
• Inflexible partitioning of the project into distinctstages (i.e. one phase has to complete before moving
onto the next phase) – Commitments must be made at early stages.
• Customers will not see the product until it is
complete - may contain errors.
• Requirements must be stated explicitly. – Difficult to respond to changing customer requirements.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
18/54
The Waterfall ModelThe Waterfall ModelWhen to use?• It is only appropriate when:
– The product development starts from scratch and “full-blown”. – The requirements are well-understood.
– Changes are fairly limited during the design process.
• Few business systems have stable requirements (e.g.government-related projects).
• The waterfall model is mostly used for large systemsengineering projects (i.e. different teams work on differentmodules, developed at several sites). – The plan-driven nature of the waterfall model helps coordinate the
work , thus more control and manageable process.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
19/54
The Waterfall ModelThe Waterfall Model – – VV--ModelModel
• A variation of thewaterfall model.
• Emphasises “qualityassurance actions”.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
20/54
Incremental DevelopmentIncremental Development• The idea:
1) Develop an initial implementation.2) Expose it to users for review and comments.3) Refining it through many versions until complete.
Concurrentactivities
ValidationFinal
version
DevelopmentIntermedia te
versions
SpecificationInitial
version
Outlinedescription
Intermediate
versions
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
21/54
Incremental DevelopmentIncremental DevelopmentPRO:• The cost of accommodating changing customer
requirements is reduced. – The amount of analysis and documentation that has to be redone is
much less than is required with the waterfall model.
• It is easier to get customer feedback on the developmentwork that has been done. – Customers can comment on demonstrations of the software and see
how much has been implemented.
• More rapid delivery and deployment of useful software tothe customer is possible. – Customers are able to use and gain value from the software earlier
than is possible with a waterfall process.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
22/54
Incremental DevelopmentIncremental DevelopmentCON:
• Lack of process visibility. – Too quickly means not effective to produce documents so
often - Managers normally need reports/deliverables tomeasure progress.
• Systems are often poorly structured. – Continual changes tends to corrupt the system structure.
– Incorporating further software changes becomesincreasingly difficult and costly.
• Special skills (e.g. languages for rapid prototyping)may be required.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
23/54
Incremental DevelopmentIncremental Development
When to use?
• For small or medium-size interactive systems: – Customers feedback is important; – Increments are easier to manage.
• For parts of large systems: – Critical parts of the system (which requirements are normally well
understood) may still need conventional approaches such as waterfall.
– Can be used for parts which requirements are difficult to specify inadvance (e.g. the user interface).
• For short-lifetime systems. – Small and homogeneous teams.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
24/54
ReuseReuse--oriented SEoriented SE
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
25/54
ReuseReuse--oriented SEoriented SE• Based on systematic reuse where systems are
integrated from existing components or COTS(Commercial-off-the-shelf) systems.
• Process stages – Component analysis; – Requirements modification; – System design with reuse; – Development and integration.
• Reuse is now the standard approach for buildingmany types of business system.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
26/54
ReuseReuse--oriented SEoriented SETypes of software components
• Web services that are developed according to servicestandards and which are available for remoteinvocation.
• Collections of objects that are developed as apackage to be integrated with a component
framework such as .NET or J2EE.
• Stand-alone software systems (COTS) that areconfigured for use in a particular environment.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
27/54
Coping with ChangeCoping with Change• Change is inevitable in all large software projects.
– Business changes lead to new and changed systemrequirements
– New technologies open up new possibilities for improvingimplementations
– Changing platforms require application changes
• Change leads to rework so the costs of changeinclude both rework (e.g. re-analysing requirements)as well as the costs of implementing newfunctionality.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
28/54
Coping with ChangeCoping with Change• Change avoidance , where the software process includes
activities that can anticipate possible changes beforesignificant rework is required. – E.g. A prototype system may be developed to show some key features
of the system to customers.
• Change tolerance , where the process is designed so thatchanges can be accommodated at relatively low cost. – This normally involves some form of incremental development and
delivery .• Proposed changes may be implemented in increments that have not yet
been developed.
• Else, then only a single increment (a small part of the system) may havebe altered to incorporate the change.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
29/54
Software PrototypingSoftware Prototyping
• A prototype is an initial version of a system usedto demonstrate concepts and try out designoptions.
• A prototype can be used in: – The requirements engineering process to help with
requirements elicitation and validation;
– In design processes to explore options and develop auser interface design;
– In the testing process to run back-to-back tests.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
30/54
Software PrototypingSoftware Prototyping
• May be based on rapid prototyping languages ortools.
• May involve leaving out functionality. – Prototype should focus on areas of the product that
are not well-understood;
– Error checking and recovery may not be included inthe prototype;
– Focus on functional rather than non-functionalrequirements such as reliability and security.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
31/54
Software PrototypingSoftware Prototyping
Advantages:
• Improved system usability.
• A closer match to users’ real needs.• Improved design quality.• Improved maintainability.• Reduced development effort.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
32/54
Software PrototypingSoftware Prototyping
• Process
Establish
prototypeobjectives
Define
prototypefunctionality
Develop prototype Evalua te prototype
Prototyping plan
Outlinedefinition
Executa b le prototype
Evalua tionrepor t
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
33/54
Software PrototypingSoftware PrototypingThrow-away prototypes
• Prototypes should be discarded after developmentas they are not a good basis for a production system:
– It may be impossible to tune the system to meet non-functional requirements;
– Prototypes are normally undocumented;
– The prototype structure is usually degraded through rapidchange;
– The prototype probably will not meet normalorganisational quality standards.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
34/54
Incremental DeliveryIncremental Delivery• An “iterative” approach of the waterfall model.
• Rather than deliver the system as a single delivery, thedevelopment and delivery is broken down into increments
with each increment delivering part of the requiredfunctionality.
• User requirements are prioritised and the highest priorityrequirements are included in early increments.
• Once the development of an increment is started, therequirements are frozen though requirements for laterincrements can continue to evolve.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
35/54
Incremental DeliveryIncremental Delivery
C o m mu 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 ns t r u c t i o n
D e pl o y m e n t
d e l i v e r yf e e d b a c k
ana lys i s
des ign code
t e s t
increment # 1
increment # 2
delivery of1st increment
delivery of2nd increment
delivery ofn t h increment
increment # n
project calendar time
C o m mu 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 ns t r u c t i o n
D e pl o y m e n t
d e l i v e r y
f e e d b a c k
ana lys i s
des ign code
t e s t
C o m m un i c a t i o nP l a n n i n g
M o d e l i n g
C o ns t r u c t i o nD e pl o y m e n t
d e l i v e r y
f e e d b a c k
ana lys i s
des igncodet e s t
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
36/54
Incremental DeliveryIncremental Delivery
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
37/54
Incremental Development & DeliveryIncremental Development & Delivery
• Incremental development – Develop the system in increments and evaluate each increment before
proceeding to the development of the next increment;
– Normal approach used in agile methods;
– Evaluation done by user/customer proxy.
• Incremental delivery – Deploy an increment for use by end-users; – More realistic evaluation about practical use of software;
– Difficult to implement for replacement systems as increments haveless functionality than the system being replaced.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
38/54
Incremental DeliveryIncremental DeliveryPRO:
• Customer value can be delivered with each increment sosystem functionality is available earlier.
• Early increments act as a prototype to help elicitrequirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive themost testing.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
39/54
Incremental DeliveryIncremental Delivery
CON:• Increments should be relatively small (
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
40/54
Incremental DeliveryIncremental Delivery
When to use?
• It is particularly useful when staffing is limited/unavailable. – Early increments can be developed with fewer people. – When satisfactory, more additional staff can be added for later stages.
• When certain parts of the system are “under development”. – Increments are planned based on the availability of the parts.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
41/54
Incremental Development/DeliveryIncremental Development/Deliveryversus Prototypingversus Prototyping
• Incremental development/delivery – Aim: To work with customers and evolve a final system from an initial
outline specification.
– Should start with well-understood requirements and add new featuresas proposed by the customers.
• Throw-away prototyping – Aim: To understand the system requirements.
– Should start with poorly understood requirements to clarify what isreally needed.
– Once the requirements are understood, the prototype may be “thrown-away” and the actual development starts.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
42/54
The Boehm’s Spiral ModelThe Boehm’s Spiral Model• 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 stages 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.
• Encourage people think about iteration in software processes andintroducing the risk-driven approach to development.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
43/54
The Spiral ModelThe Spiral ModelDetermine objectives,alternatives and constraints
Evaluate alternatives,identify, resolve risks
Develop, verify next level product
Plan next phase
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
44/54
The Spiral ModelThe Spiral Model• 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.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
45/54
The Spiral ModelThe Spiral ModelPRO:• Incorporates “prototyping” and “iterative” approach.
• Software evolves as the process progresses. – Developers and customers understand better and react to risks at each
evolutionary level.
• Can be adapted throughout the life cycle. – One cycle for each phase.
CON:• Difficult to convince users (in contracts) that the process is
controllable.
• Require risk managers/experts to succeed. – If a major risk is not uncovered and managed, problems occur.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
46/54
The Rational Unified ProcessThe Rational Unified Process• A modern generic process derived from the work on the UML
and associated process.
• Brings together aspects of the 3 generic process modelsdiscussed previously. – A “use-case driven, architecture-centric, iterative and incremental” software
process (Jacobson, 1999).
– Recognises the importance of customer communication and role of softwarearchitecture .
• 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 practice.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
47/54
The Rational Unified ProcessThe Rational Unified Process
• In-phase iteration – Each phase is iterative with results developed incrementally.
• Cross-phase iteration – The whole set of phases may be enacted incrementally.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
48/54
The Rational Unified ProcessThe Rational Unified Process
• Inception – Establish the business case for the system.
• Elaboration
– Develop an understanding of the problem domain and thesystem architecture.
• Construction – System design, programming and testing.
• Transition – Deploy the system in its operating environment.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
49/54
The Rational Unified ProcessThe Rational Unified ProcessGood Practice:
• Develop software iteratively – Plan increments based on customer priorities and deliver
highest priority increments first.
• Manage requirements – Explicitly document customer requirements and keep track
of changes to these requirements.
• Use component-based architectures – Organise the system architecture as a set of reusable
components.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
50/54
The Rational Unified ProcessThe Rational Unified Process
Good Practice:
• Visually model software – Use graphical UML models to present static and dynamic
views of the software.
• Verify software quality – Ensure that the software meet’s organizational quality
standards.
• Control changes to software – Manage software changes using a change management
system and configuration management tools.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
51/54
Formal MethodsFormal Methods
• A set of activities that leads to formal mathematicalspecification of software.
• It enables engineers to specify , develop and verify asoftware by applying a rigorous, mathematicalnotation e.g. VDM, Z, B.
• Ambiguity, incompleteness and inconsistency can bediscovered and corrected through mathematicalanalysis.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
52/54
Formal MethodsFormal Methods
INVARIANTauction : POW(AUCTION) ®istered : POW(USER) &reserve : auction --> NAT1 &
highest_bid : auction --> NAT &seller : auction --> registered &highest_bidder : auction +-> registered &balance : registered --> NAT &name : registered >-> STRINGS &password : registered --> STRINGS &admin_amount : NAT &
auction_state : auction --> AUCTION_STATE &user_state : registered --> USER_STATE &!(aa).(aa : auction => (seller(aa) /= highest_bidder(aa) ))
OPERATIONS
placeBid(uu,aa,bb) =PRE uu : USER & aa : AUCTION & bb : NAT1THENSELECT
aa : auction &
aa : dom(highest_bidder) &uu /= seller(aa) &uu /= highest_bidder(aa) &bb > highest_bid(aa) &bb balance(highest_bidder(aa)) +highest_bid(aa)}END
END;
• Example: B Method
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
53/54
Formal MethodsFormal MethodsPRO:• Offers the promise of defect-free software.
CON:
• The development of formal models is currently quitetime consuming.
• Extensive training is required before applying themethod.
• Difficult to use the models as a communicationmechanism for non-technical end users.
-
8/17/2019 Software Process - Topic 2Lecturer 2 - Software Process.pdf
54/54
THANK YOUTHANK YOU
• Question?• Next :
– Software Process Activities