Software engineering lecture notes

Software Engineering(MCA 512)
MCA V Sem
Unit-I: Introduction
Faculty: Ms. Savita Mittal
Lecture 1
Topic :Introduction to Software Engineering
Software is a program or set of programs containing instructions which provide desired
functionality . And Engineering is the processes of designing and building something that serves
a particular purpose and find a cost effective solution to problems.
Software Engineering is a systematic approach to the design, development, operation, and
maintenance of a software system.
Dual Role of Software:
1. As a product –
It delivers the computing potential across network of Hardware.
It enables the Hardware to deliver the expected functionality.
It acts as information transformer because it produces, manages, acquires, modifies, displays, or
transmits information.
2. As a vehicle for delivering a product –
It provides system functionality (e.g., payroll system)
It controls other software (e.g., an operating system)
It helps build other software (e.g., software tools)
Objectives of Software Engineering:
1. Maintainability –
It should be feasible for the software to evolve to meet changing requirements.
2. Correctness –
A software product is correct, if the different requirements as specified in the SRS document
have been correctly implemented.
3. Reusability –
A software product has good reusability, if the different modules of the product can easily be
reused to develop new products.
4. Testability –
Here software facilitates both the establishment of test criteria and the evaluation of the software
with respect to those criteria.
5. Reliability –
It is an attribute of software quality. The extent to which a program can be expected to perform
its desired function, over an arbitrary time period.
6. Portability –
In this case, software can be transferred from one computer system or environment to another.
7. Adaptability –

In this case, software allows differing system constraints and user needs to be satisfied by
making changes to the software.
Compiled By:Ms. Savita Mittal(Astt.Professor,DCA)
References :
@existek.com
support@dzone.com
@geeksforgeeks
Lecture 2: 21/9/2020
Topic:Program vs Software Product
A program is a set of instructions which is given to a computer in order to achieve a specific task
whereas a software is when a program is made available for commercial business and is properly
documented along with its licensing.
Software=Program+documentation+licensing.
A program is one of the stages involved in the development of the software, whereas a software
development usually follows a life cycle, which involves the feasibility study of the project,
requirement gathering, development of a prototype, system design, coding and testing.
Software Characteristics:
Software is defined as collection of computer programs, procedures, rules and data. Software
Characteristics are classified into six major catagories:
1.Functionality:
It refers to the degree of performance of the software against its intended purpose.
Required functions are:
2.Reliability:
A set of attribute that bear on capability of software to maintain its level of performance under
the given condition for a stated period of time.
3.Efficiency:
It refers to the ability of the software to use system resources in the most effective and efficient
manner.the software should make effective use of storage space and executive command as per
desired timing requirement.
4.Usability:
It refers to the extent to which the software can be used with ease.the amount of effort or time
required to learn how to use the software.
5.Maintainability:
It refers to the ease with which the modifications can be made in a software system to extend its
functionality, improve its performance, or correct errors.
6.Portability:
A set of attribute that bear on the ability of software to be transferred from one environment to
another, without or minimum changes.

Software-Components:
(SW-C) are architectural elements that provide and/or require interfaces and are connected to
each other through the Virtual Functional Bus to fulfill architectural responsibilities. The
Software Component is the central structural element used when building a system at the
VFB-level.
Following are the components of a software system:
1.Network and Internet Services.
2.Hardware Level of Operating System.
3.Logical Level of Operating System.
4.Graphics Engine.
5.User Interface.
6.System Services.
7.Command Shell.
8.System Utilities.
Compiled By: Ms. Savita Mittal(Astt. Professor,DCA)
References :
@existek.com
support@dzone.com
@geeksforgeeks
Lecture 3: 26/9/2020
Another view of S/W Components is:
There are three components of the software:
1.Program: A computer program is a list of instructions that tell a computer what to do.
2.Documentation: Source information about the product contained in design documents,
detailed
code comments, etc.
3.Operating Procedures:
Set of step-by-step instructions compiled by an organization to help workers carry out complex
routine operations.
Software Crisis:
Software Crisis is a term used in computer science for the difficulty of writing useful and
efficient computer programs in the required time .software crisis was due to using same
workforce, same methods, same tools even though rapidly increasing in software demand,
complexity of software and software challenges. With increase in the complexity of software,
many software problems arise because existing methods were insufficient.
If we will use same workforce, same methods and same tools after fast increasing in software
demand, software complexity and software challenges, then there arose some problems like
software budget problem, software efficiency problem, software quality problem, software
managing and delivering problem etc. This condition is called software crisis.
Causes of Software Crisis:
The cost of owning and maintaining software was as expensive as developing the software

At that time Projects was running over-time
At that time Software was very inefficient
The quality of software was low quality
Software often did not meet requirements
The average software project overshoots its schedule by half
At that time Software was never delivered
Solution of Software Crisis:
There is no single solution to the crisis.
One possible solution of software crisis is Software Engineering because software engineering is
a systematic, disciplined and quantifiable approach. For preventing software crisis, there are
some guidelines:
1.Reduction in software over-budget
2.The quality of software must be high
3.Less time needed for software project
4.Experience working team member on software project
5.Software must be delivered
Compiled By:Ms. Savita Mittal(Astt. Professor,DCA)
References : @existek.com
support@dzone.com
@geeksforgeeks
Faculty: Savita Mittal
Lecture 4:
Software Processes in Software Engineering:
Software is the set of instructions in the form of programs to govern the computer system and to
process the hardware components. To produce a software product the set of activities is used.
This set is called a software process.
There are four basic key process activities:
1.Software Specifications:In this process, detailed description of a software system to be
developed with its functional and non-functional requirements.
2.Software Development:In this process, designing, programming, documenting, testing, and
bug fixing is done.
3.Software Validation:In this process, evaluation software product is done to ensure that the
software meets the business requirements as well as the end users needs.
4.Software Evolution:It is a process of developing software initially, then timely updating it for
various reasons.
Difference between Software Engineering process and Conventional Engineering Processs
1. Software Engineering Process : It is a engineering process which is mainly related to
computers and programming and developing different kinds of applications through the use of
information technology.

2. Conventional Engineering Process : It is a engineering process which is highly based on
empirical knowledge and is about building cars, machines and hardware.
Difference between
Software Engineering
Process and
Conventional
Engineering Process :
Compiled By: Ms. Savita
Mittal
References :
@existek.com
support@dzone.com
@geeksforgeeks
Software Engineering
Process is a process
which majorly involves
computer science,
information
Conventional
Engineering Process is a
process which majorly
involves science,
mathematics and
empirical
MCA V Sem
Lecture 5:
29/9/2020
Quality Attributes (Contd..)
Testability
Software testability is a measure of how easy is to create test criteria for the system and its
components, and to execute these tests that assess if the criteria are met.
Security
All systems must be capable of prevent malicious or accidental actions that aren't following designed
usage. With security comes a measure of the system’s ability to protect data and information from
unauthorized access while still providing access to people and systems that are authorized.
Usability
Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of
user support the system provides.
One of the basic notions of the software development process is SDLC models which stands for
Software Development Life Cycle models. SDLC – is a continuous process, which starts from the
moment, when it’s made a decision to launch the project, and it ends at the moment of its full remove

from the exploitation. There is no one single SDLC model. They are divided into main groups, each
with its features and weaknesses.
Evolving from the first and oldest “waterfall” SDLC model, their variety significantly expanded. The
SDLC models diversity is predetermined by the wide number of product types – starting with a web
application development to a complex medical software. And if you take one of the SDLC models
mentioned below as the basis – in any case, it should be adjusted to the features of the product,
project, and company. The most used, popular and important SDLC models are given below:
• • Waterfall model
• • Iterative model
• • Spiral model
• • V-shaped model
• • Agile model

