Sunday

Examination Schedule

 

Industrial Training viva:- 28/12/2020  time 9.00am to 10.00am

Seminar presentation:- 29/12/2020 time 9.00am to 10.00am

DBMS CA1 and CA2:- 30/12/2020 time 9.00am to 10.00am

SE CA1 and CA2:- 4/01/2021 time 9.00am to 10.00am

SE Syllabus for CA1:- Unit 1 to Unit 3
SE Syllabus for CA2:- Unit 4 to Unit 6

Wednesday

Hard disk drive interface

Disks usually connected directly to computer system

Disk interface standards families

Parallel ATA (PATA) ( AT Attachment) also known as ATA or IDE is standard interface for IBM computers


SATA (Serial ATA) 

SATA revision 1.0 (1.5 Gbit/s, 150 MB/s, Serial ATA-150)

SATA revision 2.0 (3 Gbit/s, 300 MB/s, Serial ATA-300)

SATA revision 2.5

SATA revision 2.6

SATA revision 3.0 (6 Gbit/s, 600 MB/s, Serial ATA-600)

SATA 3 supports data transfer speeds of up to 6 gigabits/sec

Serial Attached SCSI

SAS Version 3 supports 12 gigabits/sec 

Non-Volatile Memory Express





The NVMe protocol connects SSDs to servers via the PCIe bus and offers much faster performance. NVMe technology has become a key player in today's storage infrastructure.
 Works with PCIe connectors to support lower latency and higher transfer rates  Supports data transfer rates of up to 24 gigabits/sec


Tuesday

software design concepts

 1. Abstraction:-Abstraction is the act of representing essential features without including the background details or explanations. the abstraction is used to reduce complexity and allow efficient design and implementation of complex software systems. Many levels of abstraction can be posed.

 At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided.

As different levels of abstraction are developed, you work to create both procedural and data abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed. A data abstraction is a named collection of data that describes a data object. 

2. ARCHITECTURE- Architecture serves as a blueprint for a system.

Structure organization of program components (modules) and their interconnection 

The architectural design can be represented using one or more of a number of different models. Structural models: Represent architecture as an organized collection of program components. 

Framework models: Increase the level of design abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of applications. It represents the design in more abstract way 

Dynamic models : Address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of external events. 

Process models :Focus on the design of the business or technical process that the system must accommodate.

 Functional models can be used to represent the functional hierarchy of a system.


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

4. REFINEMENT 

 Process of elaboration from high level abstraction to the lowest level abstraction. High level abstraction begins with a statement of functions. Refinement causes the designer to elaborate providing more and more details at successive level of abstractions Abstraction and refinement are complementary concepts.

5. Refactoring -- Organization technique that simplifies the design of a component without changing its function or behavior. a reorganization technique that simplifies the design. Examines for redundancy, unused design elements and inefficient or unnecessary algorithms.  

6. Modularity

  • A software is separately divided into name and addressable components. Sometime they are called as modules which integrate to satisfy the problem requirements.
  • Modularity is the single attribute of a software that permits a program to be managed easily.
7. Information hiding
Modules must be specified and designed so that the information like algorithm and data presented in a module is not accessible for other modules not requiring that information.

8. Functional independence 
A module having high cohesion and low coupling is said to be functionally independent of other modules. By the term functional independence, we mean that a cohesive module performs a single task or function. A functionally independent module has minimal interaction with other modules.




Software Design

Software Design 

Software design,

Preliminary and detailed design activities,

Difference between analysis and design

Items developed during the software design phase

Characteristics of a good software design

Features of a design document  

Saturday

Behavioral Model

 Behavioral Model is specially designed to make us understand behavior and factors that influence behavior of a System. 

Behavioral models are models of the dynamic behavior of the system as it is executing.

Behavioral models describe the internal behavior of a system

Class-Responsibility-Collaborator (CRC) Modeling

 Class-Responsibility-Collaborator (CRC) Modeling

Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler [Amb95] describes CRC modeling in the following way: 

"A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right."

In reality, the CRC model may make use of actual or virtual index cards. The intent is to develop an organized representation of classes. 

Responsibilities are the attributes and operations that are relevant for the class. Stated simply, a responsibility is “anything the class knows or does” [Amb95].

 Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility. In general, a collaboration implies either a request for information or a request for some action.

