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)


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


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


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).


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.


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.)


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/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.


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.


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


11/54


• 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.


12/54


• 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.


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


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.


15/54


• 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.


16/54


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.


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.


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.


19/54

The Waterfall ModelThe Waterfall Model – – VV--ModelModel

• A variation of thewaterfall model.

• Emphasises “qualityassurance actions”.


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


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.


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.


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.


24/54

ReuseReuse--oriented SEoriented SE


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.


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.


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.


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.


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.


30/54


• 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.


31/54


Advantages:

• Improved system usability.

• A closer match to users’ real needs.• Improved design quality.• Improved maintainability.• Reduced development effort.


32/54


• Process

Establish

prototypeobjectives

Define

prototypefunctionality

Develop prototype Evalua te prototype

Prototyping plan

Outlinedefinition

Executa b le prototype

Evalua tionrepor t


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.


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.


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


36/54



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.


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.


39/54


CON:• Increments should be relatively small (


40/54


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.


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.


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.


43/54

The Spiral ModelThe Spiral ModelDetermine objectives,alternatives and constraints

Evaluate alternatives,identify, resolve risks

Develop, verify next level product

Plan next phase


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.


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.


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.


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.


48/54


• 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.


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.


50/54


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.


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.


52/54

Formal MethodsFormal Methods

INVARIANTauction : POW(AUCTION) &registered : 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


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.


54/54

THANK YOUTHANK YOU

• Question?• Next :

– Software Process Activities

Software Process - Topic 2Lecturer 2 - Software Process.pdf

Documents

Transcript of Software Process - Topic 2Lecturer 2 - Software Process.pdf