Database Systems - Complete Data

Here is the download links:

• Coding Slides => DOWNLOAD NOW
• Theory Slides => DOWNLOAD NOW
• SQL Lite tutorials => Youtube Video series

Software Engineering | SE Lecture 6

>>>>> Download Link Here <<<<<


You can download the slides from the link given above.
In this lecture, we will focus on following points:

• Revision
• Example
• Homework

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

In this Slide:

Introduction to

Revision & Example – 6

By Abdul Razaq Ali

Lecturer, PUCIT

In Today’s Lecture

Revision

Example

Example

Instructions

• Recreate each of the 5 pages given here using HMTL and CSS

• Choose whatever colors and design you’d like (do not keep it basic HTML – there should be some design to it)

• The “Logo” on the menu bar should be a logo that you choose

• The items on the menu bar should be hyperlinks to the other pages

• One of the photos of the homes should be a hyperlink to a single page about that home with 3 more photos and a short description of the home.

• These pages do not have to be great. I just want to see that you can build and design a basic site with multiple pages, properly layout the information, and create links.

• Feel free to add functionality if you’re an overachiever ;)

HOMEWORK

Please watch the following tutorials before next class.

https://www.youtube.com/watch?v=PF40PTJxn4Q

https://www.youtube.com/watch?v=F_xDqBa5w-s

Highlights of today’s lecture

Revision

Example

Book Reading

Roger S. Pressman  “Software Engineering- A practitioner’s approach”, 7th Ed. 

All topics we have studied yet

Questions?

Software Engineering | SE Lecture 5

>>>>> Download Link Here <<<<<


You can download the slides from the link given above.
In this lecture, we will focus on following points:

• How to analyze the Requirements/Structure
• Specification/Designing
• Analysis Models
• Data Models (DD)
• Functional Models (ERD)
• Behavior Models (STD)

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

In this Slide:

Introduction to
Structured Analysis and Design – 5
By Abdul Razaq Ali
Lecturer, PUCIT
In Today’s Lecture
Class Test # 1
Introduction to Structured Analysis & Design
Data Modeling
Functional Modeling
Behavior Modeling
Class Test # 1 (6 min.)
Difference among RAD, Waterfall, Incremental & Spiral models.
Requirement Analysis
Requirement Analysis is a software engineering task that bridges the gap between system level requirement engineering and software design

If you don’t analyze it, its highly likely that you will build a highly elegant software that solves the wrong problem
Operational Analysis Principles
Information domain of a problem must be represented and understood.
The functions that the software is to perform must be defined.
The behavior of the software must be represented.
The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion.
The analysis process should move from essential information toward implementation detail.
Analysis Rules of Thumb
Model should focus on requirements that are visible within the problem or business domain.
Each element of the requirements model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.
Delay consideration of infrastructure and other nonfunctional models until design
Minimize coupling throughout the system
Be certain that requirements model provides value to all stakeholders
Keep the model as simple as it can be.
Specification
Specification Principles
Separate functionality from implementation.
Develop a model of the desired behavior of a system.
Establish the context in which software operates.
Define the environment in which the system operates
Create a cognitive model
Recognize that “the specifications must be tolerant of incompleteness and augmentable.”
Establish the content and structure of a specification amenable to change
The Software Requirements Specification
The function and performance allocated to software as part of system engineering are refined by establishing
a complete information description
a detailed functional description
a representation of system behavior
an indication of performance requirements
design constraints
appropriate validation criteria
other information pertinent to requirements.
The Software Requirements Specification (Demo)
Introduction – goals and objectives
Information description – detailed description of the problem
Functional description – description of each function
Behavioral description – operation of the software as a consequence of external events
Validation criteria – implicit review of all other requirements
Bibliography – references to all documents that relate to the software
Appendix – supplements the specifications.
Modeling
Scenario-based models
Data models
Class-oriented models
Flow-oriented models
Behavioral models
Modeling
Functional model(Flow-oriented models)
Software transforms information
To accomplish this, it must perform at least three generic functions: input, processing, and output.
When created, the software engineer focuses on problem specific functions.
Behavioral model
Most software responds to events from outside world.
This response forms the basis of the behavioral model.
Analysis Model
The Elements of the Analysis Model
Objectives
Describe what the customer requires
Establish a basis for the creation of a software design
Define a set of requirements that can be validated once the software is built.
Structure of the Analysis Model
Data Dictionary – repository that contains descriptions of all data objects consumed or produced by the software
Entity relation diagram – relationships between data objects
Data flow diagram –
Provide an indication of how data are transformed as they move through the system
Depict the functions (and sub functions) that transform the data flow
State transition diagram – how the system behaves as a consequence of external events.
Highlights of today’s lecture
How to analyze the Requirements/Structure
Specification/Designing
Analysis Models
Data Models (DD)
Functional Models (ERD)
Behavior Models (STD)
Book Reading
Roger S. Pressman  “Software Engineering- A practitioner’s approach”, 7th Ed.
6.1

