Software Engineering

Software engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures.

The outcome of software engineering is an efficient and reliable software product.

Dual Role of Software

As a product

It delivers the computing potential across network of Hardware.

It enables the Hardware to deliver the expected functionality.

As a vehicle for delivering a product

It provides system functionality (e.g., payroll system)

It controls other software (e.g., an operating system)

It helps build other software (e.g., software tools)

Why is Software Engineering required?

Software Engineering is required due to the following reasons:

To manage Large software

For more Scalability

Cost Management

To manage the dynamic nature of software

For better quality Management

Classification of software

System software – This type of software that manages and controls the internal functions of a computer system for example, drivers, compilers, operating systems, etc.

Embedded software – This type of software is placed in the “Read-only memory (ROM)” of the product and controls the various functions of the product.

Business Software – This type of software is widely used in areas where managerial and control of financial activities has the highest priority. The main component of a business system is payroll, inventory, and accounting software, which allows the user to access relevant data from the database.

Personal computer software – This software is used for official and personal use. The PC software market has grown over the past two decades, from the simple text editor to the standard word processor.

Real time software – This type of software observes, analyzes, and controls real-world events as they occur. An example of real-time software is the weather forecasting software that collects and processes parameters such as temperature and humidity of the outdoor environment to forecast the weather.

Artificial intelligence (AI) refers to the simulation of human intelligence in machines that are programmed to think like humans and mimic their actions.

Web-based software – This type of software serves as an interface between the user and the Internet.

Software Evolution

The process of developing a software product using software engineering principles and methods is referred to as Software Evolution.

This includes the initial development of software and its maintenance and updates, till desired software product is developed, which satisfies the expected requirements

Software Evolution Laws

Lehman has given laws for software evolution. He divided the software into three different categories:

S-type (static-type) - This is a software, which works strictly according to defined specifications and solutions. The solution and the method to achieve it, both are immediately understood before coding. The s-type software is least subjected to changes hence this is the simplest of all. For example, calculator program for mathematical computation.

P-type (practical-type) - This is a software with a collection of procedures. This is defined by exactly what procedures can do. In this software, the specifications can be described but the solution is not obvious instantly. For example, gaming software.

E-type (embedded-type) - This software works closely as the requirement of real-world environment. This software has a high degree of evolution as there are various changes in laws, taxes etc. in the real world situations.

For example, Online trading software.

E-Type software evolution

Lehman has given eight laws for E-Type software evolution -

Continuing change - An E-type software system must continue to adapt to the real world changes, else it becomes progressively less useful.

Increasing complexity - As an E-type software system evolves, its complexity tends to increase unless work is done to maintain or reduce it.

Conservation of familiarity - The familiarity with the software or the knowledge about how it was developed, why was it developed in that particular manner etc. must be retained at any cost, to implement the changes in the system.

Continuing growth- In order for an E-type system intended to resolve some business problem, its size of implementing the changes grows according to the lifestyle changes of the business.

Reducing quality - An E-type software system declines in quality unless rigorously maintained and adapted to a changing operational environment.

Feedback systems- The E-type software systems constitute multi-loop, multi-level feedback systems and must be treated as such to be successfully modified or improved.

Self-regulation - E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal.

Organizational stability - The average effective global activity rate in an evolving E-type system is invariant over the lifetime of the product.

Legacy software

The older programs are often referred to as legacy software.

Legacy software systems were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms.

Process Frame Work

CMM Process Patterns

Process Assessment

Process Models

Personal and Team Process Models

Personal Software Process (PSP)

Framework Activities

1. Planning 2. High-Level Design 3. High-Level Design Review 4. Development 5. Post-mortem

Team Software Process (TSP)

Framework Activities

1. Launch (Communication and Planning). 2. High-level Design. 3. Implementation. 4. Integration and Test. 5. Post-mortem. /colorred

Prescriptive Models

Waterfall Model

Framework Activities

CPMCD

Communication

Planning

Modelling

Construction

Development

V Model

Framework Activities

Incremental Process Model [IPM]

Framework Activities

Same as waterfall

Rapid Application Development (RAD) Model [Type of IPM]

Framework Activities

Same as waterfall

Difference between both

Evolutionary Process Models

Prototyping Model

Framework Activities

Communication

Quick Plan

Quick Design

Construction

Deployment and Feedback

Image

Spiral Model

proposed by “Boehm”

Encompasses best features of Waterfall and Prototype model

Risk-driven Risk Analysis

Framework Activities