No matter what type of the models has been chosen, each of them has basic stages which are used by
every software development company. Let’s explore those stages as this is important for the
understanding of the each of SDLC models and the differences between them.
BASIC STAGES OF SOFTWARE DEVELOPMENT LIFE CYCLE
Stage 1. Planning and requirement analysis
Each software development life cycle model starts with the analysis, in which the stakeholders of the
process discuss the requirements for the final product. The goal of this stage is the detailed definition
of the system requirements. Besides, it is needed to make sure that all the process participants have
clearly understood the tasks and how every requirement is going to be implemented. Often, the
discussion involves the QA specialists who can interfere the process with additions even during the
development stage if it is necessary.
Stage 2. Designing project architecture
At the second phase of the software development life cycle, the developers are actually designing the
architecture. All the different technical questions that may appear on this stage are discussed by all
the stakeholders, including the customer. Also, here are defined the technologies used in the project,
team load, limitations, time frames, and budget. The most appropriate project decisions are made
according to the defined requirements.
Stage 3. Development and programming
After the requirements approved, the process goes to the next stage – actual development.
Programmers start here with the source code writing while keeping in mind previously defined
requirements. The system administrators adjust the software environment, front-end programmers
develop the user interface of the program and the logics for its interaction with the server. The
programming by itself assumes four stages
• • Algorithm development
• • Source code writing
• • Compilation
• • Testing and debugging
Stage 4. Testing
The testing phase includes the debugging process. All the code flaws missed during the development
are detected here, documented, and passed back to the developers to fix. The testing process repeats
until all the critical issues are removed and software workflow is stable.
Stage 5. Deployment
When the program is finalized and has no critical issues – it is time to launch it for the end users.
After the new program version release, the tech support team joins. This department provides user
feedback; consult and support users during the time of exploitation. Moreover, the update of selected
components is included in this phase, to make sure, that the software is up-to-date and is invulnerable
to a security breach.

SDLC MODELS
Waterfall SDLC Model
Waterfall is a cascade SDLC model, in which development process looks like the flow, moving step
by step through the phases of analysis, projecting, realization, testing, implementation, and support.
This SDLC model includes gradual execution of every stage completely. This process is strictly
documented and predefined with features expected to every phase of this software development life
cycle model.
References : Compiled By:Ms. Savita Mitta
DCA
@existek.com
support@dzone.com
@geeksforgeeks
MCA V Sem
Lecture 6: 30/9/2020
Waterfall Model(Contd…)
ADVANTAGES
Simple to use and understand Disadvantages
The software is ready only after the last stage
is over
Management simplicity thanks to its rigidity:
every phase has a defined result and process
review
High risks and uncertainty
Development stages go one by one Not the best choice for complex and object-
oriented projects
Perfect for the small or mid-sized projects
where requirements are clear and not
equivocal
Inappropriate for the long-term projects

Easy to determine the key points in the
development cycle
The progress of the stage is hard to measure
while it is still in the development
Easy to classify and prioritize tasks Integration is done at the very end, which does
not give the option of identifying the problem
in advance
Use cases for the Waterfall SDLC model:
• • The requirements are precisely documented
• • Product definition is stable
• • The technologies stack is predefined which makes it not dynamic
• • No ambiguous requirements
• • The project is short
Iterative SDLC Model
The Iterative SDLC model does not need the full list of requirements before the project starts. The
development process may start with the requirements to the functional part, which can be
expanded later. The process is repetitive, allowing to make new versions of the product for every
cycle. Every iteration (which last from two to six weeks) includes the development of a separate
component of the system, and after that, this component is added to the functional developed
earlier. Speaking with math terminology, the iterative model is a realization of the sequential
approximation method; that means a gradual closeness to the planned final product shape.
ADVANTAGES DISADVANTAGES
Some functions can be quickly developed at
the beginning of the development lifecycle
Iterative model requires more resources than
the waterfall model
The paralleled development can be applied Constant management is required
The progress is easy measurable Issues with architecture or design may occur

because not all the requirements are foreseen
during the short planning stage
The shorter iteration is - the easier testing and
debugging stages are
Bad choice for the small projects
It is easier to control the risks as high-risk
tasks are completed first
The process is difficult to manage
Problems and risks defined within one
iteration can be prevented in the next sprints
The risks may not be completely determined
even at the final stage of the project
Flexibility and readiness to the changes in the
requirements
Risks analysis requires involvement of the
highly-qualified specialists
Use cases for the Iteration model:
• • The requirements to the final product are strictly predefined
• • Applied to the large-scale projects
• • The main task is predefined, but the details may advance with the time
References : Compiled By:Ms. Savita Mittal , DCA
@existek.com
support@dzone.com
@geeksforgeeks
MCA V Sem
Lecture 7:
1/10/2020
Spiral SDLC Model
Spiral model – is SDLC model, which combines architecture and prototyping by stages. It is a
combination of the Iterative and Waterfall SDLC models with the significant accent on the risk
analysis. The main issue of the spiral model – is defining the right moment to make a step into
the next stage. The preliminary set time frames are recommended as the solution to this issue.
The shift to the next stage is done according to the plan, even if the work on the previous stage
isn’t done yet. The plan is introduced basing on the statistic data, received during the previous
projects even from the personal developer’s experience.

Lifecycle is divided into small parts, and if the risk
concentration is higher, the phase can be finished earlier
to address the treats
Can be quite expensive
The development process is precisely documented yet
scalable to the changes
The risk control demands involvement
of the highly-skilled professionals
The scalability allows to make changes and add new
functionality even at the relatively late stages
Can be ineffective for the small
projects
The earlier working prototype is done - sooner users can
point out the flaws
Big number of the intermediate stages
requires excessive documentation
Use cases for the Spiral model
 Customer isn’t sure about the requirements
 Major edits are expected during the development cycle
 The projects with mid or high-level risk, where it is important to prevent these risks
 The new product that should be released in a few stages to have enough of clients
feedback.

References : Compiled By:Ms. Savita Mittal(Astt. Professor,DCA)
@existek.com
support@dzone.com
@geeksforgeeks
MCA V Sem
Lecture 8:
5/10/2020
V-shaped SDLC Model
V-shaped SDLC model is an expansion of classic waterfall model and it’s based on associated
test stage for the every development stage. This is a very strict model and the next stage is started
only after the previous phase. This is also called “Validation and verification” model. Every
stage has the current process control, to make sure that the conversion to the next stage is

possible.
Every stage of V-shaped model has strict results so it’s easy to control Lack of the flexibility
Testing and verification take place in the early stages Bad choice for the small projects
Good for the small projects, where requirements are static and clear Relatively big risks
Use cases for the V-shaped model:
 For the projects where an accurate product testing is required
 For the small and mid-sized projects, where requirements are strictly predefined
 The engineers of the required qualification, especially testers, are within easy reach.
Agile SDLC Model
In the agile methodology after every development iteration, the customer is able to see the result
and understand if he is satisfied with it or he is not. This is one of the advantages of the agile
software development life cycle model. One of its disadvantages is that with the absence of
defined requirements it is difficult to estimate the resources and development cost. Extreme
programming is one of the practical use of the agile model. The basis of such model consists of

short weekly meetings – Sprints which are the part of the Scrum approach.
Corrections of functional requirements are
implemented into the development process to provide
the competitiveness
Difficulties with measuring the final cost
because of permanent changes
Project is divided by short and transparent iterations
The team should be highly professional and
client-oriented
Risks are minimized thanks to the flexible change
process
New requirements may conflict with the
existing architecture
Fast release of the first product version
With all the corrections and changes there is
possibility that the project will exceed expected
time
Use cases for the Agile model:
 The users’ needs change dynamically
 Less price for the changes implemented because of the many iterations
 Unlike the Waterfall model, it requires only initial planning to start the project
Conclusion

During the years of the SDLC evolution, different models were developed from the basic
cascade model to meet a huge variety of development requirements and expectations. There is no
only one suitable model for all the projects, starting conditions and payment model. Even at the
first sight, multi-purpose Agile cannot be used widely because of some customers’
unpreparedness to scale the budget. The SDLC models often cross in the solutions and
particularly look similar.
References : Compiled By:Ms. Savita Mittal(Astt. Professor,DCA)
@existek.com
support@dzone.com
@geeksforgeeks
SW Engg. Unit 2
Lecture 9
S/W Engg. Process

Activities of S/w Engg. Process:
Elicitation, Analysis, Documentation, Review and
Management of User Needs
Requirement Engineering
Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analyzing the
need, and assessing feasibility, negotiating a reasonable solution, specifying the solution
clearly, validating the specifications and managing the requirements as they are transformed
into a working system. Thus, requirement engineering is the disciplined application of proven
principles, methods, tools, and notation to describe a proposed system's intended behavior and
its associated constraints.
Requirement Engineering Process
It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software
that is acceptable to users, flexible to change and conformable to established standards.
Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the current technologies, which
are needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and customer
requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software
can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with
the help of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.
Problems of Elicitation and Analysis
o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

Lecture 10(8/10/2020)
Lecture 10 (8/10/2020)
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software
that is acceptable to users, flexible to change and conformable to established standards.
Types of Feasibility:
4. Technical Feasibility - Technical feasibility evaluates the current technologies, which
are needed to accomplish customer requirements within the time and budget.
5. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and customer
requirements.

