MODULE NAME AND CODE :BACKEND SYSTEM DESIGN SWDBS401

Sector: ICT and Multimedia

Trade: Software Development

Leval:4

Learning outcome 1: Analyze System Backend

• BACKEND: refers to the server-side of a software application.

• It includes the server, database, and other components that are

responsible for processing and storing data, as well as managing the logic
and functionality of the application.

• The backend interacts with the frontend (user interface) to deliver a

complete software solution.

 System: A system is a collection of interconnected components or

elements that work together to achieve a specific purpose or function.

• A server is a computer or software program that provides services,

resources, or data to other computers or programs, known as clients, over
a network.

• Database: is a structured collection of data organized for efficient retrieval,

storage, and management.

• It typically consists of tables that store related data and can be queried
and manipulated using database management systems (DBMS) such as
MySQL, PostgreSQL, or Microsoft SQL Server.

• JSON (JavaScript Object Notation):

• JSON is a lightweight data interchange format used for storing and

exchanging data between a server and a client, or between different parts
of an application.

• Framework:

• A framework is a pre-designed, reusable set of tools, libraries, and

conventions that provides a structured foundation for developing software
applications.

• It simplifies common tasks and promotes best practices in software

development.
 • UML (Unified Modeling Language):UML is a standardized visual modeling
language used in software engineering to create diagrams and
representations of a system's structure and behavior.

• It helps developers and stakeholders visualize and communicate design

concepts and requirements.

• FURPS (Functionality, Usability, Reliability, Performance, and

Supportability):

• FURPS is an acronym used to assess and prioritize software quality

attributes. It represents different aspects of software quality, including
functionality (features), usability (user-friendliness), reliability (stability),
performance (speed and efficiency), and supportability (maintainability
and extensibility).

• It is often used as a framework for software quality requirements analysis.

L.O 1.2 SYSTEM DEVELOPMENT LIFE CYCLE

1.2.1 SYSTEM LIFE CYCLE

System life cycle is an organizational process of developing and maintaining

systems. It helps in establishing a system project plan, because it gives overall
list of processes and sub-processes required for developing a system.

It is a frame work defining tasks (activities) performed at each step in the

software development process. It is a structure followed by a development team
from the beginning up to the end of software development.

System development life cycle means combination of various activities. In other

words, we can say that various activities put together are referred as system
development life cycle. In the System Analysis and Design terminology, the
system development life cycle also means software development life cycle.

1.2.2 Different phases of System development life cycle

Typically the SDLC has 8 steps (phases) in the development and improvement of
a computer system.

Following are the different phases of system development life cycle:

1. Preliminary study
2. Feasibility study
3. Detailed system study
4. System analysis
 5. System design
6. Coding
7. Testing
8. Implementation
9. Maintenance

Let us now describe the different phases and related activities of system
development life cycle.

(a) Preliminary System Study

Preliminary system study is the first stage of system development life cycle. In
practice, the initial system study involves the preparation of a ‘System Proposal’
which lists the Problem Definition, Objectives of the Study, Terms of reference
for Study, Constraints, and Expected benefits of the new system, etc. in the light
of the user requirements. The system proposal is prepared by the System Analyst
(who studies the system) and places it before the user management. The
management may accept the proposal and the cycle proceeds to the next stage.
The management may also reject the proposal or request some modifications in
the proposal. In summary, we would say that system study phase passes
through the following steps:

 Problem identification and project initiation

 Background analysis
 Inference(Conclusions) or findings (information they get)
System study identifying problems, opportunities and objectives of the target
system after gathering all possible information.

(b) Feasibility Study

It is an assessment of determining the viability of the idea, ensuring whether a

proposed project is legally, technically, operationally, as well as economically
feasible and justifiable.

In case the system proposal is acceptable to the management, the next phase is
to examine the feasibility of the system. The feasibility study is basically the test
of the proposed system in the light of its workability, meeting user’s
requirements, effective use of resources and of course, the cost effectiveness.
These are categorized as:

 Technical feasibility
 Operational feasibility
 Economic feasibility
 And schedule feasibility.

1. Technical Feasibility

Helps organizations to determine whether the technical resources meet capacity

and whether technical team is capable of converting the ideas into working
system.

Technical feasibility also involves the evaluation of the hardware, software and
other technical requirements of the proposed system. A project may requiring
many technical resources, where many cost more than that an organizational
could earn back.

That project is said to be not profitable.

2. Operational feasibility

It is an assessment of determining and examining whether organization’s needs

can be meet by completing the project.

3. Economic feasibility

It is an assessment that involves a cost/benefits analysis of the project. It helps

organizations to determine the viability, cost, and benefits associated with a
project. This should be done before that financial resources are allocated.

4. Schedule feasibility
In schedules feasibility study, organization estimates how much time the project
will take to be completed.

5. Legal Feasibility

It is an assessment that investigates whether any aspect of the proposed project

conflicts with legal requirements

Eg: Like zoning lows, drags marketing etc.

The main goal of feasibility study is not to solve the problem but to achieve the
scope.

In the process of feasibility study, the cost and benefits are estimated with
greater accuracy to find the Return on Investment (ROI). This also defines the
resources needed to complete the detailed investigation. The result is a
feasibility report submitted to the management. This may be accepted or
accepted with modifications or rejected. The system cycle proceeds only if the
management accepts it.

Feasibility Study or Planning

 Define the problem and scope of existing system.

 Overview the new system and determine its objectives.
 Confirm project feasibility and produce the project Schedule.
 During this phase, threats, constraints, integration and security of system
are also considered.
 A feasibility report for the entire project is created at the end of this phase.

(c) System Analysis

It is the process of collecting (gathering) and interpreting facts, identifying

problems and decomposing a system into its components in order to identify its
objectives.

This involves detailed study of the business processes, gathering operational

data, understand the information flow, finding out bottlenecks and evolving
solutions for overcoming the weaknesses of the system so as to achieve the
organizational goals.

System Analysis also includes subdividing of complex process involving the

entire system, identification of data store and manual processes.
At this
phase systems analyst studies the problems and needs of an organization to de
termine how people,data,processes,communications, and information technolo
gy can best accomplish improvements for the business.

In short system analyst determines how technology can be involved to provide

the solution to current problems.

The result of this process is a logical system design. Systems analysis is an

iterative process that continues until a preferred and acceptable solution
emerges.

Tools and Technics of system analysis:

1. Grid chart
2. System flow Chart
3. Decision Tree
4. Simulation
5. Decision table

(d) System Design

Based on the user requirements and the detailed analysis of the existing system,
the new system must be designed. This is the phase of system designing. It is
the most crucial phase in the developments of a system. The logical system
design arrived at as a result of systems analysis is converted into physical
system design. Normally, the design proceeds in two stages:

 Preliminary or General Design

 Structured or Detailed Design
Preliminary or General Design: In the preliminary or general design, the
features of the new system are specified. The costs of implementing these
features and the benefits to be derived are estimated. If the project is still
considered to be feasible, we move to the detailed design stage.

Structured or Detailed Design: In the detailed design stage; the design of the
system becomes more structured. Structure design is a blue print of a computer
system solution to a given problem having the same components and inter-
relationships among the same components as the original problem.

Notes:

1. Input, output, databases, forms, codification schemes and processing

specifications are drawn up in detail.
2. In the design stage, the programming language and the hardware and software
platform in which the new system will run are also decided.

There are several tools and techniques used for describing the system design of
the system. These tools and techniques are:

 Flowchart
 Data flow diagram (DFD)
 Data dictionary
 Structured English
 Decision table
 Decision tree

(e) Coding

The system design needs to be implemented to make it a workable system. This

demands the coding of design into computer understandable language, i.e.,
programming language.

This also called the programming phase in which the programmer converts the
program specifications into computer instructions, which we refer to as
programs. It is an important stage where the defined procedures are transformed
into control specifications by the help of a computer language. The result of the
phase is workable system

(f) Testing

Before actually implementing the new system into operation, a test run of the
system is done for removing the bugs, if any. It is an important phase of a
successful system. After codifying the whole programs of the system, a test plan
should be developed and run on a given set of test data. The output of the test
run should match the expected results. Sometimes, system testing is considered
a part of implementation process. The purpose of testing phase is removing the
bugs from the system if any.

Using the test data following test run are carried out:

 Program test
 System test

Program test: Done when the programs have been coded, compiled and brought
to working conditions, they must be individually tested with the prepared test
data. Any undesirable happening must be noted and debugged (error
corrections).
This test done when the programs have been coded and compiled.

System Test: After carrying out the program test for each of the programs of the
system and errors removed, then system test is done. At this stage the test is
done on actual data. The complete system is executed on the actual data.

At each stage of the execution, the results or output of the system is analyzed.
During the result analysis, it may be found that the outputs are not matching
the expected output of the system.

In such case, the errors in the particular programs are identified and are fixed
and further tested for the expected output.

When it is ensured that the system is running error-free, the users are called
with their own actual data so that the system could be shown running as per
their requirements. The result is user acceptance of the system or System
validation.

(g) Implementation

After having the user acceptance of the new system developed, the
implementation phase begins. Also called deployment phase. At this phase the
product made in use. After the product team tests product and product passes,
the product is ready to go live.

It seems like the final phase of SDLC. It puts the products into production

The major steps or activities involved in this phase are:

 Installation of Hardware and Software

 Conversion:
 User Training
 Documentation

The hardware and the relevant software required for running the system must
be made fully operational before implementation. The conversion is also one of
the most critical and expensive activities in the system development life cycle.
The data from the old system needs to be converted to operate in the new format
of the new system. The database needs to be setup with security and recovery
procedures fully defined.

During this phase, all the programs of the system are loaded onto the user’s
computer. After loading the system, training of the user starts. Main topics of
such type of training are:
  How to execute the package?
 How to enter the data?
 How to process the data (processing details)?
 How to take out the reports?

After the users are trained about the computerized system, working has to shift
from manual to computerized working. The process is called ‘Changeover’.

Changeover of the System: Is a smooth shift from old system to new system.

The following strategies are followed for changeover of the system.

(i) Direct Changeover: This is the complete replacement of the old system by
the new system. It is a risky approach and requires comprehensive system
testing and training.