Requirement Analysis

Design

Construction

Testing and Risk Analysis

Spiral Model - javatpoint

The biggest problem we face in the waterfall model is that taking a long duration to complete the product, and the software became outdated. To solve this problem, we have a new approach, which is known as the Spiral model. The spiral model is also known as the cyclic model.

https://www.javatpoint.com/spiral-model

Concurrent Development Model

States

The Unified Process Model (UPM)

Unified Process refers to a methodology of extracting the most essential activities of conventional software development phases (communication, planning, Modeling, construction and deployment) and characterizing them, so that they can be applied in the Agile (highly valued) software development.

Its designed for Object Oriented Approach

Framework Activities

Communication

Planning

Modelling

Construction

Deployment

Pic

Rational Unified Process Model (RUP) [Refinement of UPM]

Same as UPM as per syllabus

Framework Activities

Agile Unified Process Model (AUP) [Simplified version of RUP]

Aggressively change and growth oriented

What is Agile ?

The meaning of Agile is swift or versatile."Agile process model" refers to a software development approach based on iterative development. Agile methods break tasks into smaller iterations, or parts do not directly involve long term planning. The project scope and requirements are laid down at the beginning of the development process. Plans regarding the number of iterations, the duration and the scope of each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which typically lasts from one to four weeks. The division of the entire project into smaller parts helps to minimize the project risk and to reduce the overall project delivery time requirements. Each iteration involves a team working through a full software development life cycle including planning, requirements analysis, design, coding, and testing before a working product is demonstrated to the client.

12 Agile Principles

1. Our highest priority is to satisfy customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even later in development. Agile processes harness change for customer’s competitive advantage. 3. Deliver working software frequently, from couple of weeks to months. 4. Business people and developers must daily work together throughout the project. 5. Build projects around motivated individuals.(Give them support environment and trust to get the job done). 6. Most efficient and effective method of conveying information in a development team is face-to face conversation. 7. Working software is primary measure of progress. 8. Agile processes promote sustainable development. (Users, sponsors, developers should maintain a constant pace). 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity is essential. (Art of maximum amount of work not done). 11. Self-organizing teams are required for best architectures, requirements and designs. 12. At regular intervals, team will tune and adjust its behavior to become more effective.

7 Traits of an Agile Team

Competence

Common Focus

Collaboration

Decision Making Ability

Fuzzy probelm solving ability

Mutual Trust

Self - Organization

Phases of Agile Model

Requirements Gathering

In this phase, you must define the requirements. You should explain business opportunities and plan the time and effort needed to build the project. Based on this information, you can evaluate technical and economic feasibility.

Design the Requirements

When you have identified the project, work with stakeholders to define requirements. You can use the user flow diagram or the high-level UML diagram to show the work of new features and show how it will apply to your existing system.

Construction / Iteration

When the team defines the requirements, the work begins. Designers and developers start working on their project, which aims to deploy a working product. The product will undergo various stages of improvement, so it includes simple, minimal functionality.

Testing / Quality Assurance

In this phase, the Quality Assurance team examines the product's performance and looks for the bug.

Deployment

In this phase, the team issues a product for the user's work environment.

Feedback

After releasing the product, the last step is feedback. In this, the team receives feedback about the product and works through the feedback.

Advantages

Is a very realistic approach to software development.

Promotes teamwork and cross training.

Functionality can be developed rapidly and demonstrated.

Resource requirements are minimum.

Suitable for fixed or changing requirements

Delivers early partial working solutions.

Good model for environments that change steadily.

Minimal rules, documentation easily employed.

Enables concurrent development and delivery within an overall planned context.

Little or no planning required.

Easy to manage.

Gives flexibility to developers.

Disadvantages

Not suitable for handling complex dependencies.

More risk of sustainability, maintainability and extensibility.

An overall plan, an agile leader and agile PM practice is a must without which it will not work.

Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines.

Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction.

There is a very high individual dependency, since there is minimum documentation generated.

Transfer of technology to new team members may be quite challenging due to lack of documentation.

Agile Process Models

Extreme Programming (XP)

Framework Activities

Planning

Design

Coding

Testing

pic

Adaptive Software Development (ASD)

proposed by Jim HighSmith

best technique for building complex software and systems.

Phases of ASD Life Cycle

Speculation

Collaboration

Learning

Focus Groups

Formal Technical Reviews

Post Mortems

Pic

Dynamic Systems Development Method (DSDM)

building and maintaining systems which meet tight time constraints through the use of incremental prototyping

