Software engineering

SOFTWARE ENGINEERING K.A.Mohamed Riyazudeen
15UCSC52 Assistant Professor,
Department of CS (SF).
1
V SEMESTER
SOFTWARE ENGINEERING
UNIT I
 Introduction
 What is software
 What is software engineering
 Software process
 Software process model
 Software engineering methods
 Emergent System properties
 System engineering
 System requirements
 System design
 System modeling
 sub system development
 System integration
 System evolution
 System decommissioning
 System procurement
 Software processes: Software process models:
1. The waterfall model
2. Evolutionary development
3. Spiral development
 CASE

2
What is software?
 Software is a set of program, associated document and the data that is needed to make
this program operate correctly.
Software Product:-
 It is a software system deliver to the customer with the documentation which describes
how to install and use the system.
 Software product can be classified as follow
Generic
Customized or Bespoke
Generic product:-
 There are stand alone systems which are produced by development organization sold on
the open market to any customer who is able to buy them.
 E.g.: Operating system, MS Office
Customized or Bespoke:-
 These are system which is developed for a particular customer.
 The software is developed specially for that customer by some contractor.
 E.g.: Railway Reservation, Banking
Software Product Attributes
 The following are some of the attributes
Maintainability
Dependability
Efficiency
Usability
Maintainability:-
 Software System should be developed in such a way that it may evolve to meet changing
the need of customer.
 This is an important attributes because in today’s world changes are unavoidable.

3
Dependability:-
 One software system is always depending on some other software system Hence, A
failure in one software system should not make any physical or economical damage to
other system.
 It means that if one system is not working properly another system will not be affected.
Efficiency:-
 System resources such as CPU time and memory space should not be wasted.
 The system should fake less time for processing and must give response in a fast
manner.
Usability:-
 The software should have an appropriate user interface and adequate documentation.
Software Process:-
 Software is set of activities and related results to produce a software product.
 All activities in the software process are carried out by the software engineers.
 There are four fundamental activities
Software Specification
Software Development
Software validation
Software Evolution
Software Specification:-
 The functionality of a software and limitation on the operation of the software specified.
 That is list out what the software will do? And What the Software will not do?
Software development:-
 The software development is started by writing programs in a way that software must
meet the particular specification.
Software Validation:-
 The software must be tested or validated to ensure that our software product is
producing what the customer wants.

4
Software Evolution:-
 The software must be developed such the way that as went a customer requirement our
software adapt with a change.
Emerged system properties
 The emerged system properties are the system attributes.
 The value of these emergent properties can’t in advance.
 They can be only measure after integrating all sub systems.
 They are two types of emergent system properties are:
Functional properties
Non Functional property
Functional properties:-
 The functional properties will appear when all the part of the system to work together.
Non Functional properties:-
 Non functional properties to relate to the behavior of the system it needs operational
environment.
 These are very important and critical for any computer based system.
 If non functional system properties are not defined clearly then the system will be UN
useable.
 Some of the non functional emergent system properties are
Reliability
Performance
Safety
Security
 As for reliability is constrain three factor influencing the reliability of a system
Hardware Reliability
Software Reliability
Operator Reliability
Hardware Reliability:-
 Hardware reliability means how often the hardware will fail and how much time takes
to repair to this hardware.

5
Software Reliability:-
 Software Reliability means how a software component produces an incorrect result,
whether the software is continuously working even after producing an incorrect result.
Operator Reliability:-
 The operator of a system will make an error. So that how reliable the operator is?
System and their Environment
 No system is working independently all system are dependent and existing in an
environment.
 Certainly environment does affect the functioning and performance of an every system.
 The factor these are affecting system & design are
Process changes
Job changes
Organization changes
Process changes:-
 It means the changes in organization make any significant change.
 Weather training is occur; the user are resisting the system the new system will make
job losses.
Job changes:-
 The system will make the change the user.
 De-skill or more skill our system will make a working style of manager are not
Organizationchanges:-
 Our system will change political power of the organization.
System engineering process
Introduction:-
 It is the inter-disciplinary activity.
 The software to be developed must be flexible.
 So that many unexpected problems to be solved only by the software engineer.

6
 Much software is failed because software engineers are not able to enhance the
software capability without increase the hardware cost.
 Different activity involved in system engineering process is
System Requirement Definition
System Design
Sub system Development
System Integration
System Installation
System operation
System Evolution
System Decommissioning
System Requirement Definition
 In consultation with system customer and end users.
 The system engineer has to design the system requirement.
 There are three types of
Abstract function requirement
System properties
Characteristic system must not exhibit
Abstract functionrequirement:-
 The basic function of the system are define at an abstract level (Not in a detail level)
Systemproperties:-
 Non functional emergent property is described here.
Characteristic system must not exhibit:-
 System designer must clearly specify that what the system should not do.
System Design
 It means assign system functionality two different component.
 Different activity involve in this process are
Partition Requirement
Identify Subsystem

7
Assign Requirement to Subsystem
Specify Subsystem functionality
Define Subsystem Interface
Partition Subsystem:-
 Different subsystem to meet the requirement are identify individually or collectively.
 Sub system identification has been affected by the organization process or outside
factor.
Assign Requirement to Subsystem:-
 It is not an easy job. Because there is no clear match between the requirement and
subsystem.
 E.g.: If we purchase COTS then requirement most is modified.
Specify Subsystemfunctionality:-
 At the state, relationship between subsystem are identify function of each subsystem are
specified.
Define SubsystemInterface:-
 Link between one sub systems is called interface.
 During development, when interface are clearly defined then parallel development can
be possible.
Subsystem Development
 During this state identify subsystem design are implemented.
 If a subsystem is a software system, then subsystem are developed from scratch (new).
Some of the sub system may be COTS.
 Different subsystem is usually developed in parallel, when system needs more hardware
engineering than manufacturing is very expensive.
System Integration
 In system integration indecently developed subsystem are combine together to make
complete system Integration can be performed by two approaches.
Big Bang Approach

8
Incremental Approach
Big Bang Approach:-
 In big bang approach all the sub system are integrated at the same time.
Incremental Approach:-
 In incremental approach sub system are integrated one at a time.
System Installation
 During system installation the entire system is put it into the environment that is at the
customer side.
 During these stage the following may be appear
 The environment in which the system is to be installed is not the same as before.
 Potential user of the system may oppose the new system.
 Our new system may have two co-exists with an existing system. If organization a
satisfied with the new system, then only old system will be stopped.
 Physical installation problem may also be appearing.
System Operation
 System operation means it is put it into operation. During this state training session are
organized for users.
 At this state many problem and errors may arrives.
 We may come to know errors and omission.
 Many problems are of the following type
Data transfer
User Interface
Operator error rate problem
System Evolution
 The large and complex system has a very long life time.
 During the use, they have to subject to many errors and new requirement.
 The organization which gives such system we change it. External factors may also affect
the system.
 Hence, the system evolution is an important costly process.

9
 The amount and time for keeping software useful are called evolution.
System Decommissioning
 Taking the system out of service is called system decommissioning some tie it is an easy
work.
 But mostly it will damage the environment. A system engineer must anticipate with the
problem related with decommissioning at the time design the software.
System procurement
 In large organization the system may be purchased as a whole or part of a system is
purchased or integrated or design and developed completely in their own.
 The option for the above three is called system Procurement.
 A system procurement process is completely a division making process.
 The system procurement process as following activities
Issuing request for proposal
Choosing a supplier
Making contract for the system
Adopt
Requirement
Choose
System
Issue request
for bids
Choose
supplier
Survey market
for existing
system
Issue request
to tenders
Sole of
tender
Negotiate
contract
Contract
for
developer

10
 It shows the procurement process for existing system and newly designed system.
 COTS components usually not match exactly when a system by the contract for own the
main.
 After designing the contractor discussion must be had with them about changes in the
requirement in the future.
 It shows usually there are only one main contractor and mainly sub contractors.
 Every sub contractor design and develop part of the system.
 After every sub contractor completing his own system. The principle contractor
integrated all the sub system and then delivers to the customer.
Software process Model
Introduction:-
 It is an abstract representation of software process. A model provides partial
information about the process.
 A software model provides frame work of the process.
 Software process model can be used to explain different activities involved in software
development.
 There are many model uses for development. Some process models are
System
Customer
Principle
contract
Sub
contract 1
Sub
contract 1
Sub
contract 1