6. Economic Feasibility - Economic feasibility decides whether the necessary software
can generate financial profits for an organization.
2. Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with
the help of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.
Problems of Elicitation and Analysis
o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:
Software requirement specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources - the requirement received
by the customer written in ordinary language. It is the job of the analyst to write the
requirement in technical language so that they can be understood and beneficial by the
development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.
o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a
company, an organization, a set of procedures, a computer hardware system, a
software system, or any combination of the preceding. The DFD is also known as a
data flow graph or bubble chart.

o Data Dictionaries: Data Dictionaries are simply repositories to store information
about all data items defined in DFDs. At the requirements stage, the data dictionary
should at least define customer data items, to ensure that the customer and developers
use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the
entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e. data
entities, relationships, and their associated attributes.
References: GeeksForGeeks Compiled By: Ms. Savita Mittal(Astt.Prof.; DCA)
JavaT
Books:
Gill, Naseeb Singh- S/E Engineering
Pressman, R- S/E Engineering
Software Engineering – MCA 512 Unit II
Lecture 11(12/10/2020)
4. Software Requirement Validation:
After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the check against the following conditions -
o If they can practically implement
o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques
o Requirements reviews/inspections: systematic manual analysis of the requirements.
o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.

o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.
Software Requirement Management:
Requirement management is the process of managing changing requirements during the
requirements engineering process and system development.
New requirements emerge during the process as business needs a change, and a better
understanding of the system is developed.
The priority of requirements from different viewpoints changes during development process.
The business and technical environment of the system changes during the development.
Prerequisite of Software requirements
Collection of software requirements is the basis of the entire software development project.
Hence they should be clear, correct, and well-defined.
A complete Software Requirement Specifications should be:
o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source
Software Requirements: Software requirement categories:
1. Functional Requirements: Functional requirements define a function that a system
or system element must be qualified to perform and must be documented in different
forms. The functional requirements are describing the behavior of the system as it
correlates to the system's functionality.

2. Non-functional Requirements: This can be the necessities that specify the criteria
that can be used to decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run
time.
o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software
An information model in software engineering is a representation of concepts and the
relationships, constraints, rules, and operations to specify data semantics for a chosen domain of
discourse. Typically it specifies relations between kinds of things, but may also include relations
with individual things. It can provide sharable, stable, and organized structure of information
requirements or knowledge for the domain context.[1]
The term information model in general is used for models of individual things, such as facilities,
buildings, process plants, etc. In those cases the concept is specialised to facility information
model, building information model, plant information model, etc. Such an information model is
an integration of a model of the facility with the data and documents about the facility.
Within the field of software engineering and data modeling an information model is usually an
abstract, formal representation of entity types that may include their properties, relationships and
the operations that can be performed on them. The entity types in the model may be kinds of
real-world objects, such as devices in a network, or occurrences, or they may themselves be
abstract, such as for the entities used in a billing system. Typically, they are used to model a
constrained domain that can be described by a closed set of entity types, properties, relationships
and operations.
An information model provides formalism to the description of a problem domain without
constraining how that description is mapped to an actual implementation in software. There may
be many mappings of the information model. Such mappings are called data models, irrespective
of whether they are object models (e.g. using UML), entity relationship models or XML
schemas.
References:
S/W Engg. Roger Pressman
Lecture 12(13/10/2020)
Information modeling languages

A sample ER diagram.
Database requirements for a CD collection in EXPRESS-G notation.
In 1976, an entity-relationship (ER) graphic notation was introduced by Peter Chen. He stressed
that it was a "semantic" modelling technique and independent of any database modelling
techniques such as Hierarchical, CODASYL, Relational etc.[2]
Since then, languages for
information models have continued to evolve. Some examples are the Integrated Definition
Language 1 Extended (IDEF1X), the EXPRESS language and the Unified Modeling Language
(UML).[1]
Research by contemporaries of Peter Chen such as J.R.Abrial (1974) and G.M Nijssen (1976) led
to today's Fact Oriented Modeling (FOM) languages which are based on linguistic propositions
rather than on "entities". FOM tools can be used to generate an ER model which means that the
modeler can avoid the time-consuming and error prone practice of manual normalization.
Object-Role Modeling language (ORM) and Fully Communication Oriented Information
Modeling (FCO-IM) are both research results, based upon earlier research.
In the 1980s there were several approaches to extend Chen’s Entity Relationship Model. Also
important in this decade is REMORA by Colette Rolland.[3]
The ICAM Definition (IDEF) Language was developed from the U.S. Air Force ICAM Program
during the 1976 to 1982 timeframe.[4]
The objective of the ICAM Program, according to Lee
(1999), was to increase manufacturing productivity through the systematic application of
computer technology. IDEF includes three different modeling methods: IDEF0, IDEF1, and
IDEF2 for producing a functional model, an information model, and a dynamic model
respectively. IDEF1X is an extended version of IDEF1. The language is in the public domain. It

is a graphical representation and is designed using the ER approach and the relational theory. It
is used to represent the “real world” in terms of entities, attributes, and relationships between
entities. Normalization is enforced by KEY Structures and KEY Migration. The language
identifies property groupings (Aggregation) to form complete entity definitions.[1]
EXPRESS was created as ISO 10303-11 for formally specifying information requirements of
product data model. It is part of a suite of standards informally known as the STandard for the
Exchange of Product model data (STEP). It was first introduced in the early 1990s.[5][6]
The
language, according to Lee (1999), is a textual representation. In addition, a graphical subset of
EXPRESS called EXPRESS-G is available. EXPRESS is based on programming languages and
the O-O paradigm. A number of languages have contributed to EXPRESS. In particular, Ada,
Algol, C, C++, Euler, Modula-2, Pascal, PL/1, and SQL. EXPRESS consists of language
elements that allow an unambiguous object definition and specification of constraints on the
objects defined. It uses SCHEMA declaration to provide partitioning and it supports
specification of data properties, constraints, and operations.[1]
UML is a modeling language for specifying, visualizing, constructing, and documenting the
artifacts, rather than processes, of software systems. It was conceived originally by Grady
Booch, James Rumbaugh, and Ivar Jacobson. UML was approved by the Object Management
Group (OMG) as a standard in 1997. The language, according to Lee (1999), is non-proprietary
and is available to the public. It is a graphical representation. The language is based on the
objected-oriented paradigm. UML contains notations and rules and is designed to represent data
requirements in terms of O-O diagrams. UML organizes a model in a number of views that
present different aspects of a system. The contents of a view are described in diagrams that are
graphs with model elements. A diagram contains model elements that represent common O-O
concepts such as classes, objects, messages, and relationships among these concepts.[1]
IDEF1X, EXPRESS, and UML all can be used to create a conceptual model and, according to
Lee (1999), each has its own characteristics. Although some may lead to a natural usage (e.g.,
implementation), one is not necessarily better than another. In practice, it may require more than
one language to develop all information models when an application is complex. In fact, the
modeling practice is often more important than the language chosen.[1]
Information models can also be expressed in formalized natural languages, such as Gellish.
Gellish, which has natural language variants Gellish Formal English, Gellish Formal Dutch
(Gellish Formeel Nederlands), etc. is an information representation language or modeling
language that is defined in the Gellish smart Dictionary-Taxonomy, which has the form of a
Taxonomy/Ontology. A Gellish Database is not only suitable to store information models, but
also knowledge models, requirements models and dictionaries, taxonomies and ontologies.
Information models in Gellish English use Gellish Formal English expressions. For example, a
geographic information model might consist of a number of Gellish Formal English expressions,
such as:
- the Eiffel tower <is located in> Paris
- Paris <is classified as a> city
whereas information requirements and knowledge can be expressed for example as follows:
- tower <shall be located in a> geographical area
- city <is a kind of> geographical area

Such Gellish expressions use names of concepts (such as 'city') and relation types (such as ⟨is
located in⟩ and ⟨is classified as a⟩) that should be selected from the Gellish Formal English
Dictionary-Taxonomy (or of your own domain dictionary). The Gellish English Dictionary-
Taxonomy enables the creation of semantically rich information models, because the dictionary
contains definitions of more than 40000 concepts, including more than 600 standard relation
types. Thus, an information model in Gellish consists of a collection of Gellish expressions that
use those phrases and dictionary concepts to express facts or make statements, queries and
answers.
Standard sets of information models[edit]
The Distributed Management Task Force (DMTF) provides a standard set of information models
for various enterprise domains under the general title of the Common Information Model (CIM).
Specific information models are derived from CIM for particular management domains.
The TeleManagement Forum (TMF) has defined an advanced model for the Telecommunication
domain (the Shared Information/Data model, or SID) as another. This includes views from the
business, service and resource domains within the Telecommunication industry. The TMF has
established a set of principles that an OSS integration should adopt, along with a set of models
that provide standardized approaches.
The models interact with the information model (the Shared Information/Data Model, or SID),
via a process model (the Business Process Framework (eTOM), or eTOM) and a life cycle
model.
Levels in Data Flow Diagrams (DFD)
In Software engineering DFD(data flow diagram) can be drawn to represent the system of
different levels of abstraction. Higher level DFDs are partitioned into low levels-hacking more
information and functional elements. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we
will see mainly 3 levels in data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level
DFD.
0-level DFD:
It is also known as context diagram. It’s designed to be an abstraction view, showing the system
as a single process with its relationship to external entities. It represent the entire system as
single bubble with input and output data indicated by incoming/outgoing arrows.

References: GeeksForGeeks
JavaT
Jalote Pankaj ; S/W Engg
Pressman roger; S/W Engg
Lecture 13(15/10/2020)
Levels in Data Flow Diagrams (DFD)
In Software engineering DFD(data flow diagram) can be drawn to represent the system of
different levels of abstraction. Higher level DFDs are partitioned into low levels-hacking more
information and functional elements. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we
will see mainly 3 levels in data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level
DFD.
0-level DFD:
It is also known as context diagram. It’s designed to be an abstraction view, showing the system
as a single process with its relationship to external entities. It represent the entire system as
single bubble with input and output data indicated by incoming/outgoing arrows.

Lecture 13(13/10/2020)
1-level DFD:
In 1-level DFD, context diagram is decomposed into multiple bubbles/processes.in this level we
highlight the main functions of the system and breakdown the high level process of 0-level DFD
into subprocesses.

2-level DFD:
2-level DFD goes one step deeper into parts of 1-level DFD.It can be used to plan or record the
specific/necessary detail about the system’s functioning.

Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to produce a conceptual
data model of an information system. Diagrams created using this ER-modeling method are
called Entity-Relationship Diagrams or ER diagrams or ERDs.
Purpose of ERD
o The database analyst gains a better understanding of the data to be contained in the
database through the step of constructing the ERD.
o The ERD serves as a documentation tool.

o Finally, the ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.
Components of an ER Diagrams
1. Entity
An entity can be a real-world object, either animate or inanimate, that can be merely
identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a school
database, students, teachers, classes, and courses offered can be treated as entities. All these
entities have some attributes or properties that give them their identity.
Entity Set
An entity set is a collection of related types of entities. An entity set may include entities with
attribute sharing similar values. For example, a Student set may contain all the students of a
school; likewise, a Teacher set may include all the teachers of a school from all faculties.
Entity set need not be disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values.
For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.
There are four types of Attributes:
1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute
1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an
entity among the entity set. For example, the roll_number of a student makes him identifiable
among students.

Lecture 14(17/10/2020)
2-level DFD:
2-level DFD goes one step deeper into parts of 1-level DFD.It can be used to plan or record the
specific/necessary detail about the system’s functioning.

Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to produce a conceptual
data model of an information system. Diagrams created using this ER-modeling method are
called Entity-Relationship Diagrams or ER diagrams or ERDs.
Purpose of ERD
o The database analyst gains a better understanding of the data to be contained in the
database through the step of constructing the ERD.

o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.
Components of an ER Diagrams
1. Entity
An entity can be a real-world object, either animate or inanimate, that can be merely
identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a school
database, students, teachers, classes, and courses offered can be treated as entities. All these
entities have some attributes or properties that give them their identity.
Entity Set
An entity set is a collection of related types of entities. An entity set may include entities with
attribute sharing similar values. For example, a Student set may contain all the students of a
school; likewise, a Teacher set may include all the teachers of a school from all faculties.
Entity set need not be disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values.
For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.
There are four types of Attributes:
6. Key attribute
7. Composite attribute
8. Single-valued attribute
9. Multi-valued attribute
10. Derived attribute
1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an
entity among the entity set. For example, the roll_number of a student makes him identifiable
among students.

Lecture 15
26/10/2020
There are mainly three types of keys:
1. Super key: A set of attributes that collectively identifies an entity in the entity set.
2. Candidate key: A minimal super key is known as a candidate key. An entity set may
have more than one candidate key.
3. Primary key: A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.
2. Composite attribute: An attribute that is a combination of other attributes is called a
composite attribute. For example, In student entity, the student address is a composite
attribute as an address is composed of other characteristics such as pin code, state, country.

3. Single-valued attribute: Single-valued attribute contain a single value. For example,
Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a
multi-valued attribute. Multi-valued attributes are depicted by the double ellipse. For
example, a person can have more than one phone number, email-address, etc.
5. Derived attribute: Derived attributes are the attribute that does not exist in the physical
database, but their values are derived from other attributes present in the database. For
example, age can be derived from date_of_birth. In the ER diagram, Derived attributes are
depicted by the dashed ellipse.

3. Relationships
The association among entities is known as relationship. Relationships are represented by the
diamond-shaped box. For example, an employee works_at a department, a student enrolls in a
course. Here, Works_at and Enrolls are called relationships.

Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a
relationship too can have attributes. These attributes are called descriptive attributes.
Degree of a relationship set
The number of participating entities in a relationship describes the degree of the relationship.
The three most common relationships in E-R models are:
1. Unary (degree1)
2. Binary (degree2)
3. Ternary (degree3)
1. Unary relationship: This is also called recursive relationships. It is a relationship between
the instances of one entity type. For example, one person is married to only one person.
2. Binary relationship: It is a relationship between the instances of two entity types. For
example, the Teacher teaches the subject.

3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig,
the relationships "may have" provide the association of three entities, i.e., TEACHER,
STUDENT, and SUBJECT. All three entities are many-to-many participants. There may be
one or many participants in a ternary relationship.
In general, "n" entities can be related by the same relationship and is known as n-ary
relationship.
Lecture 16
Date : 28/10/2020
Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the
number of entities of other sets via relationship set.
Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of entity
set B and vice versa. Let us assume that each student has only one student ID, and each
student ID is assigned to only one person. So, the relationship will be one to one.
Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with more than one
instances of another entity then it is called one to many relationships. For example, a client
can place many orders; a order cannot be placed by many customers.
3. Many to One: More than one entity from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than
one entity from entity set A. For example - many students can study in a single college, but a
student cannot study in many colleges at the same time.
4. Many to Many: One entity from A can be associated with more than one entity from B
and vice-versa. For example, the student can be assigned to many projects, and a project can
be assigned to many students.
Software Engineering | Decision Table
Decision table is a brief visual representation for specifying which actions to perform depending on given
conditions. The information represented in decision tables can also be represented as decision trees or in a
programming language using if-then-else and switch-case statements.
A decision table is a good way to settle with different combination inputs with their corresponding
outputs and also called cause-effect table. Reason to call cause-effect table is a related logical
diagramming technique called cause-effect graphing that is basically used to obtain the decision table.
Importance of Decision Table:
1. Decision tables are very much helpful in test design technique.
2. It helps testers to search the effects of combinations of different inputs and other software states
that must correctly implement business rules.
3. It provides a regular way of stating complex business rules, that is helpful for developers as well as
for testers.
4. It assists in development process with developer to do a better job. Testing with all combination
might be impractical.
5. A decision table is basically an outstanding technique used in both testing and requirements
management.
6. It is a structured exercise to prepare requirements when dealing with complex business rules.
7. It is also used in model complicated logic.
Decision Table in test designing:
Blank Decision Table
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1

Condition 2
Condition 3
Condition 4
Decision Table: Combinations
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1 Y Y N N
Condition 2 Y N Y N
Condition 3 Y N N Y
Condition 4 N Y Y N
Advantage of Decision Table:
1. Any complex business flow can be easily converted into the test scenarios & test cases using this
technique.
2. Decision tables work iteratively that means the table created at the first iteration is used as input
table for next tables. The iteration is done only if the initial table is not satisfactory.
3. Simple to understand and everyone can use this method design the test scenarios & test cases.
4. It provide complete coverage of test cases which help to reduce the rework on writing test scenarios
& test cases.
5. These tables guarantee that we consider every possible combination of condition values. This is
known as its completeness property.
References: GeeksForGeeks
Java T
MCA V Sem
Unit-II: Software Requirement Specifications (SRS)
Lecture 17
A software requirements specification (SRS) is a description of a software system to be
developed. It is modeled after business requirements specification (CONOPS), also known as
a stakeholder requirements specification (StRS).[citation needed]
The software requirements
specification lays out functional and non-functional requirements, and it may include a set of use

cases that describe user interactions that the software must provide to the user for perfect
interaction.
Software requirements specification establishes the basis for an agreement between customers
and contractors or suppliers on how the software product should function (in a market-driven
project, these roles may be played by the marketing and development divisions). Software
requirements specification is a rigorous assessment of requirements before the more specific
system design stages, and its goal is to reduce later redesign. It should also provide a realistic
basis for estimating product costs, risks, and schedules.[1]
Used appropriately, software
requirements specifications can help prevent software project failure.[2]
The software requirements specification document lists sufficient and necessary requirements for
the project development.[3]
To derive the requirements, the developer needs to have clear and
thorough understanding of the products under development. This is achieved through detailed
and continuous communications with the project team and customer throughout the software
development process.
The SRS may be one of a contract's deliverable data item descriptions[4]
or have other forms of
organizationally-mandated content.
Typically a SRS is written by a technical writer, a systems architect, or a software programmer.[5]
Structure
An example organization of an SRS is as follows:[6]
1. Purpose
1. Definitions
2. Background
3. System overview
4. References
2. Overall description
1. Product perspective
1. System Interfaces
2. User interfaces
3. Hardware interfaces
4. Software interfaces
5. Communication Interfaces
6. Memory constraints
2. Design constraints
1. Operations
2. Site adaptation requirements
3. Product functions
4. User characteristics
5. Constraints, assumptions and dependencies
3. Specific requirements
1. External interface requirements
2. Functional requirements

3. Performance requirements
4. Logical database requirement
5. Software system attributes
1. Reliability
2. Availability
3. Security
4. Maintainability
5. Portability
6. Functional requirements
1. Functional partitioning
2. Functional description
3. Control description
7. Environment characteristics
1. Hardware
2. Peripherals
3. Users
8. Other
Goals
The software requirements specification (SRS) is a communication tool between users and
software designers. The specific goals of the SRS are as follows:
 Facilitating reviews
 Describing the scope of work
 Providing a reference to software designers (i.e. navigation aids, document structure)
 Providing a framework for testing primary and secondary use cases
 Including features to customer requirements
 Providing a platform for ongoing refinement (via incomplete specs or questions)
Requirements smell
Following the idea of code smells, the notion of requirements smell has been proposed to
describe issues in requirements specification where the requirement is not necessarily
wrong but could be problematic.
Examples of requirements smells are subjective language, ambiguous adverbs and adjectives,
superlatives and negative statements.
References:
Java T
Compiled By:
Ms. Savita Mittal

MCA V Sem
Lecture 18
Topic: Verification and Validation
The Software Quality Assurance (SQA) process compromises of the verification and validation
process of the software code. In general, guaranteeing that the software conforms to its
specification while meeting the customer needs. Let us compare and contrast the verification and
validation process.
Verification and validation begin by reviewing the requirements and covering the design and
analysis of the code up to the product testing. For this reason, verification demands to check that
the program meets specified requirements. While, on the other hand, validation requires
examining that the software product meets the client expectation as well as a formal proof of
program correctness (IEEE, 1990).
Software Quality Assurance (SQA) is a set of activities for ensuring quality in software
engineering processes. It ensures that developed software meets and complies with the defined or

standardized quality specifications. SQA is an ongoing process within the Software Development
Life Cycle (SDLC) that routinely checks the developed software to ensure it meets the desired
quality measures.
SQA practices are implemented in most types of software development, regardless of the
underlying software development model being used. SQA incorporates and implements software
testing methodologies to test the software. Rather than checking for quality after completion,
SQA processes test for quality in each phase of development, until the software is complete.
With SQA, the software development process moves into the next phase only once the
current/previous phase complies with the required quality standards. SQA generally works on
one or more industry standards that help in building software quality guidelines and
implementation strategies.
It includes the following activities −
 Process definition and implementation
 Auditing
 Training
Processes could be −
 Software Development Methodology
 Project Management
 Configuration Management
 Requirements Development/Management
 Estimation
 Software Design
 Testing, etc.
Once the processes have been defined and implemented, Quality Assurance has the following
responsibilities −
 Identify the weaknesses in the processes
 Correct those weaknesses to continually improve the process
Components of SQA System
An SQA system always combines a wide range of SQA components. These components can be
classified into the following six classes −
Pre-project components
This assures that the project commitments have been clearly defined considering the resources
required, the schedule and budget; and the development and quality plans have been correctly
determined.

Components of project life cycle activities assessment
The project life cycle is composed of two stages: the development life cycle stage and the
operation–maintenance stage.
The development life cycle stage components detect design and programming errors. Its
components are divided into the following sub-classes: Reviews, Expert opinions, and Software
testing.
The SQA components used during the operation–maintenance phase include specialized
maintenance components as well as development life cycle components, which are applied
mainly for functionality to improve the maintenance tasks.
Components of infrastructure error prevention and improvement
The main objective of these components, which is applied throughout the entire organization, is
to eliminate or at least reduce the rate of errors, based on the organization’s accumulated SQA
experience.
Components of software quality management
This class of components deal with several goals, such as the control of development and
maintenance activities, and the introduction of early managerial support actions that mainly
prevent or minimize schedule and budget failures and their outcomes.
Components of standardization, certification, and SQA system assessment
These components implement international professional and managerial standards within the
organization. The main objectives of this class are utilization of international professional
knowledge, improvement of coordination of the organizational quality systems with other
organizations, and assessment of the achievements of quality systems according to a common
scale. The various standards may be classified into two main groups: quality management
standards and project process standards.
Organizing for SQA – the human components
The SQA organizational base includes managers, testing personnel, the SQA unit and the
persons interested in software quality such as SQA trustees, SQA committee members, and SQA
forum members. Their main objectives are to initiate and support the implementation of SQA
components, detect deviations from SQA procedures and methodology, and suggest
improvements.
Compiled By:
Savita Mittal
MCA V Sem

Lecture 19
Topic: ISO 9000 ; SEI-CMM
The ISO 9000 family of standards is the same across the globe even though they are called by different
names. Each member country has their own entity authorized by ISO to manage the standards, but they
are all the same exact ISO 9000 quality documents.
What is the ISO 9000 series of quality management system standards?
The ISO 9000 series was created by the International Organization for Standardization (ISO) as
international requirements and guidelines for quality management systems. It was originally
introduced in 1987 and over the years has established itself in the global economy having been
adopted in over 178 countries with over one million registrations.
The phrase “ISO 9000 family” or “ISO 9000 series” refers to a group of quality management
standards which are process standards (not product standards).
 ISO 9000 Quality management systems – Fundamentals and Vocabulary, referenced in all
ISO 9000 Standards.
 ISO 9001 Quality management systems – Requirements, contains the requirements an
organization must comply with to become ISO 9001 certified.
 ISO 9002 – Guidelines for the application of ISO 9001:2015
 ISO 9004 – Managing for the sustained success of an organization, provides guidelines for
sustaining QMS success through evaluation and performance improvement.
ISO 9001:2015 is the current version of the ISO 9001 standard. ISO 9001 lists
requirements, while the other standards in the 9000 family provide guidelines and
information. People often say “ISO 9000 certified“, but what they mean is they have met
the requirements of the ISO 9001 standard. Read more about ISO 9001 Certification.
The ISO 9000 Series of Quality Standards is not industry specific and is applicable to any
manufacturing, distribution or service organization. It is managed by Technical
Committee (TC) 176, comprised of international members from many industries and
backgrounds.
What are the older (obsolete) ISO 9000 quality standards?
ISO 9000 (1994) originally had three QMS models depending on the primary function:

 ISO 9001:1994 Model for quality assurance in design, development, production,
installation, and servicing was for companies and organizations whose activities
included the creation of new products.
 ISO 9002:1994 Model for quality assurance in production, installation, and
servicing had basically the same material as ISO 9001 but without covering the
creation of new products. Learn more about ISO 9002.
 ISO 9003:1994 Model for quality assurance in final inspection and test covered
only the final inspection of finished product, with no concern for how the product
was produced. Learn more about ISO 9003.
All of these were combined into ISO 9001:2000, which was updated to ISO
9001:2008 and is now ISO 9001:2015.
What standards support the ISO 9000 Series of Quality Standards?
Other ISO quality standards were created to support the ISO 9000 family, and not
all start with ISO 9001:
 ISO 10000 Series of Standards
 What is ISO 19011?
 What is ISO/IEC 17021?
Standards based upon ISO 9001
There are other ISO quality standards created based up the 9000 family
which are specific to certain industries (Aerospace, Automotive Medical
Devices, etc):
Software Engineering | Capability maturity model (CMM)
CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in 1987.
 It is not a software process model. It is a framework which is used to analyse the approach and
techniques followed by any organization to develop software products.
 It also provides guidelines to further enhance the maturity of the process used to develop those
software products.
 It is based on profound feedback and development practices adopted by the most successful
organizations worldwide.

 This model describes a strategy for software process improvement that should be followed by
moving through 5 different levels.
 Each level of maturity shows a process capability level. All the levels except level-1 are further
described by Key Process Areas (KPA’s).
Key Process Areas (KPA’s):
Each of these KPA’s defines the basic requirements that should be met by a software process in order to
satisfy the KPA and achieve that level of maturity.
Conceptually, key process areas form the basis for management control of the software project and
establish a context in which technical methods are applied, work products like models, documents, data,
reports, etc. are produced, milestones are established, quality is ensured and change is properly managed.

The 5 levels of CMM are as follows:
Level-1: Initial –

 No KPA’s defined.
 Processes followed are adhoc and immature and are not well defined.
 Unstable environment for software dvelopment.
 No basis for predicting product quality, time for completion, etc.
Level-2: Repeatable –
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar natured projects.
 Project Planning- It includes defining resources required, goals, constraints, etc. for the project. It
presents a detailed plan to be followed systematically for successful completion of a good quality
software.
 Configuration Management- The focus is on maintaining the performance of the software
product, including all its components, for the entire lifecycle.
 Requirements Management- It includes the management of customer reviews and feedback
which result in some changes in the requirement set. It also consists of accommodation of those
modified requirements.
 Subcontract Management- It focuses on the effective management of qualified software
contractors i.e. it manages the parts of the software which are developed by third parties.
 Software Quality Assurance- It guarantees a good quality software product by following certain
rules and quality standard guidelines while development.
Level-3: Defined –
 At this level, documentation of the standard guidelines and procedures takes place.
 It is a well defined integrated set of project specific software engineering and management
processes.
 Peer Reviews- In this method, defects are removed by using a number of review methods like
walkthroughs, inspections, buddy checks, etc.
 Intergroup Coordination- It consists of planned interactions between different development
teams to ensure efficient and proper fulfilment of customer needs.
 Organization Process Definition- It’s key focus is on the development and maintenance of the
standard development processes.
 Organization Process Focus- It includes activities and practices that should be followed to improve
the process capabilities of an organization.
 Training Programs- It focuses on the enhancement of knowledge and skills of the team members
including the developers and ensuring an increase in work efficiency.
Level-4: Managed –
 At this stage, quantitative quality goals are set for the organization for software products as well
as software processes.
 The measurements made help the organization to predict the product and process quality within
some limits defined quantitatively.

 Software Quality Management- It includes the establishment of plans and strategies to develop a
quantitative analysis and understanding of the product’s quality.
 Quantitative Management- It focuses on controlling the project performance in a quantitative
manner.
Level-5: Optimizing –
 This is the highest level of process maturity in CMM and focuses on continuous process
improvement in the organization using quantitative feedback.
 Use of new tools, techniques and evaluation of software processes is done to prevent recurrence
of known defects.
 Process Change Management- Its focus is on the continuous improvement of organization’s
software processes to improve productivity, quality and cycle time for the software product.
 Technology Change Management- It consists of identification and use of new technologies to
improve product quality and decrease the product development time.
 Defect Prevention- It focuses on identification of causes of defects and to prevent them from
recurring in future projects by improving project defined process.
Compiled By : Savita Mittal
Unit III – Software Design
Lecture 20
Topic : Basic Concept Of S/W Design
Software Design is the process to transform the user requirements into some suitable form, which
helps the programmer in software coding and implementation. During the software design phase,
the design document is produced, based on the customer requirements as documented in the SRS
document. Hence the aim of this phase is to transform the SRS document into the design
document.
The following items are designed and documented during the design phase:
 Different modules required.
 Control relationships among modules.
 Interface among different modules.
 Data structure among the different modules.
 Algorithms required to implement among the individual modules.

Objectives of Software Design:
1. Correctness:
A good design should be correct i.e. it should correctly implement all the functionalities of
the system.
2. Efficiency:
A good software design should address the resources, time and cost optimization issues.
3. Understandability:
A good design should be easily understandable, for which it should be modular and all the
modules are arranged in layers.
4. Completeness:
The design should have all the components like data structures, modules, and external
interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change whenever a change request is
made from the customer side.
Software Design Concepts:
Concepts are defined as a principal idea or invention that comes in our mind or in thought to
understand something. The software design concept simply means the idea or principle behind the
design. It describes how you plan to solve the problem of designing software, the logic, or thinking
behind how you will design software. It allows the software engineer to create the model of the
system or software or product that is to be developed or built. The software design concept
provides a supporting and essential structure or model for developing the right software. There are
many concepts of software design and some of them are given below:

Following points should be considered while designing a Software:
1. Abstraction- hide relevant data
Abstraction simply means to hide the details to reduce complexity and increases efficiency
or quality. Different levels of Abstraction are necessary and must be applied at each stage
of the design process so that any error that is present can be removed to increase the
efficiency of the software solution and to refine the software solution. The solution should
be described in broadways that cover a wide range of different things at a higher level of
abstraction and a more detailed description of a solution of software should be given at the
lower level of abstraction.
2. Modularity- subdivide the system
Modularity simply means to divide the system or project into smaller parts to reduce the
complexity of the system or project. In the same way, modularity in design means to
subdivide a system into smaller parts so that these parts can be created independently and
then use these parts in different systems to perform different functions. It is necessary to
divide the software into components known as modules because nowadays there are
different software available like Monolithic software that is hard to grasp for software
engineers. So, modularity is design has now become a trend and is also important.
3. Architecture- design a structure of something
Architecture simply means a technique to design a structure of something. Architecture in
designing software is a concept that focuses on various elements and the data of the

structure. These components interact with each other and use the data of the structure in
architecture.
4. Refinement- removes impurities
Refinement simply means to refine something to remove any impurities if present and
increase the quality. The refinement concept of software design is actually a process of
developing or presenting the software or system in a detailed manner that means to
elaborate a system or software. Refinement is very necessary to find out any error if present
and then to reduce it.
5. Pattern- a repeated form
The pattern simply means a repeated form or design in which the same shape is repeated
several times to form a pattern. The pattern in the design process means the repetition of a
solution to a common recurring problem within a certain context.
6. Information Hiding- hide the information
Information hiding simply means to hide the information so that it cannot be accessed by
an unwanted party. In software design, information hiding is achieved by designing the
modules in a manner that the information gathered or contained in one module is hidden
and it cant be accessed by any other modules.
7. Refactoring- reconstruct something
Refactoring simply means to reconstruct something in such a way that it does not affect the
behavior or any other features. Refactoring in software design means to reconstruct the
design to reduce and complexity and simplify it without affecting the behavior or its
functions. Fowler has defined refactoring as “the process of changing a software system in
a way that it won’t affect the behavior of the design and improves the internal structure”.
Different levels of Software Design:
There are three different levels of software design. They are:
1. Architectural Design:
The architecture of a system can be viewed as the overall structure of the system & the way
in which structure provides conceptual integrity of the system. The architectural design
identifies the software as a system with many components interacting with each other. At
this level, the designers get the idea of the proposed solution domain.
2. Preliminary or high-level design:
Here the problem is decomposed into a set of modules, the control relationship among
various modules identified and also the interfaces among various modules are identified.
The outcome of this stage is called the program architecture. Design representation
techniques used in this stage are structure chart and UML.
3. Detailed design:
Once the high level design is complete, detailed design is undertaken. In detailed design,
each module is examined carefully to design the data structure and algorithms. The stage
outcome is documented in the form of a module specification document.
Compiled By:
Ms.Savita Mittal

S/W Engineering
Unit 3
Lecture 21
Architectural Design
Introduction: The software needs the architectural design to represents the design of software.
IEEE defines architectural design as “the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a computer
system.” The software that is built for computer-based systems can exhibit one of these many
architectural styles.
Each style will describe a system category that consists of :
 A set of components(eg: a database, computational modules) that will perform a function
required by the system.
 The set of connectors will help in coordination, communication, and cooperation between
the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties of the system.
The use of architectural styles is to establish a structure for all the components of the system.
Taxonomy of Architectural styles:
1. Data centred architectures:
 A data store will reside at the center of this architecture and is accessed frequently by
the other components that update, add, delete or modify the data present within the
store.
 The figure illustrates a typical data centered style. The client software access a central
repository. Variation of this approach are used to transform the repository into a
blackboard when data related to client or data of interest for the client change the
notifications to client software.
 This data-centered architecture will promote integrability. This means that the
existing components can be changed and new client components can be added to the
architecture without the permission or concern of other clients.
 Data can be passed among clients using blackboard mechanism.

2. Data flow architectures:
 This kind of architecture is used when input data to be transformed into output data
through a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe and filter and
it has a set of components called filters connected by pipes.
 Pipes are used to transmit data from one component to the next.
 Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form. The filters don’t
require any knowledge of the working of neighboring filters.
 If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of
sequential components to transform it.

3. Call and Return architectures: It is used to create a program that is easy to scale and
modify. Many sub-styles exist within this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
 Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components.

4. Object Oriented architecture: The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The coordination and
communication between the components are established via the message passing.
5. Layered architecture:
 A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
 At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.
Compiled By:
Ms. Savita Mittal
Lecture 22
2.1 Modularisation
Modularisation (Morbach, Wiesner & Marquardt 2009, Doran, Tamma & Iannone 2007) extends
in three dimensions of the ontology: i) domain, ii) level, and iii) properties. Domain
modularisation refers to the creation of different modules at the domain level. The main criteria
are the knowledge representation and the intended use of the ontology in domain modularisation.

By using different and more importantly modules representing distinct parts of the domain, the
ontology can be reused as a whole, but also in parts, as demonstrated by the example of
eSymbiosis ontology in Figure 1, where distinct segments of the domain refer to processing
technologies, materials, description of the process using attributes, and description of
participants.
Sign in to download hi-res image
Figure 1. eSymbiosis ontology domain modularisation
Level modularisation serves a similar purpose as the domain modularisation (Figure 2); it is used
to differentiate the whole level of abstraction instead of distinct knowledge segments. It is more
useful for the reuse of top-level and meta-level ontologies, which usually consist of fewer classes
and properties in comparison to the domain level.
Sign in to download hi-res image
Figure 2. eSymbiosis ontology level modularisation
As with concepts, modularisation of the properties in the ontology is also possible and useful.
Properties can be grouped along their range, their function, or both. Grouping along the range

supports reusability of separate modules of the ontology while grouping along the function
supports the reusability of the ontology as a whole, but it also supplements the represented
knowledge, as it enables the use of these properties in an application in a more structured
approach aiding specific functionalities of the user .
Modularization Smells
Girish Suryanarayana, ... Tushar Sharma, in Refactoring for Software Design Smells, 2015
5.2.1 Rationale
Modularization concerns the logical partitioning of a software design so that the design becomes
easy to understand and maintain. One of the key enabling techniques for effective modularization
is to “decompose abstractions to manageable size.” In this context, Lanza and Marinescu [21]
recommend that “operations and classes should have a harmonious size, i.e., they should avoid
both size extremities.” When an abstraction has complex methods or a large number of methods,
it violates this enabling technique and the principle of modularization. Since the abstraction is
inadequately decomposed, we name this smell Insufficient Modularization.
MULTIFACETED ABSTRACTION VERSUS INSUFFICIENT MODULARIZATION
Note that Multifaceted Abstraction smell (Section 3.4) is different from Insufficient
Modularization smell. In Multifaceted Abstraction, an abstraction addresses more than one
responsibility, thereby violating the Single Responsibility Principle (SRP). In Insufficient
Modularization, an abstraction violates the Principle of Decomposition, indicating that the
abstraction is large, complex, or both. Interestingly, these two smells often occur together: It is
common to see a large and complex abstraction that has multiple responsibilities. However, they
are different smells: An abstraction could have a single responsibility, but could still be large and
complex. Similarly, an abstraction could be small, but could still have multiple responsibilities.
Design modularity enables production modularity
Modularization of platform architectures matters also because it determines whether
development around a platform can feasibly be organized as an ecosystem or whether it must be
done within the boundaries of a single organization. Different architectures impose different
constraints on those who interact with it or are exposed to it (van Schewick, 2012, p. 4). The
preceding discussion focuses primarily on modularity in design, overlooking another kind of
modularity—modularity in production (Gamba and Fusari, 2009), which refers to modularity in
the logic used to organize production of a design. A traditionally integrated organization
represents a monolithic organizing logic whereas a distributed ecosystem composed on many
independent app developers represents a modular organizing logic used for producing the design.
Modularity of production is a platform governance decision (the focus of the next chapter), but
one whose feasibility is determined by modularity of the platform’s design. Lack of design
modularity, in contrast, makes production modularity infeasible (Langlois, 2002; Sanchez and
Mahoney, 1996). Architectural choices therefore preordain the realm of execution possibilities.
This is the essence of the mirroring principle. Design modularity and production modularity are
therefore fundamentally isomorphic (i.e., design modularity enables production modularity)
(Baldwin and Clark, 2000, p. 12; Hoetker, 2006). A platform’s architecture is therefore
particularly decisive in the evolution of its ecosystem because it is closely intertwined with the

organization of the ecosystem: who chooses to participate, how much they are willing and able to
invest in creating complementary innovations around a platform, and their incentives to innovate.
Reference: 28th European Symposium on Computer Aided
Process Engineering
Nikolaos Trokanas, ... Franjo Cecelja, in Computer Aided Chemical Engineering, 2018
S/W Engg.(MCA 512)
Unit 3
Lecture 23
Design Structure Charts
Structure Chart represent hierarchical structure of modules. It breaks down the entire system into
lowest functional modules, describe functions and sub-functions of each module of a system to a
greater detail. Structure Chart partitions the system into black boxes (functionality of the system is
known to the users but inner details are unknown). Inputs are given to the black boxes and
appropriate outputs are generated.
Modules at top level called modules at low level. Components are read from top to bottom and left
to right. When a module calls another, it views the called module as black box, passing required
parameters and receiving results.
Symbols used in construction of structured chart
1. Module
It represents the process or task of the system. It is of three types.
 Control Module
A control module branches to more than one sub module.
 Sub Module
Sub Module is a module which is the part (Child) of another module.
 Library Module
Library Module are reusable and invokable from any module.

2. Conditional Call
It represents that control module can select any of the sub module on the basis of some
condition.
3. Loop (Repetitive call of module)
It represents the repetitive execution of module by the sub module.
A curved arrow represents loop in the module.

All the sub modules cover by the loop repeat execution of module.
4. Data Flow
It represents the flow of data between the modules. It is represented by directed arrow with
empty circle at the end.
5. Control Flow
It represents the flow of control between the modules. It is represented by directed arrow
with filled circle at the end.
6. Physical Storage
Physical Storage is that where all the information are to be stored.

Example : Structure chart for an Email server
Types of Structure Chart:
1. Transform Centered Structured:
These type of structure chart are designed for the systems that receives an input which is
transformed by a sequence of operations being carried out by one module.
Transaction Centered Structure:
These structure describes a system that processes a number of different types of transaction
Compiled by:
Ms.Savita Mittal
Lecture 24
Definition of 'Pseudocode'
Definition: Pseudocode is an informal way of programming description that does not require any
strict programming language syntax or underlying technology considerations. It is used for