80/20 rule

2 life cycle activities, then

3 different iterative cycles

Steps

Feasibility Study

Business Study

Functional Model Iteration

Design and Build Iteration

Implementation

Crystal

Alistair Cockburn and Jim Highsmith created the “crystal family of agile methods”, to achieve a software development approach that focuses on “manoeuvrability”-“a resource-limited, cooperative game of invention and communication, with a primary goal of delivering useful, working software and secondary goal of setting up for the next game”.

Crystal family is a set of agile processes that are effective for different types of projects.

The intent is to allow agile teams to select the member of crystal family that is most appropriate for their software project and environment

Scrum

Developed by Jeff Sutherland

Principles

1. Small working teams are organized to “maximize communication, minimize overhead and maximize sharing of tacit, informal knowledge”. 2. Process must be adaptable to both technical and business changes “to ensure best possible product is produced.” 3. Process yields frequent software increments “that can be inspected, adjusted, tested, documented and build on”. 4. Developed work and teams are partitioned “into clean low coupling packets”. 5. Constant testing and documentation is performed as the product is built. 6. Scrum process provides the “ability to declare a product ‘done’ whenever required”

Development Activities

Backlog

“A prioritized list of project requirements or features that provide business value for the customer”. Product manager assesses each backlog and updates priorities as required.

Sprints

“Consists of work units that have to achieve a requirement defined in the backlog that must be fit into a predefined time-box (30 days)”.As changes are not introduced during the sprint, it allows team members to work in a short-term, but stable environment

Scrum Meeting

“Short (15 minutes) meeting held daily by the scrum team. A team leader, called a “scrum master” leads the team meeting and assesses responses from each person. The key question asked and answered by all team members are:  What did you do since last meeting?  What obstacles are you encountering?  What do you plan to accomplish by next meeting? These daily meetings help to know the problems in the team and lead to “knowledge socialization” and so promote team structure.

Feature Driven Development (FDD)

Agile Modelling (AM)

Specialized Process Models

Component Based Development

Steps

1. Available component-based products are researched and evaluated for the application domain in question. 2. Component integration issues are considered. 3. Software architecture is designed to accommodate the components. 4. Components are integrated into the architecture. 5. Comprehensive testing is used (conducted to ensure proper functionality).

Formal Methods Model

Specialized software development approach that uses mathematical based techniques for specifying, developing and verifying the computer softwares.

Formal Methods Model helps the software developers to apply correct mathematical notations to create the issue of insufficiency, inconsistency and uncertainty of the software by applying mathematical analysis.

During design phase, formal methods model acts as a program verifier and help Software Engineers to detect and correct these errors, which are otherwise very difficult to be detected. This model assures defect free software

Framework Activities

Aspect-Oriented Software Development

Cross -Cutting concerns spanning across the architecture

AOSD, often referred to as Aspect-Oriented Programming (AOP), is a relatively new software engineering paradigm which provides a process for defining, specifying, designing and constructing aspects (crosscutting concerns)

Framework Activities

Extra

The Unified Process Models

Process Technology

Product and Process

UNIT 2

Software Engineering Principles

Core Principles

Principles that guide Process

Mnemonic : CARVE QAC

Communication

Agility

Risk

Value

Effective

Quality

Adapt

Change

Principles that guide Practice

Mnemonic : ACID MPMP

Abstraction

Consistency

Information

Divide (and conquer)

Maintain

Pattern

Modularity

Perspective

Communication Principles

Mnemonic : MANDAP PLC ( Remove all A's )

Modularize

Negotiate

Document

Prepare

Picturize (show diagrams)

Listen

Collaborate

Planning Principles

Minimalist Vs Agilitist Vs Traditionalist

Mnemonic : SQUIRTER IC

Specific

Quality

Understand

Iterate

Risk Realistic

Track

Estimate

Reach

Involve

Change

Modelling Principles

Requirements Modelling Principles [ Informational, Functional, Behavioural Domains ]

Mnemonic : URADO 🔫

Understand

Represent

Analyze

Define

Organize

Design Modelling Principles [ Architecture, UI, Component Level Detail ]

Mnemonic : U SAID I

🗒️

Design should be tracable to the Requirements Model

Understandable

Simple

Architecture

Iterate

Data

Interface

🗒️

It's difficult to condense principles for this one into a mneomnic. Go through them once

Principles

Design should be tracable to requirements

Always consider architecture of the system to be built

Design of data is as important as design of system

Interfaces must be designed with care

UI should be tuned to the needs of the user

Component level design should be functionally independant

Components should be losely coupled

Design representations should be easiliy understandable

Design should be developed iteratively

Construction Princples

Coding Principles

Preparation Principles

Programming Principles

Validation Principles

Testing Principles

Deployment Principles

Actions : Delivery, Support, Feedback

Mnemonic : STEM Q

Support

Test

Expectation

Manual (Instruction Manual)

Quality (Don't ship low quality software first fix bugs and improve)

System Engineering

The System Engineering Hierarchy

pic

System Modelling

CLAPS

Assumptions

Simplifications

Limitations

Constraints

Preferences

Business Process Engineering

The goal of Business Process Engineering (BPE) is to define architectures that will enable a business to use information effectively

Architectures

Data Architecture

Application Architecture

Technology Infrastructure

BPE Heirarchy

Information Strategy Planning

Business Area Analysis

Application Engineering

Construction and Delivery

pic

Product Engineering

Product Engineering: The goal of product engineering is to translate customer’s desire into a working product. It consists of four system components.  Software  Hardware  Data  People

System Modelling with UML

Requirements Engineering

Requirement Engineering builds a bridge to design and construction. It allows a software team, to examine, 1) About the context of the software work to be performed. 2) The specific needs that design the construction must address. 3) The priorities that guide the order in which work is to be completed. 4) The information, functions and behaviors that will have a profound impact on the resultant design.

Requirements Engineering Tasks

Mnemonic : INVERSE

Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements Management

Initiating Requirements Engineering Process

CARI

Identify

Recognize

Collaborate

Eliciting Requirements

Elaboration

Negotiating Requirements

Validating Requirements

UNIT 5

Develop

Review

Verify

Verification vs Validation

Types of Testings

Unit Testing

Compare actual output with predefined output

Test DSA

Internal Logic

A Unit test consists of 5 'module' Tests

Interface

Local DSA=

Boundary Conditions

Independant Paths

Error Handling Paths

Common Errors

Computation

Comparison

Control Flow

pic 1

pic 2

Integration Testing

Approaches

Big Bang Approach

Incremental Integration

Non - incremental Integration Strategies

Big Band Integration Strategy

Incremental Integration Strategies

Top-Down Integration

DFS or BFS Integration

Steps

1. The main control module is used as a test driver and stubs are substituted for all components directly subordinate to the main control module. 2. Depending on the integration approach selected (i.e., depth or breadth first), subordinate stubs are replaced one at a time with actual components. 3. Tests are conducted as each component is integrated. 4. On completion of each set of tests, another stub is replaced with the realcomponent. 5. Regression testing may be conducted to ensure that new errors have not been introduced. The process continues from step 2 until the entire program structure is built.

Diagram

Bottom-Up Integration

Steps

1. Low-level components are combined into clusters (sometimes-called builds) that perform a specific software sub function. 2. A driver (a control program for testing) is written to coordinate test case input and output. 3. The cluster is tested. 4. Drivers are removed and clusters are combined moving upward in the program structure.

Diagram

D1 D2 D3 are drivers not actual code, they are incrementally removed

Sandwitch Integration

Steps

High and low-level modules are grouped based on the control and data processing they provide for a specific program feature – Integration within the group progresses in alternating steps between the high and low level modules of the group – When integration for a certain functional group is complete, integration and testing moves onto the next group – Uses the advantages of both types of integration while minimizing the need for drivers and stubs • Requires a disciplined approach so that integration doesn’t tend towards the “big bang” scenario.

Diagram

Smoke Integration

5 things to see when choosing test strategy

No. of drivers and stubs required

Availability of sufficient hardware

Scheduling Concerns

Location of important parts in complete program

Cusomter's urgency for prototype

System Testing

Recovery Testing

Security Testing

Stress Testing

Validation Testing

Software validation is achieved through a series of black-box tests that demonstrate conformity with requirements. Both plan and procedure are designed to ensure that all functional requirements are satisfied, all behavioral characteristics are achieved, all performance requirements are attained, documentation is correct and other requirements are met. 9 After each validation test case has been conducted, one of two possible conditions exist: 1. The function or performance characteristics conform to specification and are accepted 2. A deviation from specification is uncovered and a deficiency list is created

Regression Testing

Each time a new module is added as part of integration testing, the software changes. New data flow paths are established, new I/O may occur, and new control logic is invoked. Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.

The regression test suite (the subset of tests to be executed) contains three different classes of test cases: • A representative sample of tests that will exercise all software functions. • Additional tests that focus on software functions that are likely to be affected by the change. • Tests that focus on the software components that have been changed.

Smoke Testing

Smoke testing is also known as "Build Verification Testing" or “Confidence Testing.”

In simple terms, we are verifying whether the important features are working and there are no showstoppers in the build that is under testing.

It is a mini and rapid regression test of major functionality. It is a simple test that shows the product is ready for testing. This helps determine if the build is flawed as to make any further testing a waste of time and resources.

Tests not in syllabus

Development Testing

Qualification Testing

Installation Testing

(Widget Testing ?)

Acceptance Testing

Other Activities apart from tests that are important

Organization of Software Testing

Independant Test Group

Conventional Software Testing Strategy

Strategy

Steps

OO Software Testing Strategy

Class Testing

Integration

Thread based testing

use-based testing

cluster testing

Testing Tactics

White Box

goal is to ensure that all statements and conditions have been executed at least once

guaranteed to execute every statement in the program at least one time during testing

Using this tactic we can derive test cases with following characteristics

1.Guarantee that all independent paths within a module have been exercised at least once. 2.Exercise all logical decisions on their true and false sides. 3.Execute all loops at their boundaries and within their operational bounds. 4.Exercise internal data structures to ensure their validity.

Implementation Techniques

proposed by Tom McCabe

Basis Path Testing

Flow graph notation representing flow of control

Diagram

Cyclomatic Comlexity [ No. of closed Regions + 1 ]

Resources

Software Engineering | White box Testing - GeeksforGeeks

Prerequisite - Software Testing | Basics White box testing techniques analyze the internal structures the used data structures, internal design, code structure and the working of the software rather than just the functionality as in black box testing. It is also called glass box testing or clear box testing or structural testing.

https://www.geeksforgeeks.org/software-engineering-white-box-testing/

Black Box

Focuses on functional Requirements and not code

Category of errors

incorrect or missing functions

Interface errors

errors in dsa

behavious / performance errors

initialization and termination errors

Testing methods

Graph based testing method

Equivalence Partitioning

Boundary Value Analysis

Orthogonal Array Testing

Resources

Software Engineering | Black box testing - GeeksforGeeks

Prerequisite - Software Testing | Basics Black box testing is a type of software testing in which the functionality of the software is not known. The testing is done without the internal knowledge of the products. Black box testing can be done in following ways: 1.

https://www.geeksforgeeks.org/software-engineering-black-box-testing

The Art of Debugging

Approaches

Brute Force

Backtracking

Cause Elimination

Resources

Software Engineering | Debugging - GeeksforGeeks

Introduction: In the context of software engineering, debugging is the process of fixing a bug in the software. In other words, it refers to identifying, analyzing and removing errors. This activity begins after the software fails to execute properly and concludes by solving the problem and successfully testing the software.

https://www.geeksforgeeks.org/software-engineering-debugging/

Software Quality Assurance (SQA)

Elements of SQA

SQA Tasks

7 principles of ISO 9000

RECIPE L

The SQA Plan

Product Metrics

Software Quality

ISO 9126 Quality Factors

Metrics for Analysis Model

Metrics for Specification of Quality

Metrics for Design Model

Metrics for Object Oriented Design

Class-oriented Metrics

Use-Case Oriented Metrics

Metrics for source code

Metrics for testing

Metrics for maintainance

Resources

Software Engineering | Software Metrics - javatpoint

A software metric is a measure of software characteristics which are measurable or countable. Software metrics are valuable for many reasons, including measuring software performance, planning work items, measuring productivity, and many other uses. Within the software development process, many metrics are that are all connected.

https://www.javatpoint.com/software-engineering-software-metrics

Keywords

Abstraction

Adapt

Agility

Analyze

Ambiguity

Architecture

Assumptions

Behaviour

Control

Change

Collaborate

Communication

Consistency

Constraints

Context

Data

Define

Divide (and conquer)

Document

Effective

Elaboration

Elicitation

Estimate

Evolution

Feasible

Identify

Implement or Implementation

Incomplete

Inception

Information

Interface

Involve

Iterate

Limitations

Listen

Maintain

Modularity or Modularize

Negotiate

Organize

Priority or Prioratize

Perform

Pattern

Perspective

Picturize (show diagrams)

Preferences

Prepare

Quality

Reach

Recognize

Represent

Requirements Management

Risk

Refine

Realistic

Simple

Specific or specifications

Track or Traceable

Understand or understandable

Verification

Validation

Value