A simple CRC index card for the FloorPlan class is illustrated in Figure 6.11. The list of responsibilities shown on the CRC card is preliminary and subject to additions or modification. The classes Wall and Camera are noted next to the responsibility that will require their collaboration.




CLASS-BASED MODELING

 What is class based modeling 


Class-based modeling represents the objects that the system will manipulate, the operations (also called methods or services) that will be applied to the objects to effect the manipulation, relationships.

Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve system requirements 


Wednesday

Use Case

 https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/

Software Metrics and Measures

 Software Measures can be understood as a process of quantifying and symbolizing various attributes and aspects of software.

Software Metrics provide measures for various aspects of software process and software product.

Software measures are fundamental requirement of software engineering. They not only help to control the software development process but also aid to keep quality of ultimate product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.” By his saying, it is very clear how important software measures are.

Let us see some software metrics:

  • Size Metrics - LOC (Lines of Code), mostly calculated in thousands of delivered source code lines, denoted as KLOC.

    Function Point Count is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of software.

  • Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound of the number of independent paths in a program, which is perceived as complexity of the program or its modules. It is represented in terms of graph theory concepts by using control flow graph.
  • Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications define the quality of product.

    The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

  • Process Metrics - In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
  • Resource Metrics - Effort, time and various resources used, represents metrics for resource measurement.

Software System Analyst

 

Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed system and ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the developed software meets the requirements of the client.

System Analysts have the following responsibilities:

  • Analyzing and understanding requirements of intended software
  • Understanding how the project will contribute in the organization objectives
  • Identify sources of requirement
  • Validation of requirement
  • Develop and implement requirement management plan
  • Documentation of business, technical, process and product requirements
  • Coordination with clients to prioritize requirements and remove and ambiguity
  • Finalizing acceptance criteria with client and other stakeholders


Saturday

Notice

 Mid term will for software Engineering and DBMS will be conducted as per schedule:

CA1 for Software Engineering and DBMS will be conducted on 30 October 2020  

Syllabus for Mid term test:

SE: Syllabus for Mid term test: Lectures 1 to 11.

DBMS: Unit 1 and Unit 2

----------------------------------------------------------------------------

Syllabus for CA 1:

SE: Unit 1

DBMS: Unit 1

Tuesday

Characteristics of Good SRS[Software Requirement Specification] 

Characteristics of Good SRS[Software Requirement Specification]  
Following are the characteristics of a good SRS document: 

Correctness: User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it covers all the requirements that are actually expected from the system. 

Completeness: Completeness of SRS indicates every sense of completion including the numbering of all the pages, resolving the to be determined parts to as much extent as possible as well as covering all the functional and non-functional requirements properly. 

Consistency: Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. Examples of conflict include differences in terminologies used at separate places, logical conflicts like time period of report generation, etc. 

Unambiguousness: A SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some of the ways to prevent unambiguousness include the use of modelling techniques like ER diagrams, proper reviews and buddy checks, etc. 

Ranking for importance and stability: There should a criterion to classify the requirements as less or more important or more specifically as desirable or essential. An identifier mark can be used with every requirement to indicate its rank or stability. 

Modifiability: SRS should be made as modifiable as possible and should be capable of easily accepting changes to the system to some extent. Modifications should be properly indexed and cross-referenced. 

Verifiability: A SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which every requirement is met by the system. For example, a requirement stating that the system must be user-friendly is not verifiable and listing such requirements should be avoided. 

Traceability: One should be able to trace a requirement to design component and then to code segment in the program. Similarly, one should be able to trace a requirement to the corresponding test cases. 

Design Independence: There should be an option to choose from multiple design alternatives for the final system. More specifically, the SRS should not include any implementation details. 

Testability: A SRS should be written in such a way that it is easy to generate test cases and test plans from the document. 

Understandable by the customer: An end user maybe an expert in his/her specific domain but might not be an expert in computer science. Hence, the use of formal notations and symbols should be avoided to as much extent as possible. The language should be kept easy and clear. 

Right level of abstraction: If the SRS is written for the requirements phase, the details should be explained explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the level of abstraction varies according to the purpose of the SRS.

Classification of Software Requirements

sOFTWARE rEQUIREMENT:- According to IEEE standard 729, a requirement is defined as follows:

  •  A condition or capability needed by a user to solve a problem or achieve an objective 
  • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents 
  • A documented representation of a condition or capability as in 1 and 2.