(ii) Parallel run: In parallel run both the systems; computerized and manual,
are executed simultaneously for certain defined period. The same data is
processed by both the systems. This strategy is less risky but more expensive
because of the following:

 Manual results can be compared with the results of the computerized

system.
 The operational work is doubled.
 Failure of the computerized system at the early stage does not affect the
working of the organization, because the manual system continues to
work, as it used to do.

(iii) Pilot run: In this type of run, the new system is run with the data from one
or more of the previous periods for the whole or part of the system. The results
are compared with the old system results. It is less expensive and risky than
parallel run approach. This strategy builds the confidence and the errors are
traced easily without affecting the operations.

The documentation of the system is also one of the most important activity in
the system development life cycle. This ensures the continuity of the system.
There are generally two types of documentation prepared for any system. These
are:

 User or Operator Documentation

 System Documentation

The user documentation is a complete description of the system from the user’s
point of view detailing how to use or operate the system.
It also includes the major error messages likely to be encountered by the users.

The system documentation contains the details of system design, programs,

their coding, system flow, data dictionary, process description, etc.

This helps to understand the system and permit changes to be made in the
existing system to satisfy new user needs.

The results of the phase is implemented system and System documentation

(i) Maintenance

Maintenance is necessary to eliminate errors in the system during its working

life and to tune the system to any variations in its working environments. It has
been seen that there are always some errors found in the systems that must be
noted and corrected. It also means the review of the system from time to time.
The review of the system is done for:

 Knowing the full capabilities of the system

 Knowing the required changes or the additional requirements
 Studying the performance.

If a major change to a system is needed, a new project may have to be set up to

carry out the change. The new project will then proceed through all the above
life cycle phases.

1.2.3 Stakeholders of the System Development

Stakeholder in software development is people or group of people affected by a

software development.
Two types of System Development Stakeholders:
1. Internal stakeholders
2. External stakeholder
1.InternalStakeholder:
An internal stakeholder is a person, group or a company that is directly involved
in the project.
For example,
a. ProjectManager:
Is the one who is responsible for managing the whole project. Project
Manager is generally never involved in producing the end product but
he/she controls, monitors and manages the activities involved in the
production.
b. Project Team or Development Team:
It is a group of employees performs the actual work of the project under the
Project Manager including development, testing, etc.
c. Company:
It is an Organization who has taken up the project and whose employees are
directly involved in the development of the project.
d. System Owners, Project Funders or Project Sponsors:
Are the information system's sponsors and chief advocates; responsible for fun
ding the information system to be developed, operate, and to be maintained.
They are at the side of Business Company
2.ExternalStakeholder:
An external stakeholder is the one who is linked indirectly to the project but has
significant contribution in the successful completion of the project.
For example,
a. System user or Customer:
 Are the people who use or affected by information system
on a regular basis, by
capturing, validating, entering, responding to, storing, and exchanging
data and information.
 Specifies the requirements of the project and helps in the elicitation
process of the requirement gathering phase.
 Customer is the one whom the project is being developed for.
 A common synonym is client.
b. Supplier:
Supplies essential services and equipment for the project.
c. Government:
Government makes policies which helps in better working of the organization.
Members of the Development Team

 System Analyst: is the one who work with the customers to identify and
document the requirement.
 Business Analyst: Is a systems analyst that specialized in business prob
lem analysis and technology independent requirements analysis.
 System Designers: Translate system users' business requirements and c
onstraints into technical solutions. They design the computer files, data
bases, inputs,
outputs, screens, networks and programs that will meet the system user
s' requirements.
 System Programmer: Write lines of code to implement the system design.
Convert system design into working system.
 Testers: Catch faults
 Trainers: Show users how to use system
 Maintenance Team: Fix faults that show up later
 Librarians: Prepare and store documents such as software requirements
 Configuration management Team: Maintain correspondence among
various artefacts.

NB: What Does a Systems Analyst Do?

 Identify the problem.

 Analyze and understand the problem.
 Identify solution requirements or expectations.
 Identify alternative solutions and decide a course of action.
 Design and implement the “best” solution.
 Evaluate the results. If the problem is not solved, return to Step 1 or 2 as
appropriate

1.3.3 System testing, implementation and maintenance

System Maintenance: It is the act of regularly checking your system for issues,
mistakes, and keeping it updated and relevant.

Importance of System maintenance

 Keep your system healthy
 Encourage continued growth, and
 Strengthen your SEO (Search Engine Optimization) and Google rankings.
  Is important to big and small companies in order to engage and retain
customers
 Keeps your System running smoothly

Whenever a new feature added in a system or any change made, it have to be

tested and then the full system tested too. Testing the solution and full site by.

 Links testing
 Forms testing for all pages
 Cookies testing
 HTML/CSS validation
 Usability resting
 Content testing
 UI (User Interface testing)
 Compatibility (Configuration testing)
 Cross-platform testing
 Database testing
 Security testing
 Change related testing.
 Mobile-friendly testing.
 Beta testing

Difference between alpha and beta testing

Alpha Testing is a type of software testing performed to identify bugs before

releasing the product to real users or to the public. Beta testing is performed by
clients who are not part of the organization. Alpha testing is performed at
developer's site. Beta testing is performed at end-user of the product.
Differences between Black Box Testing vs White Box Testing

