Chap 4 Software Processes

©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1

Chap 4Software Processes


Objectives

l To introduce software process modelsl To describe three generic process models

and when they may be usedl To describe outline process models for

requirements engineering, software development, testing and evolution

l To explain the Rational Unified Process model

l To introduce CASE technology to support software process activities


Topics covered

l 4.1 Software process modelsl 4.2 Process iterationl 4.3 Process activitiesl 4.4 The Rational Unified Processl 4.5 Computer-aided software engineering


What is the software process?

l A software process is a set of activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language. Increasingly, however, new software is developed by extending and modifying existing systems and by configuring and integrating off-the-shelf software or system components.


The fundamental activities of software processes.

l Although there are many software processes, some fundamental activities are common to all software processes:• Software specification : the functionality of the software

and constraints on its operation must be defined.• Software design and implementation : the software to

meet the specification must be produced.• Software validation : the software must be validated to

ensure that it does what the customer wants.• Software evolution : the software must evolve to meet

changing customer needs. 64


4.1 The software process

l A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective, and thus provides only partial information about that process.


Generic software process modelsl The waterfall model

• Separate and distinct phases of specification development, validation and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing and so on.

l Evolutionary development• This approach interleaves (interchange) the activities of

specification, development and validation. An initial system is rapidly developed from abstract specifications. This is then refined with customer input to produce a system that satisfies the customer’s needs.

l Component-based software engineering• The system is assembled from existing components, the

focuses on integrating these components into a system rather than developing them from scratch.


l These generic process models are widely used in current software engineering practice. They are not mutually (interchange) exclusive and are often used together, especially for large systems development.

l Sub-system within a larger system may be developed using different approaches, but we should understand that, in practice, they are often combined.


4.1.1 Waterfall modelRequirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenanceFigure 4.1

the software life cycle


4.1.1 Waterfall model phases

1. Requirements analysis and definition• The system’s services, constraints and goals are

established by consultation with system users. They are then defined a detail system specification.

2. System and software design• Systems design process partitions the requirements to

either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.

3. Implementation and unit testing• Software design is realized (accomplish) as a set of

programs or program units. Unit testing involves verifying that each unit meets its specification.


Waterfall model phases

4. Integration and system testing• Individual program units or programs are integrated and

tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the Customer.

5. Operation and maintenance• This is longest life-cycle phase. The system is installed

and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered. 67


Waterfall model problems

l Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

l Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

l Few business systems have stable requirements.l The waterfall model is mostly used for large

systems engineering projects where a system is developed at several sites.


4.1.2 Evolutionary development

There are two fundamental types of evolutionary development:

l Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.

l Throw-away prototyping • Objective is to understand the system requirements. Should

start with poorly understood requirements to clarify what is really needed.


4.1.2 Evolutionary development

Concurrentactivities

ValidationFinal

version

Development Intermediateversions

SpecificationInitial

version

Outlinedescription

Figure 4.2Evolutionary development


4.1.2

l An evolutionary approach to software development is often more effective than the waterfall approach in producing system that meet the immediate needs of customers.

l From an engineering and management perspective, the evolutionary approach has two problems:• Process is not visible: Managers need regular deliverables

(report) to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.

• Systems are often poorly structured: Continual change tend to corrupt the software structure. incorporating (combine) software changes becomes increasingly difficult and costly.


4.1.2 Evolutionary developmentl Problems

• Lack of process visibility;• Systems are often poorly structured;• Special skills may be required.

l Applicability (suitable)

• For small or medium-size interactive systems;• For parts of large systems (e.g. the user

interface);• For short-lifetime systems.


l For small and medium-sized systems (up to 500,000 lines of code). I think that the evolutionary approach is the best approach to development.

l For large, complex, long-life-time systems, where different teams develop different part of the system, it is difficult to establish a stable system architecture using this approach. Which makes it hard to integrate contributions from the teams.


l For large systems, I recommend a mixed process that incorporates the best features of the waterfall and the evolutionary development models.

l This may involve developing a throwaway prototype to resolve uncertainties in the system specification, then re-implement the system using a more structured approach.

l Part of the system that are well understood can be specified and developed using a waterfall-based process.