A software requirement can be of 3 types:
Functional requirements
Non-functional requirements
Domain requirements

Functional Requirements: These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.
For example, in a hospital management system, a doctor should be able to retrieve the information of his patients. Each high-level functional requirement may involve several interactions or dialogues between the system and the outside world. In order to accurately describe the functional requirements, all scenarios must be enumerated There are many ways of expressing functional requirements e.g., natural language, a structured or formatted language with no rigorous syntax and formal specification language with proper syntax.

Non-functional requirements: These are basically the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements. They basically deal with issues like:
Portability
Security
Maintainability
Reliability
Scalability
Performance
Reusability
Flexibility
NFR’s are classified into following types:
Interface constraints
Performance constraints: response time, security, storage space, etc.
Operating constraints
Life cycle constraints: mantainability, portability, etc.
Economic constraints

The process of specifying non-functional requirements requires the knowledge of the functionality of the system, as well as the knowledge of the context within which the system will operate.

Domain requirements: Domain requirements are the requirements which are characteristic of a particular category or domain of projects. The basic functions that a system of a specific domain must necessarily exhibit come under this category. For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement. These requirements are therefore identified from that domain model and are not user specific.








Thursday

 https://drive.google.com/file/d/1QxvGAd60xv5rjUW-3we4UhHr30RLjOsZ/view?usp=sharing

Tuesday

Agile

 The Agile movement proposes alternatives to traditional project management. Agile approaches are typically used in software development to help businesses respond to unpredictability which refer to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The primary goal of being Agile is empowered the development team the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.


PPT

Monday

Rapid Application Development Model

 The Rapid Application Development Model was first proposed by IBM in 1980’s. The critical feature of this model is the use of powerful development tools and techniques.

A software project can be implemented using this model if the project can be broken down into small modules wherein each module can be assigned independently to separate teams. These modules can finally be combined to form the final product.

Development of each module involves the various basic steps as in waterfall model i.e analyzing, designing, coding and then testing, etc. as shown in the figure.
Another striking feature of this model is a short time span i.e the time frame for delivery(time-box) is generally 60-90 days.

PPT

Software Engineering syllabus

UNIT I Software Development Process: Software crisis and myths, Software process and development: Generic view of process, Software life cycle and models, Analysis and comparison of varies models, an agile view of process. 

UNIT II Requirement Engineering: Requirements engineering tasks, Initiating requirement engineering process, Eliciting requirement, developing use-cases, Building the analysis model, Negotiating and validating requirement, Building the analysis model. 

UNIT III System Design Overview: Design process and design quality, Design concepts, Design model, Pattern based software design, Architectural design, User interface design. UML: Different methods: Rambaugh / Booch / Jakobsons, Need for standardization. Developing diagrams in UML (Use CASE, Class, Interaction, State diagrams) CASE TOOLS. 

UNIT IV Validation and Testing: Strategic approach to Software testing, Strategic issues, Test strategies for conventional software, Validation testing, System testing, Debugging. White box testing and Black box testing. 

UNIT V Web Engineering: WebApps engineering layers, Web engineering processes planning for web engineering projects, Project management issue for web engineering. Metrics, Requirement analysis, Analysis models for web engineering design for WebApps, testing for WebApps. 

UNIT VI Planning and Management of Project: Project management, Metrics for process and projects, Estimation, Project scheduling, Risk management, Importance of software quality and measurements software engineering techniques for quality assurance, and Change management. ISO 9000 and CMM/PCMM. 


Text Books 1. Roger S. Pressman, “Software Engineering”, Tata McGraw-Hill, 6th Edition, 2006. 2. G. Booch, J. Rambaugh, and I. Jacobson, “The Unified Modeling Language User Guide”, Addison Wesley, 2nd Edition, 2005. Reference Books: 1. Shari Pfleeger, “Software Engineering”, Pearson Education, 3rd Edition, 2008. 2. Ian Sommerville, “Software Engineering”, Pearson Higher Education, 10th Edition, 2016. 3. Pankaj Jalote, “An Integrated Approach to Software Engineering”, Springer New York, 2nd Edition, 2013.

Sunday

Query Language

In simple words, a Language which is used to store and retrieve data from database is known as query language. For example – SQL

There are two types of query language:
1.Procedural Query language
2.Non-procedural query language

1. Procedural Query language:

In procedural query language, user instructs the system to perform a series of operations to produce the desired results. Here users tells what data to be retrieved from database and how to retrieve it.