1. Black Box Testing is a software testing method in which the internal

structure/ design/ implementation of the item being tested is NOT known
to the tester
2. White Box Testing is a software testing method in which the internal
structure/ design/ implementation of the item being tested is known to the
tester.
 Types of White Box Testing:
 A. Path Testing
 B. Loop Testing
 C. Condition testing

Some website/System error Testing

a) Links testing: Link testing is the testing of a group of modules to ensure that
the modules operate correctly in combination. It performed after the individual
modules have been tested in isolation and prior to the integration testing that is
performed for the complete system.

b) Usability testing: Usability testing is a technique used in user-centered

interaction, evaluate a product by testing it on users.

c) Content testing: Also known as Usability Testing, simply defined as a practice

of testing whether the website content is appropriate & suitable for the users
understand & comprehend.

d) Cross-platform testing: Cross-platform testing is performed to determine the

behavior of your application and website in different environments (Devices).

e) Compatibility testing is a type of software testing used to ensure

compatibility of the system/application/website built with various other objects
such as other web browsers, hardware platforms, users (in case if it’s very
specific type of requirement, such as a user who speaks and can read only a
particular language), operating systems etc.

Difference between user-interface testing and database testing

User-Interface testing Database or Data testing

This type of testing is also known as This type of testing is also known as Backend
Graphical User Interface testing or Front-end Testing or data testing.
Testing.

This type of testing chiefly deals with all the This type of testing chiefly deals with all the
testable items that are open to the user for testable items that are generally hidden from
viewership and interaction like Forms, the user for viewership. These include
Presentation, Graphs, Menus, and Reports, internal processes and storage like Assembly,
etc. (created through VB, VB.net, VC++, DBMS like Oracle, SQL Server, MYSQL, etc.
Delphi - Front-end Tools )

This type of testing includes validating the This type of testing involves validating:

 text boxes  the schema

 select dropdowns  database tables
 calendars and buttons  columns
 Page navigation  keys and indexes
 display of images  stored procedures triggers
 Look and feel of the overall application  database server validations
 validating data duplication
.

The tester must be thoroughly knowledgeable To be able to perform backend testing, must
about the business requirements as well as the tester have a strong background in the
the usage of the development tools and the database server and Structured Query
usage of automation frameworks and tools. Language concepts.

Difference between system validation and System Verification

Software verification

 Software Verification is done at the starting of the development process. It

includes reviews and meetings, walk-throughs, inspection, etc. to
evaluate documents, plans, code, requirements and specifications.
 It takes place at the starting of the development process.
 It answers the questions like:

 Am I building the product right?

 Am I accessing the data right (in the right place; in the right way)?

Advantages of Software Verification:

1. Verification helps in lowering down the count of the defect in the later
stages of development.
2. Verifying the product at the starting phase of the development will help in
understanding the product in a better way.
3. It reduces the chances of failures in the software application or product.
 4. It helps in building the product as per the customer specifications and
needs.

Software validation

Validation is basically done by the testers during the testing. While validating
the product if some deviation is found in the actual result from the expected
result then a bug is reported or an incident is raised. Not all incidents are bugs.
But all bugs are incidents. Incidents can also be of type ‘Question’ where the
functionality is not clear to the tester.

Advantages of Software Validation

1. During verification if some defects are missed then during validation

process it can be caught as failures.
2. Validation is done during testing like feature testing, integration testing,
system testing, load testing, compatibility testing, stress testing, etc.
3. Validation helps in building the right product as per the customer’s
requirement and helps in satisfying their needs.
1.3 SDLC models

1. Waterfall

The waterfall model is a sequential approach, where each fundamental activity of

a process represented as a separate phase, arranged in linear order.

Each stage has concrete deliverables and is strictly documented. The next stage
cannot start before the previous one is fully completed. Thus, for example,
software requirements cannot be re-evaluated further in development. There is
also no ability to see and try software until the last development stage is finished,
which results in high project risks and unpredictable project results. Testing is
often rushed, and errors are costly to fix.

Use cases:

 Simple small or mid-sized projects with clearly defined and unchanging

requirements (small company website development).
 Projects with the need for stricter control, predictable budget and timelines
(e.g. governmental projects).

 Projects that must adhere to multiple rules and regulations (healthcare

projects).
 Projects where a well-known technology stack and tools are used.
 Waterfall Should only be applied when requirements are well understood
Notes: In the waterfall model, you must plan and schedule all of the activities
before starting working on them (plan-driven process).
Plan-driven process: Is a process where all the activities are planned first and
the progress is measured against the plan. While the agile process, planning is
incremental and it’s easier to change the process to reflect requirement changes.

Iterative Waterfall Model and Classic Waterfall Model

Iterative Waterfall Model is the extension of the Waterfall model (Classic).
This model is almost same as the waterfall model except some modifications
are made to improve the performance of the software development.
The iterative waterfall model provides customer's feedback paths from each
phase to its previous phases.
In the classical waterfall model, there are no feedback paths, so there is no
mechanism for error correction. But in iterative waterfall model feedback path
from one phase to its preceding phase allows correcting the errors that are
committed and these changes are reflected in the later phases.

NB: All other model are extensions of this model

