Software devolopment life cycle

CSD 68

Prabhath Dhanushka Kodisinghe

fxkodisinghe@gmail.com

0|Page
1 Contents
What is SDLC?........................................................................................................................................................ 5
SDLC phases:......................................................................................................................................................... 6
Requirement planning or feasibility.................................................................................................................. 6
Requirement analysis or defining...................................................................................................................... 7
What is Requirement?................................................................................................................................... 8
Activities for Requirement Analysis...............................................................................................................8
Designing phase................................................................................................................................................ 9
Roles & Responsibilities of designing phase:.................................................................................................9
Development Phase.......................................................................................................................................... 9
Roles & Responsibilities...............................................................................................................................10
Testing Phase................................................................................................................................................... 10
Implementing/Deployment and maintain.......................................................................................................10
Implementing.............................................................................................................................................. 10
Maintaining................................................................................................................................................. 11
SDLC Models........................................................................................................................................................ 11
Iterative model................................................................................................................................................ 12
Agile model.................................................................................................................................................. 13
Spiral Model................................................................................................................................................ 15
Sequential models........................................................................................................................................... 17
Waterfall Model.......................................................................................................................................... 17
V-Model....................................................................................................................................................... 19
Spiral model........................................................................................................................................................ 22
Risk handling of the spiral model.................................................................................................................... 23
Why is the spiral format called meta mode?...................................................................................................24
Advantages of Spiral........................................................................................................................................ 24
Disadvantages of Spiral................................................................................................................................... 24
Why we cannot use waterfall model for large software development process?................................................25
What is feasibility study?.....................................................................................................................................25
Feasibility Study Process:................................................................................................................................ 26
Need of Feasibility Study:............................................................................................................................ 27
Requirement analysis or defining........................................................................................................................27
What is Requirement?..................................................................................................................................... 28

1|Page
 Activities for Requirement Analysis.................................................................................................................28
Requirement gathering techniques.................................................................................................................29
Interviews.................................................................................................................................................... 29
Group Interviews......................................................................................................................................... 29
Question Papers / Surveys:..........................................................................................................................29
Combined Application Plans / JAD...............................................................................................................30
feasibility criteria and constraints....................................................................................................................... 31
Executive Summary............................................................................................................................................. 32
Feasibility Study Types.................................................................................................................................... 33
Technical Feasibility..................................................................................................................................... 33
Time feasibility............................................................................................................................................ 34
Legal Feasibility........................................................................................................................................... 34
Operational Feasibility.................................................................................................................................34
Financial Feasibility..................................................................................................................................... 35
Project Overview................................................................................................................................................. 36
Background Information..................................................................................................................................... 36
Feasibility Type: A................................................................................................................................................ 37
Feasibility Study Solutions problems & solutions............................................................................................37
Assessments.................................................................................................................................................... 37
Feasibility Type: B................................................................................................................................................ 37
Feasibility Study Solutions problems & solutions............................................................................................37
Assessments.................................................................................................................................................... 37
Conclusion........................................................................................................................................................... 38
Features........................................................................................................................................................... 39
Requirements.................................................................................................................................................. 39
References........................................................................................................................................................... 39
Appendix............................................................................................................................................................. 40
2. Your name *................................................................................................................................................ 40
3. your profession in hospital *....................................................................................................................... 40
4. Gender......................................................................................................................................................... 40
5. Do you have Basic Computer Knowledge ? *.............................................................................................. 40
6. what is the details you ask from the patients *...........................................................................................41
7. how you note down the details ? *............................................................................................................. 41
8. how you find the details if you need it again ? *.........................................................................................41

2|Page
9. how you divide the data *........................................................................................................................... 42
10. how do you keep diet plans for patients*................................................................................................42
11. how do you keep Recipes for patients *...................................................................................................42
12. how do you update your file system *......................................................................................................43
13. how do you set remainder for important works? *..................................................................................43
Software Requirements Specification................................................................................................................. 44
Introduction.......................................................................................................................................................... 0
Purpose............................................................................................................................................................. 0
Document Conventions..................................................................................................................................... 0
Intended Audience and Reading Suggestions....................................................................................................0
Product Scope................................................................................................................................................... 0
References......................................................................................................................................................... 0
Overall Description................................................................................................................................................ 1
Product Perspective.......................................................................................................................................... 1
Product Functions............................................................................................................................................. 1
User Classes and Characteristics....................................................................................................................... 1
Operating Environment..................................................................................................................................... 2
Design and Implementation Constraints........................................................................................................... 2
User Documentation......................................................................................................................................... 2
Assumptions and Dependencies........................................................................................................................2
External Interface Requirements...........................................................................................................................3
User Interfaces.................................................................................................................................................. 3
Hardware Interfaces.......................................................................................................................................... 5
Software Interfaces........................................................................................................................................... 6
Communications Interfaces...............................................................................................................................6
System Features.................................................................................................................................................... 6
Dataflow Diagram.............................................................................................................................................. 6
Activity diagram............................................................................................................................................... 10
Use Case Diagram............................................................................................................................................ 11
Sequence diagram........................................................................................................................................... 11
Other Nonfunctional Requirements.................................................................................................................... 12
1.1 Performance Requirements..................................................................................................................12
1.2 Safety Requirements.............................................................................................................................12
1.3 Security Requirements..........................................................................................................................12

3|Page
 1.4 Software Quality Attributes.................................................................................................................. 12
1.5 Business Rules....................................................................................................................................... 12
Software development process...........................................................................................................................13
Software development models....................................................................................................................... 13
Procedure........................................................................................................................................................ 14
Data manipulation........................................................................................................................................... 14
Data-driven paradigm......................................................................................................................................14
Object-orientation paradigm...........................................................................................................................15
Data based operating model........................................................................................................................... 15
The complexity of data processing.................................................................................................................. 15
Data based operating model........................................................................................................................... 16
Consumer intelligence................................................................................................................................. 16
Determination............................................................................................................................................. 16
Distribution.................................................................................................................................................. 16
Business intelligence................................................................................................................................... 16
Data conversion........................................................................................................................................... 16
The importance of a data-based plan..................................................................................................................17
Limited state machinery...................................................................................................................................... 18
Limited State Machine vs. Unclear State Machine..........................................................................................18
Comparison of FSM and EFSM.........................................................................................................................19
References........................................................................................................................................................... 20

4|Page
Part-01.1

2 What is SDLC?
SDLC- it aims to produce high quality system that meets or exceeds customer expectations, works efficiently in
the current and planned information technology infrastructure, and is inexpensive to maintain and cost
effective to enhance.
when making the software, it must fulfill these areas, maximum client satisfaction, robust and high accuracy,
easy to use and user-friendly, can anytime update. all of these things can make if we have a structure that can
be make software as the client requested. To do this, the SDLC process gives us hand.
the SDLC is the flow of the steps of making and developing software.

ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that
defines all the tasks required for developing and maintaining software. SDLC is a process that is being followed
to a software project in a software development company. It consists of a detailed plan that describes,
maintain, restoration, and modifying specific software. The living cycle defines the quality and the overall
development process.

3 SDLC phases:
The process fallows to develop the software is SDLC. each phase of SDLC produces deliverable required by the
next to phase of the lifecycle. Requirements are translated in to design. Code is produced according to the
design. Testing should be done on develop to product based on requirement. Deployment should be done
once the test invest completed.
1. Requirement planning/ feasibility
2. Requirement analysis or defining
3. Designing
4. Development/building or coding
5. Testing
6. Implementing/Deployment and maintain

5|Page
3.1 Requirement planning or feasibility
The first step is to find out if the project offered by a client is affordable to their organization. A feasibility
study should be done and the profit of the company from the development of the software and its future
benefits should be examined. Feasibility study is carried out based on many purposes to analyze whether
software product will be right in terms of development, implantation, contribution of project to the
organization etc. In feasibility studies, there are several types of feasibility studies. It mainly focuses on five
areas.
This economic feasibility study is the most important part of the feasibility analysis and the legal feasibility
study is not considered the feasibility analysis.

3.2 Requirement analysis or defining

This is the most important phase of the SDLC. because this is the steps of making template for build the
software. if the template is mismatching the software is definitely failed. so, in this phase very important
about collecting information of the software that going to make. when collecting the information, that
information should be high accurate, understandable and very similar to ideas of client.
look at the picture below. Left-hand side image shown that client request and the right-hand side image show
that actual image that software company understand:

Requirement Analysis, additionally called demand Engineering, that is the method of process user
expectations for a brand-new package being designed or changed. In software engineering, it's generally
remarked loosely by names like necessities gathering or necessities capturing. Requirement’s analysis
encompasses those tasks that come in determinative the wants or conditions to satisfy for a brand new or

6|Page
altered product or project, taking account of the probably conflicting necessities of the assorted stakeholders,
analyzing, documenting, verificatory, and managing package or system necessities.
Here are the objectives for performing requirement analysis in the early stage of a software project:

 From What to How: Software engineering task is the bridge that between system requirements
engineering and software design.
 3 Orthogonal Views: Provides software designer with a model of:
1. system information (static view)
2. function (functional view)
3. behavior (dynamic view)
 Software Architecture: Model can be translated to data, architectural, and component-level designs.
 Iterative and Incremental Process: Expect to do a little bit of design during analysis and a little bit of
analysis during design. (paradigm, 2020)
3.2.1 What is Requirement?
Requirement Analysis Techniques: Software requirement is the ability of the user to solve a problem or
achieve a goal. A requirement is the software capability that a system or system component must meet or
have in order to fulfill a contract, standard, specification, or other formally imposed documentation. Finally,
what we want to achieve is to develop quality software that meets the needs of our customers on time and on
a budget.
The biggest challenge facing software developers is sharing the look of the end product and its experience
with the customer. There should be a common understanding of what a product should do among all the
stakeholders in a project, developers, end-users, software managers, customer managers, or someone will be
confused when it is delivered. Software confusion is never good news.
3.2.2 Activities for Requirement Analysis
Requirement analysis is critical to the success or failure of a systems or software project. The requirements
should be documented, actionable, measurable, testable, traceable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system design.
Conceptually, requirements analysis includes four types of activity:
1. Needs Selection: The task of deciding which customers and users identify their needs in consultation
with. This is sometimes referred to as need gathering.
2. Needs Analysis: Determining whether the requirements are published and documented, ambiguous,
incomplete or contradictory and then resolving those issues.
3. Requirement Modeling: Requirement documents
4. Can be configured in a variety of ways. They can be documented in a variety of formats, such as natural
language documents, usage cases, user stories, or process specifications.
5. Review and reconsider: Team members reflect on what happened in the iteration and identify actions
to move forward.
Requirement analysis is a team effort that combines the specialization of hardware, software, and human
factors engineering as well as the skills of dealing with people.
Here are the main activities involve in requirement analysis:
1. Identify customer's needs.
7|Page
 2. Evaluate system for feasibility.