Questions?

Software Engineering | SE Lecture 4

>>>>> Download Link Here <<<<<


You can download the slides from the link given above.
In this lecture, we will focus on following points:

• Requirement Engineering
• Some topics from previous lectures

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

In this slide:

Introduction to

Requirement Engineering - 3

By Abdul Razaq Ali

Lecturer, PUCIT

In Today’s Lecture

Spiral Model

Agile Process

Requirement Engineering

Spiral Model (again)

The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed.

Link: http://istqbexamcertification.com/what-is-spiral-model-advantages-disadvantages-and-when-to-use-it/

Agile Process

“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include 

Extreme Programming (XP)

Scrum

An Agile Process implies a

A light Process – prefers a small set of activities and artifacts

An Adaptive Process – emphasizes on handling changing requirements

Software Requirements -1

Requirements are…a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute

The IEEE Standard Glossary of Software Engineering Terminology (1990) defines a requirement as:

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

Software Requirements -2

A complete description of what the software system will do without describing how it will do it is represented by the software requirements

Software requirements are complete specification of the desired external behavior of the software system to be built

Software Requirements -3

Software requirements can be:

Part of the bid of contract

The contract itself

Part of the technical document, which describes a product

Software requirements can be:

Abstract statements of services and/or constraints Detailed mathematical functions

What are NOT Requirements

Requirements do not include:

Design or Implementation details (other than known constraints)

Project planning information, or testing information. 

Development environment requirements, schedule or budget limitations

Need for a tutorial to help new users get up to speed, or requirements for releasing a product and moving it into the support environment.

These are project requirements but not product requirements. Separate such items from the requirements so that the requirements activities can focus on understanding what the team intends to build.

Levels of Requirements

Software Requirements Engineering

Requirements engineering -is the process which enables us to systematically determine the requirements of a software product

Requirements engineering -refers to the process of formulating, documenting and maintaining software requirements

A principal -A Domain

Requirement Development

Requirements development can be further subdivided into elicitation, analysis, specification, and validation

Identifying the product's expected user classes

Eliciting needs from individuals who represent each user class

Understanding user tasks and goals and the business objectives with which those tasks align

Analyzing the information received from users to distinguish their task goals from functional requirements, nonfunctional requirements, business rules, suggested solutions, and extraneous information

Negotiating implementation priorities

Translating the collected user needs into written requirements specifications and models

Reviewing the documented requirements to ensure a common understanding of the users' stated requirements and to correct any problems before the development group accepts them

Requirements Development Process

Requirements Management

Defining the requirements baseline (a snapshot in time representing the currently agreed-upon body of requirements for a specific release)

Reviewing proposed requirements changes and evaluating the likely impact of each change before approving it

Incorporating approved requirements changes into the project in a controlled way

Keeping project plans current with the requirements

Negotiating new commitments based on the estimated impact of requirements changes

Tracing individual requirements to their corresponding designs, source code, and test cases

Tracking requirements status and change activity throughout the project

Highlights of today’s lecture

Agile Process (Extreme Programming, Scrum)

Requirement Engineering

Book Reading

Roger S. Pressman  “Software Engineering- A practitioner’s approach”, 7th Ed. 

5.1 

Questions?

Software Engineering | SE Lecture 3

>>>>> Download Link here <<<<<

You can download the slides from the link given above.
In this lecture, we will focus on following points:

•RAD Model