2. V-SHAPE MODEL (Validation and Verification model)
The V-model is another linear model with each stage having a corresponding
testing activity. Such workflow organization implies exceptional quality control,
but at the same time, it makes the V-model one of the most expensive and time-
consuming models.

Moreover, even though mistakes in requirements specifications, code and

architecture errors can be detected early, changes during development are still
expensive and difficult to implement. As in the Waterfall case, all requirements
are gathered at the start and cannot be changed.

Use cases:

 Projects where failures and downtimes are unacceptable (e.g., medical

software, aviation fleet management software).
 3. PROTOTYPING MODEL

Prototyping Model is a software development model in which prototype is

built, tested, and reworked until an acceptable prototype is achieved.

It creates base to produce the final system or software. It works best in scenarios
where the project's requirements are not known in detail.
Software prototyping is the activity of creating prototypes of software
applications, i.e., incomplete versions of the software program being
developed.
A prototype is a version of a system or part of the system that’s developed quickly
to check the customer’s requirements or feasibility of some design decisions. In
short it is incomplete versions of the software program being developed.
So, a prototype is useful when a customer or developer is not sure of the
requirements, or of algorithms, efficiency, business rules, response time, etc.
In prototyping, the client is involved throughout the development process, which
increases the likelihood of client acceptance of the final implementation.
While some prototypes are developed with the expectation that they will be
discarded, it is possible in some cases to evolve from prototype to working system.

A software prototype can be used:

[1] In the requirements engineering, a prototype can help with the elicitation
and validation of system requirements.
It allows the users to experiment with the system, and so, refine the
requirements. They may get new ideas for requirements, and find areas of
strength and weakness in the software.

Furthermore, as the prototype is developed, it may reveal errors; and in the

requirements, the specification maybe then modified to reflect the changes.

[2] In the system design, a prototype can help to carry out design experiments
to check the feasibility of a proposed design.
For example, a database design may be prototype-d and tested to check it
supports efficient data access for the most common user queries.

The phases of a prototype are:

1. Establish objectives: The objectives of the prototype should be made
explicit from the start of the process. Is it to validate system
requirements, or demonstrate feasibility, etc.
2. Define prototype functionality: Decide what are the inputs and the
expected output from a prototype. To reduce the prototyping costs
and accelerate the delivery schedule, you may ignore some
functionality, such as response time and memory utilization unless
they are relevant to the objective of the prototype.
3. Develop the prototype: The initial prototype is developed that
includes only user interfaces.
4. Evaluate the prototype: Once the users are trained to use the
prototype, they then discover requirements errors. Using the
feedback both the specifications and the prototype can be improved.
If changes are introduced, then a repeat of steps 3 and 4 may be
needed.

NB: Prototyping is not a standalone, complete development methodology, but

rather an approach to be used in the context of a full methodology (such as
incremental, spiral, etc).
4. Incremental and Iterative model

Incremental development is a development approach that slices the

product into fully working slices that are called increments. Each new
increment builds on top of the existing released functionality.
Example of Incremental Model: Ecommerce website

Consider a team building an ecommerce website using incremental

development. The final target product has search, product information,
a shopping basket, checkout, favorites, and customer reviews.

For the first released increment, the team builds the basic functionality
to buy a product. It includes search, product information, adding
products to a shopping basket and checkout. This first slice would only
be released once it’s complete.

The second released increment builds on that basic functionality, and

would add another capability such as favorites. They would be released
when the favorite’s functionality is complete.

The third released increment adds customer reviews once that is

complete, and so on

NB: The Incremental development process can go either sequentially or in

parallel. Parallel development adds to the speed of delivery, while many repeated
cycles of sequential development can make the project long and costly.

5. Iterative model

Iterative development is when teams gradually build up the features

and functions but don’t wait until each of these is complete before
releasing.
Example of Iterative: Ecommerce website
Assume a team building the same ecommerce website using an iterative
process.

The first release has a really stripped back version of all the required
functionality; namely search, product information, a shopping basket,
checkout, favorites, and customer reviews.

For the second iterative release, the team would improve some of the
existing basic functionality, taking into account feedback from
stakeholders or customer, or other inputs such as analytics.

On every subsequent iterative release, new ideas and requirements are

added or low value/usage areas may be removed.

This SDLC model typically entails some customer involvement because of the
possible need in small requirements amendments during the development
process.

NB: Iterative model,

  Go through improvement cycles, means build the whole system and
improve.
 Can start the project with few requirements
 Requirements can be added in between the stages
 It is suitable for large projects

6. AGILE MODEL

Agile Software Development Life Cycle (SDLC) is the combination of both

iterative and incremental process models. It focuses on process adaptability and
customer satisfaction by rapid delivery of working software product. Agile SDLC
breaks down the product into small incremental builds. These builds are
provided into iterations.
The Agile process had started early in the software development and started
becoming popular with time due to its flexibility and adaptability.
The most popular Agile methods (Agile group) include
1. Rational Unified Process (RUP)(1994),
2. Scrum (1995),
3. Extreme Programming(XP) (1996),
 4. Kan ban