3. Perform economic and technical analysis.
4. Allocate functions to system elements.
5. Establish schedule and constraints.
6. Create system definitions.
7. Requirement Analysis Techniques
Needs analysis helps organizations determine the real needs of stakeholders. At the same time, it enables the
development team to communicate with stakeholders in a way that they understand (such as charts,
templates, streaming charts).
Once the requirements have been assembled, we document them in the Software Requirements Specification
(SRS), use the cases, or approve them as user stories. This document is easy for the average user and
developer to understand. (Model, 2020). (paradigm, 2020)

3.3 Designing phase

In this third stage, the system and software design documents are prepared according to the requirements
specification document. This helps to define the overall system layout. This design phase serves as the input
for the next phase of the model. The objective of this phase is to transform business requirements identified
during previous phases, into a detailed system architecture that is feasible, robust, and brings value to the
organization.
At this stage, two types of design documents have been developed:
High-Level Design (HLD):
1. Brief description and name of each module
2. An outline about the functionality of every module
3. Interface relationship and dependencies between modules
4. Database tables identified along with their key elements
5. Complete architecture diagrams along with technology details
Low-Level Design (LLD):
1. Functional logic of the modules
2. Database tables, which include type and size
3. Complete detail of the interface
4. Addresses all types of dependency issues
5. Listing of error messages
6. Complete input and outputs for every module
3.3.1 Roles & Responsibilities of designing phase:
1.Customer – sponsor project and signs off team effort; review strategy and artifacts.
2.End User – Final users of the system.
3.Business Analyst – Provide requirements to the design team; review software design and artifacts.
4.Project Manager – Finalize data conversion strategy and test strategy; review software design and
artifacts.
5. Technical-Architect, Tech-Designer, Design-Team – Design system architecture, software components,
etc.; Design walk-through.

8|Page
 6. Developer/Construction Team – Assist in finalizing data conversion strategy; review of the architecture
and software components.
7. Testing Team/Tester – Assist with identifying and finalizing testing strategy; review of the architecture
and software components.
8. Database Team – Assist with architecture design and data conversion strategy.

3.4 Development Phase

This phase is called the coding phase. After the system design phase is completed, the next phase is coding. At
this stage, the developers begin writing the code using the appropriate programming language of their choice
and begin building the entire system. At this stage, the tasks are divided into units or modules and assigned to
different developers. This is the longest phase of the software development life cycle. The objective of this
phase is to transform approved architecture and design into a working system that is consistent with
functional and technical requirements identified during earlier phases of the software life cycle.
At this stage, the developer should follow the pre-set encoding guidelines. They also need programming tools
such as compilers, converters, and debuggers to generate and execute the code.
3.4.1 Roles & Responsibilities
1.Customer – Sponsor and signs off team effort; review progress with the developers and the PM.
2.Project Manager – Resolve resource, scheduling, budget issues; review and report progress.
3.Developer – Construct a working software from the approved design; produce artifacts and put them
under configuration control and perform change control; employ tools, systems and conform to
prescribed standards (platforms, coding practices, programming languages, etc.) that are in line with
the organization’s objectives.
4. Database Administration Group – Assist with implementing the solution design and data conversion
strategy.
5. Implementation supervisor/manager – Assist with identifying the requirements for implementation of
the software (which includes system readiness, resources, time-lines).
6. Integration supervisor/manager – Identify how integration of the solution in a new hardware/software
environment would be achieved; what tests are required to evaluate integration.

3.5 Testing Phase

Once the software is complete, it is executed in a test environment. The test team begins a step-by-step test
of the functionality of the entire system. This is done to ensure that the entire application is functional to the
customer's needs.
At this stage, QA (Quality Assurance) and the testing team do some bug fixes. If there are any deficiencies,
they will be sent to the development team by the testing team. The identified bugs are then corrected by the
development team and sent back to QA for testing. This process continues as long as the software is flawless,
stable, and operating according to the system's business requirements. The system test may require any
number of additional tests depending on the scope and complexity of the requirements; examples include
security, conformance, accessibility, performance, stress, compatibility, and regression tests.
Roles & Responsibilities:
1. Project Manager – Resolve resource, scheduling, budget issues; review and report progress.
2. Developer – Assist with building tests and analysis of test results.

9|Page
 3. Database Administration Group – Assist with integration of the solution design and data conversion
tests.
4. Implementation manager – Assist with analysis of test results.
5. Integration manager – Assist with analysis of test results.

3.6 Implementing/Deployment and maintain

In here we can see two in one phase. One is implementing and other one is maintaining.
3.6.1 Implementing
When the software testing phase is complete, the final deployment process begins when no system errors or
bugs are left. Based on the feedback provided by the project manager, the final software will be released and
tested for deployment issues. Here you need to make sure that the software is working properly according to
the customer's computer environment. (Guru99, 2019)
Roles and Responsibilities:
1. User Acceptance Test Writer - This role may include stakeholders, solution distribution team members,
or neutral third parties.
2. User Acceptance Test Developer - The Automated Testing Tool requires a User Acceptance Test
Developer to translate the User Acceptance Test Writer into human readable script program
instructions.
3. User acceptance tester - This role may include stakeholders, solution distribution team members,
passive third parties or automated tools.
4. Project Manager - Resources, Scheduling, Budget Solving.
5. Implementation Manager - Assist in the analysis of test results.
6. Customer - sponsoring and signing team efforts; Review progress with developers and PM.
3.6.2 Maintaining
After deploying the system and starting the customer to use the developed system, the following 3 activities
take place

 Error Correction - Errors are reported only occasionally. This is because it is difficult to test all the
components to cover the entire system.
 Upgrade - Update the app to the latest versions of the software
 Improvement - Adding some new features to existing software
The main focus of this SDLC phase is to ensure that the requirements continue to be met and that the system
continues to operate according to the specifications outlined in the first phase.
Successfully delegate software maintenance to the relevant team. The software distribution team provides the
software maintenance team with detailed documentation and training, and this information facilitates the
configuration, administration, and troubleshooting of common problems. (Uconn, 2019)
Roles and Responsibilities:

 Software Distribution Team - Prepares all software documentation and manuals for the maintenance
team. Maintenance team technicians will be provided with any training requested by the software
distribution team to learn solution behavior.

10 | P a g e
  Software Maintenance Team - Supports the software by reviewing all software documentation until
the terms of the maintenance agreement expire.

4 SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project management that defines the
stages include in an information system development project, from an initial feasibility study to the
maintenance of the completed application.
There are different software development life cycle models specify and design, which are followed during the
software development phase. These models are also called "Software Development Process Models." Each
process model follows a series of phase unique to its type to ensure success in the step of software
development.
There are two models in the industry uses:
1. Iterative model
2. Sequential model

4.1 Iterative model

This is not an attempt to start with a complete specification of the complete software.
Instead, they use only part of the software, review it, and move on to the next part. You can review it here to
find out more. This process is repeated and a new version of the software is produced for each cycle of each
model.
Diagram of iterative model:

Advantages of the model:

 In this model, we can create a high-level design of the application before actually designing the
software, launching and defining the design solution for the entire product. Later, a skeletal version of
it could be designed and built into another piece of software, and then the design could be expanded
based on what was built.
 The relevant software in this model is built and improved step by step by building products. Therefore,
deficiencies in relevant program components can be found from an early stage. This prevents the
shortcomings from flowing down.
 Software developers can get reliable user feedback in this format. When presenting software product
outlines and maps for user feedback, the company urges them to think about how the software
product works. Then, if there are any shortcomings, they can be rectified at the same time and move
forward.
 In a repeat format, less time is spent documenting and more time is spent planning. It can produce
more quality software.

11 | P a g e
  Examining and troubleshoot while the fewer iteration is simple.
 Hazards are recognized and fixed through iteration, and every iteration can be simply handled.
 In the iteration model, concise time is consumed on record, and extended time is provided for
outlining. (Kumar, 2021)
Disadvantages of the model:

 Improved resources may be required as this involves relatively high labor costs.
 Although the modification cost of each step is low, it does not always match the modification
specifications to the original specifications.
 Additional administrative recognition is required as several teams are involved in the development
work here.
 This format is not suitable for short projects.
 Extremely skilled resources are required to test the capabilities of program design in this format.
 Project development depends largely on the risk assessment stages.
 The whole system can be defined by determining the gradual increase.
For which designs the iterative model should be used:

 When the requirements of the complete system are clearly defined by the buyers.
 When the project is large and complex.
 First of all, the main requirements must be defined
 Some details about the software may evolve over time.
Examples for iterative models:
1. Agile model
2. Spiral Model
4.1.1 Agile model
This model is especially used in the production of functional software to focus on faster and customer
satisfaction systems. Diligent methods break down the product into smaller and growing varieties. These
buildings are given from repetitions. In each iteration, cross-action groups work in different areas
simultaneously.
The agile is: The diligent model here believes that every project is different and needs to be handled
differently and properly. Existing methods should be tailored to best suit all project needs.
In Agile, tasks are divided into time frames (small time frames) to provide specific features for a single system
partition. A repeat approach is taken for each step and a working software is created after each iteration. Each
building is enhanced according to the features of the system building steps; The final system build includes all
the features the customer needs.
Below are some of those aspects:

 planning
 Requirement analysis
 design
 Coding
 Unit inspection and
12 | P a g e
  Acceptance test.
At the end of the iteration, a working product is displayed to the customer and important stakeholders.
Graphical illustration of the Agile Model is given below

4.1.1.1 Agile model - pros and cons

These methods have recently gained popularity in the software world. However, this method is not always
suitable for all products. Below are some of the advantages and disadvantages of the Agile model.
Advantages of agile model:

 This is a very realistic approach to software development. This is because it deals with mutual
understanding with the regular customer.
 Promotes teamwork and cross-training. Here, several groups need to work together. All actions here
are based on cooperation and understanding between groups and within a group.
 Activity can be rapidly developed and demonstrated. Rapid growth can be achieved with the
participation of several groups and a large number of people.
 Suitable for changing needs. All the steps here are repeated so that the customer can work without
any problems when changing ideas and adding ideas.
 Provides previously semi-working solutions due to step splitting and moving in both directions between
steps.
 Easy to manage as you can move back and forth between steps.
 Dividing all the steps of the complex into smaller subsets gives developers flexibility.
Disadvantages of agile model:

 This leaves less room for designing, making it riskier for sustainability, maintenance, and extension.
 There must be an overall plan, an agile leader, and an agile Prime Minister habit and without it, this
model cannot be implemented. This requires skilled and experienced engineers so novices will not
have the opportunity. So, it will cost more and the apprentices will not get a chance.

13 | P a g e
  If customer clarity and understanding are lacking as they rely heavily on customer interaction, the
development operations team can go in the wrong direction. Transferring technology can be a bit
challenging for team members as the use of documents here is minimal.
 There is a very high level of personal dependence as it relies on minimal documentation.
4.1.2 Spiral Model
The idea of repetitive development with systematic controlled aspects of the waterfall model is the basis of
this model. This spiral model is a repetitive development process model. This model has been developed
through risk analysis of the waterfall model, which is a sequential linear growth model. It allows for product
release or enhancement refining through each iteration around the spiral. (point, 2021)
The spiral model consists of four stages, and a repetitive software project called a spiral repeat itself through
those stages.
Identification
This phase begins with the addition of the business requirements of the basic spiral. Once the production
process has reached its final stages, in the subsequent spiral, system requirements identification, subsystem
requirements, and unit requirements are performed at this stage.
The system analyzer processes the report files according to the customer's request requirements. This phase
also includes understanding the system requirements through continuous communication between the
customer and the system analyst.
design
The design phase begins with the conceptual design of the basic spiral, which includes the architectural
design, the logical design of the modules, the physical product design and the final design implementation and
subsequent design of the spirals.
Construction or erection
The construction phase takes place while creating a virtual software product in every spiral situation. In the
basic spiral, POC (Evidence of Concept) is developed at this stage to get customer feedback when designing
the product considering the product.
Here a functional model of the build software is produced with a world number of spirals with more clarity of
requirements and design details. This bundled step is sent to the customer for response.
Evaluation and risk analysis
Risk analysis involves identifying technical feasibility and management risks, such as schedule slippage and
cost overruns. Further risk analysis here includes technical feasibility assessment and monitoring. After
inspecting the build, at the end of the first iteration, the customer evaluates the software and provides
feedback.
The following illustration illustrates the spiral model and lists the activities in each phase:

14 | P a g e
(point, 2021)
Based on customer feedback and feedback, the software development process enters the next iteration.
Following that entry, the customer adopts a linear approach to implementing the suggested responses. The
process of repetition along the spiral is repeated throughout the life of the software.
Spiral Format Application:
This model is widely used in software development. Because it coincides with the natural development
process of any software product and learns with maturity, it poses minimal risk to the consumer as well as
development companies.

The following are some suggestions on how to use a spiral model:

 When there is a strict budget limit and risk assessment is important. For medium to high-risk projects.
 For long-term projects where needs change over time and economic priorities change.
 Usually when the customer does not have a clear understanding of their needs.
 Requirements are complex and cannot be properly assessed due to ambiguity.
4.1.2.1 Spiral model - advantages and disadvantages
The main advantage of the spiral life cycle model is that the element can be added to the product when the
element of the product is available or when the element is not known. This ensures that there is no conflict
with previous requirements and plans.
15 | P a g e
This system is compatible with multiple software build and release approaches that allow for the formal
transition to a maintenance function. Another positive aspect of this method is that the spiral model forces
the original user to join the system development effort.
Advantages of Spiral SDLC Model:

 Allows for changing needs and can be modified at any time.

 Allowing the prototypes to be used extensively can give the customer a broader understanding. This
allows users to see the system in advance.
 Customer needs can be more accurately grasped.
 Development can be divided into smaller parts and riskier parts can be developed earlier, which leads
to better risk management.
Disadvantages of Spiral SDLC Model:

 As management becomes more complex, skilled and experienced professionals should be used in
software development. So, this is not suitable for small or low risk projects and can be expensive for
small projects.
 The process is complex and as a result the end of the project may not be known in advance. Further
this can go on indefinitely.
 Because there are a large number of intermediate stages, more documentation is required.

4.2 Sequential models

Sequential models act as a top-down flow.
Software development approaches can be broadly classified as sequential access and repetitive / incremental
approaches. Project differentials have led to the classification of SDLC models in software development.
Different environment project opportunities include software development, technology, client needs, budget
constraints, etc. The IT project manager or IT company framework selects the most suitable SDLC model for
software development.
Examples for sequential models:
1. Waterfall Model
2. V-Model
4.2.1 Waterfall Model
The waterfall is a universally accepted SDLC model. In this system the whole process of software development
is divided into different stages. This model is a continuous software development model. Here, development
seems to flow downwards (like a waterfall) through the steps of need analysis, design, implementation, testing
(validation), consolidation and maintenance.
The linear sequence of activities has significant consequences. First, in order to identify the end of one stage
and the beginning of the next stage, some certification methods must be used at the end of each stage. Some
verification and validation usually mean that the output of the platform is consistent with its input (previous
step output) and that the output of the platform is consistent with the overall requirements of the system.
This waterfall model was introduced in 1970 by Winston Royce. This model has five stages: requirements
analysis and specification, design, implementation and unit testing, integration and system testing and
operation and maintenance. Steps always follow this sequence. The developer must complete each stage
16 | P a g e
before the next stage can begin. This model is called the "waterfall model" because its illustrations resemble a
waterfall.

Requirement Analysis and Specification Phase:

The purpose of this phase is to properly understand the customer's needs and document them properly. Both
the client and the software developer work together to document all the functions of the software and its
functionality and interfaces, requirements. This, in turn, describes the "what" of the system, not the "how". At
this stage, a large document called the Software Requirements Specification (SRS) document is created, which,
in general language, contains a detailed description of what the system will do.
Design phase:
In the first phase, the objective of this phase is to convert the requirements collected in SRS into a suitable
format to facilitate further coding in the programming language. It defines the overall software architecture
with a high level and detailed design. All of these functions are documented as a software design document
(SDD). In this stage, the first stage is studied and the system design is prepared. This system design helps
specify hardware and system requirements and defines the overall system layout.
Implementation and Unit Testing:
At this stage, the prepared plans of the previous stages are implemented. If the SDD is complete, the executor
or encryption phase will run smoothly, as the SDD contains all the information that software developers need.
With system design applications, the system is initially developed by small programs called units, which are
then integrated into the next stage.
Integration and System Testing:
This stage is very important because the quality of the final product is determined by the effectiveness of the
test. Better Reward will provide customers with more productive software with lower maintenance costs. Unit
testing determines the efficiency of individual modules. At this stage, however, the modules are tested for
each other and for their interaction with the system.
Operation and maintenance phase:
Maintenance is the care that is taken after the software is delivered to the customer. Once the software is
installed and activated, each user performs this task. There are some issues that sometimes arise in the client
17 | P a g e
environment. Patches will be released to fix those issues and some better versions will be released to improve
the product. Maintenance is done to make these changes in the customer environment.
4.2.1.1 When to use SDLC Waterfall Model?
Some Circumstances where the use of the Waterfall model is most suited are:

 When the requirements are constant and not changed regularly.

 A project is short
 The situation is calm
 Where the tools and technology used is consistent and is not changing
 When resources are well prepared and are available to use.
4.2.1.2 Advantages of Waterfall model
 Model The implementation of this model is simple and the number of resources required for it is
minimal.
 Requirements are stated in a simple and clear way so that they remain the same throughout the
development of the project.
 Phase The starting and ending points for each stage are clearly linked, making it easier to cover
progress.
 The release date for the full product as well as its final cost can be easily determined before
development.
 Report Due to the use of a rigorous reporting system, it provides easy control and clarity to the
customer.
4.2.1.3 Disadvantages of Waterfall model
 Model This model is not suitable for more important, larger and more complex projects as the risk
factor is slightly higher in this model.
 Changes in requirements cannot be accepted while the model is being developed for this model.
 Back it is difficult to go back to the previous stage. For example, if the application has now moved to
the encoding stage and then there is a change in requirement, it is difficult to go back and change it.
 Stage Subsequent testing has shown that risk mitigation strategies are somewhat weak as it does not
allow early detection of challenges and risks.

4.2.2 V-Model
The V-model is an SDLC model and the process activation takes place in a sequential V-shape. It is also known
as the authentication and validation form. This is an extension of the waterfall model itself and is based on the
relationship of an experimental phase to each of the corresponding developmental stages in the waterfall
model. This means that there is a phase of testing that is directly related to each stage of the development
cycle. This is a very light format and the next stage starts after the previous stage is completed.
V-Mode - Design
Under the V-model, the corresponding test phase of the development phase is designed in parallel. So, on one
side of 'V' is the verification stage and on the other side there are validation stages. The coding phase is
slightly V-mode and connects to both sides. (points, 2021)

18 | P a g e
 (points, 2021)

V-Model - Verification Stage

There are several stages of V-mode authentication, including:
Business Needs Analysis
At this stage the needs of the customers are taken into consideration. This is done by communicating in detail
with the customer to understand their expectations and real needs. This is a very important task as most of
the customers do not know exactly what they want and in this case the customer needs to be well managed.
At this stage, the acceptance test plans are prepared as business needs can be used as input for the
acceptance test.
System design
Once all the clear and detailed production requirements have been fully met, the entire system is considered
for design at this stage. Contains complete understanding and description of hardware and communication
features for developing software. The system design plan is based on the system design. Implementing this in
the early stages can save a lot of time to run the actual test.
Architectural design
At this stage, the architectural specifications are understood and the design is implemented. Here usually
more than one technical approach is suggested and the final technical approach is based on technical and
financial feasibility.
Will be decided. The system design will be further subdivided into modules that obtain different
functionalities, also known as advanced level design (HLD).
Data exchange and communication between the internal module and the external world (other systems) are
clearly understood and defined at this stage. With this information, integration tests can be planned and
documented at this stage.
Module design

19 | P a g e
At this stage the detailed internal design for all system modules is specified and is referred to as the Lower-
Level Plan (LLD). It is important that this design be compatible with other modules of system architecture and
other external systems. Unit testing is an essential part of any development process and helps to eliminate
maximum errors and omissions at an early stage. These unit tests can be planned at this stage based on the
internal module design.
Coding Phase
The actual encoding of the designed system modules is taken during the coding phase. The best programming
language depends on the system and architectural requirements.
Coding is done based on code instructions and standards. The code goes through many code reviews and is
optimized for best performance before the final build enters the store.

Validation phase
Below are the different validation stages of a V-model.
Inspection of the unit
All unit tests designed during the module design phase are coded and executed during this validation phase.
Inspection of the unit is only a symbolic test and it helps to remove the defects in the initial stage but the unit
test does not reveal all the shortcomings.
Combined tests
This test is associated with the architectural design phase. Combined tests are performed to test coexistence
and communication within the internal module of the system.
Systems testing
This system test is directly related to the system design phase. Systems testing thoroughly examines the
system functionality of all systems as a whole and the communication of the developing system with related
external systems. Since many other external systems are involved in system design, the functionality of the
existing hardware and software must be monitored. Many software and hardware compatibility issues can be
detected during this system test.
Acceptance test
The acceptance test is associated with the business needs analysis phase. Here the software takes full
attention of the user. Evaluates how the software behaves in a user environment. It measures the
performance of other systems in the user environment. Tests reveal compatibility issues with other systems in
the user environment. I can also detect non-functional issues such as loading and performance errors in the
real user environment.
4.2.2.1 V-Model - Advantages and Disadvantages
The advantage of the V-mode system is that it is very easy to understand and apply. The simplicity of this
model makes it easy to manage. The downside is that the model is not flexible to change and it can be very
expensive to change if there is a need change that is so common in today's dynamic world.

20 | P a g e
4.2.2.2 Advantages of the V-model system
 This is a very disciplined format and the stages are all done at once. Therefore, it works well for small
and well-understood projects.
 The steps here are all simple and easy to understand so they are easy to use. You can also involve
novice software developers. This is perfect for getting more results in less time and for quick and quick.
This is especially suitable for start-up companies and small projects.
 Easy to manage due to the rigidity of the model. Each stage has a smooth distribution because it has a
specific distribution and review process. (points, 2021)
4.2.2.3 Disadvantages of the V-model system
 There is a lot of risk and uncertainty here. The steps here are not between steps as they flow forward
at once. Once one step is completed, that step will not be reviewed again. So, this is not a good
example for complex and object-oriented projects.
 This is not suitable for long and continuous projects. Why The simplicity of the steps here gives quick
results but it is difficult to confirm its success.
 Not suitable for large projects whose requirements change from time to time and for projects with a
high risk of changing from moderate. This is because during the testing phase of an application, it is
difficult to go back and change the functionality. (Points, 2021)

Part 1.2

5 Spiral model
Spiral mode is one of the most important software development lifecycle models that provides support for risk
management. The number of spiral loops is not accurately calculated and may vary from project to project.
Each loop in the spiral is referred to as one stage in the software development process. The project manager
can change the number of specific stages required to improve the product and those changes should be made
based on the project risks. Because the project manager dynamically determines the number of stages, the
project manager plays an important role in developing a product using a spiral model.
The radius of the spiral represents the cost (cost) of the project at any given time and the angular dimension
represents the progress made so far in the present phase.
The following diagram shows the different stages of the spiral model: -

21 | P a g e
Each stage of the spiral model can be divided into four squares as shown in the figure above. The functions of
these four squares are as follows:
1. Set objectives and identify alternative solutions: At this stage all the requirements from the
customers are collected. Objectives are identified at the beginning of each stage. Described and
analyzed. Alternative solutions for further stages are suggested within this square.
2. Risk Identification and Resolution: During the second quarter, all currently proposed and usable
solutions are evaluated to select the best possible solution to a problem. The risks associated with that
solution will then identify other shortcomings and address the risks through the best possible strategy
for the problem. At the end of this square, the prototype is built for the best solution.
3. Prepare the next version of the product: Examination of the features identified during the third
trimester and confirmation of those features through those tests and conclusions. The next version of
the software will be available later this quarter.
4. Review and plan for the next phase: In the fourth quarter, customers will evaluate the version of
software they have developed so far. Finally, you can start planning for the next stage based on the
feedback from customers.

5.1 Risk handling of the spiral model

Any adverse condition that affects the successful completion of a software project is called a risk. The most
important feature of the spiral model is the proper identification and handling of these unknown risks once a
project is started. It is easy to address such risks by developing a prototype. Providing the scope needed to
build a prototype at each stage of software development helps to copy the spiral model with risks. (Pal, 2021)
The prototype model also supports risk management, but the potential risks to the project must be fully
identified before project development can begin. But even after the start of development, if there is a project
risk, we cannot use the prototype model. At each stage of the spiral model, the product dates and the
characteristics of the analysis and the risks at that point are identified and resolved by the prototypes. Thus,
this model performs more flexibly compared to other SDLC models. (Pal, 2021)

22 | P a g e
5.2 Why is the spiral format called meta mode?
The spiral format is called the meta mode because it is compatible with all other SDLC models. Subordination
to all other SDLC models means that, as a view, a spiral with a single loop represents the waterfall model. The
spiral model includes a step-by-step approach to the classic waterfall model. The spiral model acts as a risk
management technology. At the beginning of each stage, a prototype model approach is used to create a
prototype. Also, the spiral shape can be considered as a support for the evolutionary model. Repetition along
the spiral can be considered as the evolutionary levels at which the entire system is built. (Pal, 2021)

5.3 Advantages of Spiral

 Risk handling is high: As software development progresses, many unknown risky projects are often
encountered. In each of these cases the spiral model is the best development model to follow due to
risk analysis and risk handling.
 Most suitable for large projects: High results can be achieved by using the spiral mode for large and
complex projects.
 Flexibility in requirements: This can be done accurately and easily by using this form when requested
to change requirements at a later time.
 Customer Satisfaction: From the earliest stages of software development, the customer can see the
progress of the product, and they can use those systems to get used to working with the system from
the very beginning of the overall production process to produce more quality and successful software.

5.4 Disadvantages of Spiral

 Slightly more complex: The spiral model is much more complex than other SDLC models.
 Expensive: Spiral mode requires experienced software developers. The staff is also relatively high. So it
should cost more. Not suitable for small projects as it is expensive.
 Over-reliance on risk analysis: The successful completion of the project largely depends on risk
analysis. Without a very experienced expert, developing a project using this model will fail.
 Difficulty managing time: It is very difficult to estimate the time as the number of stages at the
beginning of the project is not known.

Part 01.3
According to the scenario, there is a need to develop software for the management of hospital day-to-day
works. So, this is one database and there is no complex database management or network system or AI
system or any complex and hard functionality running in this software. So, not this is a simple software with a
simple database. they need only keep their records in a database. and more, they need a backup system and a
simple functionality system with a user-friendly User interface. and I think they need this software as soon as
possible. So, I choose the waterfall model to develop this software.
why I choose the waterfall model for this:

 This is simple and small software and for small software, we can use waterfall methodology.
 There are no complex changes among the developing. because all details can collect at once. So, we do
not need to do it part by part. The project can be taken over at once and completed and delivered to
the customer.

23 | P a g e
  this project is can make with a low budget. there are no complex functionalities. So, we can make it
under the limited assets.
 we have limited time to do this project. because they already start the management system with
bookkeeping. and they are in a lot of trouble with this paper system. So, with the waterfall model, we
can give them that software in a limited time period.

Part 01.4

6 Why we cannot use waterfall model for large software development process?
The waterfall model is a simple model with one direction of the flow between steps. There is no turning back
between the steps. if you collecting the requirements from the client then you move to the next step, you
cannot go to the first step of requirement collecting. in the middle of the process, let's think that is a coding
phase, the client cannot add or change their mind. because in the coding phase there is no way to go back to
the requirement collecting step.
for a long time, project, there is a lot of change middle of the process. because according to the budget or
Attitudes, ideas, timely economic changes the client will need to change his software. but in waterfall model
cannot do that.
in large projects, we need to get more developers and more managers for design projects. all of these
employees are work at the same stage. So, in sitting the same phase they cannot do this thing. because when
developing the large software, we need to check every time that software will Make sure it matches with the
customer opinions. we cannot do this with the waterfall model.

Part 02.1

7 What is feasibility study?

The first step is to find out if the project offered by a client is affordable to their organization. A feasibility
study should be done and the profit of the company from the development of the software and its future
benefits should be examined. Feasibility study is carried out based on many purposes to analyze whether
software product will be right in terms of development, implantation, contribution of project to the
organization etc. In feasibility studies, there are several types of feasibility studies. It mainly focuses on five
areas.
This economic feasibility study is the most important part of the feasibility analysis and the legal feasibility
study is not considered the feasibility analysis.

24 | P a g e
 1. Technical feasibility:
In Technical feasibleness current resources, each hardware-software system at the side of needed technology
square measure analyzed/assessed to develop the project. This technical feasibility study offers a report on
whether or not there exists correct needed resources and technologies which can be used for project
development. On the side of this, the feasibility study additionally analyzes technical skills and capabilities of
the technical team, existing technology is often used or not, maintenance and up-gradation is simple or not for
chosen technology, etc.
2. Operational feasibility:
In Operational feasibleness degree of providing service to needs is analyzed alongside what quantity simple
product are to work and maintenance once prepared. alongside these alternative operational scopes square
measure determinant usability of the product, determinant advised resolution by the package development
team is suitable or not, etc.
3. Economic Feasibility:
In the Economic feasibility study price and advantage of the project are analyzed. suggests that underneath
this feasibility feasibleness study a detailed analysis is distributed what is going to be the price of the project
for development which has all needed prices for final development like hardware and code resource needed,
style and development price, and operational price and then on. at the moment it's analyzed whether or not
projects are going to be helpful in terms of finance for the organization or not.
4. Legal Feasibility:
In Legal feasibility, the study project is analyzed in lawfulness purpose of reading. This includes analyzing
barriers to the legal implementation of projects, knowledge protection acts or social media laws, project
certificates, licenses, copyright, etc. Overall, it will be aforesaid that the Legal practicability Study is studying to
grasp if the planned project conforms to legal and moral necessities.
5. Schedule Feasibility:
In Schedule feasibility Study in the main timelines/deadlines square measure analyzed for the projected
project which has what number times groups can want a complete final project that includes a nice impact on
the organization as the purpose of the project could fail if it can’t be completed on time.

7.1 Feasibility Study Process:

The below steps are carried out during entire feasibility analysis:
25 | P a g e
  Information assessment
 Information collection
 Report writing
 General information
7.1.1 Need of Feasibility Study:
The feasibility study is thus necessary stage of code Project Management method as once the completion of
practicability study it offers a conclusion of whether or not to travel ahead with the planned project because it
is much possible or to prevent planned project here because it isn't right/feasible to develop or to
think/analyze regarding planned project once more.
Along with this practicability, the study helps in characteristic risk factors concerned in developing and
deploying the system and coming up with risk analysis additionally narrows the business alternatives and
enhance success rate analyzing completely different parameters related to planned project development.

Part 02.2

8 Requirement analysis or defining

This is the most important phase of the SDLC. because this is the steps of making template for build the
software. if the template is mismatching the software is definitely failed. so, in this phase very important
about collecting information of the software that going to make. when collecting the information, that
information should be high accurate, understandable and very similar to ideas of client.
look at the picture below. Left-hand side image shown that client request and the right-hand side image show
that actual image that software company understand:

Requirement Analysis, additionally called demand Engineering, that is the method of process useexpectations
for a brand-new package being designed or changed. In software engineering, it's generally remarked loosely
by names like necessities gathering or necessities capturing. Requirement’s analysis encompasses those tasks
that come in determinative the wants or conditions to satisfy for a brand new or altered product or project,
taking account of the probably conflicting necessities of the assorted stakeholders, analyzing, documenting,
verificatory, and managing package or system necessities.
Here are the objectives for performing requirement analysis in the early stage of a software project:

26 | P a g e
  From What to How: Software engineering task is the bridge that between system requirements
engineering and software design.
 3 Orthogonal Views: Provides software designer with a model of:
4. system information (static view)
5. function (functional view)
6. behavior (dynamic view)
 Software Architecture: Model can be translated to data, architectural, and component-level designs.
 Iterative and Incremental Process: Expect to do a little bit of design during analysis and a little bit of
analysis during design. (paradigm, 2020)

8.1 What is Requirement?

Requirement Analysis Techniques: Software requirement is the ability of the user to solve a problem or
achieve a goal. A requirement is the software capability that a system or system component must meet or
have in order to fulfill a contract, standard, specification, or other formally imposed documentation. Finally,
what we want to achieve is to develop quality software that meets the needs of our customers on time and on
a budget.
The biggest challenge facing software developers is sharing the look of the end product and its experience
with the customer. There should be a common understanding of what a product should do among all the
stakeholders in a project, developers, end-users, software managers, customer managers, or someone will be
confused when it is delivered. Software confusion is never good news.

8.2 Activities for Requirement Analysis

Requirement analysis is critical to the success or failure of a systems or software project. The requirements
should be documented, actionable, measurable, testable, traceable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system design.
Conceptually, requirements analysis includes four types of activity:
6. Needs Selection: The task of deciding which customers and users identify their needs in consultation
with. This is sometimes referred to as need gathering.
7. Needs Analysis: Determining whether the requirements are published and documented, ambiguous,
incomplete or contradictory and then resolving those issues.
8. Requirement Modeling: Requirement documents
9. Can be configured in a variety of ways. They can be documented in a variety of formats, such as natural
language documents, usage cases, user stories, or process specifications.
10. Review and reconsider: Team members reflect on what happened in the iteration and identify actions
to move forward.
Requirement analysis is a team effort that combines the specialization of hardware, software, and human
factors engineering as well as the skills of dealing with people.
Here are the main activities involve in requirement analysis:
8. Identify customer's needs.
9. Evaluate system for feasibility.
10. Perform economic and technical analysis.
11. Allocate functions to system elements.

27 | P a g e
 12. Establish schedule and constraints.
13. Create system definitions.
14. Requirement Analysis Techniques
Needs analysis helps organizations determine the real needs of stakeholders. At the same time, it enables the
development team to communicate with stakeholders in a way that they understand (such as charts,
templates, streaming charts).
Once the requirements have been assembled, we document them in the Software Requirements Specification
(SRS), use the cases, or approve them as user stories. This document is easy for the average user and
developer to understand. (Model, 2020). (paradigm, 2020)

8.3 Requirement gathering techniques

8.3.1 Interviews
 Interviews are one of the most common and popular technologies used to meet needs as well as a
basic source of needs.
 To get the most out of an interview, the analyst should think carefully and prepare before sitting down
with the client. The analyst should be able to identify the parties to the interview.
 These partners may be users who are currently or new to the system, management, project financiers,
or anyone else who interacts with the system.
 Two types of questions are asked when preparing for an interview. They are open-ended and closed-
ended. It is important to use both.
 Open-ended queries help to obtain a system that is generally configured to depend on different people
and to obtain valuable information on how users interact or view the system.
 When asked these kinds of questions, the user needs to explain or explain their thoughts at length and
it is not advisable to get short answers like "yes" or "no".
 During the interview, the analyst must obtain the permission of the interviewer, and recorders can be
used to ensure that the details are readily available in case of omission. At the end of the interview, the
results should be given to confirm the interviewer's response.
8.3.2 Group Interviews
 This involves more than one person participating in the interview. Group interviews bring together a
few organizations and a few more as users. Group interviews work best when the interviewers are at
the same level or position. Suggesting or suggesting an idea that someone in the group has overlooked
by others can generate other thoughts and discussions, which can lead to a discussion or more about a
topic. The interviewer can assess the issues that are generally agreed upon and the issues that vary.
8.3.3 Question Papers / Surveys:
 Questionnaires or surveys allow this to gather information from more people in a shorter period of
time than pre-arranged interviews.
 Often large projects have stakeholders, when there are hundreds of contributors to meet system
requirements and they are geographically spread out. This is especially helpful in such cases. When
using question papers, questions should be focused and organized by a feature or project objective.
Questionnaires should not be extended to ensure that users complete them. When creating a
questionnaire, the questions should be designed in a way that is concise but simple enough to get all
the information.

28 | P a g e
  A general guideline for determining questions is to ask, "How, where, when, who, what, and why?"
"How do we meet this business need?" "How do we know this is complete?" Where: "Where does the
process begin?" "Where does the user get this feature?" "Where can I see the results?" When: "When
to use this feature?" "When does the feature fail?" "When are we ready to start?" For whom: "Who
uses this feature?" "Who provides inputs for the feature?" "Who provides the results of the feature?"
For what: "What do I know about this feature?" "What to do for this feature?" "What is the end
result?" "What should happen next?" (Eid, 2015)
8.3.4 Combined Application Plans / JAD
All of the above technologies are traditional need collection methods and this method of adding needs is a
modern and relatively more successful method. Introduced Integrated Application Development (JAD) in the
late 1970s, this method was able to solve some of the problems experienced by users of traditional methods
used to meet the needs. 40% or more of JAD record organizations report on project planning. This method has
shown successful results in reducing the time as the user and other key members are heavily involved in the
process. (Eid, 2015)
The main goal here is to get the plan right in the first place and thereby reduce the number of repetitions. JAD
usually collects people associated with aging in a place other than the workplace. This helps to reduce
distractions.
Participants for JAD include:
JAD session leader (also known as facilitator), users, managers, sponsors, system analysts, author and other IS
staff members. The entire process is usually managed by a facilitator who is trained in project management
and system analysis. The facilitator is responsible for keeping the team on the agenda and resolving conflicts.
Most importantly, facilitators do not contribute ideas. They ask for the team’s opinions. User participation
helps to dispel their uncertainty about the system development process. The user stays connected throughout
the JAD session and can make a huge contribution as they are the ones using the new system. Managers can
provide a better understanding of the organizational aspects of the system. The sponsor does not attend all
JAD sessions, but usually only the beginning or end, and since they do not contribute ideas, they sponsor the
process. There are system analysts to learn from users and managers. As with other requirements collection
technologies, they should not be biased. The author takes detailed notes during the session. Other IS staff
members, such as programmers or database analysts, contribute to the technical aspects of the proposed
ideas. (Eid, 2015)
Some of the benefits of JAD include:

 Combining months of work into a structured workshop

 Specifies specification requirements in a consensus environment
 The parties responsible for identifying open problems and resolving them
 Tie a summary of the steps in the planning process
 Increases user satisfaction by engaging users directly in the design process
 Builds commitment through the use of an executive sponsor
 Builds a sense of entitlement and helps to create a collective team through physical and social
backgrounds

29 | P a g e
Part 02.3

9 feasibility criteria and constraints

Feasibility study includes a basic overview of all the systems involved. Therefore, the study
should study the operational, economic as well as technical and utility feasibility of the system
proposal. These are the four main types of feasibility studies.
1. Technical Feasibility
2. Operational
3. Time
4. Legal

Technical Feasibility:
The technical facet explores if the project practicableness is at intervals the boundaries of current technology
and will the technology exist in the slightest degree, or if it's out there at intervals given resource constraints
(i.e., budget, schedule…). within the technical practicableness, the system analyst appearance between the
wants of the organization, such as, (I) data input device which might enter an oversized quantity of
information within the effective time (II) Output devices which might manufacture output in an exceedingly
bulk in an efficient time (III) the selection of process unit depends upon the kind of process needed within the
organization.
Operational Feasibility:
This facet defines the urgency of the matter and therefore the satisfactoriness of any answer. It shows if the
system is developed, can it's have used. The operational study includes people-oriented and social problems:
internal issues, like hands issues, labor objections, manager resistance, structure conflicts, and policies;
additionally, external problems, together with social satisfactoriness, legal aspects, and government laws.
It takes into thought whether or not these work practices and procedures support a brand-new system and
social factors of however the structural changes can have an effect on the operating lives of those stricken by
the system.
Time Feasibility:
Given his technical experience, the analyst ought to confirm if the project deadlines area unit cheap whether
or not constraints placed on the project schedule are fairly met. Some come area unit initiated with specific
deadlines. you wish to work out whether or not the deadlines area unit obligatory or fascinating. If the
deadlines area unit fascinating instead of obligatory, the analyst will propose various schedules. it's preferred
(unless the point is totally mandatory) to deliver a properly functioning data system 2 months late than to
deliver AN erring, useless data system on time! lost schedules area unit unhealthy, however inadequate
systems area unit worse!
We could have the technology, however, that doesn’t mean we have the abilities needed to properly apply
that technology. True, all info systems professionals will learn new technologies. However, that learning curve
can impact the technical practicableness of the project, specifically, it'll impact the schedule.
Legal practicability:

30 | P a g e
Determines whether or not the projected system conflicts with legal necessities e.g. an information process
system should accommodates the native knowledge Protection Acts. once a corporation has either internal or
external legal counsel, such reviews square measure generally customary. However, a project could face legal
problems once completion if this issue isn't thought-about at this stage.

10 Executive Summary
Give a professional statement about the company, the area where feasibility report, given credits to
participants, describe the scope of the feasibility, why it was performed, what this feasibility will lead to
This is a hospital. From the hospital management to the cleaners, the staff is on the job. At present, they
usually use data in books. Several other details are recorded daily, including details of patients and staff who
come to the hospital for treatment. Making these notes here is not an easy task. Keeping notes reduces the
accuracy of the data. And when that data is reused, they cannot be clearly separated. There can be big
problems with the order of the data and their accuracy.
Here the database should be kept in one computer and its backup should be kept in a cloud account. MySQL
computer language for database and JAVA for system creation and JAVA Swing for system interface design.
Several computers are used in this system. The administration computer and resection should form a network
of several computers as three computers.
The new system introduces an automated data filing system, replacing the current bookkeeping system.
Features:
This system requires data filing from the following sections:
1. Physician’s file
2. Staff file
3. Patient file
4. Salary processing of staff
5. Provide diet plans for patients
6. Giving prescriptions to patients
7. Providing bill and payment details
Mandatory needs:
Customers expect the following upgrades to this system:
1. A robust and highly accurate system; Since this is a system that works with patients, the accuracy and
reliability of the data contained herein must be high.
2. Must have an accurate and efficient information backup system; The accuracy of the data as well as the
existence of the data must be confirmed.
3. Strong security system; Like any system, this system has sensitive data. They must have a good security
system.
Scope of this system:

31 | P a g e
This system will make the existing paper-based manual system a new automated system. In this way, saving
time is one of the main objectives, and the system is expected to be data accurate and easy to handle. And if
one day the hospital grows with another branch network, the same system can be expanded accordingly.
Existing System:
The current system is a paper based manual system. This spends more time on data errors and data
management. Manipulating data is also a very difficult process.
Proposed System:
Through the new system introduced. With a single click, data can be entered and retrieved, as well as many
other things. This system will ensure the security as well as the accuracy of the data.
After adding some of the basic requirements to the test, the feasibility study report is prepared to test the
impact of the software on the organization, workability, and effective use of resources.
After preparing the basic requirements, the feasibility study report is prepared. Is the report being compiled
through the following features? To check. 1. The impact of software on the organization, 2. The ability to work
with software, 3. Resource productivity. The feasibility study for these tests focuses on these 4 key questions.
1. What are the implications of software for organization?
2. What are the needs of the user / users and does the software meet those needs?
3. Is it worth solving the current problem of the organization?
4. What are the resources available to build the system?
Technical feasibility

10.1 Feasibility Study Types

For the above system four types of feasibility was analyzed and one type was assumed based on reports and
documents
10.1.1 Technical Feasibility
This study discusses whether the company has the resources to successfully complete the project.

 Is it possible to work with existing equipment and technology in the organization?

 Do employees currently have sufficient knowledge in the organization?
 Is there an option to upgrade the system or add other features in the future?
Here's how to put one together for use with your client Technical feasibility. This study discusses whether the
company has the resources to successfully complete the project.

 Is it possible to work with existing equipment and technology in the organization?

 Do employees currently have sufficient knowledge in the organization?
 Is there an option to upgrade the system or add other features in the future?
The front end and back end of the software should file what the customer expects.
The expectation of the front end:
1. The robustness of the functionality of the software
32 | P a g e
 2. The flexibility of the software with the user
3. It should be easy to maintain and debug.
For front end design we are use JAVA-Swing.
The expectation of the Back end:
1. The system should be easy to install.
2. Must be compatible with any operating system currently in use.
3. The required drivers must be provided with the software.
4. Must be functional correctly, easily and without problems with the front end.
5. The software must efficiently handle and manage the data provided by the users.
6. Multi-user support
7. Data must be stored correctly.
8. It should have a graphical user interface that can be used even by people who have no advanced
knowledge of computers.
9. Must have the ability to obtain hard copies of the data contained in the software.
You must use the MySQL language to handle the data file for the backend in this software.
10.1.2 Time feasibility
Time is an important factor for us here. Below are some of them.

 We have to incur additional costs to set up the system over time.

 Inconvenience to customers due to overdue.
 Due to the dynamics of this system design along with other projects, the expiration date of this system
will have an impact on future programs as well.
 Breakdown of customer trust.
In order to avoid such vulnerabilities, the system must be completed in a timely manner.
10.1.3 Legal Feasibility
This data should not be used for any personal or commercial purpose.
This system contains sensitive data. This includes patient data as well as medical staff. A suitable security
system should be put in place as this data may be passed on to other parties.
The danger is not only from outsiders. The system must also be properly protected from employees inside the
service station. A monitoring process should be entered into the system to monitor the behavior of all data
from the data entry into the system. It must be set up in such a way that only one person can enter the
system.

 Must comply with government approved policies.

 As a system in the field of health, it must be subject to the relevant legal framework.
 Employee payroll procedures should be followed.
10.1.4 Operational Feasibility
The following issues should be considered as the client and programmer will mainly deal with the knowledge
required to build and use the software.

33 | P a g e
In the software manufacturing process, knowledge must be exchanged between the client and the
programmer to build the software and use it. The following issues should be discussed there.

 What are the problems faced by the customer using the previous system?
 What is the difference between the existing system and the new system?
 What new knowledge does the user need to work with the new system?
The main change and disruption of the system is to make the whole system digital and computerized.
The pre-existing system is a system that works entirely with manual book files. But with the new system they
have to work with the computer. They should be given the knowledge to work especially with computer
software. So, it takes some time to get used to the new system. We have designed the software for this
purpose in a simple and efficient way so that everyone can use it without any problems.
The main point I felt while collecting the above information was that 40% of the people in this hospital do not
have computer knowledge. Knowledge must be provided here to operate that computer program.
To do this, we can organize a brief workshop on how the system works and how it is maintained.
For the development section, there is no such requirement as our development team consists of
professionally qualified JAVA programmers and graphic designers. Ensures that work is done properly with
experience of the same project in the past.
10.1.5 Financial Feasibility
This is the core of every feasibility study.
It examines a wide range of issues related to economic viability cost-benefit analysis. This is the most
important part of the organization. It considers the revenue and profit that can be earned from the sale of the
system relative to the cost of creating the system.
Economic viability analyzes the following:
1. Total cost of a complete system test
2. Examines whether the project can be done within the existing funds.
3. Cost of new hardware and software components
4. How Much Money Does a System Make as a Profit?
The cost table is given below:

Cost Month
0 1 2 3 4
Software 25,000LKR
Purchase
Hardware 45,000LKR
Purchase
Frameworks & 10,000LKR 10,000LKR
Tools purchase
Development 20,000LKR 20,000LKR 10,000LKR 10,000LKR 20,000LKR
Costs
Unit Testing 20,000LKR 20,000LKR 20,000LKR 20,000LKR 20,000LKR
Costs

34 | P a g e
 Testing 30,000LKR
Equipment’s
Salary 300,000LKR 300,000LKR 500,000LKR 300,00LKR 300,000LKR
Payments
Systems 10,000LKR 10,000LKR 10,000LKR 10,000LKR 30,000LKR
Maintains
Total 2,070,000LKR
Costs

Benefits Month
0 1 2 3
Project income 2,000,000LKR 25,000,000LKR
Total Benefits 2,430,000LKR

11 Project Overview
Project Name: Hospital Management and data base System
Project Manager: Mr. P.D. Kodisinghe
Proposal Rev and Date: 2021-08-29
Project Commencement: 2021-08-20
Target Completion: 2022-02-03

12 Background Information
Unlike other systems, the design of a system that supports people dealing with human lives needs to be done
more carefully.
The hospital has well-trained doctors and staff. This system requires good support to get them to do their job.
It is important to manage the data properly through this system.
Unlike before, they expect superior service through the new system. Accurate and up-to-date information
records are required for diagnosis and treatment. Failure to provide accurate data at the right time can cause
serious damage to this hospital.
Not only key data records but also other records such as X-ray report, patient history of medication, sample
report and patient registration need to be properly maintained. Maintaining a good record helps keep the
hospital running well.
The tasting of information must be done in a prescribed manner. Information should be categorized as
necessary, essential, and unnecessary. By doing this you can quickly access any patient report to save time and
resources.

35 | P a g e
13 Feasibility Type: A
Here is the feasibility type A.

13.1 Feasibility Study Solutions problems & solutions

System Problems Possible Solutions

Manual report writing and record keeping system Make a database to keep data and manage the
database correctly

13.2 Assessments
Risk Description Risk Possibility Risk Impact Actions required to
(High/Medium/Low.) mitigate risk
Describe a Give a rating to the Which area is affected Solutions or methods to
identified risk risk based on it by the risk when it avoid risks
seriousness and presents itself
affecting scope

Risk Description Risk Possibility Risk Impact Actions required to

Patient Details Getting
repeated or modified or
missing
When admitting new
patients, spend a lot of time
Delay in data retrieval on
return of the same patient
Delay in prescribing
(High/Medium/Low.) mitigate risk
High This can lead to erroneous This can be avoided with
prescriptions given to a proper data management.
patient.
High This means that patients Quick data entry through a
have to stay in the hospital simple and quick interface
longer and are unable to
provide quality service.
High This means that patients Quick data entry through a
have to stay in the hospital simple and quick interface
longer and are unable to
provide quality service.
High The inconvenience to Obtaining data through an
patients due to the time accurate automation system
taken to search for
information about
prescriptions

14 Feasibility Type: B
14.1 Feasibility Study Solutions problems & solutions
System Problems Possible Solutions
Too late payment and inability to Establishment of a deadly system for payment and
make advance reservations. pre-booking on a single system
14.2
14.3 Assessments
Risk Description Risk Possibility Risk Impact Actions required to
(High/Medium/Avg.) mitigate risk
Here, calculating This will reduce the High Creating a web page for

36 | P a g e
 the cost of image of the this system can save a
patients' bills institution as well as lot of time by paying
adds up to all the the day-to-day online.
calculations and attendance of
discounts, if any, patients. And the use of an
add up, so it automated bill
takes a long time processing system
to issue a single
bill. So adding a
few bills can
make the whole
time a lot bigger.

15 Conclusion
This system basically makes the manual activation system currently operating in the hospital an automated
system. This system controls and manipulates all data in the hospital. This system manages patient data and
provides easy and accurate data control.
It also cares about that. This software also comes with a backup facility on request.
The software provides prescription details, laboratory test results, dietary advice, etc., and includes billing and
activity.

 I can avail the following facilities.

 This is overall due to a fully automated system
 Improves the efficiency of the hospital system itself.
 The inefficiency of the system currently in use is greatly reduced, giving the user a faster experience.
 This system is highly secure and the privacy of the user's details is protected in all respects.
 Information on the current system is available to anyone. But with the new system, access controls
allow only authorized users to access the appropriate content based on the permissions granted.

37 | P a g e
15.1 Features
The features of the system have been summarized into the following

Feature Importance Description

Patient Detail Core Feature Manage all Patient details insert new details and
management update details and search their detail in one click
Patient Medical Optional Feature Manage all Patient Medical records insert new
Records records, update and search their records in one
click
Patient Diets Core Feature Manage all Patient Medical records insert new
Plans records, update and search their records in one
click
Staff Details Core Feature Manage all staff details insert new details and
Management update details and search their detail in one click
Staff Salary Optional Feature Count salary payments and keep count and
Counter payments
Building Bill Optional Feature Light bill, rent for building, gas bill, water bill,
Payments phone bill etc. pay all bill automatically with bank
payments.
Payment Optional Feature Make easy calculators for calculate all payments in
Calculators the hospital
Automated Billing Core Feature Make online payment and bling calculate system
system for billing.
Laboratory Details Core Feature The testing costs, testing counts, features in testing
Management etc. management
Pharmacy Details Core Feature The medicine count, income, payments for
Management medicine, profit calculation.

15.2 Requirements
The following are the minimum requirements for run this software:

Type Requirement
Software Operating system - Win 7,10
Programming languages –Web-Technology, .Net, ASP.NET
Front-end – JAVA, C++
Back End – MySQL, Web Server: IIS
Hardware Core i3 or higher
4GB RAM
2GB free of Hard Drive

16 References

38 | P a g e
17 Appendix
Hospital Management system
This Event: Get ideas from Staff * Required

1.
Mark only one oval.

Option 1

2. Your name *

3. your profession in hospital *

4. Gender
Mark only one oval.

Male

Female

5. Do you have Basic Computer Knowledge ? *

Mark only one oval.

Yes No

little

39 | P a g e
6. what is the details you ask from the patients *

7. how you note down the details ? *

8. how you find the details if you need it again ? *

40 | P a g e
9. how you divide the data *

10. how do you keep diet plans for patients*

11. how do you keep Recipes for patients *

41 | P a g e
12. how do you update your file system *

13. how do you set remainder for important works? *

This content is neither created nor endorsed by Google.

Forms

42 | P a g e
Part 03.1

18 Software Requirements Specification

HOSPITAL MANAGEMANT SYSTEM

Version 1.0 approved
Prepared by P.D.Kodisinghe
SoftE Company
2021-08-29

43 | P a g e
19 Introduction
19.1 Purpose

This report is intended to provide an overview of the proposed hospital management system (version 1.0).
The objectives of this hospital management system are as follows:

 Automating the existing record management system in operation in the existing hospital
 Monitoring the performance of all staff in the hospital
 Maintaining records for hospitalized patients
 Automatic prescription and health counseling through the system
 Provide clinical trials and monitor such test data

19.2 Document Conventions

Hospital Management System: The proposed digital system to automate the existing overall record
management system
End User: The client or user who intends to use the Software
Database: The database where the same data entry is stored

19.3 Intended Audience and Reading Suggestions

In any case, any person or group who needs an idea about this project.
Management Hospital Management System:
Expected Audience and Reading Suggestions and Expected viewers of the document:

 The client of the system

 Hospital Director
 Receptionist
 Device Activators
 Project Team

19.4 Product Scope

Introducing a new automated computer system to replace the old manual record management system
currently in use.

19.5 References

https://www.tutorialspoint.com/software_testing_dictionary/software_requirement_specification.htm
Tutorial points details on report
20 Overall Description
20.1 Product Perspective

Monitor all daily activities in the hospital.

Storage and management of patient information, staff information handling, financial management, handling
of records,
The above methodology is very difficult to manage properly.
This process is unsafe because of the files currently in use. This new system can work efficiently.

20.2 Product Functions

OPD Management

 Patient detail store & management

 issuing Channel number
 issuing medic report
Staff Details management

 Staff details store

 Staff details management
 Salary payments
Manage Laboratory

 Keep medicine list reports

 Revenue Expenditure Estimates
Manage laboratory

 Keep testing reports

 Issuing lists
 Revenue Expenditure Estimates

20.3 User Classes and Characteristics

Admin
The admin is allowed to access the entire system, which means he can manage any activity on the system. He
is the most privileged user who can access the system.
Main Functions:

 Managing staff, patients and supplies

 Allocation of funds for activities and expenses and fee management.
 Report preparation
1|Page
  Managing data on physicians
 Salary Management
 Employee
It often interacts with systems to provide services to customers
Main Functions:

 Monitoring patient details

 Observation of test details
 Keep track of bill details

20.4 Operating Environment

20.5 Design and Implementation Constraints

Software requirements:

 Windows 8 or above operating system

 JRE 1.8
 MySQL server

Hardware Requirements:

 Core i3 processor
 4GB Ram
 18GB of hard disk space in terminal machines
 1TB hard disk space in Server Machine

20.6 User Documentation

20.7 Assumptions and Dependencies

When the system is released, as part of the system itself, customers are presented with a software manual
that provides an overview of the process. It includes a complete product summary and clear organized steps
to download the program.
In this system:

 Each user must have a valid user ID and password, which must be set by the admin.
 Users must be logged into the system to access any data.
 Files can only be deleted by the administrator

2|Page
21 External Interface Requirements
21.1 User Interfaces

Login Form

Admin Dashboard

Patient Details

3|Page
Pharmacy Details

Lab Details

4|Page
21.2 Hardware Interfaces

Desktop PC:
core i3 processor
4GB RAM
250GB HDD
Used on this computer:
To get the details of the doctors in this hospital
Assistance in obtaining information such as laboratory tests etc.
Display Unit (LED/LCD Monitor):
A monitor with a 23inch screen is used for this. The screen should be usable as well as visible to consumers.
Laser Printer (B/W):
Basically, this machine is for bill printing.
Wi-Fi router:
For internet operations inside a hospital, the Wi-Fi router is used simply to transmit data from pcs to servers.

5|Page
21.3 Software Interfaces

Software Interfaces:
Developing end
JDK - Java is simple, clean, and trustworthy. And many of developers are agree with this.
IntelliJ - IDE for Java developing.
MySQL server - Database connectivity and management
Adobe Illustrator - Logo and other designing such as User interfaces
Client End
OS – Windows 7/8/8.1/10- Very user friendly and common OS
JRE - JAVA Runtime Environment for run Java Application and System
MySQL server - for Database connectivity

21.4 Communications Interfaces

NIC (Network Interface Card) — This is a hardware element that allows a device to connect to a network. For
wired and wireless networks, NICs can be used.
High signal integrity CAT 5 network cable
TCP / IP protocol- Internet service provider.
Ethernet Communications Interface- Ethernet is a computer network technology based on systems for local
area networks (LANs)

22 System Features
22.1 Dataflow Diagram

6|Page
7|Page
8|Page
9|Page
22.2 Activity diagram

10 | P a g e
22.3 Use Case Diagram

11 | P a g e
22.4 Sequence diagram

23 Other Nonfunctional Requirements

1.1 Performance Requirements

 Response Time - The device will respond within 1 second of data.

 Capacity - The system has the ability to support up to 100 people at once.
 Compatibility - The device must be compatible with Windows Accessibility

1.2 Safety Requirements

Data backup is important to protect data security. Supports several hard drives and DVDs. It also takes hard
copies and converts them into files.

1.3 Security Requirements

Administration and data entry operators have unique logins that allow them to identify who is accessing the
system separately.

1.4 Software Quality Attributes

 Utility: The device is always open.

 Correction: Flawless software that meets the needs of the client.
 Management capability: The system has the ability to maintain, modify data, and troubleshoot system
issues.
 Compatibility: The code can be used repeatedly without distortion.
 ability

12 | P a g e
  Accuracy: The accuracy of the information / output and the accuracy of the results can be assured.
 Stability: The output or output of the device does not change from time to time in each case. The same
output is always generated for a given input.

1.5 Business Rules

 We do not accept liability for failures due to hardware malfunction.

 The warranty period for maintaining the software is two years.
 Additions are made for further services.
 A is not responsible for any misuse caused by a user.

13 | P a g e
Part - 04.1

24 Software development process

It is possible to integrate different processes and stages in software development, or to name similar stages
differently. Some stages of most processes are normal.
Below are three specific stages. (The "OO" in the acronym below is an object-oriented version.)
Analysis (OOA)
The emphasis in the analysis is not on the problem but on the solution. A basic model is first developed by
summarizing the essential elements or features of the problem. This template is presented in a code that is
understandable to the customers, relevant industry experts, and system operators involved in the process.
This program can usually be identified in any programming language or system.
Planning (OOD)
By creating a solution structure, the model widens the gap between the research environment and the
functional-environment. Architecture represents domain information found and documented in the research
process. Here the final solution is planned and the basis for it is provided. It is often convenient to add sample
data structures and related operations that are invisible in the original problem and require a software
solution. In the development process, missing information is included in the evaluation, and omitting
information that appears to be foreign is the most common process. Development here is subdivided into
several sub-models that focus on specific functions related to them:

 UI
 Data management
 Task Management
 Communication Management
Implementation
This process involves creating a commonly used system or program. The software project provides a running
program or computer system; When the software is installed in a physical environment it will provide a mix of
hardware and software.

24.1 Software development models

In the past, experiments were carried out extensively by software developers. There are three major software
design examples:

 Procedure
 Data driven
 Object-oriented
Four samples of the software category can be shown as the path between the real world and the working
program.

14 | P a g e
24.2 Procedure
The model of the system focuses on the algorithm or steps needed to solve a problem. This process divides
the problem into simple sub-problems defined by process-method or method. In general, the breakdown of
action procedures is represented as a hierarchy and further represented as a list or a tree. Computer scientists
usually draw hierarchical trees on the roots at the beginning and the leaves at the bottom. There is no well-
defined set of rules for determining how simple the tasks were to allow for decay or initiation of
programming. When this is further explained; It proves that two separate and talented designers have been
able to create two different designs.
By following this model, the transition from design and analysis to implementation is relatively easy. However,
as the size of the problem increases and the complexity of the problem increases, the procedural model or
problem domain and the gap between analysis and design begin to have a greater impact. It is normal to have
a poor understanding of the problem domain by the paradigm in the procedure, as the interrelationship
between the problem and the functional tree is arbitrary and essentially abstract. But the side effect is that
these trees grow in large numbers, making it difficult for consumers to understand, and the widespread effects
of unexpectedly rippling through trees due to changes in decay (i.e. trees). Finally, the process model and the
associated dissociation trees also contribute to global data and link functions. Even so, owning one is still
beyond the reach of the average person.

24.3 Data manipulation

Here, when they enter a system, they observe the information and go through data conversion processes. But
is to follow the data until it is removed from the system. Data streams flow in and out, and data entering and
exiting the bubbles are formatted as arrows. Often several arrows enter a single bubble and merge into one
exit stream. Sometimes splitting several streams out of the system is done by entering only one stream. As a
result, a network of data and processes that explain a problem can be obtained.
Problem domain is easier to understand than any process-based analysis by performing an analysis based on
any paradigm guided by data. Data flow-based formats provide authentication and documentation support for
software testing. This makes it easier to read data flow diagrams for customers who have more problems than
procedural decay. However, the large gap between the data flow diagrams and the published programs in the
development process causes many problems. This large gap makes programming difficult and greatly reduces
the usefulness of the data-based paradigm.

24.4 Data-driven paradigm

Here research development is similar to the problem with the real world, which helps to develop an
understanding of the environment and makes it easier for software developers to find. However, it is more
difficult to convert data streams generated by research and layouts into functional programs.
Object-oriented
The object-oriented frame is called object information. A class is a description of a group of similar objects.
Classes are usually represented by a chart. Constructs a class diagram using integrated example language
(UML) notation.

15 | P a g e
This analysis identifies existing objects in the real world and abstracts them into classes. The planning stage
involves the addition of class details, the introduction of new classes.
UML class diagrams need to be translated into an appropriate programming language in order to implement
the above classes. This conceptual consistency connects real-world, analysis and design and implementation.

24.5 Object-orientation paradigm

Analysis, planning, and execution are three events that are equally pervasive. In the analysis, a collection of
classes representing the problem domain is created. Classes optimize classes by adding details to existing
classes throughout the development process and adding classes that represent code-related components.
During the implementation phase, the same class of classes is programmed, and between each two steps of
the software development process, a series of classes builds object-oriented bridges. It effectively eliminates
changes in other paradigms.
The main advantage of the object-oriented model is the ability to bridge the gap between stages and
streamline the development process. This is protected by the best features of paradigms and information-
guided paradigms when it comes to removing or minimizing the worst trait / symptoms. See the example
below, which represents object information using models generated during a study.
Based on the data, the paradigms, like the guiding paradigms, provide the same interpretations within the
domain, but the classes also show operations or procedures. For that reason, the process of switching from
design to implementation steps is much easier. Controlling data access eliminates the need for operational
connectivity, which can set a high limit on the size and complexity of software systems that can be built based
on the procedural paradigm. Because of the many advantages of object-oriented paradigms, it is now widely
used to create large and complex software systems.

24.6 Data based operating model

Data and machine learning, especially institutionally, is considered a 'silver bullet' that can solve any business
challenge. These are just some of the goal setting sharewares that you can use. To achieve this, many
companies strive to build the infrastructure and skills they need.
The dynamics and productivity of a detailed as well as pre-determined analytical business can be completely
changed. But many companies are in a constant struggle to fulfill the high promises represented by data and
machine learning.
As usual, a successful data science or analytics business in every way is inextricably linked with the relevant
business outcome. It can be spread across a number of groups, organizations and knowledge domains. The
'simple' part of creating a template or stitching data together, by being complex on its own, often has a real
impact on the business. The same thing applies with activating a data stream or algorithm to advance a
strategy. It is very rare to see land through data projects of that level. Many data projects fail or are
completely unaware of this cause.

24.7 The complexity of data processing

The best answer to the question of how to solve a problem is to believe that it is due to a lack of skills. That is,
it is easier to solve the problem of evidence if there are the right experts or experts to solve it. As difficult
challenges approach, many companies begin to focus on this approach. Uses the best tactics to solve a

16 | P a g e
complex problem. To do this, you must rely on experts in a range of knowledge and domains. This idea is
known in scientific circles as 'local search'.

24.8 Data based operating model

A data-based operating model is a model for the development of processes and infrastructure that allow
businesses to implement data efficiently.
Implementing the most effective descriptive and realistic analytical solutions. To do this you need to have a
framework for building your own strategy for organizing your businesses, processes and data infrastructure.
The five pillars of the model are as follows:
1. Consumer intelligence
2. Determination
3. Distribution
4. Business intelligence
5. Data conversion
24.8.1 Consumer intelligence
Consumer intelligence is the complete database and process of a customer. This empowers the entire data-
driven mode. In the final stage, the customer takes the company forward. Therefore, it is important to allow
business-based analytical solutions, such as assembling a customer awareness team, to logically link that
information one by one.
24.8.2 Determination
Decision making is the demonstration of the data processing department and technology. It defines algorithms
and automation for various analyzes and decision-making or decision-making and flow to networks for market
intelligence.
24.8.3 Distribution
Distribution can be expressed as facts. The team is dedicated to automating implementation, including
forecasting models, which allows the customer or company to engage in a variety of activity groups with the
goal of providing infrastructure to the team.
24.8.4 Business intelligence
Business Intelligence is the development, management and distribution of report and dashboard
infrastructure within the business team.
24.8.5 Data conversion
Data conversion can be defined as the proper operation of other towers by a process based on data by an
operating model. By this the data translation team is responsible for translating business objectives and
strategic technical data into initiatives.
How to bring data based operating model to the organization?
As with all systems, this is basically a checklist of how positive changes can be made within the organization.
Here are some key pointers in moving forward:

17 | P a g e
Coordinate different analysis groups or team members around the company rather than software activities.
Instead of using separate computer technology, data science, and analytics teams, bring together people who
can achieve business goals or complete projects more efficiently.
This database should be linked to the business units and information organization. It must provide a
professional 'data converter' or team with business needs and strategic technical solutions.
Above all, it is good to do "parallel thinking"; That is, you can spend more time working and learning in
completely different fields than in the specialist field.

25 The importance of a data-based plan

Implementing a data-based plan enables manufacturers to meet customer needs now as well as in the future.
But far-reaching, that is, implementing a data-based design typically applies to an entire product group. It can
have a positive impact on future planning- and profit margins. It also helps to identify trends in the product
data. For example, think of a manufacturer that oversees the real-time use of a product. When this situation
arises, the use of data is a method that can be used to redesign excessively engineering components and
reduce production costs while preventing the manufacturer from affecting customer satisfaction. Data-based
design can help businesses identify potential trends in product failure.

 Compliance: As Wang notes guarantee, “You may have a good company for what other companies do,
but they do not have a data-based company.
 Longevity: Increased retention power always goes hand in hand with compliance. Understand the
implicit consumer of the data collected and managed and they will take appropriate action accordingly.
 Awareness: Data-based organizations are aware of the ups and downs of sales.
 Response: This is the ultimate advantage for data-based organizations, which, in the broadest sense,
make real-time, real-time, and forecast data more responsive and dynamic.

Req: Requirement Test Test Design Test User Test Defect Req:
ID Description cas Desig accep Execution s Coverage
e ner tance Status
ID
Req Login to TC0 Insert invalid PW and ID Comp No pa N N null complete
-01 Application 01 leted ss o o ly
TC0 Insert valid PW and ID Comp No pa N N null complete
02 leted ss o o ly
TC0 Login different type users Comp No pa N N null complete
02 leted ss o o ly
Req View profile TC0 View button click and Comp No pa N N null complete
-02 4 display profile leted ss o o ly
Req Edit User TC0 Edit tables Comp No pa N N null complete
-03 5 leted ss o o ly
Req Logout TC0 Logout from System Comp No pa N N null complete
-04 6 leted ss o o ly
Part 04.2

18 | P a g e
26 Limited state machinery
This is a mathematical concept. This allows programmers, mathematicians, and other
professionals to describe any device with limited or large conditions as a mathematical model.
It can be described as a limited government machine used to simplify any form or complex
problem implemented by software or hardware. All that needs to be considered here is a
limited listing in the FSM, which can only be obtained from one of those states at a time using
the abstract method. It allows you to analyze and evaluate each of the current input and
output opportunities.
Limited state machines are called computer models of automation theory. In automation
theory, computer models include the following:
 Limited state machinery - models for any device with minimal conditions.
 Pushdown Automation - This involves the use of memory zones called stacks to store
information as part of a template that is more complex than limited state machines.
 Linear-Marginal Automated Machines (LBAs) - This is similar to Turin machines. But the
main feature is that the data is limited to an input section that is only in a limited input
group.
 Turning machines - have different input combinations to evaluate a large system or
problem. This is the most complex mathematical method in ‘Ottomata’ theory to test
them.
As a practical example of a limited state machine, a video game controller can be used to
identify a series of buttons that correspond to a series of actions in the game. When a user
clicks on a key, the system already knows how to execute the corresponding actions.
26.1 Limited State Machine vs. Unclear State Machine
Creating a finite state machine consists of a set of potential input cases. But they consist of a
set of corresponding output events and predictive statements made by the instrument. In a
limited state machine, the list of possible combinations of these elements is small. But instead,
the data point is vaguely accessible by a state machine, not separately and under pre-named
categories.
Extended limited state machine
It is a collection of traditional state operations, events, actions, and transitions. Government
machines are used to control the flow of data and behavior of software and hardware
components. Many languages are widely used when designing, validating, and testing model-
based software systems.

19 | P a g e
The algorithm maintains a long class of state machinery called register automat. There is a
limited power structure here. Conditions, functions as well as extensions by the guards can be
seen here.
Perform collection of tests, including usable and operational information in Domain Security.
In any case, the process takes place in exactly one step. It is an event where the device is
maintained and switched to another state. In this case, different events can be modified to be
parameterized as part of their significance. The currently undefined method produces a
stream of input events for a valuable source, which can be parameterized using the input
event vector. It is no secret that the algorithm certainly requires a long class of state
machinery called Register Automat. Extended limited state machinery cannot be defined. But
a fraternal transition with the same motivational events and non-digital guards may be
needed.
26.2 Comparison of FSM and EFSM
It is not uncommon for the Phoenician state apparatus to fail to decipher the critical
relationship between events and the status quo in general. Separating data from finite state
machine names is expensive. It also tends to generate unequally large editions. The various
pitfalls are referred to as the extended limited state computer. The code contained therein can
be overly expensive and as a result, when the design encounters a generally non-critical
situation, it is very helpful to balance data restrictions with translations. From an evaluation
point of view, it is common for significant problems to persist with non-diagnostic systems.
The same provision may or may not allow for a continuous sequence of events.
Additions are made to the number of test cases required so that the universe does not detect
an explosion. The finite computer determines whether the data code has a primary number or
not. It has identified many simple languages.
The finite state machine is a system that sets the conditions for predetermined results. It is
also common for the finite state machine to offer a wide range of options for unplanned
results. It shifts a limited state machine, often from one state to another, with an input given,
and an expanded limited state machine when only a specific set of orders is met.

27 References
Eid, M., 2015. Requirement Gathering Methods. [Online]
Available at: https://www.umsl.edu/~sauterv/analysis/F2015/Requirement%20Gathering
20 | P a g e
%20Methods.html.htm
[Accessed 21 08 2021].
Guru99, 2019. What is SDLC. [Online]
Available at: https://www.guru99.com/software-development-life-cycle-tutorial.html
[Accessed 09 05 2021].
Kumar, S., 2021. What is Iterative model- advantages, disadvantages and when to use it?. [Online]
Available at: http://tryqa.com/what-is-iterative-model-advantages-disadvantages-and-when-to-use-it/
[Accessed 19 08 2021].
Pal, S. K., 2021. Software Engineering | Spiral Model. [Online]
Available at: https://www.geeksforgeeks.org/software-engineering-spiral-model/
[Accessed 21 08 2021].
paradigm, v., 2020. Requirement Analysis Techniques. [Online]
Available at: https://www.visual-paradigm.com/guide/requirements-gathering/requirement-analysis-
techniques/#:~:text=Requirement%20Analysis%2C%20also%20known%20as,requirements%20gathering%20or
%20requirements%20capturing.
[Accessed 08 05 2021].
points, T., 2021. SDLC - V-Model. [Online]
Available at: https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm
[Accessed 19 Augest 2021].
Points, T., 2021. SDLC - V-Model. [Online]
Available at: https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm
[Accessed 21 08 2021].
point, t., 2021. SDLC - Spiral Model. [Online]
Available at: https://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm
[Accessed 21 08 2021].
Uconn, 2019. Post Implementation. [Online]
Available at: https://sdlc.uconn.edu/activity-9-post-implementation/
[Accessed 09 05 2021].

21 | P a g e