For example – Let’s take a real world example to understand the procedural language, you are asking your younger brother to make a cup of tea, if you are just telling him to make a tea and not telling the process then it is a non-procedural language, however if you are telling the step by step process like switch on the stove, boil the water, add milk etc. then it is a procedural language.

Relational Algebra:

Relational algebra is a conceptual procedural query language used on relational model.

2. Non-procedural query language:

In Non-procedural query language, user instructs the system to produce the desired result without telling the step by step process. Here users tells what data to be retrieved from database but doesn’t tell how to retrieve it.

Relational Calculus:

Relational calculus is a conceptual non-procedural query language used on relational model.


Note: while describing relational algebra and relational calculus, because they are theoretical mathematical system or query language, they are not the practical implementation, SQL is a practical implementation of relational algebra and relational calculus.

Relational Algebra, Calculus, RDBMS & SQL:

Relational algebra and calculus are the theoretical concepts used on relational model.

RDBMS is a practical implementation of relational model.

SQL is a practical implementation of relational algebra and calculus.

Relational Calculus: Tuple Relational Calculus, Domain Relational Calculus

 

Relational Calculus

  • Relational calculus is a non-procedural query language. In the non-procedural query language, the user is concerned with the details of how to obtain the end results.
  • The relational calculus tells what to do but never explains how to do.

Types of Relational calculus:


DBMS Relational Calculus

Relational algebra

 Relational algebra is a procedural query language, which takes instances of relations as input and yields instances of relations as output. It uses operators to perform queries. An operator can be either unary or binary. They accept relations as their input and yield relations as their output.

PPT

Wednesday

Unit 2: Keys

Types of keys in DBMS 

Super Key – A super key is a set of one of more columns (attributes) to uniquely identify rows in a table. Candidate Key – A super key with no redundant attribute is known as candidate key
Primary Key – A primary is a column or set of columns in a table that uniquely identifies tuples (rows) in that table. 

Study Material:

Unit 2: Integrity Constraints

 

Integrity Constraints

  • Integrity constraints are a set of rules. It is used to maintain the quality of information.
  • Integrity constraints ensure that the data insertion, updating, and other processes have to be performed in such a way that data integrity is not affected.
  • Thus, integrity constraint is used to guard against accidental damage to the database.
https://drive.google.com/file/d/12TyGNuG0lgGqG6B95qZgi5LBwagkN9KQ/view?usp=sharing
https://drive.google.com/file/d/12TyGNuG0lgGqG6B95qZgi5LBwagkN9KQ/view?usp=sharing

Unit 2: Relational Model (Introduction)

 Relational Model was proposed by E.F. Codd to model data in the form of relations or tables. After designing the conceptual model of Database using ER diagram, we need to convert the conceptual model in the relational model which can be implemented using any RDMBS languages like Oracle SQL, MySQL etc. So we will see what Relational Model is.

PPT

Monday

SE

 Book

Syllabus

Unit 1:

Lecture 1:  PPT Definition, characteristics, Myths,Crisis 

Lecture 2:  PPT1  PPT2

Lecture 3: PPT SDLC, Build and fix, water fall, iterative

Lecture 4: PPT Prototype model

Lecture 5: PPT1    PPT2  Spiral model , V model

Lecture 6: RAD model

Lecture 7: Agile Model Agile Model and Scrum

  Agile Models XP,KANBAN etc.

Unit 2:

Lecture 9: Classification of Software requirements , Functional vs Non-functional Requirements

Lecture 10: Characteristics of Good SRS

Lecture 11: Requirement Engineering 7 Tasks 

Lecture 12: Who is System Analyst? Software Metrics

Lecture 13: requirement analysis and Modeling

scenario based modeling

Lecture 14: scenario based modeling 1) use case

Lecture 15: Use case symbols etc 2) activity diagram

Lecture 16: How to draw Activity diagram 

Class based modeling

Lecture 17:  what is class based modeling 1) Class Diagram 2) Class-Responsibility-Collaborator (CRC) Modeling

Behavioral Modeling

Lecture 18: What is Behavioral Model? state diagram  sequence diagram 

Flow oriented model 

Lecture 19: Flow oriented model 

Unit 3
Lecture 24 architectural styles Part 1 |  Part 2



Unit 4: Software Testing 



 Unit 5


Unit 6: