Saturday, 17 March 2018

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?

Tuesday, 6 March 2018

Android - How to create custom Adapter Listview

Here is the complete video tutorial explaining how to create custom adapter listview in android. Its super easy to create. 


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?

Sunday, 4 March 2018

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?