l Other part of system, such as the user interface, which are difficult to specify in advance, should always be developed using an exploratory programming approach.


4.1.3 Component-based software engineering (CBSE)

l Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.

l This approach is becoming increasingly used as component standards have emerged.


4.1.3

l Process stages1. Component analysis;

• Given the requirements specification, a search is made for components to implement that specification. Usually, there is no exact match, and the components that may be used only provide some of the functionality required.

2. Requirements modification;• During this stage, the requirements are analysed using

information about the components that have been discovered. They are then modified to reflect (consider) the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions.


3. System design with reuse;• During this phase, the framework of the system is

designed or an existing framework is reused. The designers take into account the components that are reused and organize the framework to cater (supply) to this. Some new software may have to be designed if reusable components are not available.

4. Development and integration.• Software that cannot be externally procured is

developed, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity.


Reuse-oriented development

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

CBSE : Component-based software engineering

Figure 4.3component-based software engineering


Advantage and short-point of Component-based software engineering

l Has obvious advantage of reducing the amount of software to be developed and so reducing cost and risks.

l Leads to faster delivery of the software.l However, requirements compromises are inevitable

and this may lead to a system that does not meet the real needs of users.

l Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.70


4.2 Process iteration

l Change is inevitable in all large software projects.l The system requirements change as the business

procuring the system responds to external pressures.

l Management priorities change.l As new technologies become available designs and

implementation change. l This means that the software process is not a one-

off process; rather, the process activities are regularly repeated as the system is reworked in response to change requests.


4.2

l Two (related) approaches• Incremental delivery:

• The software specification, design and implementation are broken down into a series of increments that are each developed in turn.

• Spiral development: • The development of the system spirals outwards from

an initial outline through to the final developed system.


4.2

l The essence of iterative processes is that the specification is developed in the same time with the software developed.

l However, this conflicts with the procurement model of many organizations where the complete system specification is part of the system development contract.

l In the incremental approach, there is no complete system specification until the final increment is specified.

l So which large customers such as government agencies may find difficult to accommodate.


4.2.1 Incremental delivery

l The waterfall model of development requires customers for a system to commit (make sure) to a set of requirements before design begins and the designer to commit to particular design strategies before implementation.

l An evolutionary approach to development allows requirements and design decisions to be delayed but also leads to software that may be poorly structured and difficult to understand and maintain.

l Incremental delivery is an in-between approach that combines the advantages of these models. 71


In the incremental development process

l Customer identify, in outline, the services should be provided in the system.

l They identify which of the services are most important and which are least important to them.

l A number of delivery increments are then defined, with each increment providing a sub-set of the system functionality.

l The allocation (assign) of services to increments depends on the service priority with the highest priority services delivered first. 72


Incremental development

Validateincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validatesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem


4.2.1 Incremental development advantages

1. Customer do not have to wait until the entire system is delivered before they can gain value from it, the first increment satisfies their most critical requirements so they can use the software immediately.

2. Customer can use the early increments as prototypes and gain experience that informs their requirements for later system increments.


3. There is a lower risk of overall project failure. Although problems may be encountered in some increments, it is likely that most of them will be successfully delivered to the customer.

4. As the highest priority services are delivered first, and later increments are integrated with them, it is inevitable that the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most important parts of the system. 72


Incremental delivery problems

l Should be relatively small ( no more than 20,000 lines of code )

l Each increment should deliver some system functionality.


4.2.2 Spiral development

l Process is represented as a spiral rather than as a sequence of activities with backtracking.

l Each loop in the spiral represents a phase in the process.

l No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

l Thus the innermost loop might be concerned with system feasibility (practicability), the next loop with requirements definition, the next loop may with system designed.


Spiral model of the software process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

designCode

Unit testIntegration

testAcceptancetestService Develop, verify

next-level product

Evaluate alternatives,identify, resolve risks

Determine objectives,alternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


Spiral model sectors

Each loop in the spiral is split into four sectors:1. Objective setting

Specific objectives for that phase are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned.

2. Risk assessment and reduction (reduce) For each of the identified project risks, a detailed

analysis is carried out. Steps are taken to reduce the risk. For example, if there is risk that the requirements are inappropriate, a prototype system may be developed.


3. Development and validation• After risk evaluation, a development model for the system

is chosen. • If safety risks are the main consideration, development

based on Formal Transformations may be the most appropriate.

• If the main identified risk is sub-system integration then Waterfall model may be the most appropriate development model.

4. Planning• The project is reviewed and the next phase of the spiral is

planned.


Conclusion of Spiral development

l The main difference between the spiral model and other software process models is the explicit recognize of risk in the spiral model.

l For example, if the intention is to use a new programming language, a risk is that the available compilers are unreliable or do not produce sufficiently efficient object code. So risk in project problems such as schedule and cost overrun so risk minimization is very important project management activity.


l A cycle of the spiral begins by determine clear objectives. such as performance and functionality.

l Alternative ways of achieving these objectives and the constraints imposed on each of the loop.

l Each alternative is assessed or evaluate.l To resolve these risks by information-gathering

activities such as more detailed analysis, prototyping and simulation.

l Once risks have been assessed, some development is carried out, followed by a planning activity for the next phase of the process. 74


4.3 Process activities

1. Software specification2. Software design and implementation3. Software validation4. Software evolution


4.3.1 Software specification

l The process of establishing what services are required and the constraints on the system’s operation and development.

l Requirements engineering process1. Feasibility study;

• An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies, and whether the proposed system will be cost-effective from a business point of view and within existing budgetary constraints.


2. Requirements elicitation (draw out) and analysis;• This is a process of deriving the system requirements

through observation of existing systems, discussions with potential users and customer, task analysis and so on.

3. Requirements specification;• This activity will translating the information gathered during

the analysis activity into a set of requirement documents. 4. Requirements validation.

• This activity checks the requirements for consistency and completeness .in this stage, error in the requirements document may occur, it must be modified to correct these problems.


The requirements engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument


4.3.2 Software design and implementation

l The process of converting the system specification into an executable system.

l Software design• Design a software structure that realizes the

specification;l Implementation

• Translate this structure into an executable program;

l The activities of design and implementation are closely related and may be interleaved.


Design process activities

1. Architectural design The sub-system making up the system and their

relationships are identified and documented. 2. Abstract specification

For each sub-system, under its services an abstract specification and the constraints which will be produced.

3. Interface design For each sub-system, its interface with other sub-systems

is designed and documented. This interface specification must be clear,


4. Component design • Service are assigned to components and

interface of these components are designed.

5. Data structure design • To designed a detail and specified Data

structure for the implementation system.6. Algorithm design

• Detail designed and specified the algorithms that used to provide service.


The software design process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specificationAlgorithm

specification


Design activities

Design products


Structured methods

Structured methods is approach that rely on producing graphical models of the system， include a design process model， notations to represent the design, report formats, rules and design guidelines, it may support some or all of the following models of a system:


Structured methods

l Possible models1. Object model; that show the object classes used in the

system and their dependencies.

2. Sequence model; show how objects in the system interact when the system is executing.

3. State transition model; shows system states and the triggers condition for the transitions from one state to another.

4. Structural model; to documented the system components and their aggregations.

5. Data-flow model. to describe the model when data transformation is processed. 78


Programming and debugging

l Translating a design into a program and removing errors from that program.

l Programming is a personal activity - there is no generic programming process.

l Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.79


The debugging process

Locateerror

Designerror repair

Repairerror

Re-testprogram


4.3.3 Software validation

l Verification and validation (V & V) is intended to show that a system conforms (obedient) to its specification and meets the requirements of the system customer.

l Involves checking and review processes and system testing.

l System testing involves executing the system with test cases that are derived (gain) from the specification of the real data to be processed by the system.


The testing process

Componenttesting

Systemtesting

Acceptancetesting

Figure 4.9the testing process


Testing stagesl Component or unit testing

• Individual components are tested independently; • Components may be simple entities such as functions or

objects class. or may be related groupings of these entities.

l System testing• The components are integrated to make up the system.• This process is concerned with finding errors that result

from unanticipated (unexpected) interactions between component interface problems.

• It is also concerned with validating that the system meets its functional and non-functional requirements.

• For large systems, may be a multistage process where components are integrated to form sub-systems that are individually test before they are themselves integrated to form the final system.


Testing stages

l Acceptance testing• Testing with customer (real) data to check that

the system meets the customer’s needs.• It may reveal errors and omissions in the

system requirements definition because the real data exercise the system in different ways from the test data. 80

l Usually, system development and testing are interleave.

l Figure 4.10, explain how to connect with testing plain between the development and testing


Testing phases


Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

Service Acceptancetest

Systemintegration test

Sub-systemintegration test

Figure 4.10Testing Phases


Category of Acceptance Testing

l Alpha testing: custom system are developed for a single client. The Alpha testing process continues until the system developer and client agree that the delivered system is an acceptable implementation of the system requirements.

l Beta testing: when a system is to be marketed as a software product, this testing process called Beta testing, it involves delivering a system to a number of potential customers who agree to use that system. Then report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the system builders. 81


4.3.4 Software evolution

l Once a decision has been made to procure hardware, it is very expensive to make changes to the hardware design, however change can be made to software at any time during or after the system development.

l As requirements change through changing business circumstances, the software that supports the business must also evolve and change.


l Distinction between development and evolution (maintenance) is becoming increasingly irrelevant (unrelated) .

l Fewer and fewer software systems are now completely new systems,

l It is more realistic to think of software engineering as an evolutionary process. 82


System evolution

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

Figure 4.11System evolution


4.4 The Rational Unified Process(RUP)

l A modern process model derived from the work on the UML (Unified Modeling Language) and associated process.

l Normally described from 3 perspectives (viewpoint)• A dynamic perspective that shows phases over time;• A static perspective that shows process activities;• A practice perspective that suggests good practice.


RUP phases

l RUP is a phased model that identifies four discrete (separated) phases in the software process. However, unlike the waterfall model where phases are equated with process activities, the phase of RUP are more closely related to business rather than technical concerns.

l Include four stage as followed : (Dynamic view)1. Inception

• Establish the business case for the system. You should identify all external entities (people and system) that will interact with the system and define these interactions. You should use this information to assess the contribution that the system makes to the business. In case the contribution is minor then the project may be cancelled.


Dynamic view

2. Elaboration • Toe goals is Develop an understanding of the problem domain • Establish an architecture framework for the system• Identify key project risks when develop project plan• When completion of this phase, you have

Requirements model for the system (UML are specified) Architectural description and software development plan

3. Construction • In this phase is essentially concerned System design,

programming and testing.• Some systems are developed in parallel and integrated during

this phase.• When completion, you should have a working software system

and associated documentation that is ready for delivery to users.


4. Transition• Is final phase, concerned with moving the system

from the development environment to the user community and making it work in a real environment.

• This is a expensive and sometimes problematic activity, but is ignored in the most software process models. 83


Dynamic view

l RUP is Iteration activities and supported in two ways.• Each phase may be enacted (act) in an

interative way with the results (complete) developed incrementally.

• The whole set of phase may also be enacted an interative way incrementally too, as show by the looping arrow from Tasnsition to Inception in followed next Figure 4.12


RUP phase model

Phase iteration

Inception Elaboration Construction Transition


Workflows in the RUP description

l The static view of the RUP focuses on the activities during the development process.

l These are called workflows in RUP description• There are six core process workflows identified in

the process and three core supporting workflows.• The RUP has been designed in conjunction with

the UML (Unified Modeling Language)• The workflows show in followed figure 4.13


Static workflows (static view)

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.


RUP describes good SE practice

Six fundamental best practices are recommended:1. Develop software iteratively

• Plan increments of the system based on customer requirement

• Develop and deliver the highest priority system features early in the development process.

2. Manage requirements• Explicitly the customer’s requirements document• keep track of change the requirements• Analyse the impact of changes on the system before

accepting them.


3. Use component-based architectures• Transfer the system structure into components

4. Visually model software• Use graphical UML models to show static and dynamic

view of the software system.5. Verify software quality

• Ensure that the software meets the organization quality standards.

6. Control changes to software• Manage changes to the software using a change

management system and configuration management procedures and tools 84