•Evolutionary software process models

•Incremental Model

•Spiral Model

•Agile Process

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

In slide:

Software Process Models – 2

By Abdul Razaq Ali

Lecturer, PUCIT

In Today’s Lecture

RAD Model

Evolutionary software process models

Incremental Model

Spiral Model

Agile Process

Rapid Application Development

Rapid Application Development is an adaptation of linear sequential software development process model that emphasises an extremely short development cycle.

A component-based construction approach is used.  

To use this approach, the project scope must be constrained and the requirements should be well understood.  

A task that should take no more than ninety days to complete is modelled, generated and implemented.  

There can be several teams working on different components during this ninety day time-box

Like other process models, the RAD approach maps into the generic framework activities

Communication

Works to understand the business problem and the information characteristics that the software must accommodate (requirements gathering)

Planning

Describes the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule

Contd.

Modeling

Establishes design representations that serve as the basis for RAD’s construction activity(Encompasses the creation of models that allow the developer and the customer to better understand software requirements and the design that will achieve those requirements)

Construction

emphasizes the use of pre-existing software components and the application of automatic code generation (Combines code generation and the testing that is required to uncover errors in the code)

Contd.

Deployment

Establishes a basis for subsequent iterations, if required (the software as a complete entity or as a partially completed increment is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation)

Advantages of RAD

Less time

Reusability

Problems

For large, scalable projects, RAD requires sufficient human resources to create the right number of RAD teams

RAD requires developers and customers who are committed to the rapid-fire activities necessary to complete a system in this time frame, or failure will result.

RAD is not suitable for many project types. (must be modularized enabling each function to be completed in less than 3 months)

If high performance is an issue, and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work

RAD may not be appropriate when technical risks are high

The incremental model

This is a combination of the linear sequential model and the iterative model.  

The problem is broken into increments, and each increment is tackled as a linear sequence.  

Further increments can either be done after the previous ones, or can overlap with the previous ones.  

Incremental delivery focuses on the delivery of an operational product with each increment.  

Early increments are stripped-down versions of the final product, but they do provide capability that serves the user and also provides a platform for evaluation by the user.

Incremental model

This approach has the advantages that : -

Less staffing available for a complete implementation by the business deadline that has been established for the project (Early increments can be implemented with fewer people)

Early delivery is guaranteed

Progress of the whole project is not delayed if one of the resources is not available for part of it

Increments can be planned to manage technical risks

Incremental Model

Homework

Advantages

?

Problems

?

Evolutionary Software process models

Prototyping

Spiral Model

Prototyping Model (part 2)

Throw away prototyping

Prototype merely used for the identification of requirements

Evolutionary prototyping

Final product will be based upon it

(side notes)

Two Requirement engineering process activities:

Requirements elicitation

Requirements validation

Benefits

Misunderstandings between developers and users identified

Incomplete requirements found

A working system is available quickly to demonstrate feasibility

Used as a basis for writing the specification for production of quality software

Disadvantages

No Non-functional requirements

Change deteriorates software

Time less, so no specification maintained

Problems

The customer sees a working version and expects the finished product to be available in a short time.  This puts pressure on the developer to take short cuts, at the expense of quality and maintainability.

The developer may make compromises for speed.  

Inappropriate tools may be used or inefficient algorithms may be used, which then become integral parts of the system.

If the user isn’t focused on what they want, the system may never be completed.

The Spiral model

Boehm’s (1988) spiral model couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.  

Software is developed in a series of incremental releases. 

During the early releases, there may be just a paper model, but the system becomes increasingly more complete. 

There are a number of framework activities (Customer communication, Planning, Risk analysis, Engineering, Construction and release, Customer evaluation).  

Unlike any of the other models, this model keeps revisiting the system throughout its lifetime.

The spiral model is a risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of software intensive systems

It has two main distinguishing features.

One is a cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk.

The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.

Spiral Model

Spiral Model

Spiral model is divided into a number of framework activities, named as “task regions”. Each task region has its own task sets.

Advantages

Explicit risk handling

More realistic and appropriate for large scale projects-research based

Evolutionary 

Differences between Spiral and Incremental Model

Both models, incremental and spiral offer partial deliveries to the customer at different phases BUT ….

The Incremental Model focuses on the delivery of a fully-tested production code in a step-by-step fashion; each step adds more functionality

The Spiral Model focuses on the development of prototypes at each stage which will be used only for information gathering and then throw-away

Agile Process

“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include 

Extreme Programming (XP)

Scrum

An Agile Process implies a

A light Process – prefers a small set of activities and artifacts

An Adaptive Process – emphasizes on handling changing requirements

Highlights of today’s lecture

Different Process Models

RAD Model

Incremental Model

Evolutionary software process models

Spiral Model

Agile Process (Extreme Programming, Scrum)

Their Comparison

Advantages/Disadvantages

Book Reading

Roger S. Pressman  “Software Engineering- A practitioner’s approach”, 7th Ed. 

2.3 

Questions?

Software Engineering | SE Lecture 2

>>>>> Download Link here <<<<<

You can download the slides from the link given above.
In this lecture, we will focus on following points:

1. Software Process Models
2. Linear Sequential Model
3. Prototyping Model

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

In slide:

Software Process Models – 1

By Abdul Razaq Ali

Lecturer, PUCIT

In Today’s Lecture

Introduction

Linear Sequential Model

Prototyping Model

Quick Look

What is it?

Prescriptive process models define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high quality software

These Process models are not perfect, but they do provide a useful roadmap

Who does it?

Software engineers adapt them to their needs and then follow it

Why is it important?

It provides stability, control and organization to an activity

What are the steps?

The process guides a software team through a set of framework activities that are organized into a process flow that may be linear, incremental, or evolutionary.

Software Process Models

A model

 is a structured collection of elements that describe characteristics of effective processes. 

Software Process Model

Is the strategy to adopt software engineering as a layered technology

A simplified representation of a set of activities whose goal is the development or evolution of software, presented from specific perspective

Prescriptive Models

Prescriptive software process models called “prescriptive” because

Prescribe a set of process elements- framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms for each project.

Prescribes a workflow - The manner in which the process elements are interrelated to each other (linear, incremental or evolutionary)

Software engineers have traditionally chosen a generic process framework consisting of the following framework activities which can be applied on any process model

Communication

Planning

Modeling

Construction

Deployment

The Process Model: Adaptability

The framework activities will always be applied on every project ... BUT

The tasks (and degree of rigor) for each activity will vary based on:

the type of project (an “entry point” to the model)

characteristics of the project

common sense judgment; concurrence of the project team

The environment in which the work will be conducted

Process Flow

Iterative

Evolutionary

Parallel

The Waterfall Model

Alternate names

Linear Sequential Model

Classic Life cycle

Introduction

A systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing, and support.

                         OR

A systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in on-going support of the completed software.

Linear Sequential Model

Used when

The requirements of a problem are reasonably well understood 

When work flows from communication through deployment in a reasonably linear fashion.

Disadvantages

Real projects rarely follow the sequential flow that the model proposes.

It is often difficult for the customer to state all requirements explicitly.

A working version of the program will not be available until late in the project time span.

Linear nature leads to “blocking states”.

The Prototyping Model

The developer and customer define the overall (general) objectives for the software. 

In other cases, developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take

A quick design focuses on what the customer will see.  From this, a prototype is constructed.

Prototyping can be treated as a standalone process model

More commonly treated as a TECHNIQUE that can be implemented within the context of any one of the process models

A prototype is a smaller-scale, representative or working model of the user requirements or a proposed design for an information system. 

 The user evaluates it and improvements are made.  This continues in an iterative fashion until a satisfactory product is achieved

The Prototyping Model

Advantages & Disadvantages

?

(Homework)

Highlights of today’s lecture

Software Process Models

Linear Sequential Model

Prototyping Model

Book Reading

Roger S. Pressman  “Software Engineering- A practitioner’s approach”, 7th Ed. 

2.3 

Questions?

Presentation Slides - Analysis of Important MDRE Products

>>>>> Download Link Here <<<<<


I will upload only selective MDRE Products on this thread.

SRE Lec # 13 - Non-Functional Requirements

>>>> Download Link Here <<<<<



In this slide
_______________________________________________________

