- Slides => DOWNLOAD NOW
- Book => DOWNLOAD NOW
Showing posts with label Slide. Show all posts
Showing posts with label Slide. Show all posts
Thursday, 11 October 2018
Tuesday, 27 February 2018
Software Engineering | SE Lecture 1
>>>>> Download Link here <<<<<
You can download the slides from the link given above.
In this lecture, we will focus on following points:
You can download the slides from the link given above.
In this lecture, we will focus on following points:
- The Scope of Software Engineering
- Motivation and need for software engineering
- Definition of Software Engineering
- Introduction to software engineering vocabulary
--------------------------------------------------------------------------
In slide:
Introduction to Software Engineering
By Abdul Razaq Ali
Lecturer, PUCIT
Why this subject?
We know how to code!
But can we build Facebook alone??
So why this course?
To learn how to develop different software by using different methods (process models).
Importance
The core subject like PF, OOP, DSA and Data bases
Ensure your survival in industry
Increase your chances to become a team lead or project manager in shortest time possible.
Mark Division
Mid 35%
Final 40%
Classroom assessment 25%
Quizzes & Tests 10 marks
Assignment and Presentations 5 marks
Project 10 marks
Books and Reading Materials
Data will be posted on “pucitbookstore”
What’s PUCITBookStore?
Google it (Homework)
2 main Books:
Roger S. Pressman “Software Engineering- A practitioner’s approach”, 7th Ed.
Craig Larman “Applying UML and design Patterns”, 2nd Ed.
Some Ground Rules
Don’t beg for marks at the end of semester. You look really pathetic when you beg
Do work on daily basis
Check your CMS on regular basis and ensure your marks are correct.
Visit “PUCITBookStore.blogger.com” on daily basis to download curse content and see announcements.
(Cont.)
Keep you mobile phones on silent.
You are allowed to take calls outside the class
Any type of misbehavior will not be tolerated.
Any type of cheating will result direct F in your course and a report will be filed to your degree coordinator and higher authorities.
So, don’t cheat.
You will eventually get good marks if you do your work on daily basis
(Cont.)
Don’t beg for attendance.
Questions are appreciated
But avoid off topic questions.
And last…
Good students get Good teachers
Bad students get Bad teachers
Software
Definition
Computer software is the product that software engineers design and build
Components of Software
Types of software
Generic software
Stand-alone systems produced by a development organization and sold on the open market to any customer
for example word processors, spreadsheets and games
Customized software
Systems commissioned by a particular customer.
for example web sites, air-traffic control systems and software for managing the finances of large organizations
Engineering
Definition
Implementation of a solution to a practical problem
Comprises any kind of activity which aims at either solving a problem or completing a task related to the definition, design, and specification of a product.
Analysis, design, construction, verification, and management of technical (or social) entities.
Software Engineering
Definition
Establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.
The application and study of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software
Importance of Software Engineering
Software crisis
Software quality
Over budget
Out of schedule-OS360
Property damage-explosion of European Ariane rocket
Life and death-radiotherapy
Difference
Software Engineering
Concerned with the practicalities of developing and delivering useful software
A field of study deals with practicalities of software development
Computer science
Concerned with theory and fundamentals
A field of study deals with theories and practices of computation, communication, automation, coordination and data manipulation.
Difference
System engineering
Concerned with all aspects of computer-based systems development, including hardware, software, and process engineering
Software engineering
Part of system engineering
Deals with software only
Highlights of today’s lecture
The Scope of Software Engineering
Motivation and need for software engineering
Definition of Software Engineering
Introduction to software engineering vocabulary
Book Reading
Roger S. Pressman “Software Engineering- A practitioner’s approach”, 7th Ed.
1.1
Questions?
Introduction to Software Engineering
By Abdul Razaq Ali
Lecturer, PUCIT
Why this subject?
We know how to code!
But can we build Facebook alone??
So why this course?
To learn how to develop different software by using different methods (process models).
Importance
The core subject like PF, OOP, DSA and Data bases
Ensure your survival in industry
Increase your chances to become a team lead or project manager in shortest time possible.
Mark Division
Mid 35%
Final 40%
Classroom assessment 25%
Quizzes & Tests 10 marks
Assignment and Presentations 5 marks
Project 10 marks
Books and Reading Materials
Data will be posted on “pucitbookstore”
What’s PUCITBookStore?
Google it (Homework)
2 main Books:
Roger S. Pressman “Software Engineering- A practitioner’s approach”, 7th Ed.
Craig Larman “Applying UML and design Patterns”, 2nd Ed.
Some Ground Rules
Don’t beg for marks at the end of semester. You look really pathetic when you beg
Do work on daily basis
Check your CMS on regular basis and ensure your marks are correct.
Visit “PUCITBookStore.blogger.com” on daily basis to download curse content and see announcements.
(Cont.)
Keep you mobile phones on silent.
You are allowed to take calls outside the class
Any type of misbehavior will not be tolerated.
Any type of cheating will result direct F in your course and a report will be filed to your degree coordinator and higher authorities.
So, don’t cheat.
You will eventually get good marks if you do your work on daily basis
(Cont.)
Don’t beg for attendance.
Questions are appreciated
But avoid off topic questions.
And last…
Good students get Good teachers
Bad students get Bad teachers
Software
Definition
Computer software is the product that software engineers design and build
Components of Software
Types of software
Generic software
Stand-alone systems produced by a development organization and sold on the open market to any customer
for example word processors, spreadsheets and games
Customized software
Systems commissioned by a particular customer.
for example web sites, air-traffic control systems and software for managing the finances of large organizations
Engineering
Definition
Implementation of a solution to a practical problem
Comprises any kind of activity which aims at either solving a problem or completing a task related to the definition, design, and specification of a product.
Analysis, design, construction, verification, and management of technical (or social) entities.
Software Engineering
Definition
Establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.
The application and study of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software
Importance of Software Engineering
Software crisis
Software quality
Over budget
Out of schedule-OS360
Property damage-explosion of European Ariane rocket
Life and death-radiotherapy
Difference
Software Engineering
Concerned with the practicalities of developing and delivering useful software
A field of study deals with practicalities of software development
Computer science
Concerned with theory and fundamentals
A field of study deals with theories and practices of computation, communication, automation, coordination and data manipulation.
Difference
System engineering
Concerned with all aspects of computer-based systems development, including hardware, software, and process engineering
Software engineering
Part of system engineering
Deals with software only
Highlights of today’s lecture
The Scope of Software Engineering
Motivation and need for software engineering
Definition of Software Engineering
Introduction to software engineering vocabulary
Book Reading
Roger S. Pressman “Software Engineering- A practitioner’s approach”, 7th Ed.
1.1
Questions?
Sunday, 22 October 2017
SRE Lec # 4
>>>>> Download Link Here <<<<<<
In this Slide
______________________________________________________
SRE – Types of Requirements
BSEF15 (V)
Abdul Razaq Ali
Views on Requirements Types
Requirements types can be identified using different views.
1. Hardware vs. Software requirements
2. Production process requirements
3. Complete Taxonomy
1.1 Hardware vs. Software requirements
1. Hardware requirements
1. Performance requirements
2. Constraints:
1. Interface requirements
2. Specialty engineering requirements
3. Environmental requirements
1. Software requirements
1. Functional requirements
2. Nonfunctional requirements
1.2 Production Process Requirements
Complete RE Taxonomy
Requirements Types
Business requirements
Stated requirements vs real requirements
User requirements
High-level or system-level requirements
Process requirements
Qualified requirements
Non-functional requirements
Functional requirements (define business rules)
Derived requirements
Design requirements and constraints
Performance requirements
Unknowable requirements
System and component requirements
Requirements Types
Interface requirements
Verified requirements
Validated requirements
Product requirements
Logistic support requirements
Environmental requirements
Requirements
Business Requirements
Highest in the hierarchy due to its importance
Reason for developing systems and software in the first place.
Essential activities for an enterprise
Any system made MUST reflect and support Business requirements
Stated vs Real Requirements
Stated requirements are provided by a customer at the beginning of the project
Real requirements are identified during requirements analysis phase,
Key responsibility of RA and should cover anything/everything a user wants from the system
User Requirements
User requirements are verified needs of users from the system or software
These are acceptance criteria of a product
Requirements
High Level or System Level Requirements
Comprehend the required system
Capture vision of the customer
Enable defining scope
Allow cost and schedule estimates required to build the system
Functional Requirements
Business Rule Identification – provides basis for Functional requirements
Important Category for Real requirements
Describes what a software system must do
Behavioral or operational requirements as they specify inputs and outputs of the system and the relationship among them
These are depicted in Functional Specification (FS)
Requirements
Business Rules
- The policies, conditions, and constraints of the business activities supported by the
system
- The decision processes, guidelines, and controls behind the functional
requirements (e.g., procedures)
- Definitions used by the business
- Relationships and work flows in the business
- Knowledge needed to perform actions
Requirements
Non-Functional Requirements
Nonfunctional requirements specify system properties, such as reliability, performance and safety.
Derived Requirements
A derived requirement is one that is further refined from a higher-level requirement or a requirement that results from choosing a specific implementation or system element.
Design Requirements
Requirement (design constraint) may be that the system to be developed must obtain its information from an existing database.
For reasons of budget, schedule, or quality, an organization may wish to reuse some or all existing software systems in the implementation of a new system.
Requirements
Performance Requirements
How well the system should perform
Also termed as 'Dependability requirements'
One of the most difficult challenge in system development
availability, security, performance, reliability, and safety.
Interface Requirements
GUI based requirements
Identifies physical and functional relationships among system elements and modules
Verified Requirements
Verified requirements are real requirements that are met or satisfied in the design solution.
Requirements
Validated Requirements
Validated requirements are requirements that are implemented in the delivered System.
Qualification Requirements
Qualification refers to the verification or validation of item performance in a specific application and results from design review, test data review and configuration audits.
Product Requirements
These are requirements of the products that are produced by a system
Process Requirements
Requirements that exist because of the processes being used to develop the software/system
Requirements
Logistic Support Requirements
These are requirements that exist because of such things as tools, training, procedures, facilities and spares
Environmental Requirements
These are requirements that result from the physical settings an
Requirements Errors
A deficiency in the requirements quality that can hamper software development. Requirements errors are the most expensive error type to remove, almost impossible to remove when drilled down to the system
Error Types
Error of Omission: Most Common type
Domain experts easily forget to convey domain knowledge to requirements engineers, because they consider that to be obvious and implicit
Error of Clarity and Ambiguity
Primarily, because of natural languages use (like English), instead also use Use case diagrams to depict requirements
Language Barrier
Different understanding of business
“Always have Client sign off once requirements documents
are made, remade, finalized and concluded for reference”
Error of Speed and Capacity
These occur due to conflicting understanding or competing needs of different stakeholders
Negative impact of Requirements Errors
The resulting software may not satisfy user’s real needs
Multiple interpretations of requirements may cause disagreements between customers and developers, wasting time and money, and perhaps resulting in lawsuits
Negative impact on humans
Unsatisfied customers and developers
Lack of interest in automation of processes
Blame game
All of this can be avoided by using some techniques and guidelines
Defect prevention
Understand application domain and business area
Training on Requirement gathering techniques (elicitation, analysis, negotiation etc)
Join Application Development (JAD), Quality Function Deployment (DFD), Prototyping
Defect removal (Inspections, Reviews, checklist etc)
Guidelines while documenting Requirements
No vague terminology - such as “usually, often, typically, generally, user friendly, versatile, flexible, reliable, and upgradeable,” in writing requirements.
Avoid putting more than one requirement in a requirement (often indicated by the presence of the word “and”)
Avoid clauses like “if that should be necessary.”
Avoid wishful thinking: 100% reliability, running on all platforms, pleasing all users, handling all unexpected failures.
It is a good practice to separate user requirements from more detailed system requirements in a requirements document
The rationale associated with requirements is very important. It helps in managing changes to requirements
Questions ?
In this Slide
______________________________________________________
SRE – Types of Requirements
BSEF15 (V)
Abdul Razaq Ali
Views on Requirements Types
Requirements types can be identified using different views.
1. Hardware vs. Software requirements
2. Production process requirements
3. Complete Taxonomy
1.1 Hardware vs. Software requirements
1. Hardware requirements
1. Performance requirements
2. Constraints:
1. Interface requirements
2. Specialty engineering requirements
3. Environmental requirements
1. Software requirements
1. Functional requirements
2. Nonfunctional requirements
1.2 Production Process Requirements
Complete RE Taxonomy
Requirements Types
Business requirements
Stated requirements vs real requirements
User requirements
High-level or system-level requirements
Process requirements
Qualified requirements
Non-functional requirements
Functional requirements (define business rules)
Derived requirements
Design requirements and constraints
Performance requirements
Unknowable requirements
System and component requirements
Requirements Types
Interface requirements
Verified requirements
Validated requirements
Product requirements
Logistic support requirements
Environmental requirements
Requirements
Business Requirements
Highest in the hierarchy due to its importance
Reason for developing systems and software in the first place.
Essential activities for an enterprise
Any system made MUST reflect and support Business requirements
Stated vs Real Requirements
Stated requirements are provided by a customer at the beginning of the project
Real requirements are identified during requirements analysis phase,
Key responsibility of RA and should cover anything/everything a user wants from the system
User Requirements
User requirements are verified needs of users from the system or software
These are acceptance criteria of a product
Requirements
High Level or System Level Requirements
Comprehend the required system
Capture vision of the customer
Enable defining scope
Allow cost and schedule estimates required to build the system
Functional Requirements
Business Rule Identification – provides basis for Functional requirements
Important Category for Real requirements
Describes what a software system must do
Behavioral or operational requirements as they specify inputs and outputs of the system and the relationship among them
These are depicted in Functional Specification (FS)
Requirements
Business Rules
- The policies, conditions, and constraints of the business activities supported by the
system
- The decision processes, guidelines, and controls behind the functional
requirements (e.g., procedures)
- Definitions used by the business
- Relationships and work flows in the business
- Knowledge needed to perform actions
Requirements
Non-Functional Requirements
Nonfunctional requirements specify system properties, such as reliability, performance and safety.
Derived Requirements
A derived requirement is one that is further refined from a higher-level requirement or a requirement that results from choosing a specific implementation or system element.
Design Requirements
Requirement (design constraint) may be that the system to be developed must obtain its information from an existing database.
For reasons of budget, schedule, or quality, an organization may wish to reuse some or all existing software systems in the implementation of a new system.
Requirements
Performance Requirements
How well the system should perform
Also termed as 'Dependability requirements'
One of the most difficult challenge in system development
availability, security, performance, reliability, and safety.
Interface Requirements
GUI based requirements
Identifies physical and functional relationships among system elements and modules
Verified Requirements
Verified requirements are real requirements that are met or satisfied in the design solution.
Requirements
Validated Requirements
Validated requirements are requirements that are implemented in the delivered System.
Qualification Requirements
Qualification refers to the verification or validation of item performance in a specific application and results from design review, test data review and configuration audits.
Product Requirements
These are requirements of the products that are produced by a system
Process Requirements
Requirements that exist because of the processes being used to develop the software/system
Requirements
Logistic Support Requirements
These are requirements that exist because of such things as tools, training, procedures, facilities and spares
Environmental Requirements
These are requirements that result from the physical settings an
Requirements Errors
A deficiency in the requirements quality that can hamper software development. Requirements errors are the most expensive error type to remove, almost impossible to remove when drilled down to the system
Error Types
Error of Omission: Most Common type
Domain experts easily forget to convey domain knowledge to requirements engineers, because they consider that to be obvious and implicit
Error of Clarity and Ambiguity
Primarily, because of natural languages use (like English), instead also use Use case diagrams to depict requirements
Language Barrier
Different understanding of business
“Always have Client sign off once requirements documents
are made, remade, finalized and concluded for reference”
Error of Speed and Capacity
These occur due to conflicting understanding or competing needs of different stakeholders
Negative impact of Requirements Errors
The resulting software may not satisfy user’s real needs
Multiple interpretations of requirements may cause disagreements between customers and developers, wasting time and money, and perhaps resulting in lawsuits
Negative impact on humans
Unsatisfied customers and developers
Lack of interest in automation of processes
Blame game
All of this can be avoided by using some techniques and guidelines
Defect prevention
Understand application domain and business area
Training on Requirement gathering techniques (elicitation, analysis, negotiation etc)
Join Application Development (JAD), Quality Function Deployment (DFD), Prototyping
Defect removal (Inspections, Reviews, checklist etc)
Guidelines while documenting Requirements
No vague terminology - such as “usually, often, typically, generally, user friendly, versatile, flexible, reliable, and upgradeable,” in writing requirements.
Avoid putting more than one requirement in a requirement (often indicated by the presence of the word “and”)
Avoid clauses like “if that should be necessary.”
Avoid wishful thinking: 100% reliability, running on all platforms, pleasing all users, handling all unexpected failures.
It is a good practice to separate user requirements from more detailed system requirements in a requirements document
The rationale associated with requirements is very important. It helps in managing changes to requirements
Questions ?
Tuesday, 10 October 2017
SRE - Lec # 1
What's in this Slide
Software Requirement Engineering
BSEF15 (V)
Abdul Razaq Ali
Introduction
Purpose -Why this course?
System requirements and the requirements engineering process.
Requirements engineering and a Software Engineer
Importance of the requirements documentations -SRS
This course -Blend of Bespoke and MDRE
Introduction (Cont. )
What is SRE impact in Software engineering learning curve?
Requirements Management vs Project Management
Understanding role of RE in SDLC
Introduction (Cont. )
What are pre-requisites – Previous experience?
Basic concepts of software engineering and understanding of overall software project cycle.
Understanding of project management processes
Good grip on software testing and Object oriented analysis & Design
Introduction (Cont. )
What are outcomes – Future expertise ?
Requirements Analyst
Composed software engineers
Better project team member
Course Site Details
Website URL: http://pucitbookstore.blogspot.com/
Go to the site, press subscribe button to get emails about latest posts.
I suggest you to check blog daily for latest updates on course.
Course Details
Assignments & Final Project
Assignment 1
– Requirement Elicitation & SRS for Library software or Rent a car website.
Assignment 2
– Requirement Engineering Trend Analysis - Case Study: Comparison in 5 years
Final Term Project
– Report submission – Your own experience with client and whole requirement engineering process.
Course Assessment Criteria
Subscribe to:
Posts
(
Atom
)