4.5 Computer-aided software engineering (CASE)

l Computer-aided software engineering (CASE) is software to support software development and evolution processes activities.

l The activities include such requirements engineering, design, program development and testing.

l So case tool include design editors, data dictionaries, compilers, debuggers, system building tools and so on.


l Case technology provides software process support by automating some process activities and by providing information about the software that is being developed.


l Example of Activity that can be automated : 1. Graphical editors for system model

development;2. Data dictionary that holds information about the

entities and relations in a design;3. Generation of user interfaces from a graphical

interface description that is created interactively by the user;

4. Program debugging through the provision of information about an executing program;

5. Automated translators to generate new versions of a program from an old version of a programming, language such as COBOL. 85


Case technology

l Case technology has led to significant improvements in the software process, in fact, the improvements have been achieved 40% saved. However, it did not generate huge savings in software process costs.


l CASE are limited by two factor :1. Software engineering requires creative thought

• existing CASE system can easily automate routine activities

• But try to use artificial intelligence technology to provide support for design have not been successful.

2. Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.


CASE technology is now mature

l In the market the CASE tools and workbenches are available from a wide range of suppliers.


CASE classification

Classification helps us understand the different types of CASE tools and their support for process activities.

1. Functional perspective• Tools are classified according to their specific

function.2. Process perspective

• Tools are classified according to process activities that are supported.

3. Integration perspective• Tools are classified according to their organisation

into integrated units.


Figure 4.14

l In figure 4.14, according to functionality to classified the case tool.


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

Figure 4.14


Figure 4.15

l It is the other way to classified to show the each step of development when use CASE tools.


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

Figure 4.15


CASE integration

The other classified way for CASE is depending on it can support the how wide of software process

l Tools• Support individual process tasks such as design

consistency checking, text editing, etc.l Workbenches

• Support a process phase such as specification or design, Normally include a number of integrated tools.

l Environments• Support all or a substantial part of an entire software

process. Normally include several integrated workbenches.


Tools, workbenches, environments

Single-methodworkbenches

General-purposeworkbenches

Multi-methodworkbenches

Language-specificworkbenches

Programming TestingAnalysis anddesign

Integratedenvironments

Process-centredenvironments

FilecomparatorsCompilersEditors

EnvironmentsWorkbenchesTools

CASEtechnology


Key points

1. Software processes are the activities involved in producing and evolving a software system.

2. Software process models are abstract representations of these processes.

3. General activities are specification, design and implementation, validation and evolution.

4. Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.

5. Iterative process models describe the software process as a cycle of activities.


Key points

6. Requirements engineering is the process of developing a software specification.

7. Design and implementation processes transform the specification to an executable program.

8. Validation involves checking that the system meets to its specification and user needs.

9. Evolution is concerned with modifying existing system to meet new requirements. This is becoming the normal approach to software development for small and medium-sized systems.

More informationsl Computer Aided Software Engineering (CASE tool) Computer Aided Software Engineering

tools offer many benefits for developers building large-scale systems. As spiralling user requirements continue to drive system complexity to new levels, enabling us to abstract away from the entanglement of source code, to a level where architecture and design become more apparent and easier to understand and modify. The larger a project, the more important it is to use a case tool in software development.

As developers interact with portions of a system designed by their colleagues, they must quickly seek a subset of classes and methods and assimilate an understanding of how to interface with them. In a similar sense, management must be able, in a timely fashion and from a high level, to look at a representation of a design and understand what's going on. For these reasons, CASE tools coupled with methodologies give us a way of representing systems too complex to comprehend in their underlying source code or schema-based form.

Select Business Solutions has been developing and building these CASE tools since the late 1980s, as well as developing processes and methods to support high quality application development.Solution Breakdown Select Solution Factory a Business Process Modeling - BPM, a Unified Modeling Language - UML modeling tool, and Data Modeling CASE Tool Select Scope Manager a eXtreme Programming and Agile Modeling CASE Tool Select SSADM a Structured Systems Analysis and Design Methodology CASE Tool Select Yourdon a real time CASE Tool supporting the Yourdon, Hatley-Pirbhai and Ward-Mellor real-time extensions.