11
Waterfall
Evolutionary development model
Formal system development model
Reused based development model
Waterfall Model
 The first published model of the software development process was waterfall model.
 Figure shows such as model there is a cascading from one Phase to another Phase this
model is also known as software development life cycle model.
 The main stages of the models are
Requirements definition:-
 At this stage system services, constrains and goals are clearly defined in consultation
with systems users.
 System specification is defined in detail manner.
Requirement
Definition
Systemand
software design
Implementing
&unittesting
Integrating &
Systemtesting
Operationand
maintenance

12
System& Software Design:-
 In this process, the system requirement is partition in accordance with hardware and
software.
 Fundamental software systems are identified.
 Overall system architecture is established.
Implementation & Unit Testing:-
 In this stage only the developer started writing program this is called codification.
 Programs are developed as module unique and every module is tested with test date.
 Every module is verified that customer requirements are satisfied or not.
Integration & SystemTesting:-
 Individual units are integrated and tested as a complete system.
 Testing is performed and enters system to ensure that software requirement is satisfied.
Operation& Maintenance:-
 This is a stage in water fall model take longest life cycle time.
 During these stage the system is install and let it into practical use it the customer side.
 Maintenance means when system gives problem during operations, it must be
corrected.
 During this stage new errors may be discovered and new requirement may be
incorporated new enhanced may be proposed.
Disadvantages of waterfall model:-
 In each stage some document are prepared and approved.
 The waterfall model is inflexible.
 The developer must be committed in each state. Hence this model is recommended only
for the system requirements as well understood.

13
Evolutionary Development model
 In Evolutionary development model and initial implementation develops and given to
the user of command and then do the modification in the system until a satisfied system
has been develop.
 In this model specification development and validation activities are performed
simultaneously
 There are two types of evolutionary development model. They are
Exploratory Development
Throw away prototype
Exploratory Development:-
 In this process, the development starts with the part of the system which are
understand.
 As a when customer proposing new features they are added.
 The main objectives of the method are to work with the customer to know the
requirement clearly for delivery the final system.
Outline
description
Specification
Validation
Development
Initial
Version
Intermediate
version
Final
version

14
Throw away prototyping:-
 In this process, developer starts with the part of the system which are poorly
understand.
 The development concentrated on part of the requirement which is no properly
represented.
 The main objectives of the method are also to understand customer requirement clearly.
Advantages:-
 The better understanding of the problem.
 More effective then waterfall model
 Customer requirements are immediately satisfied.
 Un-certainties in the system are resolved quickly.
Disadvantages:-
 The process is not visible.
 They require more cost.
 Special tools and techniques are required.
 Making changes in the software frequently will corrupt other software.
Spiral Development

15
 Spiral process model was proposed by Boehm in the year 1988.
 In this model the software process model activities are represents as a back tracking
from one activity from another activity.
 Each loop represented as phase of the software process.
 Each loop in the spiral split into four parts
Objective Setting
Risk assessment and reduction
Development and Validation
Planning
Objective Setting:-
 Objective related with particular project are defined.
 Constrains and the process on the product identified.
 Project risk are also identified a detailed plain is purposed and alternative strategies also
planned.
Risk assessment and Reduction:-
 A detailed analysis is carried out at the stage on the identified project risk.
 A prototype system may be developing.
Developmentand Validation:-
 After evaluating risk a development model is chosen various risk are identified and
respective development model are developed.
Planning:-
 The project is review periodically and decision has been taken weather to continue
further with the loop or not.
 If any decision is taken suitable plans are drawn.
CASE
 A case workbench is a set of tool which is used to perform activity such as design
implementation or testing.
 Different case workbench tool can be working together as a single tool.

16
 Analysis and design workbench are used mainly for modeling the system with the help
of graphical notation particular software can be designed or analysis.
 Following figures shows various tools available in an analysis and design workbench
here various tools are integrated through a central shared repository.
 Usually analysis and design workbench is a close environment. Which means that it is
very difficult for the user to modify or add his icon tools
 The analysis and design work bench has a following eight tools
Diagram Editor:-
 This is used for creating DFD (Data flow diagram), ER (Entity Relationship) and
object hierarchy this tool receive information about all the above entity and then
saves that information in the central repository.
Design analysis checking tools:-
 By using this tool, user can identify errors of the beginning stage.
Query language facilities:-
 This tool permits the software designer to find designs and the information from the
central database.
Central
Information
Depository
Data
Dictionary
Structural
programming
tools
Report
Generation
Facility
Query
language
facilities
Import/Export
facilities
Designanalysis
& checking Form creation
tools
Code
Generation

17
Data Dictionary:-
 This tool maintains information about entity which is used in the system.
Report definitionand generationtool:-
 This tool take information from the central storage and documentation generated
automatically.
Form DefinitionTool:-
 These tools are used to specify screen and document format.
Import/Export Facilities:-
 Other development tool is allowed to share information with central repository.
Code Generation:-
 The tool of this work bench is creating or generates a source code automatically
with the help of design already made in the central repository.
Advantages:-
 The CASE workbench may generate source coding language such as c,c++,java
 The design workbench is used for the development business, system application.
 Database system such as Sybase or Oracle is used to implement the tool repository.

18
UNIT II
 Project management
 Management activities
 Project planning
 Milestones and Deliverable
 Project scheduling
 Bar charts and activity networks
 Software requirement : Functional and Non functional requirements
 Domain requirements
 User requirements
 System requirements
 Structured language specification
 Software requirements document (SRS)

19
Project Management
 Project management is very important in developing quality software.
 If the management activity none carried out perfectly then the result will is late delivery
of software more cost of the software and poor performance of the product.
 Project management is a professional activity any software product will be
Intangible.
No standard procedure.
One Project is different from other project.
Project Planning
 A project manager must anticipate the problems.
 He must have planned with available information.
 There are five types
Quality
Validation
Configuration Management
Maintenance
Staff development
 The project plan defines about the available resources the breakdown of work schedule
for carrying out various works.
 A project plan should be regular and must be revise and change frequently
Milestone and deliverable
 Project manager need information can only provides to known the project process it
cost estimate and scheduling information about particular project are in a well
documented form.
 Whenever a project manager planning a project. He makes several mile stone and
deliverable.
 A milestone is an end point of a process activity.
 At each mile stone a formal output and a report should be presented to the
management.
 Milestone report should not be a big report.
 In milestone report illogical statement should be avoided.
 Milestone may be internal project results to check project progress.

20
 Milestone is established by splitting basic activities into many processes.
Deliverable:-
 A deliverable is a project result. Deliver to the customer.
 At the end of major project stages deliverable is deliver to the customer.
 Deliverable are milestone, but milestones did not be deliverable.
 The following figure shows how milestone are appear in the required process.
Software Requirements
 Software system requirements are classified as
Functional requirement
Non-Functional requirement
Domain requirement
Functional requirement
 How the system is behaving in a particular situation are writer, is called function
requirement.
 Functional requirement describe various services and function of a particular system
has to provide.
 Functional requirement may be written in different ways.
Feasible
Study
Feasibility
Report
User
requirement
Prototype
development
System
requirement
Requirement
analysis
Evolution
report
Architecture
design
Design
study
Requirement
specification

21
 Many problems are arrives because of unclear functional requirements.
 Functional requirement documents should be complete and consistence.
 All services must be defined without any leftover.
 There is no contradictory definition.
Non functional requirements
 Non functional requirements are the requirement which is not directly related with the
services of the system they are emergent system properties.
 Non functional requirements are very critical to the system function.
 Any failure non functional requirement will decrease the performance of the system.
 Non functional requirement are not only related with software but also related with
hardware.
 Various types of Non functional requirement
Product requirement
Organization requirement
Extended requirement
 Non functional requirements are very difficult to verify.
 They are not quantifiable sometime, some metric are used to specific non functional
requirements.
 They are
Speed
Size
Reliability
Robustness
Portability
Case of use
Domain Requirement
 It is derived from the application domain.
 Domain requirement are not related with system user.
 Domain requirement may be functional requirement.
 IF the domain requirement is not satisfy then the system can’t work satisfactory.
 E.g.: Report can be product on a particular standard format. Database must be created
on some standard format.
 Domain requirement are sometime consider as requirement constrains.

22
User Requirement
 There are three types of requirement engineering process in order to make a clear