5. Crystal Clear,
6. Adaptive Software Development(ASD)
7. Feature Driven Development,(FDD)
8. Dynamic Systems Development Method.(DSDM) (1995).
9. Rapid Application Development(RAD)
These are now collectively referred to as Agile Methodologies, after the Agile
Manifesto was published in 2001.
Agile Vs Traditional SDLC Models
1. Agile is based on the adaptive software approach, whereas the
traditional SDLC models like the waterfall model are based on a
predictive approach.
2. Customer Interaction is the backbone of this agile methodology whereas
traditional SDLC models not allow Customer interaction
3. The agile teams work in close collaboration with each other and are most
often located in the same geographical location.

Difference between Predictive approach and Adaptive approach

a. Predictive Approach

 Predictive methods entirely depend on the requirement analysis and

planning done in the beginning of cycle.

 Any changes to be done go through a strict change control management

and prioritization.

 Predictive teams in the traditional SDLC models usually work with

detailed planning
b. Adaptive approach

 In adaptive approach there is no detailed planning and there is clarity on

future tasks only in respect of what features need to be developed.

 Development team adapts to the changing product requirements

dynamically.

 The product is tested very frequently, through the release iterations.

  Little or no planning required

 Adaptive approach minimizes the risk of any major failures in future.

 An open communication with customer is allowed with minimum

documentation

NB. Each iteration of agile SDLC consists of cross-functional teams working on

various phases:

1. Requirement gathering and analysis

2. Design the requirements
3. Development
4. Deployment
5. Testing
6. Feedback

Advantages of Agile SDLC

1. Project is divided into short and transparent iterations.

2. It has a flexible change process.
3. Best choice for large projects
 4. Gives flexibility to developers

5. It minimizes the risk of software development.

6. Quick release of the first product version.
7. The correctness of functional requirement is implemented into the
development process.
8. Customer can see the result and understand whether he/she is satisfied
with it or not.

Disadvantages of Agile SDLC

1. The development team should be highly professional and client-oriented.
2. Conflict of New requirement with the existing architecture.
3. Increased development time & cost
4. Hard to estimate project over runs

3. Backend Development Technologies

a. Python and its frameworks (Django,Flask)

b. PHP and its frameworks (Sympony, Laravel)

c. JAVA and its frameworks (Vaadin, Play Framework)

d. JavaScript and its frameworks (AngularJS, Expresss.js)

e. Ruby and its frameworks (Ruby for nails, Paradrino)

4. System analysis tools

Grid chart
System Flowchart
Decision tree
Simulation
Decision table

5. Data gathering
Tools/Techniques/Method for data collection
These tools have unique abilities, but they complement each other. This is
why the analyst must use them in turn.
1. The interview

 To interview is to gather facts and opinions and identify needs.

 It is a service that must be carefully planned and prepared during
which the analyst should be objective and flexible.
 Why, when and who to interview?
 We conducted the interview to gather information that is not in the
documents but found by experience in a system field, in the user of
a system to be developed.
 We interviewed the people found on land. In the hierarchy of
responsibilities, we go from top to bottom.
 The time of conducting the interview is when assessing (evaluation)
the demand and detailed analysis. Understood

2. The observation
The observation allows the analyst to realize with his own eyes how
activities are performed. This tool can complement what has been
collected using other methods. The method of observation has two
major problems:

 The time in which the observation is made may have some different
realities being calm (if such there can customers) and others are
busy (eg when there are many customers).
 The observation itself can be a problem because people often do not
feel comfortable when they are observed.

3. The questionnaire
The questionnaire is a tool for gathering information using questions
appropriate to many people when the time factor does not pose
problems.

 Each question must be well formulated,

 Pre-test (sampling) the questionnaire on a small number of people,

 Check the interpretation of each question and each statement

make adjustments until you find a reliable questionnaire,
 Gets a letter from the head of the firm receiving the questionnaire
supporting and asking the employees to respond to your
questionnaire.
 4. Documentation

The documentation is to read the various writings (books, reports,

newspapers etc) speaking on the system to analyze, the activities it
does and so the sequence of operations, etc.

6. Identification of FURPS Requirements

FURPS is an acronym for:

Functionality: This is the one most of us jot down when defining
requirements. It answers the question, “What do I want the end
product to do?” In addition to considering product features and
capabilities, remember to think about what level of security is
required.

Usability: Who will use the product? How will they use it? What look-
and-feel do you want? What about help screens and self-help
“wizards”? One often overlooked area is that of user documentation
and training–often sub-projects unto themselves!

Reliability: What is your expectation in terms of system up-time?

What do you consider an “acceptable” system failure? How quickly
should the system be able to recover from a failure? What should the
mean time between failures (MTBF) be?

Performance: Consider the functional requirements you have

defined. What level of performance are you expecting? Think about
speed, efficiency, availability, accuracy, response time, recovery time,
and resource usage.

Supportability: How easy should it be to test the system; and how

would this be done? What about maintenance–what’s your
expectation in terms of system care and feeding? How configurable
should the system be? What about installation–who should be able
to install it?

FURPS Requirements
Requirements become a key focus of analysis activities in system development
life cycle. Analysts spend most of their time to requirements: gathering
information about requirements, formalizing them through generating models
and prototypes, refining and expanding them, prioritizing them, and generating
and evaluating such alternatives. Because of this, we need to have a clear
definition of requirements.