SRE – 
 Non-Functional Requirements

BSEF15 (V)

Abdul Razaq Ali

Objectives

● To introduce non-functional requirements

● To explain the schemes used to classify non-functional requirements

● To illustrate various derivation techniques for non-functional requirements

● To demonstrate the importance of non-functional requirements in critical systems

Non-Functional Requirements (NFRs)

Non-functional requirements:

● Define the overall qualities or attributes of the resulting system

● Place restrictions on the product being developed & its development process

● Specify external constraints that the product must meet.

Types of NFRs

The ‘IEEE-Std 830 - 1993’ lists 13, non-functional requirements to be included in a Software Requirements Document.

● Performance requirements

● Interface requirements

● Verification requirements

● Documentation requirements

● Security requirements

● Quality requirements

● Reliability requirements

● Maintainability requirements

Classification of NFRs

● NFRs may be classified n terms of qualities that a software must exhibit (Boehm)

● A more general classification distinguishes between product, process and external requirements

Product Requirements

● Specify the desired characteristics that a system or subsystem must possess.

● Most NFRs are concerned with specifying constraints on the behaviour of the executing system.

● The System service X shall have an availability of 999/1000 or 99%. This is a reliability requirement which means that out of every 1000 requests for this service, 999 must be satisfied.

● System Y shall process a minimum of 8 transactions per second. This is a performance requirement.

● The executable code of System Z shall be limited to 512Kbytes. This is a space requirement which specifies the maximum memory size of the system.

Source-code requirements

There are product requirements which relate to the source code of the system

Examples:

The system shall be developed for PC and Macintosh platforms. This is a portability requirement which affects the way in which the system may be designed

The system must encrypt all external communications using the RSA algorithm. This is a security requirement which specifies that a specific algorithm must be used in the product

Process Requirements

Process requirements are constraints placed upon the development process of the system

Process requirements include:

● Requirements on development standards and methods which must be followed

● CASE tools which should be used

● The management reports which must be provided

● Examples:

● The development process to be used must be explicitly defined and must be conformance with ISO 9000 standards

● The system must be developed using the XYZ suite of CASE tools

● Management reports setting out the effort expanded on each identified system component must be produced every two weeks

● A disaster recovery plan for the system development must be specified

External Requirements

● May be placed on both the product and the process

● Derived from the environment in which the system is developed

● External requirements are based on:

● Application domain information

● Organisational considerations

● The need for the system to work with other systems

● Health and safety or data protection regulations

● OR even basic natural laws such as the laws of physics

Relationship between User needs, concerns and NFRs

Goal-based Derivation

● Relates non-functional requirements to the goals of the enterprise

● Goal converted into a NFR:

● Goal (unverifiable)

● The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized

● Non-functional requirement (verifiable)

● Experienced controllers shall be able to use all the system functions after a total of two hours’ training. After this training, the average number of errors made by experienced users shall not exceed two per day

Testable NFRs

● Stakeholders may have vague goals which cannot be expressed precisely

● Vague and imprecise ‘requirements’ are problematic

● NFRs should satisfy two attributes for being Testable:

● Make it objective

● Use measurable metrics

Objective NFR is based on facts, can be measured and can be verified.

Subjective NFR is based on personal choices and desires

** It is not always possible to express NFRs objectively

Examples of measurable metrics for NFRs

Reliability

● Describe the run-time behaviour of the system

● Can be considered under two separate headings:

● Availability - is the system available for service when requested by end-users.

● Failure rate - how often does the system fail to deliver the service expected by end-users.

Performance

● Describe the speed of operation of a system

● Types of performance requirements:

● Response requirements

Security

● Security requirements are included in a system to ensure:

● Unauthorised access to the system and its data is not allowed

● Ensure the integrity of the system from accidental or malicious damage

● Examples of security requirements are:

● The access permissions for system data may only be changed by the system’s data administrator

● All system data must be backed up every 24 hours and the backup copies stored in a secure location which is not in the same building as the system

● All external communications between the system’s data server and clients must be encrypted

Usability

Concerned with specifying the user interface and end-user interactions with the system.

Well structured user manuals, informative error messages, help facilities and consistent interfaces enhance usability

Questions ?