separation between requirements system requirements are divided into three types.
User
System
Software design specification
User:-
 It is used to describe the functional and non functional requirements.
 The user without technical knowledge must understand the behavior of the system in a
clear manner.
 The user requirement must be written natural language (English) using from and
diagram.
Problem1:-
 Lack of clarity the language must be provider and clear.
 Don’t use unwanted words.
 Requirementconfusion - some type functional & Non functional requirements may not
be clearly differentiated.
 The best practice is to give both the requirement separately.
 Requirementamalgamation – When more than one requirement is combined are
represented as only one requirement the problem arrives.
Recommendation:-
 Use a standard format
 Use a language very consistently
 Be careful in using shall,should,will
 Text highlighting features such as Bold, italic must be used.
 Better to avoid using computer terminologies.
System Requirements:-
 If we represent user requirement in detail manner then these are called system
requirements.
 For software engineers system requirements are the starting point for system design.

23
 Many model used such as object model or date flow model.
 Here also natural language used to represents system requirements, two of such natural
languages are
Structure natural language.
Design description language.
Structure natural language:-
 The main reason for using these language is understandability and easy to express our
ideas.
 In structure language very limited terminologies are used.
 The control statements are of some as programming languages.
Design descriptionlanguage:-
 It is also known as program description language.
 A program description is a language is derived from JAVA or ADA.
 A main advantage of PDL is it can be checked syntaxily and semantically.
 Requirements omission and inconsistency is easily indentified.
Disadvantage:-
 The main disadvantage of the PDL is a notation used only familiar to programmers and
the language may not sufficient for our specification.
Software Requirement Specification
 The software requirement document is the agreed statement of the system requirement
specification.
 It should be organized so that it can be used by both system customer and software
developer.
System
customer
Specifythe requirementandread then to
check that theymeettheir needs.They
specifychangesto the requirements.
Manager Use the requirementsdocumenttoplan a
bid of the system and to plan the system
requirementprocess

24
Project Scheduling
Introduction:-
 Split project into tasks and estimate time and resource required to complete each task.
 Organize the activities that are carried out in parallel to make optimal use of work
force.
 Minimum task dependencies to avoid delays caused by one task waiting for another to
complete.
 For any activity it should be set to no more than 8-10 weeks. If longer than this it
should be subdivided for project planning and scheduling.
 Estimate principal resources: Human effort, disk space on a server time to specialize
such as simulator, travel budget dependent on project manager’s intuition and
experience.
System
Engineers
Use the requirementtounderstand what
systemis to be developed.
Systemtest
engineers
Use the requirementtodevelop
validationtests for the system
System
maintenances
engineers
Use the requirementtohelpunderstand
the systemand the relationshipbetween
its pair

25
The projectschedulingprocess:-
Software Activity chart and bar charts
Requirements
Scheduling problems:-
 Estimating the difficulty of problem and hence the cost of developing a solution is hard.
 Productivity is not proportional to the number of people working on a task.
 Adding people to a late project makes it later because of communication overheads.
 The unexpected always happens allows contingency in planning.
Bar charts and activity networks
 Graphical notations used to illustrate the project schedule.
 Activity networks show task dependencies and the critical path.
 Bar charts show who is responsible for each activity and when the activity is schedule to
begin and end.
 Show project breakdown into tasks. It should not be too small. They should take about a
week or two week.
 Bar chart and activity network can be general by the project management tools.
 Activity is represented as rectangle. Milestone or deliverable is shown as rounded
corner.
 The minimum time required to finish the project can be estimated by considering the
longest path in the activity network.
Identify
Activities
Identifyactivity
dependencies
Estimate resource
for activities
Allocate
people
Create
project charts

26
Task durationsand dependencies:-
Task Duration(days) Dependencies
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
8
15
15
10
10
5
20
25
15
15
7
10
__
__
T1(M1)
__
T2,T4(M2)
T1,T2(M3)
T1(M1)
T4(M5)
T3,T6(M4)
T5,T7(M7)
T9(M6)
T11(M8)
Bar charts and activity network:-
 The longest path in the graph indicates the critical path.
 The overall schedule of project depends on the critical path.
 Activity network can provide manages about the activity dependencies which are not
obvious.
 Modify the system design to reduce the project schedule by reducing amount of time
spend waiting for activities to finish.
Gantt chart:-
 It shows the calendar day from start to finish.
 It shows some flexibility in the completion date of this activity.
 If an activity do not complete on time the critical path will not be affected until the end
of the period marked by the shaded bar.
 Allocate suitable staff to the suitable activity.
 Staff doesn’t have to be assigned to a project at all time.
 During the intervening period, they may be on a holiday, work on other project attend a
training course.

27
Staff allocation and time chart:-
Fired
Jane
Anne
Jim
Mary
T4
T1
T2
T3
T5
T7
T6
T8
T9
T10
T11
T12

28
UNIT III
 System models
 Context model
 Behavioral models
 Data-flow models
 State machine models
 Data models
 Object models. Architectural design
 System organization
 Repository model
 Client –server model
 Layered model
 Modular decomposition object oriented decomposition
 Function oriented pipelining
 Control styles
 Centralized control
 Event driven system
 Reference architecture

29
SYSTEM MODEL
 System models are graphical representation of a problem of a problem to be solved and
the system to be develop models are more understandable they remove difference
between analyze and design.
 A system model is an abstract of system being studied .The term abstraction mean some
details can be ignored.
 Some of the type of the models are:
Data processing model
A composition model
An architectural model
Classification model
A stimulus response model
 Data processing model –shows how data is processed at different stages in the system.
 A composition model – It shows entity relation shows how entities in the system are
composed of thing entities.
 An architectural model – It shows the principle such system which makes up the system.
 Classification model – The object class, Inheritances diagram show entities have
common characteristics.
 A stimulus response model –Itstate transition shows how the system reacts to internal
and external events.
CONTEXT MODEL
 It is used to be illustrating the operational context of the system they should what lies
outside the system boundaries.
 Social and organization concerns may affect the decision on where to position system
boundaries.
 Architectural model show the system and its relationship with other system.
BEHAVIORAL MODEL
 It is used to describe the overall behavioral of a system
Type of behavioral model:-
 Data processing model:- It shows how data is processed as it moves through the system
 StateMachine model:-It shows the system response to events. These model show
different perspectives so both of them are required to describe the system’s behavior.

30
Data - processing model
 It is used to represent how the data is processed by the system. Several notations are
used in this model to represent processing, storing and moving of data.
 The above figure shows the data flow model involved in processing order are
equipment.
 Each transformation represents a single function.
 Data flow model represent how difference system and sub system exchange
Information.
State machine model
 State machine models are used to explain behavior of a system in response to internal
or external events
 The state of the machine or system has been moving in response to various input .State
machine model are used for real time system
 The following figure illustrate the

31
 The above figure shows state machine model of a simple microwave oven is describe
 This model has following sequences of action;
Select the power level either half or full power.
Input the cooking time
Press the start button to cook the food for a given time
 The buzzer is used the door is open or when cooking time is complete.
 The display is an alpha numeric display different state associated with this microwave
oven.
 Waiting:- The oven is waiting for input
 Half power:- The oven power is set to 300V
 Full power:-The oven power is set to 600V
 Set time:-Cooking time is given by user and can be updated
 Disable:-For safety reasons ,oven operation ,and interior light is on
 Enable:-For safety reason,ovenoperation is enable and interior light is on
 Operation:-Interior oven light is ON; timer display count down time on the completion
of cooking a buzzer is for 5 sec.
Conclusion:-
 A state machine model has more number of state than represented, the state are
change so rapidly.

32
DATA MODEL
 It is used to describe the logical structure of data process by the system.
 An entity +relation-attribute models set out the entities in the system, the relationship
between these entities and the entity attributes.
 Widely used in data base design can readily be implemented using relational database.
Data Dictionaries:-
 It is used to lists of all of the names used in the system models.
 Descriptions of the entities, relationship and attributes are also included.
Advantages:-
 Support name management and avoid duplication
 Store of organization knowledge linking analysis , design and implementation
 Many case work benches support data dictionaries.