creating an outline or a rough draft of a program. Pseudocode summarizes a program’s flow, but
excludes underlying details. System designers write pseudocode to ensure that programmers
understand a software project's requirements and align code accordingly.
Description: Pseudocode is not an actual programming language. So it cannot be compiled into
an executable program. It uses short terms or simple English language syntaxes to write code for
programs before it is actually converted into a specific programming language. This is done to
identify top level flow errors, and understand the programming data flows that the final program
is going to use. This definitely helps save time during actual programming as conceptual errors
have been already corrected. Firstly, program description and functionality is gathered and then
pseudocode is used to create statements to achieve the required results for a program. Detailed
pseudocode is inspected and verified by the designer’s team or programmers to match design
specifications. Catching errors or wrong program flow at the pseudocode stage is beneficial for
development as it is less costly than catching them later. Once the pseudocode is accepted by the
team, it is rewritten using the vocabulary and syntax of a programming language. The purpose of
using pseudocode is an efficient key principle of an algorithm. It is used in planning an algorithm
with sketching out the structure of the program before the actual coding takes place.
Advantages of pseudocode –
• Pseudocode is understood by the programmers of all types.
• it enables the programmer to concentrate only on the algorithm part of the code development.
• It cannot be compiled into an executable program. Example, Java code : if (i < 10) { i++; }
pseudocode :if i is less than 10, increment i by 1.
Prototype Model
Definition: The Prototyping Model is a Systems Development Methodology (SDM) within
which a paradigm output (or an early approximation of a final system or product) is constructed,
tested, and then reworked. It is done till an appropriate paradigm is achieved to help develop the
entire system or product. This model works best in situations when all the details or requirements
are not known well in advance. It is majorly a trial-and-error process which works in an iterative
fashion. Description: There are many steps within the Prototyping Model: 1. New system
requirements or expectations of the system output are outlined in as much detail as possible. This
requires interviewing variety of users, representing all the segments or stakeholders of the
prevailing system. 2. A preliminary layout specification is formed for the new system. 3. A first
output model of the new system is made from the preliminary layouts. This is often a scaled-

down system which tentatively gives an approximation of the desired output required. 4. The
users check the primary output, noting its strengths and weaknesses, the things which need to be
carried ahead in the next steps and the things which need to be discarded. The developer collects
and examines the remarks from the all the stakeholders. 5. The first paradigm is changed,
supported by the comments provided by the users, and is shaped to a second output of the new
system. 6. The second output is evaluated in the same manner as was the primary output. 7.
These steps are reiterated persistently, till the users are satisfied with the output. 8. The final
system is hence constructed, supported by the ultimate output. The final system is completely
evaluated and tested. Routine maintenance is administered on a seamless basis to forecast large-
scale failures and to reduce the time period.
Flow Chart
Flow charts are easy-to-understand diagrams that show how the steps of a process fit together.
American engineer Frank Gilbreth is widely believed to be the first person to document a process
flow, having introduced the concept of a “Process Chart” to the American Society of Mechanical
Engineers in 1921.
Flow charts tend to consist of four main symbols, linked with arrows that show the direction of
flow:
1. Elongated circles, which signify the start or end of a process.
2. Rectangles, which show instructions or actions.
3. Diamonds, which highlight where you must make a decision.
4. Parallelograms, which show input and output. This can include materials, services or
people.
Tip:
You can use many other symbols in a flow chart but remember that these diagrams are used for
communication . If you use symbols that only a few people understand, you may fail to get your
message across. So, be sure to keep things simple !
When to Use a Flow Chart
All manner of organizations use flow charts to:
 Define a process.
 Standardize a process.
 Communicate a process.

 Identify bottlenecks or waste in a process.
 Solve a problem .
 Improve a process.
For example, software developers can use them to work out how the automated and manual parts
of a process join up. Inexperienced team members might follow a flow chart to help them to
complete activities in the right order. A manufacturer could ensure that it keeps to its values by
applying a quality-control flow chart that presents questions and decision points. And an HR
department might combine a flow chart with an organogram to show people who to contact
about issues and when.
Why Use Flow Charts?
This tool's simplicity makes communicating and documenting a process quick and clear, so that
the process will more likely be understood and applied correctly and consistently. It can also help
you to estimate the timescale of the process, as you're better able to gauge the time needed for
each task along the way. And you'll more likely identify who you should involve and at what
stage, such as senior management or a compliance authority.
But you can also benefit from the process of creating a flow chart itself, as you build it step by
step. You'll be able to focus on the detail of each individual stage, without feeling overwhelmed
by the rest of the process, and then "zoom out" again to see the wider picture.
Tip:
If your process or project involves several people or teams, you might find it more useful to use a
Swim Lane Diagram rather than a flow chart – this helps you to show process flows between
people and teams.
How to Create a Flow Chart
Follow these four steps:
Step 1: Identify Tasks
Begin by listing all of the tasks in a process in chronological order. Ask questions such as, "What
happens next in the process?" or, "Do you need to make a decision before the next step?" or,
"What approvals are required before you move on to the next task?"
Put yourself in the shoes of the person using the process, possibly for the first time. Talk to team
members who work with the process directly, and get their opinions on where improvements
could be made. Better yet, take a hands-on approach and go through the procedure yourself, and

think about the practicalities of each stage. Use Customer Experience Mapping if your flow
chart focuses on customer service, so that you can gain a better understanding of the process.
Step 2: Organize and Document Tasks
Next, start your flow chart by drawing the elongated circle shape and labeling it "Start."
Then, work through your whole process, and show the actions and decisions in the order that
they happen. Link them with arrows to illustrate the flow of the process.
Where you need to make a decision, draw arrows from the decision diamond to each possible
solution, and then label each arrow with the decision made. Remember to show the end of the
process by using an elongated circle labeled "Finish."
Step 3: Double-Check the Process
When you've completed your flow chart, go back to the start and try it out to make sure that you
haven't overlooked anything. Work through each step, and ask yourself whether you've
represented the sequence of actions and the decisions involved correctly. Are there more
decisions to be made at certain stages?
Then show your flow chart to other people, especially those who work directly with the process.
Ask them to test that it works and to tell you if there are any problems or omissions.
Step 4: Challenge the Flow Chart
Finally, you might want to improve the process rather than just record it. So, see whether any of
the steps that you've described are unnecessary or overly complicated. Identify any major
bottlenecks , and deal with them to improve performance.
Compiled By:
Ms. Savita Mittal
Lecture 25
Topic: Coupling and Cohesion
Coupling and Cohesion

Introduction: The purpose of Design phase in the Software Development Life Cycle is to produce a
solution to a problem given in the SRS(Software Requirement Specification) document. The output of the
design phase is Sofware Design Document (SDD).
Basically, design is a two-part iterative process. First part is Conceptual Design that tells the customer what
the system will do. Second is Technical Design that allows the system builders to understand the actual
hardware and software needed to solve customer’s problem.
Conceptual design of system:
 Written in simple language i.e. customer understandable language.
 Detail explanation about system characteristics.
 Describes the functionality of the system.
 It is independent of implementation.
 Linked with requirement document.
Technical Design of system:
 Hardware component and design.
 Functionality and hierarchy of software component.
 Software architecture
 Network architecture
 Data structure and flow of data.
 I/O component of the system.
 Shows interface.
Modularization: Modularization is the process of dividing a software system into multiple independent
modules where each module works independently. There are many advantages of Modularization in
software engineering. Some of these are given below:
 Easy to understand the system.

 System maintenance is easy.
 A module can be used many times as their requirements. No need to write it again and again.
Coupling: Coupling is the measure of the degree of interdependence between the modules. A good software
will have low coupling.
Types of Coupling:
 Data Coupling: If the dependency between the modules is based on the fact that they communicate
by passing only data, then the modules are said to be data coupled. In data coupling, the
components are independent to each other and communicating through data. Module
communications don’t contain tramp data. Example-customer billing system.
 Stamp Coupling In stamp coupling, the complete data structure is passed from one module to
another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors-
this choice made by the insightful designer, not a lazy programmer.
 Control Coupling: If the modules communicate by passing control information, then they are said
to be control coupled. It can be bad if parameters indicate completely different behavior and good if
parameters allow factoring and reuse of functionality. Example- sort function that takes comparison
function as an argument.
 External Coupling: In external coupling, the modules depend on other modules, external to the
software being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.
 Common Coupling: The modules have shared data such as global data structures.The changes in
global data mean tracing back to all modules which access that data to evaluate the effect of the
change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control
data accesses and reduced maintainability.
 Content Coupling: In a content coupling, one module can modify the data of another module or
control flow is passed from one module to the other module. This is the worst form of coupling and
should be avoided.
Cohesion: Cohesion is a measure of the degree to which the elements of the module are functionally
related. It is the degree to which all elements directed towards performing a single task are contained in the

Software engineering lecture notes

Software engineering lecture notes

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Software engineering lecture notes

Similaire à Software engineering lecture notes (20)

Plus de TEJVEER SINGH

Plus de TEJVEER SINGH (13)

Dernier

Dernier (20)

Software engineering lecture notes