http://www.selectbs.com/products/select-solution-factory.htm

http://www.selectbs.com/products/select-scope-manager.htm

http://www.selectbs.com/products/select-ssadm.htm

http://www.selectbs.com/products/select-yourdon.htm


10. The Rational Unified Process is a modern generic process model that is organised into phases (inception, elaboration, construction and transition “Dynamic perspective”) but that separates activities (requirements, analysis and design, etc. ”Static perspective”)

11. CASE technology provides automated supports for software process. CASE tools support individual process activities; workbenches support a set of related activities; environments support all or most software process activities.


End week 6


Week 8 testing

l Could you explain how many Software process models in this chapter, and detail explain them?


Ans

l p65


Exercises 4.1

l giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:• A system to control anti-lock braking in a car.

• Anti-lock braking system: Safety-critical system so method based on formal transformations with proofs of equivalence between each stage, therefore waterfall model is appropriate.


• A virtual reality system to support software maintenance : • Virtual reality system, the system whose requirements

cannot be predicted in advance so exploratory programming model is appropriate. (4.1.2) 68

• A university accounting system that replaces an existing system :• System whose requirements should be stable

because of existing system therefore waterfall model is appropriate.


• An interactive system that allows railway passengers to find train times from terminals installed in stations.• System with a complex user interface but which must

be stable and reliable. Should be based on throw-away prototyping to find requirements then either incremental development or waterfall model. (4.1.2) 68


Exercises 4.2

l Explain why programs that are developed using evolutionary development are likely to be difficult to maintain.• From an engineering and management perspective, the

evolutionary approach has two problems:• The process is not visible: Managers need regular

deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.

• Systems are often poorly structured: continual change tends to corrupt the software structure. Incorporating software changes becomes increasingly difficult and costly.


Exercises 4.5

l Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process.• User requirements (high-level abstract requirements): are

statement, in a natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate.

• System requirements (detailed description of what the system should do, sometimes call a functional specification): set out the system’s functions, services and operational constraints in detail. The system requirements document should be precise (exact). It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.


Exercises 4.6

l Describe the main activities in the software design process and the outputs of these activities. Using a diagram, show possible relationships between the outputs of these activities.


Answer 4.6

1. Architectural design2. Abstract specification3. Interface design4. Component design5. Data structure design6. Algorithm designThe diagram as show on page 77, 4.3.2 figure 4.7


Exercises 4.8

l Design a process model for running system tests and recording their results.

Running program Recording result

Error occur

Input new data for test

Yes

No

System stop


Exercises 4.9

l Explain why a software system that is used in real-world environment must change or become progressively less useful.• Systems must change because as they are installed in an

environment the environment adapts to them and this adaptation naturally generates new/different system requirements. Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence (result) of changes to the business, business goals and business policies. Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful


Exercises 4.10

l Suggest how a CASE technology classification scheme may be helpful to managers responsible for CASE system procurement• A classification scheme can be helpful for system

procurement because it helps identify gaps in the CASE tool coverage in an organization. Procurement may be aimed at filling these gaps. Alternatively, a classification scheme may be used to find tools which support a range of activities - these may represent the most cost effective purchases if funds are limited.


Exercises 4.12

l Historically, the introduction of technology has caused profound (deep) changes in the labour market and, temporarily at least, displaced (replace) people from jobs. Discuss whether the introduction of advanced CASE technology is likely to have the same consequences for software engineers. If you don’t think it will, explain why not. If you think that it will reduce job opportunities, is it ethical (moral) for the engineers affected to passively (inactive) or actively resist the introduction of this technology?


l Ans: • There are obviously (easy understand) different views

here and a lot depends on the development of CASE technology in the future. A major difference between the introduction of CASE technology and, for example, the introduction of CAD technology which made draftsmen redundant, is that the routine elements in the design and development of software are relatively minor parts of the whole development process. Therefore, savings are not that large. However, if AI (Artificial Intelligent) technology develops so that truly intelligent tools can be developed than, obviously, this situation will change.

• By the way, new technology will change some job to become redundant, but in the same time, it will create new opportunity and new jobs for the new century.


End

Chap 4 Software Processes

Documents