33
NAME DESCRIPTION TYPE
Article Details the published article
that may be ordered by people
using LIBSVS
Entity
Authors The names of the authors of
the articles who may be due a
share of the fee.
Attribute
Buyer The person or organization
that orders a copy of the
articles
Entity
Fee-payable-to A 1:1 relationship between
article and the copy right
agency that should be paid the
copy right fee.
Relation
Address buyer The address of the buyer .This
is used to any paper billing
that is required
Attribute
OBJECT MODELS
 The object models are developed during requirement analysis.
 In order to represent data and processing methods.
 Object models are used to represent real world entity. The real word can be car, aircraft,
animal, books etc.
 All the above are having identifiable attributes.
 Object is executable entity with the attributes and services of the object class.
 Various type of object model can be produce to relate object class to aggregate several
object classes to form.
 During analysis stage different object classes are related together object classes are
related together.
 The following figure shows an object class of UML

34
 The above figure represent the object class in UML and object has three section
1. The Name of the object in the top session
2. The class attributes in the middle session
3. The third section has operation relation with the object class.
Inheritance model:-

35
Fig b
 In object oriented modeling identification of object is an important work for this
domain knowledge is needed.
 Classes are organized into taxonomy. it is a classification scheme to represent how
an object class is related with other class throw common attribute and services
 Fig A shows A simple class heredity of the library system where in the top of the
hieratic a set of attribute a.
 These are inherited by the class published item and recorded item
 Fig B shows the library model with two classes of user
1. One type of users are permitted to borrow book
2. Another type of user can only read book; but cannot take book away
3. In inheritances, the upward arrow is used to represent the class which
inherits attributes and operation to the super class.
Object Aggregation:-
 The set of object is called as object aggregation
 Some object are made up of other objects
 In UML a diamond shape on the source of the link represent aggregation

36
 The above figure shows the study pack course work is compose of no. of ,assignment
,OHP slides ,Lecture note ,Video tape
 An Assignment has no. of exe and their solution.
ARCHITECTURAL DESIGN
 Many large system are developed by decomposing them into several sub system
 An Architectural Design is a method or procedure to indentify various sub system and
creating a overall frame work for sub system control and communication
 Different activities those are carried out in architectural design
1. System Structuring
2. Control Modeling
3. Modular decomposition
 The way we decide various application and system structure depend entirely on the
following non function requirement.
1. Performance:-
 It is a critical requirement so that in architectural design all critical operation are
putting inside in a small sub system
2. Security:-
 The layered Architecture is used is the most critical security components are located in
the inner layer of the sub system
3. Safety:-
 The System in structured in such a way that all safety related operation are located in
single sub system or two or more sub system
Availability:-
 The system is designed in a way that some function are repeated so that updating can be
possible
 If one sub system fails, another system will take control.

37
Maintainability:-
 For this Non-Function requirement, the system is design using fine grain method. Fine
grain method is a method so that all operation are contain in a easily changed
component
 Data are produced separately , data are processed separately no sharing of data
structure
SystemStructuring:-
 Decomposing a system into a set interacting subsystem is called system structuring.
 This is an abstract concept block diagram are used ; each box represents a sub system
boxes within boxes represents sub system within sub system
 Arrows are used to represent movement of data and control from one sub system to
another
 There are 3 standard model used for structuring the system
Repository model
Client- server model
Abstract machine model
Repository model:-
 Repository model is used when a huge database to be organized, shared and used.
 It is highly suitable for application where data or generated by one sub system and used
by remaining subsystem
 When sharing is the point the following two fundamental ways are used

38
A centralized database is accessed by all subsystem , the repository model is based on
the methods
Each sub system has its own data based so that data or exchange by the sub system
Advantages:-
 No need to send or receive one sub system to another
 A subsystem which produces data need not be worried about how the data is used by
other subsystem
 Different subsystem may have different security ,recovery and backup policies
 The repository model computes all sub system to follow a same policy
 It is easy to integrate new tools.
Disadvantage:-
 Performances is affected because a common repository data model is used by all sub
system ; if there is compromised then the performances is automatically affected
 It is very difficult to integrate new sub system
 Maintainers is difficult , expensive and sometime impossible
 It is very difficult to distribute the repository database over a number of machines.
There are problems with data redundancy and inconsistency.
CLIENT SERVER MODEL
 The client server architecture model is also known s distributed system model
 In this model in which the data and processing are distributed among different
processor

39
Components:-
 A stand alone sever are group of server to offer services to other subsystem E.g.:- print
server, video server , file sever
 A group of client which are requesting various services affected by servers a particular
client may execute more than one program simultaneously
 A communication media (called as network ) is used by the client to access various
services
Pictorial Explanation:-
 As show in figure multiuser hypertext system is used in a library, different server is
used and variety of queries is received.
 Each client must known the name of various servers and their services
Advantages:-
 Many distributed process can be used affect
 New server can be added easily
 Sever can be upgraded without affecting other parts of the system
Disadvantages
 Each sever may have different data model so that performances is restricted
 Sub system may organize their own data in different ways. These will also affect the
performances.
 Each sever is responsible for its own data management activity
ABSTRACT MACHINE MODEL
 It is also known as layered model
 This model provides a method for how to organize various services provided by
different sub system
 In a following diagram each sub system is represented by layer
 Each layer is a machine
 One layer or abstract machine is implemented on another layer.

40
Diagrammatic Representation:-
 A well known example for these approach is OSI reference model
 Another example is a version management system as shown in above fig
 The version management depends on managing different version
 This system uses the data base system for data storage and services
 This data base system is using the services of the next layered OS
 The layered approach is used in incremental development
Advantage:-
 This Arch can be easily changeable and potable
 Any layered can be replaced by another layer
 When there is a change in interface only the adjacent (nearest)
 Layer is affected.
 Hard ware related coding can be implement in inner layer
 Only machine dependent layer to be re implemented
Disadvantage:-
 Structuring system is very difficult
 It is very difficult to access some services provider by the inner layer
MODULAR DECOMPOSITION
 Another structural level where sub-system are decomposed into module
 There are two type of modular D

41
Object flow
Pipeline flow
Object flow:-
 An object –model where the system is decomposed into interacting object
Pipeline model:-
 A pipeline model where the system is decomposed into functional modules which
transform input to output
Object models:-
 Structure the system into a set of loosely coupled object with well-defined interface
 Object-oriented decomposition is concerned with identifying object classes , their
attributes and operations
 When implemented, object are created from these classes and above control model used
to coordinates object operations.
Advantages:-
 Object are loosely coupled so their implementations can be modified without
affecting other objects

42
 The objects may reflect real-world entities. It implementation languages are
widely used.
FUNCTION-ORIENTED PIPELINING (DATA FLOW)
 These model is used to process their input (using functional models to produce output)
 These model is also called as pipe and filter model
 Variants of this approach are very common
 When transformations are sequential, this a batch sequential model which is
extensively used in data processing systems
 Not really suitable for interactive system.
Advantage:-
 It supports transformation resume
 Easy to add new transformation
 Relatively simple to implement as either a concurrent or sequential system.

43
UNIT IV
 Object oriented design: Object and object classes
 An object oriented design process
 Design evolution
 Rea time software
 System design
 Real time operating systems
 Monitoring and control systems
 Data acquisition systems
 User interface design: User interface design issues
 User interface design process
 User interface prototyping
 Interface evaluation

44
User Interface Design
User Interface:-
 System user often judges a system by interface rather than its functionality.
 A poorly designed interface can cause a user to make catastrophic errors.
 Poor user interface design is the reason why so many software systems are never used.
Graphical User Interface– (GUI):-
 Most users of business systems interact with this system through graphical interfaces
although in some cases, legacy text based interfaces are still used.
GUI Characteristic:-
Characteristic Description
Windows
Multiple windows allow different information to
be displayed simultaneously on the users screen.
Icons
Icons different types of information. On some
system, icon represent files, on other icons
represent process.
Menus
Commands are selected from a menu rather than
typed in a command language.
Pointing
A pointing device such as a mouse is used for
selecting choices from a menu or indicating
items of interest in a window.
Graphics
Graphics elements can be mixed with text on the
same display.
GUI Advantages:-
They are easy to learn and use
 Users without experience can learn to use the system quickly.
 The user may switch quickly from one task to another and can interact with several
different applications.
 Information remains visible in its own window when attention is switched.

45
 Fast full screen interaction is possible with immediate access to anywhere on the screen.
User Interface design process:-
User Interface Design Principle:-
 UI design must take account of the needs experience and capabilities of the system
users.
 Designers should be aware of people’s physical and mental limitations (E.g.:-Limited
shorter memory) and should recognize that people make mistakes.
 UI design principles underlie interface designs although not all principles are
applicable to all designs.
User Interface Design Principles:-
User Familiarity The interface should use term and concepts which
are drawn from the experience people who will
make most use of the system.
Consistency The interface should be consistent in that,
whatever possible, comparable operations are
activated in the same way.

46
Minimal Surprise Recoverability User should never be surprised by the behavior of
the system.
The interface should include mechanisms to allow
users to recover from errors.
User Guidance The interface should provide meaningful feedback
when errors occurs and provide context sensitive
user help facilities.
User Diversity The interface should provide appropriate
interaction facilities for different types of system
user.
Design Principles
User Familiarity:-
 The interface should be based on user oriented terms and concepts rather than
computer concepts. (E.g.:- An office system should use concepts such as letter, document
folder etc).
Consistency:-
 The system should display an appropriate level of consistency.
 Commands and menu should have the same format; command punctuation should be
similar etc.
Minimal surprise:-
 If a command operates is a known way, the user should be able to predict the operation
of comparable commands.
Recoverability:-
 The system should provide some resilience to user errors and allow the user to recover
from error.
 This might include an undo facility confirmation of destructive actions, ‘soft’ deletes etc.
User guidance:-
Some user guidance such as help systems on line manuals etc should be applied

47
User Diversity:-
 Interaction facilities for different types of user should be supported.
 E.g.:- Some user has seeing difficulties and so larger text should be available.
User SystemInteraction:-
 Two problems must be addressed in interactive system design.
How should information from the user be providing to the computer system?
How should information from the computer system be presented to the user?
 User interaction and information presentation may be integrated through a coherent
fame work such as a user interface metaphor.
Issues:-
 System response time
 User help facilities
 Error information handling
 Command labeling
Interaction styles:-
 Direct manipulation
 Menu selection
 Form fill-in
 Command language
 Nature language
Direct manipulation advantages:-
 Users feel in control of the computer and are less likely to be intimidated by it.
 User learning time is relatively short.
 User gets immediate feedback on their action so mistakes can be quickly detected and
corrected.
Direct manipulation problems:-
 The derivation of an appropriate information space model can be very difficult.
 Given that users have a large information space, what facilities for navigating around
that space should be provided?

48
 Direct manipulation interface can be complex to program and make heavy demand on
the computer system.
Control panel interface:-
Menu System:-
 User makes a selection from a list of possibilities presented to them by the system.
 The selection may be made by pointing and clicking with a mouse using cursor key or
by typing the name of the selection.
Advantage of menu systems:-
 User need not remember command name as they are always presented with a list of
valid commands.
 Types efforts is minimal
 User error is trapped by the interface.
 Context dependent help can be provided the user’s context is indicated by the current
menus selections.
Problems with menu systems:-
 Actions which involve logical conjunction or disjunction are awkward to represent.
 Menu systems are best suited to presenting a small number of choices. If there are many
choices some menu structuring facility must be used.
 Experienced user find menu slower than command language.

49
Command interface:-
 User types commands to give instructions to the system E.g. - UNIX.
 May be implemented using cheap terminals.
 Easy to process using compiler techniques
 Command of arbitrary complexity can be created by command combination.
 Concise interface requiring minimal typing can be created.
Problems with command interface:-
 User has to learn and remember a command language. Command interface are
therefore unsuitable for occasional users.
 Users make error in command. An error detection and recovery system is required.
 System interaction is through a keyboard so typing ability is required.
Command language:-
 Often preferred by experienced users because they allow for faster interaction with the
system.
 Not suitable for casual or inexperienced user.
 May be provided as an alternative to menu commands. In some cases a command
language interface and a menu based interface are supported at the same time.
Nature language interface:-
 The user type a command in a natural language. Generally the vocabulary is limited
and these systems are confirmed to specific application domains (E.g. timetable
enquires).
 Natural language processing technology is now good enough to make this interface
effective for casual users but experienced users find that they require too much typing.

50
Multiple user interfaces:-
InformationPresentation:-
 Information presentation is concerned with presenting system information to system
users.
 The information may be presented directly or may be transformed in some way for
presentation.
 The model view controller approach is a way of supporting multiple presentations of
data.
InformationPresentation:-
Graphical user
interface
Command language
interface
Operating
System
GUImanager Command language
interpreter
Informationto be
display
Presentation
software
-------
-----

51
Model view controller:-
View modification message user input
Model queries model edits
And updates
Informationpresentation:-
Static information:-
 Initialized at the beginning of a session it does not change during the session.
 May be either numeric or textual.
Dynamic information:-
 Changes during a session and the changes must be communicated to the system user.
 May be either numeric or textual.
Alternative informationpresentation:-
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
January February March April May June
Column1
Column2
Viewstate
View
methods
Controllerstate
Controllermethods
Model state
Model method

52
Analogue vs. digital presentation:-
Digital presentation:-
 Compact takes up little screen space.
 Precise values can be communicated.
Analogue presentation:-
 Easier to get an ‘ata glance’ impression of a value.
 Possible to slow relative values.
 Easier to see exceptional data values.
Dynamic informationdisplay:-
Displaying relative values:-
Textual highlighting:-

53
Data Visualization:-
 Concerned with techniques for displaying large amount of information.
 Visualization can be reveal relationship between entities and trends in the data.
 Possible data visualization is
Weather information collected from a no of source
The state of a telephone network as a linked set of nodes
Color displays:-
 Color adds an extra dimension to an interface and can help the user understand
complex information structure.
 Can be used to highlight exceptional events.
Color use guidelines:-
 Don’t use too many colors
 Use color coding to support use tasks
 Allow users to control colors coding.
 Design for monochrome then adds color.
 Use color coding consistently.
 Avoid color pairings which clash.
 Use color change to show status change.
User support:-
 User guidance covers all system facilities to support user including on line help, error,
messages, manuals etc.
 The user guidance system should be integrated with the user. Interface to help users
when they need information about the system or when they make some kind of error.
!
The filename youhave chosenhas beenused,please choose another name
Ch.16 User Interface Design
OK Cancel

54
 The help and message system should if possible be integrated.
Help and message system:-
Error messages:-
 Error message design in critically important poor error message can mean that a user
rejects rather than accepts a system.
 Message should be polito, conise, consistent and constructor.
 The background and experience of users should be the determining factor in message
design.
Systemand user oriented error messages:-

55
Help system design:-
 Help? Means”help I want information”.
 Help? Means “Help I’m in trouble”.
 Both of these requirements have to be taken account in help system design.
 Different facilities in the help system may be required.
Help information:-
 Should not simply be an online manual.
 Screens or window don’t map well onto paper pages.
 The dynamic characteristic of the display can improve information presentation.
 People are not so good at reading screen as they are text.
Help system use:-
 Multiple entry points should be provided so that the user can get into the help system
from different places.
 Some indication of where the user a positioned in the help system is valuable.
Entry pointsto a help system:-
Top level
entry
Entry from
error
message
system
Entry from
application

56
User documentation:-
 As well as online information paper documentation should be supplied with a system.
 Documentation should be designed for a range of users from inexperienced to
experience.
 As well as manuals other easy to use documentation such as quite reference card may
be provided.
User document type:-
Documenttypes:-
Functional description:-
 Grief description of what the system can do.
Introductory manual:-
 Presents an informal introduction to the system.
Systemreference manual:-
 Describes all system facilities in detail.
Systeminstallation manuals:-
 Describes how to install the system.
Systemadministratorsmanual:-
 Describe how to manage the system when it is in use.

57
User interface evaluation
 Some evaluation of a user interface design should be carried out to assess its suitability.
 Full scale evaluation is every expensive and impractical for most systems.
Usability attributes:-
Attributes Description
Learn ability How long does it take a new user to become
productive with the system?
Speed of operation How well does the system response match the
users work practice?
Robustness How tolerant is the system of user error?
Recoverability How good is the system at recovering from user
errors?
Adaptability How closely is the system tied to a single model
of works?
Real time software
Introduction:-
 To explain the concept of real time system and why these systems are usually
implemented as concurrent processes.
 To describe a design process for real time system.
 To explain the role of a real time operating system.
Real time system:-
 Systems which monitor and control their environment.
 Inevitably associated with hardware devices.
Sensors: - Collect date from the system environment.
Actuators: - Change the systemsenvironment. Time is critical. Real time system
must respond within specified times.
Real time software types:-
 They classified into two types.

58
Soft real time system
Hard real time system
Soft real time system:-
 It is a system whose operation is degraded if result is not reduced to the specified timing
requirements.
Hard real time system:-
 It is a system whose operation is incorrect if results are not produce according to the
timing specification.
Stimulus / response system:-
 Given a stimulus the system must produce a response within a specified time.
Periodic stimulus:-
 Stimuli which occur at predictable time intervals
 E.g. A temperature sensor may be polled 10 times per second.
A periodic stimulus:-
 Stimuli which occur at unpredictable times.
 E.g. A system power failure may trigger an interrupt which must be processed by the
system.
A real time system model:-

59
Sensor actuator processes:-
System element
Sensor control:-
 Control information from sensors.
 May buffer information collected in response to a sensor stimulus.
Data processor:-
 Carries out processing of collected information and computes the system response.
Actuator control processes:-
 Generates control signals for the actuators.

60
Real time programming:-
 Hard real time systems may have to program I assembly language to ensure that
deadlines are met.
 Languages such as allow efficient programs to be written but do not have construct
management.
System design
 Design both the hardware and the software associated with system. Partition functions
to either hardware or software.
 Design decisions should be made on the basis on non functional system requirement.
 Hardware delivers better performances but potentially longer development and less
scope for change.
Real time design process:-
 Identify the stimuli to be processed and the required response to these stimuli.
 For each stimulus and response identify the timing constraints.
 The stimulus and response processing into concurrent process.
 A process may be associated with each class of stimulus and response.
Real time system modeling:-
 The effect of a stimulus in a real time system may trigger a transition from one state to
another.
 Finate state machine can be used for modeling real time system.
 FSM model lack structure even simple system can have a complex model.
 UML includes notations for defining state machine models.
Petrol pumb state model:-

61
Os components:-
Real time clock:- Provides information for process scheduling.
Interrupt handler:- Manages a periodic requests for service.
Scheduler:- Choose the next process to be run.
Resource manager:- Allocates memory and processor resource.
Dispatcher:- Start process execution.
Non-stop systemcomponents:-
Configuration manager:-
 Responsible for the dynamic reconfiguration of the system software and hardware.
 Hardwar models may be replaced and software upgraded without stopping the system.
Fault manager:-
 Responsible for detecting software and hardware fault and taking appropriate action.
(E.g Back up dick) to ensure that the system continiuos in operation.

62
Real time operating system components:-
Process priority:-
 The processing of some type of stimuli must sometimes take priority.
 Interrupt level priority. Highest priority which is allocated to processes requiring a very
fast response.
clock level priority:- Allocated to periodic processes.
Process Management:-
 Concerned with managing the set of concurrent process.
 Periodic processes are executed at pre-specified time intervals.
 The real time clock to determine when to execute a process taking into account.
 Process period time between execution.
 Process deadline the time by which processing must be complete.
Scheduling strategies:-
Scheduler
Choose process
for execution
Resource manager
Allocate memory
and processor
Dispatcher
Start executionon
an available
process

63
Non-preemptive scheduling:-
 Once a process has been scheduled for execution, it runs to completion or until it is
blocked for some reason.
Pre-emptive scheduling:-
 The execution of an execution processes may be stopped if a higher priority process
requires service.
Scheduling algorithms:-
 Round robin
 Rate monotonic
 Shortest deadline first
Monitoring and control system:-
 mportant class of real time system.
 Continuously check sensors and take actions depending on sensor values.
 Monitoring systems examine sensors and reports their results.
 Control system take sensor values and control hardware actuators.
Generic architecture:-

64
Burglar alarm system:-
 A system required to monitor sensors on doors and windows to detect the presence of
intruders in a building.
 When a sensor indicates a break in the system switches on light around the area and
calls police automatically.
 The system should include provision for operation without a mains power supply.
Burglar alarm system:-
Sensors:-
 Movement detectors, window sensors, door sensors
 50 window sensors, 30 door sensors and 200 movement.
 Voltage drop sensor.
Actions:-
 When an intruder in detected, police are called automatically.
 Light are switched on in rooms with active sensors.
 An audible alarm is switched on;
 The system switch automatically to backup power when a voltage drop is detected.
B1
Control panel
process
Testing
Process
Monitoring
process
Control
process
P(A1)
S2
S3
P(s1)
P(s2)
P(s3)
P(A4)
P(A3)
P(A2)
A1
A2
A3
A4

65
Stimuli to be processed:-
Power failure:-
 Generated a periodically by a circuit moin to when received the system must switch to
backup power within 50ms.
Intruder alarm:-
 Stimulus generated by system sensors. Response is to call the police, switch on building
lights and the audible alarm.
Timing requirement:-
Stimulus response Timing requirement
Power fail interrupt The switch to backup power must be
completed within a deadline of 50ms
Door alarm Each door alarm should be polled twice per
second.
Window alarm Each window alarm should be polled twice
per second.
Movement detector Each movement detector should be polled
twice per second.
Audible alarm The audible alarm should be switched on
within ½ second of an alarm being raised by a
sensor.
Light switch The lights should be switched on within ½
Lights switch Second of an alarm being raised by a sensor.
Communications The calls to the police should be started within
2 second of an alarm being raised by a sensor.
Voice synthesizer A synthesized message should be available
within 4 seconds of an alarm being raised by a
sensor.
Burglar alarm systemprocesses:-

66
Control system:-
 A burglar alarm system is primarily a monitoring system. It collects data from sensors
but no real time actuator control.
 Control systems are similar but in response to sensor values, the system sends.
 An example of a monitoring and control system is a system that monitors temperature
and switched heaters on and off.
A temperature control system:-
500Hz
500Hz Sensor values
500Hz
Switchcommand
Room no
Data acquisition system:-
 Collect date from sensors for sub request processing and analysis.
 Data collection processes and processing processes may have different periods and
deadlines.
Sensor Process
Heater control process Furnace control process
Theirmost at
process

67
 Circular or ring buffer are a mechanism for smoothing speed difference.
Data acquisition architecture:-
Sensor identifier Sensor identifier
& value & value
Sensor identifier Sensor identifier
& value & value
Reactor data collection:-
 A system collects data from a set of sensors monitoring the neutron flux a nuclear
reactor.
 Flux data is placed in a ring buffer for later processing.
 The ring buffer is itself implemented as a concurrent process so that the collection and
processing processes may be synchronized.
Reactor flux monitoring:-
A ring buffer:-
S1
S2
S3
Sensor
process
Process
data
Sensor data
buffer
Display
S1
S1
S1
Sensor
process
Sensor data
buffer
Process
data

68
Mutual exclusion:-
 Producer processes collect data and add it to the buffer. Consumer processes take data
from the buffer and make elements available.
 Producer and consumer processes must be mutually excluded from accessing the same
element.
 The buffer must stop producer processes adding information to a full buffer and
consumer processes trying to take information from an empty buffer.
Clean room software development:-
 It is a software development technique which is based on static verification.
 The objective of these approach to software development is zero defect software.
 The clean room approach software development is based on the notation that defect in
software should be avoided rather then detected and repair.
Characterstics:-

69
 Formal specification using a state transition model.
 Incremental development where the customer priorities increment
 Structure programming limited control and abstraction constructs are used in the
program.
 Static verification using rigorous inspection.
Process team:
Specificationteam:-
 Responsible for developing and maintaining the system specification
Developmentteam:-
 Responsible for developing and verifying the software. The software is not executed or
event compiled during this process.
Certificationteam:-
 Responsible for develop set of statistical test.
Quality management:-
 It is a software to develop without faults and conform to its specification
 Quality managers are responsible for three kind of activity
Quality assurance
Quality control
Quality planning
Quality assurance:-
 They must establish organizational procedures and standards which leads to high
quality software.
Quality control:-
 They must ensure that procedure and standards are followed by the software
development team.
Quality planning:-

70
 They must select appropriate procedure and standards are followed by the software
development team.
Process quality assurance:-
 Quality of the development process directly affects the quality of the delivered product.
 Process quality is particularly important in software development.
 The reason for this is that it is difficult to measure software attributes such as
maintainability without using the software for a long period.
 Quality manager must ensure that the quality of the software process that is used this
involves
1) Defining process standard such as how review should be conducted when
review should be help on and show on.
2) Monitoring the development process to ensure that the standards are bein
followed
3) Reporting the standard product management & to the buyer of the software.
Product quality:-
 We can quality the product depending upon following.
Design quality metric
Program quality metric
Documentation quality metric
Design quality metric:-
 There are number of possible design attributes which are important but we know that
the key attribute is maintainability.
Cohesion:- How closely are the part of the component related?
Coupling:- How independent is a component.
Understandability:- How easy is to understand the function of a component.
Programquality metrics:-
 We can quality the program using the following metric.
Length of code
Cyclometric complexity
Length of identifiers
Depth of conditional nesting

71
Length of code:-
 This is a measure of the sixe of program
 Generally the larger the size of the code of a program components.
Cyclometric complexity:-
 This is a measure of a control complexity of a program
 This control complexity is related to program understand ability
Length of identifier:-
 This is a measure of the average length of different identifiers in a program
Depth of conditional nesting:-
 This is a measure of the depth of nested if statement in a program
 Nested if statements are hand to understand and potentially error prone
Documentation quality metric:-
 The quality of the documentation associated with a software product is as important as
the quality of the software itself.
 The best known of these metric running for index which is the measure of the
readability of a passage of text
Software metric:-
 Any type of measurement which relates to software system, process are related
documentation
 Line of code in program the for index, no.of person base require to develop a
component.
 Allow the software and the software process to be qualified.
Predictor & control metrics
Control metric:-
 This metric used by the management to control the software process.
Predictor metric:-

72
 Measurement of product attribute that can be used to predict an associated product
quality
Internal and external attributes:-

73
Verification and Validation
Verification:
 "Are we building the product right”.
 The software should conform to its specification.
Validation:
 "Are we building the right product”.
 The software should do what the user really requires.
 These two terms are very confusing for most people, who use them interchangeability.
 The following table highlights the difference between verification and validation.
Verification Validation
Verification address the concern: “Are you
building it right?”
Validation address the concern: “Are you
building the right thing?”
Ensure that the software system meets all the
functionality
Ensure that the functionalities meets the
intended behavior
Verification takes place first and includes the
checking for documentation, code etc
Validation occurs after verification mainly
involves the checking of the over all product.
Done by developers Done by testers
It has static activities, as it. Includes collecting
reviews, walk thoughts, and inspection to verify
a software.
It has dynamic activities, as it includes executing
the software against the requirement.
It is an objective process and no subjective
decision should be needed to verify a software.
It is subjective process and involves subjective
decisions on how well a software works.
The V & V process
Is a whole life-cycle process - V & V must be applied at each stage in the software process.
Has two principal objectives
 The discovery of defects in a system;

74
 The assessment of whether or not the system is useful and useable in an
operational situation.
V& V goals
 Verification and validation should establish confidence that the software is fit for
purpose.
 This does NOT mean completely free of defects.
 Rather, it must be good enough for its intended use and the type of use will determine
the degree of confidence that is needed.
V & V confidence
 Depends on system’s purpose, user expectations and marketing environment
Software function
The level of confidence depends on how critical the software is to an
organisation.
User expectations
Users may have low expectations of certain kinds of software.
Marketing environment
Getting a product to market early may be more important than finding defects
in the program.
Static and dynamic verification
 Software inspection Concerned with analysis of the static system representation to
discover problems (static verification) May be supplement by tool-based document
and code analysis .
 Software testing. Concerned with exercising and observing product behaviour
(dynamic verification). The system is executed with test data and its operational
behaviour is observed

75
Software inspections
 These involve people examining the source representation with the aim of
discovering anomalies and defects.
 Inspections not require execution of a system so may be used before implementation.
 They may be applied to any representation of the system (requirements,
design,configuration data, test data, etc.).
 They have been shown to be an effective technique for discovering program errors.
Inspection success
 Many different defects may be discovered in a single inspection. In testing, one defect
,may mask another so several executions are required.
 The reuse domain and programming knowledge so reviewers are likely to have seen
the types of error that commonly arise.
Inspections and testing
 Inspections and testing are complementary and not opposing verification techniques.
 Both should be used during the V & V process.
 Inspections can check conformance with a specification but not conformance with the
customer’s real requirements.
 Inspections cannot check non-functional characteristics such as performance,
usability, etc.

76
Program inspections
 Formalised approach to document reviews Intended explicitly for defect detection
(not correction).
 Defects may be logical errors, anomalies in the code that might indicate an erroneous
condition (e.g. an uninitialised variable) or non-compliance with standards.
The inspection process
Clean room software development:-
 It is a software development technique which is based on static verification.
 The objective of these approach to software development is zero defect software.
 The clean room approach software development is based on the notation that defect in
software should be avoided rather then detected and repair.

77
Characterstics:-
 Formal specification using a state transition model.
 Incremental development where the customer priorities increment
 Structure programming limited control and abstraction constructs are used in the
program.
 Static verification using rigorous inspection.
Process team:
Specification team:-
 Responsible for developing and maintaining the system specification
Development team:-
 Responsible for developing and verifying the software. The software is not executed or
event compiled during this process.
Certification team:-
 Responsible for develop set of statistical test.
Software testing
 Testing can be described as a process used for revealing defects in software, the
software has a specified degree of quality with respect to selected attributes, An input
output model of program testing.
The main focus of such testing is to test:-
System functions and performances
System reliability and recoverability
System installation(installation test)
System behavior in the special conditions

78
Types of testing:-
System testing
Integration
Release
Performance
Component
Interface
System Testing
 The system test is a series of test conducted to fully the computer based system
 various types of system test are
Recovery testing
Security testing
Stress testing
Performance testing
Recovery testing:-
 It is intended to check the system’s ability to recover from failures.
 In this type of testing is forced to fail and then it is verified.
 For automated recovery then re-initialization checkpoint mechanisms, data recovery
and restart are verified.
Security testing:-
 Security testing verifies that system protection mechanism prevent improper
penetration or data alteration.
 It also verifies that protection mechanisms built into the system prevent instruction such
as unauthorized internal or external access or will full damage.
Stress testing:-
 Determines breakpoint of a system to establish maximum service level
 In stress testing the system is executed in a manner that demands resource in abnormal
quantity frequency or volume.
 A variation of stress testing is a technique called sensitivity testing.

79
Performance testing
 It evaluates the runtime performance of the software especially real time software.
 It utilization such as CPU load, through put, response time, memory usage, can be
measured.
 Beta testing is useful for performance testing.
Integration testing
 It is a combined parts of an application to determine if they function correctly.
 Integration testing can be done in two ways.
Bottom up integration
Top down integration
Bottom up integration:-
 This testing begins with unit testing followed by tests of progressively higher level
combination of units called modules or builds.
Top down integration:-
 The highest level modules are tested first and progressively, lower level modules are
tested there after.
Release testing
 Release testing is the process of testing a particular release of a system that is intended
for use outside of the development team.
 The primary goal of the release testing process is to continue the customer o the system
that it is good enough for use.
Release testing is a form of system testing
Important difference:-
 A separate team that has not been involved in the system development should be
responsible for release testing.
 System testing by the development team should focus on discovery bugs in the system
 The objective of release testing is to check that the system meets its requirements and is
good enough for external use.

80
Performance testing
 It is mostly used to identify any bottle necks or performance issues rather than finding
bugs in a software.
 There are different causes that contribute in lowering the performance of a software.
Network delay
Client side processing
Database transaction processing
Load balancing between servers
Data rendering
 Performance testing is considered as one of the important testing type in terms of the
following aspects.
Speed (Response time, data rendering and accessing_
Capacity
Stability
Scalability
 Performance testing can be either qualitative or quantitative can be divided into
different sub types such as load testing & stress testing.
Load testing:-
 It is a process of testing the behavior of software by applying maximum load in-terms
of software accessing and manipulating large input data.
 It can be done at both normal and peak load conditions. This type of testing identifies
load testing is performed with the help of automated tools such as load runner.
 Most of the time, load testing is performed with the help of automated tools such as load
runner, app loader, IBM rational.
Stress testing:-
 It includes testing the behavior of software under abnormal conditions.
 E.g:- It may include taking away some resources or applying a load beyond the actual
load limit.

81
 The software by applying the load to the system and taking over the resources used by
the software to identify the breaking point.
Component testing
 It is a method where testing of each component in an application is done separately.
 Component testing is also known as module and program testing.
 Component testing is done by the tester.
 In isolation from rest of the system depending on the development life cycle mode.
 In such case the missing software is replaced by stubs and drivers.
Stubs:-
 Stubs are dummy modules that are always distinguish as “called programs” that is
handle in integration testing Top down approach it used when sub programs are under
construction.
 Stubs are considered as the dummy modules that always simulate the low level modules.
Drivers:-
 Drivers are also known as dummy modules, which are always distinguished as “called
program”.
 It handled in Bottomup integration testing, it is only when main programs are under
construction.
 Driver are considered as the dummy modules that always simulate the high level model.
 Component testing is done by the testers. Before we start with the integration testing
always preferable to do the component testing.
Interface testing
 It is performed to evaluate system or components pass data and control correctly to one
another
 These modules are working properly and errors are handled properly.
Interface checklist:-
 Verify that communication between the systems are done correctly.
 Verify if all supported hardware and software has been tested..

82
 Verify if all linked documents be supported open on all platforms.
 Verify the security requirements or encryption.
 Check if a solution can handle network failures between website and application server.
Black box testing:-
 The technique of testing without having any knowledge of the interior working of the
application is called black box testing.
White box testing:-
 It is the detailed investigation of internal logic and structure of the code.
 White box testing is also called glass testing or open box testing.
 In order to perform white box testing on an application, a tester needs to known the
internal working of the code.
COCOMO Model
Introduction:-
 Boehm postulated that any software development project can be classified into one of
the following three categories based on the development
Organic
Semi detached
Embedded
 In order to classify a product into the identified categories, Boehm not only considered
the characteristics of the product but also those of the development team and
development environment.

83
 System programs interact directly with the hardware and typically involve meeting
timing constraints and concurrent processing.
Organic:-
 A development project can be considered of organic type, if the project deals with
developing a well understood application program the size of the development team is
reasonably small and the team members are experienced in developing similar types of
project.
Semidetached:-
 A development project can be considered of semidetached types, if the development
consists of a mixture of experienced and inexperienced staff.
 Team members may have limited experience on related systems but may be unfamiliar
with some aspects of the system being developed.
Embedded:-
 A development project is considered to be of embedded type, if the software being
developed is strongly coupled to complex hardware or if the stringent regulations on
the operational procedures exist.
COCOMO:-
 Constructive cost estimation model was proposed by Boehm [1981].
 According to Boehm software cost estimation should be done through three stages.
Basic COCOMO
Intermediate COCOMO
Complete COCOMO
Basic COCOMO Model:-
 The basic COCOMO model gives an approximate estimate of the project parameters.
 The basic COCOMO estimation model is given by the following expressions.
Effort=a1*(𝑲𝑳𝑶𝑪) 𝟐
𝒂
PM
𝑻 𝒅𝒆𝒗= b1*(𝑬𝒇𝒇𝒐𝒓𝒕) 𝟐
𝒃
Moths
 KLOC is the estimated size of the software product expressed in Kilo lines of code.

84
 a1 a2 b1 b2 are constants for each category of software products.
𝑇𝑑𝑒𝑣 is the estimated time to develop the software expressed in months
 Effort is the total effort required to develop the software product expressed in person
months(PMs).
Estimation of development effort:-
 For the three classes of software products the formulas for estimating the effort based
on the code size are shown below.
Organic:- Effort=2.4 (𝐾𝐿𝑂𝐶)1.05
PM
Semidetached:- Effort=3.0 (𝐾𝐿𝑂𝐶)1.12
PM
Embedded:- Effort=3.6 (𝐾𝐿𝑂𝐶)1.10
PM
Estimation of development time:-
 For the three classes of software product, the formulas for estimating the development
time based on the effort are given below.
Organic:- 𝑇𝑑𝑒𝑣 =2.5(𝑒𝑓𝑓𝑜𝑟𝑡)0.38
Months
Semidetached:- 𝑇𝑑𝑒𝑣 =2.5(𝑒𝑓𝑓𝑜𝑟𝑡)0.35
Months
Embedded:- 𝑇𝑑𝑒𝑣 =2.5(𝑒𝑓𝑓𝑜𝑟𝑡)0.32
Months
Example:-
 Organic type software product=32000 lines of source code.
 Average salary of software engineers= Rs 15000 Determine the effort required to
develop the software product and the nominal development time.
Solution:-
 From the basic COCOMO estimation formula for organic software
 Effort=2.4*(32)1.05
=91PM
 Nominal development time= 2.5*(91)0.38
=14
 Cost required to develop the product = 14 * 15000 Rs=2,10,000
Intermediate COCOMO Model:-
 The basic COCOMO Model assumes that effort and development time are functions of
the product size alone.

85
 A host of other project parameters besides the product size affect the efforts required to
develop the product as well as the development time.
 In general, the cost drivers can be classified as being attributes of the following items
Product
Computer
Personnel
Development environment
Product:-
 The characteristics of the product that are considered include inherent complexity of
the product, reliability requirements of the product etc.
Computer:-
 Characteristics of the computer that are considered include the execution speed
required storage pace required etc.
Personnel:-
 The attributes of development personnel that are considered include the experience
level of personnel programming capability, analysis capability etc.
Development environment:-
 Development environment attributes capture the development facilities available to the
developers.
 CASE tools used for software development.
Complete COCOMO model:-
 A major short coming of both the basic and intermediate COCOMO models is that they
consider a software product as a single homogeneous entity.
 However, most large system are made up several smaller subsystems.
E.g:-
 If some subsystem may be considered as organic type, some semidetached and some
embedded.

86
 The complete COCOMO model considers these differences in characteristics of the
subsystems and estimates the effort and development.
 The cost of each subsystems is estimated separately. This approach reduces the margin
of error in the final estimate.
 A distributed management information system product of an organization having
offices at several places across the country can have the following sub components
Database part
Graphical user interface part
Communication part
 The communication part can be considered as embedded software.
 The database part can be semi-detached software.
 The GUI part can be organic software.
 The costs for these three components can be estimated separately and summed up to
give the overall cost of the system.
Quality management:-
 It is a software to develop without faults and conform to its specification
 Quality managers are responsible for three kind of activity
Quality assurance
Quality control
Quality planning
Quality assurance:-
 They must establish organizational procedures and standards which leads to high
quality software.
Quality control:-
 They must ensure that procedure and standards are followed by the software
development team.
Quality planning:-
 They must select appropriate procedure and standards are followed by the software
development team.

87
Process quality assurance:-
 Quality of the development process directly affects the quality of the delivered product.
 Process quality is particularly important in software development.
 The reason for this is that it is difficult to measure software attributes such as
maintainability without using the software for a long period.
 Quality manager must ensure that the quality of the software process that is used this
involves
4) Defining process standard such as how review should be conducted when
review should be help on and show on.
5) Monitoring the development process to ensure that the standards are bein
followed
6) Reporting the standard product management & to the buyer of the software.
Product quality:-
 We can quality the product depending upon following.
Design quality metric
Program quality metric
Documentation quality metric
Design quality metric:-
 There are number of possible design attributes which are important but we know that
the key attribute is maintainability.
Cohesion:- How closely are the part of the component related?
Coupling:- How independent is a component.
Understandability:- How easy is to understand the function of a component.
Program quality metrics:-
 We can quality the program using the following metric.
Length of code
Cyclometric complexity
Length of identifiers
Depth of conditional nesting

88
Length of code:-
 This is a measure of the sixe of program
 Generally the larger the size of the code of a program components.
Cyclometric complexity:-
 This is a measure of a control complexity of a program
 This control complexity is related to program understand ability
Length of identifier:-
 This is a measure of the average length of different identifiers in a program
Depth of conditional nesting:-
 This is a measure of the depth of nested if statement in a program
 Nested if statements are hand to understand and potentially error prone
Documentation quality metric:-
 The quality of the documentation associated with a software product is as important as
the quality of the software itself.
 The best known of these metric running for index which is the measure of the
readability of a passage of text
Software metric:-
 Any type of measurement which relates to software system, process are related
documentation
 Line of code in program the for index, no.of person base require to develop a
component.
 Allow the software and the software process to be qualified.
Predictor & control metrics
Control metric:-
 This metric used by the management to control the software process.

89
Predictor metric:-
 Measurement of product attribute that can be used to predict an associated product
quality
Internal and external attributes:-

Software engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software engineering

Similar to Software engineering (20)

Recently uploaded

Recently uploaded (20)

Software engineering