System requirements are all the activities must perform or support and the
constraints that the new system must meet. System requirements are divided
into two categories: functional requirements and nonfunctional requirements.

Functional requirements describe the behavior and information that the

solution will manage and describe capabilities the system will be able to perform
in terms of behaviors or operations—a specific system action or response (. In a
simpler word, functional requirements refer to the activities that the system
must perform based on the procedures and rules that the organization uses to
run its business, such as generating fund transfer electronically, calculating
commission amounts, calculating payroll taxes, and so on in a payroll system.

Nonfunctional requirements refer to the characteristics of the system other

than those activities it must perform or support

Nonfunctional requirements used to describe attributes within the system,

such as how fast the system response to a specific command is, how efficient
system performs such tasks is, etc. Sometimes, it finds a little difficult to
differentiate functional from nonfunctional requirements.

FURPS is an acronym that stands for functionality, usability, reliability,

performance, and security.

The “F” letter in FURPS refers to the functional requirements that have defined
previously and the remaining letters describe the nonfunctional requirements.

 Usability requirements refer to operational characteristics related

to users, such as the user interface, related work procedures,
online help, and documentation (Satzinger, Jackson, & Burd,
2012). The guide questions of these requirements are “is this
 application usable by any system?”, “is this application responding
the same way to other applications?”, etc.
 Reliability requirements refer to the requirements that describe
system dependability—how reliable the system and the risk of
system to be crashed.
 Performance requirements describe the operational characteristics
related to measures workload, such as throughput and response
time (Satzinger, Jackson, & Burd, 2012).
 Security requirements refer to the grant of access control to
application and data protection during storage and transmission.

The extension of FURPS that adds additional categories is FURPS+, that have
introduced previously. This extension includes design constraints as well as
implementation, interface, physical, and supportability requirements—which
denotated by plus sign. According to Satzinger, Jackson, & Burd (2012), the
short descriptions of each category explained as follows:

 Design constraints refer to restrictions to which the hardware and

software must adhere.
 Implementation requirements refer to constraints related to
programming languages and tools, documentation method and its
level of detail, and so on.
 Interface requirements refer to interaction among systems, that
might be internal or external systems.
 Physical requirements describe hardware characteristics in its
size, weight, electrical consumption, and operating conditions.
 Supportability requirements describe the steps or procedures of
systems installation, configuration, monitoring, and maintenance.

7. Identification of Main objects of Backend System

The primary focus of the Backend Developer is to develop the server-
side logic as well as the development and maintenance of the central
database, ensuring high responsiveness and performance to requests
from the frontend.
 Define the Scope of Backend System
 The back-end developer is responsible for the underlying code that
powers an application, website, or other software system. They are
responsible for ensuring that the code they write is clean, efficient, and
meets the needs of the front-end developers.

 Database
Databases often store information about people, such as customers or
users. For example, social media platforms use databases to store user
information, such as names, email addresses and user behavior. The
data is used to recommend content to users and improve the user
experience

 APIs
API stands for Application Programming Interface. In the context of APIs,
the word Application refers to any software with a distinct function.
Interface can be thought of as a contract of service between two
applications. This contract defines how the two communicate with each
other using requests and responses.
 Servers

A server stores, sends, and receives data. In essence, it "serves" something else
and exists to provide services. A computer, software program, or even a storage
device may act as a server, and it may provide one service or several.

 Frameworks
A framework in programming is a tool that provides ready-made components or
solutions that are customized to speed up development. A framework may
include a library but is defined by the principle of inversion of control (IoC).

The SMART acronym covers 5 criteria, namely:

 Specific (Sensible, Simple, and Significant) – Make sure that your goals
are specifically defined. For instance, a goal could be to improve the social
media presence of your company. But a specific goal would be to increase
the number of followers and level of engagement on Twitter.
  Measurable (Motivating and Meaningful) – Measurable goals allow you
to track your progress. For example, your goal could be to boost sales by
20% by the end of December 2022.

 Attainable (Achievable and Agreed) – Your goals should not only be

attainable but also agree with the present status of your business. They
should fit into your existing schedule. Going back to the previous
example, if you want to improve sales by 20% by the end of the year, you
must have sufficient time to organize and implement campaigns with the
proper resources in hand.

 Relevant (Reliable, Reasonable, and Result-oriented) – Realistic goals

are the key to success. You cannot hope to increase your sales by 50%
with limited time and resources.

 Time-bound (Time-sensitive and Time-based) – Your goals should come

with a deadline to give employees the motivation to work hard for them

8. Description of System Interaction (Vissers, 2016)

 Purpose of System Interaction

What is the definition of system interaction?

Definition: A system is a set of interacting components: – By “interact”, we

mean one component changes the state of. another, through physical exchange
of energy, force, mass, or information.

An interaction system can be seen as a definition of the way systems interact to

achieve some common functional goal. By considering this functional goal as a
system in its own right, the interaction system concept represents a dual view
on the notion of system

 Main components of System Interaction

Web server
On the hardware side, a web server is a computer that stores web
server software and a website's component files (for example, HTML
documents, images, CSS stylesheets, and JavaScript files). A web
server connects to the Internet and supports physical data interchange
with other devices connected to the web.
 Application Server
An application server is a modern form of platform middleware. It is
system software that resides between the operating system (OS) on one
side, the external resources (such as a database management system
[DBMS], communications and Internet services) on another side and
the users' applications on the third side.
Database Server
A database server is a type of hardware that runs database software.
Database software helps users or companies store, manage, retrieve,
update or change files, information logs and other forms of digital data.
External Services and API
What is external service API?

External APIs expose a business's internal resources to outside users

or applications. For instance, third-party developers who need to
access data or services that belong to a business, or who want to
build apps that integrate with the business's platform, can do so
using external APIs.

Message queues or event Streams

Firstly, in a sense, messages and events are the same thing – an event is the
source that generates a message. They are both resented by packets of data.

Here are some of the biggest event queue cloud services:

 Amazon Simple Queue Service (SQS).

 Azure Message Bus

Some of the biggest event streaming services:

 AWS Managed Streaming for Kafka (MSK).

 Azure Event Hubs

Why use them?

Message queue services and event streaming services disconnect the event
generators and the consumers, so that even if a consumer is temporarily offline
or unable to receive or process the messages, the messages are not lost and
guaranteed to reach the consumers.

There are a lot of things that must be done to achieve the above goal, which are
heavy burdens for the generators or consumers if they have to do it themselves.
By putting a message queue service or event streaming service in the middle,
this burden is removed from the generators and consumers.

The fundamental differences between them

Message queue services

 They focus on the delivery of messages. Once a message is delivered

to its supposed recipients, the mission is accomplished, and the
message is usually deleted.

 To offer the maximum flexibility for the delivery, they

offer topics and subscriptions. A subscription is a set of filtering
criteria. Different subscriptions of the same topic can have different
filtering criteria, so that different subscribers can get different subsets
of the same set of messages in the topic. Such filtering is needed
perhaps because some of the recipients are not allowed to see some
events/messages, or we want to limit the amount of messages the
recipients have to process to reduce their load.

 Each subscription has its own copy of the messages.

 The messages are by default in memory.

 The focus is not to guarantee that the recipients get the messages in
a particular order.

 The focus is on the high-speed delivering of the messages to the

subscribers, not the saving of the messages.
Event streaming services

 Messages are stored persistently.

 The focus is on the sequence of the messages when they are saved.
Messages are only appended to the end of the stream.

 A message stream is equivalent to a topic in a message queue service.

However, there isn’t a filtering mechanism between the messages and
the consumers. Instead, every client can see the same stream of
events. They have to decide themselves what messages they want to
process and what they want to ignore.

 The focus is on the high-speed storing of the events, appending them

to the end of the stream, not the high-speed delivering of the events to
the recipients.

 Because events must be saved, a partition key must be specified when

the stream/topic/event hub is created. It decides which cluster server
each event is stored.

Similarities

 Both regard events/messages as part of history and disallow them to

be edited.

 Both allow the clients to call a blocking function and wait for a new
message to arrive.

 Both allows traversing the event/message queue to get earlier

events/messages.

The differences are how efficiently and conveniently these actions can be done.

How to choose between them

If the following are true in your business solution:

  It is critical to get the messages/events as quickly as possible once the
events happen,

 It is important to a have the flexibility to filter the messages so that

different recipients get different subsets of the events,

 There is no or little need for the recipients of the

events/messages to go back to the service to traverse and process
the past events/messages,

 It is not critical that the recipients receive the events/messages in a

particular order,

You would choose a message queue service.

When

 The events/messages are being generated in huge volume and it is

critical that they are all saved by the service quickly and securely,
without causing the generators to wait and block or the loss of the
events/messages,

 The sequence of the events in the storage is important,

 There is no or little need to filter the messages each recipient gets,

 It is important that clients of the services can traverse and process the
events in the stream, for example to run analytics on them, Therefore
the safe storage of the events/messages are critical.

You should choose an event streaming service.

9. Report of the System Backend Requirements (Bandakkanavar,

2021)

 Executive summary

What is the executive summary of a developer?

This summary must include the developer's technical skills and the
programming languages they are proficient. They must also present their
experience in developing software solutions for various industries and their
ability to work on multiple projects simultaneously
What Is an Executive Summary?

3wasAn executive summary is a short section of a larger document like

a business plan, investment proposal or project proposal. It’s mostly used to give
investors and stakeholders a quick overview of important information about a
business plan like the company description, market analysis and financial
information.

It contains a short statement that addresses the problem or proposal detailed in

the attached documents and features background information, a concise
analysis and a conclusion. An executive summary is designed to help executives
and investors decide whether to go forth with the proposal, making it critically
important. Pitch decks are often used along with executive summaries to talk
about the benefits and main selling points of a business plan or project.

Unlike an abstract, which is a short overview, an executive summary format is a

condensed form of the documents contained in the proposal. Abstracts are more
commonly used in academic and research-oriented writing and act as a teaser
for the reader to see if they want to read on.

GET YOUR FREE

 Detailed analysis of the Current State

A current state analysis focuses on either the entire organization or a specific

process within a team. The key is to conduct research that involves data
collection, observation, and analysis. And by using metrics, you can determine
how well the company is meeting its needs and what improvements it requires.

 Findings on Gaps and issues

 Recommendations