Software Development Lifecycles: Subash Adhikari

1/1/2019
Software Development
Lifecycles
Subash Adhikari
HND/ Second Semester Sec-B)

Software Development Lifecycles 2019
Contents
PART 1..................................................................................................................................................5
Stages of SDLC.................................................................................................................................6
Planning........................................................................................................................................6
Analysis.........................................................................................................................................7
Design............................................................................................................................................7
Development.................................................................................................................................7
Integration and Testing................................................................................................................7
Maintenance..................................................................................................................................8
What is SDLC...................................................................................................................................8
Why SDLC........................................................................................................................................8
SDLC Phases.....................................................................................................................................9
Phase 1: Requirement collection and analysis:..........................................................................9
Phase 2: Feasibility study:...........................................................................................................9
Phase 3: Design:..........................................................................................................................10
Phase 4: Coding:.........................................................................................................................11
Phase 5: Testing:.........................................................................................................................11
Phase 6: Installation/Deployment:............................................................................................11
Phase 7: Maintenance:.............................................................................................................12
Adaptive SDLC (System Development Life Cycle) model..........................................................13
Predictive SDLC (System Development Life Cycle) model........................................................13
Comparison between Adaptive SDLC model and Predictive SDLC model..............................13
Predictive Vs Adaptive, what will the best approach?................................................................14
SDLC MODELS.............................................................................................................................15
Waterfall SDLC Model..............................................................................................................15
Iterative SDLC Model................................................................................................................17
Subash Adhikari (HND/ Second Semester Sec-B)

2
Spiral SDLC Model....................................................................................................................19
V-shaped SDLC Model..............................................................................................................20
Agile SDLC Model.....................................................................................................................22
SDLC-ITERATIVE MODEL........................................................................................................23
Iterative Model - Design.................................................................................................................23
Iterative Model - Application........................................................................................................24
Iterative Model - Pros and Cons...................................................................................................25
Dynamic System Development Method (DSDM) Model............................................................25
Rapid Application Development (RAD).......................................................................................28
Identify and resolve risk............................................................................................................31
Risk management in spiral model:...........................................................................................32
Risk involved in DSDM & Agile model....................................................................................34
Risks iinvolved iin iwaterfall imodel:.......................................................................................35
M1 Model that I have chosen to build software for an Insurance company.............................35
PART 2................................................................................................................................................39
Purpose of feasibility study............................................................................................................39
Importance of feasibility study:....................................................................................................41
2Describe how technical solutions can be compared...................................................................41
Comparison of technical solution..................................................................................................42
Examples of human errors:...........................................................................................................45
Components of a feasibility report................................................................................................47
Structure of Feasibility report:.....................................................................................................47
Components of a Feasibility Study:..............................................................................................47
Introduction................................................................................................................................48
Purpose........................................................................................................................................48
Methodologies.............................................................................................................................49
Background history....................................................................................................................49

3
Document structure....................................................................................................................49
Intended audience......................................................................................................................49
Feasibility criteria......................................................................................................................50
Outcome......................................................................................................................................50
Possible alternate solutions........................................................................................................50
Evaluation criteria.....................................................................................................................51
Feasible solution.........................................................................................................................51
Conclusion and recommendations............................................................................................51
Part 3...................................................................................................................................................54
Current System...............................................................................................................................55
Identification of Requirements......................................................................................................55
Identification of Stakeholders Requirements...............................................................................55
Identify the requirements of the client.....................................................................................57
Specification of scopes................................................................................................................57
Inputs, outputs, processes and the process descriptors..........................................................57
Consideration of alternative solutions......................................................................................58
Security considerations..............................................................................................................59
Use of quality assurance............................................................................................................59
Identification of different constraints.......................................................................................59
3.2 Background information..........................................................................................................62
Problem statements....................................................................................................................62
Data collection process...............................................................................................................62
Interview.....................................................................................................................................63
Questionnaire..............................................................................................................................63
Observation.................................................................................................................................64
Use appropriate software analysis tools/techniques to carry out a software investigation and
create supporting documentation..................................................................................................64

4
Introduction....................................................................................................................................64
Data Flow Diagram (DFD):.......................................................................................................65
Building block of DFD:..............................................................................................................65
Data flow diagram Level 0........................................................................................................65
Context Diagram............................................................................................................................67
Entity Relationship Diagram.........................................................................................................68
Conclusion...................................................................................................................................71
M3 Analyze how software requirement can be traced throughout the software lifecycle.......72
Jira...................................................................................................................................................73
Jira is our main source of information.....................................................................................74
Jira helps me organize my documentation tasks.....................................................................74
Jira helps us track the progress of our documentation..........................................................74
Jira helps us to meet our documentation release deadlines...................................................75
Jira helps us measure the time spent on documentation........................................................75
Jira helps me get feedback fast.................................................................................................75
Trello................................................................................................................................................75
GitHub.............................................................................................................................................76
Advantages of GitHub....................................................................................................................77
Prototyping......................................................................................................................................77
Low fidelity prototype................................................................................................................77
Medium fidelity prototype.........................................................................................................78
High fidelity prototype...............................................................................................................78
M4 Discuss two approaches to improve software quality...........................................................78
Employ test-oriented software development management.....................................................78
1. Test-driven development.................................................................................................79

5
Benefits of test driven development..........................................................................................80
Pair programming......................................................................................................................80
Benefits of pair programming...................................................................................................81
Report bugs effectively...................................................................................................................81
i. Communication basis..........................................................................................................82
ii. Provide solutions if possible................................................................................................82
iii. Reproduce a bug before reporting it..............................................................................82
iv. Clarity...............................................................................................................................82
Part 4...................................................................................................................................................84
Documentation of user and system requirements........................................................................84
User Requirements.........................................................................................................................85
Functional Requirements...............................................................................................................85
Tabulation of the expected client requirements and the actual output of the product........86
M5 Discuss about the different software specification methods and suggest two software
behavioral specification methods and illustrate their use with an example relevant to the
project that needs to be constructed for the given context.........................................................87
Software specification........................................................................................................................87
There are different software specification methods which are given below:............................87
Flow chart...................................................................................................................................87
Pseudo code.................................................................................................................................90
M6 Differentiate between a finite state machine (FSM) and an extended Finite State
providing an application for both.................................................................................................94
Finite state machine (FSM)............................................................................................................95
Deterministic finite automation.....................................................................................................95
Extended finite state machine........................................................................................................96
Data driven software......................................................................................................................97
Difference between Finite and Extended Finite State Machine.................................................97
References...........................................................................................................................................99

6

7
Part 1
Report on project management plan and schedule

8
Submitted By: Subash Adhikari

Submitted To: Senior manager
Contents
PART 1..................................................................................................................................................5
Stages of SDLC.................................................................................................................................6
9
Planning........................................................................................................................................6
Analysis.........................................................................................................................................7
Design............................................................................................................................................7
Development.................................................................................................................................7
Integration and Testing................................................................................................................7
Maintenance..................................................................................................................................8
What is SDLC...................................................................................................................................8
Why SDLC........................................................................................................................................8
SDLC Phases.....................................................................................................................................9
Phase 1: Requirement collection and analysis:..........................................................................9
Phase 2: Feasibility study:...........................................................................................................9
Phase 3: Design:..........................................................................................................................10
Phase 4: Coding:.........................................................................................................................11
Phase 5: Testing:.........................................................................................................................11
Phase 6: Installation/Deployment:............................................................................................11
Phase 7: Maintenance:.............................................................................................................12
Adaptive SDLC (System Development Life Cycle) model..........................................................13
Predictive SDLC (System Development Life Cycle) model........................................................13
Comparison between Adaptive SDLC model and Predictive SDLC model..............................13
Predictive Vs Adaptive, what will the best approach?................................................................14
SDLC MODELS.............................................................................................................................15
Waterfall SDLC Model..............................................................................................................15
Iterative SDLC Model................................................................................................................17
Spiral SDLC Model....................................................................................................................19
V-shaped SDLC Model..............................................................................................................20
Agile SDLC Model.....................................................................................................................22
SDLC-ITERATIVE MODEL........................................................................................................23

10
Iterative Model - Design.................................................................................................................23
Iterative Model - Application........................................................................................................24
Iterative Model - Pros and Cons...................................................................................................25
Dynamic System Development Method (DSDM) Model............................................................25
Rapid Application Development (RAD).......................................................................................28
Identify and resolve risk............................................................................................................31
Risk management in spiral model:...........................................................................................32
Risk involved in DSDM & Agile model....................................................................................34
Risks iinvolved iin iwaterfall imodel:.......................................................................................35
M1 Model that I have chosen to build software for an Insurance company.............................35
PART 1
Executive summary
This report describes the phased benefits of the software development life cycle and the
shortcomings and phases of the software development life cycle. Various models of the system

11
development life cycle were discussed and evaluated, and ultimately the SDLC model that best fits
the scenario for developing software for large insurance companies was selected. He also explained
why he chose a flexible development environment model, using software from an insurance
company as an example. Finally, we appreciate the essence of using the waterfall model for large
software development projects.
Introduction
The Software Development Lifecycle (SDLC), also known as the Application Development
Lifecycle, is a term used in systems engineering, information systems, and software engineering to
describe the process of planning, creating, testing, and deploying information systems.
According to Rouse (2015), the software development lifecycle is the foundation used in project
management, including several steps from project start to completion. By selecting and adhering to
the system development lifecycle model for each project that needs to be completed, the process
operates efficiently, meeting or exceeding customer expectations, improving quality, and reducing
production time. The To help you.
Although it may seem boring at first glance, you can save time by planning the project architecture
instead of going directly to the implementation phase (coding). Developers with many years of
experience do not have an attack plan, so they must destroy the entire project and start from scratch.
Therefore, it is important to understand and follow the system development lifecycle model. This
task describes and evaluates various models in the system development lifecycle, including waterfall
models (original SDLC methods), spirals, rapid application development (RAD), dynamic and
dynamic system development methods (DSDM).
Stages of SDLC
A SDLC comprises of various stages which is illustrated in following figure:

12
Planning
This is the first and first step of SDLC. This is done by a team working with customers. At this stage,
the SDLC team identifies and identifies issues that need to be addressed in a particular system,
determines the costs and resources to implement this particular project, calculates the time interval
between project completions, decide how to improve the product compared to competitive products
and will be available after the meeting. Other alternative solutions. With customers and suppliers
(Stickily, 2017). Finally, at this stage, a general overview of project requirements and scope is
performed.
Analysis
This phase is followed by the analysis phase. At this stage, a feasibility study is conducted to
determine whether the project is technically, economically, socially and technically feasible (Alwin,
2015). In addition, various alternative solutions were proposed during the planning phase, and the
best solution to meet customer requirements was selected. Finally, through a close dialogue with the
customer, a clear vision of the final product and its functionality is developed.

13
Design
After deeply understanding the customer's needs, investigating the feasibility of the project, and
finding the optimal design solution, you need to start the system development phase. Design systems
can be built using pens and pencils and laid out using a variety of software. In some cases, you can
use a prototype of the product you are building. At this stage, customers are offered a variety of
product design methods that are analyzed based on various parameters such as product reliability,
design modularity, time constraints, and optimal product design. Finally, the detailed and expanded
system design is produced.
Development
This is the actual stage of product development. This procedure is easy if you use best practices and
work with the developer to implement the design phase. If the product under development is
software, the actual code is written at this stage, and if the product under development is hardware, it
is in the setup and configuration phase. A properly designed system can have a significant impact on
testing and maintenance. Therefore, follow the latest guidelines when designing your system.
Integration and Testing

Testing is a quality control tool used in software development. At this point, the system is checked by
an actual user or panel to determine if the system has been detected or has an error and has solved
these problems (Alwin, 2015). Unit tests are typically performed during system development,
combining various components and subsystems developed during the development phase to create an
entire system, addressing all issues encountered during testing, and testing system integration. The
Finally, you are ready to deploy the system.
Maintenance
If not updated regularly, each system is out of date. Therefore, maintenance of the system after it has
been sold to the market is performed during the maintenance phase. This is the longest and most
important phase of the system development life cycle. As everyone knows, planning will never be
perfect when entering the market. Therefore, at this stage, various versions of the system are released
after receiving customer feedback on the latest technology changes, improvements, and the use of
advanced security.

14
What is SDLC
The software development lifecycle is a systematic software creation process that ensures the quality
and accuracy of the software being created. The SDLC process is designed to create high quality
software that meets customer expectations. Software development must be completed within the
planned time and cost. Different types of SDLC model involve waterfall model, V model, Iterative
model, spiral model, agile model and others. It is defined as a mechanism in the software industry to
develop, design and test the top-quality software. It involves different phases such as planning phase,
analysis phase, design phase, implementation phase and maintenance phase. SDLC includes a
detailed plan that describes how to plan, create, and maintain specific software. Each phase of the
SDLC lifecycle has its own processes and results and moves on to the next phase.
Why SDLC
Here, are prime reasons why SDLC is important for developing a software system.
• Provides the basis for project planning, planning and evaluation.
• This is a mechanism for tracking and controlling projects.
• Improve visibility of project plans for all stakeholders in the development process.
• Improvement and improvement of development speed
• Improve customer relationships
• Reduce project risk and project management overhead
SDLC Phases
The entire SDLC process divided into the following stages:

15
• Phase 1: Requirement collection and analysis

• Phase 2: Feasibility study:
• Phase 3: Design:
• Phase 4: Coding:
• Phase 5: Testing:
• Phase 6: Installation/Deployment:
• Phase 7: Maintenance:
In this tutorial, I have explained all these phases
Phase 1: Requirement collection and analysis:

This requirement is the first step in the SDLC process. Senior team members will participate with the
participation of all stakeholders and experts in this field. At this stage, quality assurance requirements
are also planned and the associated risks are taken into account. This phase will provide a clearer
description of the overall project scope and the anticipated issues, opportunities, and instructions for
running the project.
During the collection phase the team needs to get detailed and accurate requirements. This will help
the company complete the deadline for completing this system.
Phase 2: Feasibility study:

Once the requirements analysis phase is complete, the next step is to identify and document the
software requirements. Perform this procedure using a Software Requirements Specification
document (also known as an “SRS” document). Includes everything that needs to be designed and
developed during the lifetime of the project.
There are mainly five types of feasibilities checks:
• Economic: Can we complete the project within the budget or not?

• Legal: Can we handle this project as cyber law and other regulatory
framework/compliances.
• Operation feasibility: Can we create operations which is expected by the client?

• Technical: Need to check whether the current computer system can support the software

16
• Schedule: Decide that the project can be completed within the given schedule or not.
Phase 3: Design:
In this third phase, document preparation systems and software design documents are standardized as
needed. This can help determine the overall architecture of the system.
This design stage serves as input to the next stage of the model.
There are two kinds of design documents developed in this phase:
High-Level Design (HLD)
• Brief description and name of each module
• Brief description of the function of each module
• Interface relationships and dependencies between modules
• Database tables identified using key elements
• Complete architecture diagram including technical details
Low-Level Design (LLD)
• Module functional logic
• Database tables with type and size
• Interface details
• Solve all kinds of addiction problems
• Error message list
• Complete input / output of each module
Phase 4: Coding:
Once the system design phase is complete, the next step is coding. At this stage, the developer writes
code in the chosen programming language and begins building the entire system. In the coding
phase, tasks are divided into blocks or modules and assigned to different developers. This is the
longest phase of the software development life cycle. At this point, the developer must follow certain
predefined encoding rules. You must also use a programming tool such as a compiler, interpreter, or
debugger to generate and implement the code.

17
Phase 5: Testing:
After the software is complete and deployed in a test environment. The test team began testing the
functionality of the entire system. This is done to ensure that the entire application works according
to customer requirements.At this point, the QA and test team may find bugs / defects to report to
the developer. The development team corrected the error and sent it back to QA for retesting. This
process continues until the software runs stable and runs in line with the business needs of the
system.
Phase 6: Installation/Deployment:
When the software testing phase is complete and the system is error free, the final deployment
process begins. Based on feedback from the project manager, release the final software and check for
deployment issues.
Phase 7: Maintenance:
When you deploy the system and start using the customer-developed system, the following three
operations occur:
• Bug fixes-errors reported for incomplete tests

• Update-Update the application to a new software version.
• Improvements-add some new features to existing software
The main goal of the SDLC step is to ensure that requirements continue to be met and the system
continues to operate according to the specifications mentioned in the first step.
Advantages and Disadvantages of SDLC
Some of the major advantages of SDLC are:
• It improves the monitoring and control of large projects.

• It is formed regarding the well-detailed
• The orderly sequence regarding the steps of development as well as strict controls assures the
adequacy related to the documentation.
• The design reviews assist to assure the reliability, maintainability and quality of the
developed solution or software.
• The cost and progress of the development of the system, the targets regarding completion are
measurable.
Some of the major disadvantages of SDLC are:

18
• It increases the cost and time of the development.

• It makes it hard to estimate the cost regarding the project.
• The performance regarding the system can’t be tested before the completion of the coding.
• It also increases the amount of the documentation as time advances.
Adaptive SDLC (System Development Life Cycle) model
Adaptive SDLC (System Development Life Cycle) model has evolved from the practices of RAD.
Different aspects of the team were also added to these particular practices. This development
approach has been used by many countries for their projects to get effective results. The practices
related to adaptive software developed offers potential to accommodate change as well as are fully
adaptable in the confused environments with different products evolving with very little learning and
planning. Different phases of adaptive software development involve Speculate, collaborate and
learn. These given three phases reflect the dynamic nature regarding the adaptive software
development. The adaptive development unambiguously replaces the Determinism with the
Emergence.
Predictive SDLC (System Development Life Cycle) model
Predictive SDLC (System Development Life Cycle) model is defined as an approach that assumes
the planning of the project initially before starting the project and that the new system which can be
established or developed as per planning is done initially. Different processes involve in traditional
predictive approaches are an initiation, project planning, analysis, design, implementation as well as
deployment.

19
Comparison between Adaptive SDLC model and Predictive SDLC model
Parameters Predictive Adaptive
Phases Overlapping and sequential Parallel, sequential and overlapping
High-level Yes Yes

planning
High-level scope Yes Yes
Detailed Rolling wave or at starting stage of the Only of iteration

Planning project.
When to use It is used only when the product is It is used when the project is not
understood appropriately. understood appropriately, rapidly
changing environments.
Involvement of While changing scope and in Continuous

customer Beginning
Predictive Vs Adaptive, what will the best approach?
The most famous solutions regarding the project management being deployed these days are
predictive and adaptive. The adaptive is known as agile, and the predictive approach also referred to
as the traditional or waterfall model. Both the approaches have their benefits and limitations. Their
predictive approach is only considered as appropriate for the small projects and on the other hand;
the adaptive methodology can be useful for the small as well as large projects also. For the small
projects, the predictive approach can be very beneficial to get effective outcomes in the development
of the project.
To get detailed information regarding predictive SDLC approach and adaptive SDLC approach, you
can easily hire our online assignment help services through our website. To avail our services, you

20
have to place an order first then our online experts will help you in completing your assignments
with 100% original content and top-quality.
SDLC MODELS
Waterfall SDLC Model
Waterfall is a cascaded SDLC model, and the development process looks like a stream that goes
step by step through the analysis, design, implementation, test, implementation, and support phases.
The SDLC model includes a step-through for each step. This process is strictly documented and
predetermined by the expected functionality at each phase of the software development lifecycle
model. The cost of the project. System performance cannot be verified until encoding is complete.
Also, the number of documents will increase gradually.

21
ADVANTAGES DISADVANTAGES
Simple to use and understand The software is ready only after the last stage is over
Management simplicity thanks to its rigidity: every High risks and uncertainty
phase has a defined result and process review
Development stages go one by one Not the best choice for complex and object-oriented
projects
Perfect for the small or mid-sized projects where Inappropriate for the long-term projects
requirements are clear and not equivocal
Easy to determine the key points in the development The progress of the stage is hard to measure while it is still
cycle in the development
Easy to classify and prioritize tasks Integration is done at the very end, which does not give the
option of identifying the problem in advance
Use cases for the Waterfall SDLC model:
• The requirements are precisely documented

• Product definition is stable
• The technologies stack is predefined which makes it not dynamic
• No ambiguous requirements
• The project is short
Iterative SDLC Model
The iterative SDLC model does not require a complete list of requirements before the project
begins. The development process can start with functional component requirements and can be

22
extended later. Repeat this process so that you can create a new version of the product for each
loop. Each iteration (2-6 weeks) includes a separate component of the development system and
adds this component to the previously developed functionality. In mathematical terms, the iterative
model is an implementation of the successive approximation method, which means that it
approaches the planned form of the final product.
Some functions can be quickly developed at the Iterative model requires more resources than the waterfall model
beginning of the development lifecycle
The paralleled development can be applied Constant management is required
The progress is easy measurable Issues with architecture or design may occur because not all the
requirements are foreseen during the short planning stage
The shorter iteration is - the easier testing and Bad choice for the small projects
debugging stages are
It is easier to control the risks as high-risk tasks The process is difficult to manage
are completed first
Problems and risks defined within one iteration The risks may not be completely determined even at the final stage
can be prevented in the next sprints of the project

23
Flexibility and readiness to the changes in the Risks analysis requires involvement of the highly-qualified
requirements specialists
Use cases for the Iteration model:

 The requirements to the final product are strictly predefined
 Applied to the large-scale projects
 The main task is predefined, but the details may advance with the time
Spiral SDLC Model
The spiral model is an SDLC model that combines an architecture and a prototype in stages. This is a
combination of iterative and waterfall SDLC models with an emphasis on risk analysis. The main
problem with the spiral model is determining the right time to go to the next stage. We recommend
that you use a pre-set time frame as a solution to this problem. Even if the previous phase has not
been completed, the next phase of the migration will run as planned. The program was implemented
based on statistical data obtained from previous projects, based on the developer's personal
experience.

24
Lifecycle is divided into small parts, and if the risk concentration is Can be quite expensive
higher, the phase can be finished earlier to address the treats
The development process is precisely documented yet scalable to The risk control demands involvement of the
the changes highly-skilled professionals
The scalability allows to make changes and add new functionality Can be ineffective for the small projects
even at the relatively late stages
The earlier working prototype is done - sooner users can point out Big number of the intermediate stages
the flaws requires excessive documentation
Use cases for the Spiral model

25
• Customer isn’t sure about the requirements

• Major edits are expected during the development cycle
• The projects with mid or high-level risk, where it is important to prevent these risks
• The new product that should be released in a few stages to have enough of client’s feedback
V-shaped SDLC Model
The V-shaped SDLC model is an extension of the traditional waterfall model based on the
appropriate test phase of each development phase. This is a very rigorous model; the next phase
starts only after the previous phase. This is also called validation and validation models. Each step
has continuous process control to switch to the next step.

26
Every stage of V-shaped model has strict results so it’s easy to control Lack of the flexibility
Testing and verification take place in the early stages Bad choice for the small projects
Good for the small projects, where requirements are static and clear Relatively big risks
Use cases for the V-shaped model:
• For the projects where an accurate product testing is required

• For the small and mid-sized projects, where requirements are strictly predefined
• The engineers of the required qualification, especially testers, are within easy reach.
Agile SDLC Model

With a flexible approach, after each iteration of development, the client can review the results and
understand if they are satisfied. This is one of the strengths of an agile software development
lifecycle model. One drawback is that it is difficult to evaluate resources and development costs
without any requirements. Extreme programming is one of the practical applications of the flexible
model. The basis of this model is a short weekly meeting-sprint, which is part of the Scrum
approach.

27
Corrections of functional requirements are implemented Difficulties with measuring the final cost because of
into the development process to provide the competitiveness permanent changes
Project is divided by short and transparent iterations The team should be highly professional and client-
oriented
Risks are minimized thanks to the flexible change process New requirements may conflict with the existing
architecture
Fast release of the first product version With all the corrections and changes there is
possibility that the project will exceed expected time
Use cases for the Agile model:

 The users’ needs change dynamically
 Less price for the changes implemented because of the many iterations
 Unlike the Waterfall model, it requires only initial planning to start the project

28
SDLC-ITERATIVE MODEL
The iterative model starts with a simple implementation of a small number of software requirements
and iteratively extends the development version until the entire system is implemented and ready for
deployment. The iterative lifecycle model does not try to start with a complete requirements
specification. Instead, development begins with identifying and implementing only one piece of
software and analyzing it to determine further requirements. The process is then repeated to create a
new software version at the end of each iteration of the model.
Iterative Model - Design
The iterative process starts with a simple implementation of a subset of software requirements and
iteratively extends the evolved version until a complete system is implemented. At each iteration,
design changes are made and new features are added. The main idea of this method is to use an
iterative loop (iteratively) and develop a system in smaller (gradually) parts at once.
The following illustration is a representation of the Iterative and Incremental model −
Iterative and incremental development is a combination of iterative design or iterative methods and
an incremental assembly model for development. “The software development process allows
multiple iterations of the software development cycle to run simultaneously.” The process can be
described as an “evolutionary acquisition” or “incremental assembly” approach.
In this incremental model, the entire requirement is divided into different assemblies. At each
iteration, the development module goes through requirements, design, implementation, and testing
phases. Each subsequent version of the module adds functionality to the previous version. This

29
process continues until the entire system is ready as needed.The key to the proper use of an iterative
software development lifecycle is to fully validate the requirements and validate and test each
software release based on these requirements in each model cycle. As software evolves over
sequential cycles, it must be tested and extended to verify each version of the software.
Iterative Model - Application
As with other SDLC models, iterative and incremental development has several specific applications
in the software industry. This model is most commonly used in the following scenarios −
• Clearly define and understand complete system requirements.
• Key requirements need to be identified, but some features or necessary

improvements may be pushed over time
• Have time to limit the market.
• When developing a project, the development team studies using new technologies.
• Resources with needed skill sets are not available and are planned to be used on
contract basis for specific iterations.
• There are some high-risk features and goals which may change in the future.
Iterative Model - Pros and Cons
The advantage of this model is that there is an operational model of the system that assists with
search functionality or design flaws early in development. By finding problems early in
development, you can take corrective action within a limited budget.
The disadvantage of this SDLC model is that it is only suitable for large and cumbersome software
development projects. This is because it is difficult to split a small software system into additional
small health increments / modules.
The advantages of the Iterative and Incremental SDLC Model are as follows:
• Some features can be developed quickly at the start of the lifecycle.

30
• Early and regular results.

• Plan for parallel development.
• Measure progress.
• Lower cost of changing range / requirements.
• Testing and debugging during small iterations is easy.
The disadvantages of the Iterative and Incremental SDLC Model are as follows:
• More resources may be required.

• The cost of change is low but not suitable for change requirements.
• More administrative attention is needed.
• Not all requirements are collected at the beginning of the lifecycle, so there may be a
problem with the system architecture or design.
• To define increments, you must define the entire system.
Dynamic System Development Method (DSDM) Model
Dynamic System Development (DSDM) is referred to as an iterative step-by-step approach to system

development methodology, mainly based on the RAD model (solutionsiq.com, 2017). It is also
known as a flexible project delivery structure. Unlike Agile, it focuses on pre-development and post-
development processes and tracks requirements and formal reports. The following figure
demonstrates the various phases involved in DSDM model:

31
As shown, the DSDM model has five lifecycle phases. The iterations of the various stages of the
system development process can be related to good teamwork or direct communication between
developers. First, the feasibility study application was completed and completed.
Also check whether the application is suitable for the RAD method. If these tests yield a positive
result, the project's business research creates additional business needs. The development process
uses a variety of quality management methods to support advanced applications and easily track the
incremental development process. The third phase is an iteration of the functional model, whose
main purpose is to create a functional prototype.
This phase is usually followed by design and assembly iterations that improve previously assembled
software components according to industry standards. The final assembly of the product is ready for
installation. At this stage, the system is deployed and deployed in a real-time production
environment. Users can also learn complex systems.
Advantages of DSDM model:
• Easily adjust to changing requirements.

• Providing products quickly.
• Following the DSDM model is very helpful in providing early partial work solutions,
allowing customers to maintain continuous feedback and ensure product success. Customers
are actively participating in this model and customer satisfaction is high.
Disadvantages of DSDM Model:
• As a new model, it is not uncommon or difficult to learn.

• It is difficult to move from a traditional model of an organization to a DSDM model from the
beginning.
DSDM model is most appropriate to use when:
• This model is ideal for projects that need to be developed in a short period of time and cannot
be frozen at the start of the project.
• Requirements can change over time and project resources are fixed, but projects only apply
to teams with fixed resources, even as a last resort.
Rapid Application Development (RAD)

32
Rapid application development is a development model that facilitates rapid prototyping and rapid
feedback on long-term development and test cycles. Rapid application development allows developers to
quickly complete multiple iterations and software updates without having to run a development plan
from scratch each time. The system design phase, along with the technical and detailed design and
software architecture, leads to the test phase, software integration and ends with maintenance and
support. Rapid Application Development (RAD) is a solution for inflexible processes such as the
waterfall approach. Creating software applications in this “old fashion” way usually takes a lot of
time.Meanwhile, the requirements changed before the entire system was developed and delivered. This
can damage the application.
As shown in the diagram above, RAD starts with rapid analysis and minimal planning. Initially,
prototypes were built using advanced RAD tools and then tested by end users to provide feedback to
developers and designers. Unlike the prototype model, the first built prototype is not reset. Next,
complete the same prototype that was built previously and present it to the customer, again providing
the developer with feedback and necessary / additional requirements that need to be integrated into
the system. Repeat this process until the customer is satisfied. When the customer is satisfied with
the system, the testing phase begins. In this model, the testing phase is much simpler because each
prototype is tested individually in each phase. Finally, the development team transfers the
components to the deployment system's real-time operating environment. In addition, some software
usage training will be provided as needed.
When to use RAD Methodology
• The system must be created in a short time (2 to 3 months).

• If you know the demand
• When a user participates in the entire life cycle
• Small technical risk

33
• If you need to create a system that can be modularized within 2-3 months
• If the budget is high enough, designers can model the cost of automatic code generation tools
Advantages and Disadvantages of SDLC RAD Model
Advantages Disadvantages
• Flexible and adaptable to changes • It can't be used for smaller projects
• It is useful when you have to reduce the • Not all application is compatible with
overall project risk RAD
• It is adaptable and flexible to changes • When technical risk is high, it is not

suitable
• It is easier to transfer deliverables as • If developers are not committed to

scripts, high-level abstractions and delivering software on time, RAD
intermediate codes are used projects can fail
• Due to code generators and code reuse, • Reduced features due to time boxing,
there is a reduction of manual coding where features are pushed to a later
version to finish a release in short period
• Due to prototyping in nature, there is a • Reduced scalability occurs because a

possibility of lesser defects RAD developed application begins as a
prototype and evolves into a finished
application
• Each phase in RAD delivers highest • Progress and problems accustomed are
priority functionality to client hard to track as such there is no

34
documentation to demonstrate what has

been done
• With less people, productivity can be • Requires highly skilled designers or

increased in short time developers
Identify and resolve risk

In the second quadrant of the spiral model, risk analysis is performed. This includes identifying,
assessing and monitoring technical feasibility and management risks, such as cost overruns and
schedule shifts. All possible solutions are then evaluated and the best possible solution can be
selected. The risks associated with this decision are then identified and then resolved using the best
possible solution. Finally, a prototype for the optimal solution is created at the end of this quadrant.
Thus, in essence, identifying potential risks can be performed while a risk reduction strategy is
planned and finalized. In the figure above the spiral model, we divided the development part into
four quadrants. It includes one complete quadrant to identify and eliminate risk, even if it is risky in
the future. This gives priority to risk analysis. For example, when completing a task, giving 3 hours
out of 12 hours for a task is the best task. Giving them a quarter of the time to complete a task helps
you think better and perform this task better. This is the same as spending a quarter of the time
identifying and eliminating the risk. As a result, fewer changes are associated with software risk.

35
Risk management in spiral model:

Risk is managed in the spiral lifecycle model
In all life cycle models, such as the waterfall model, there are many important steps or events in
software development. It cannot be modified, modified or sequenced, but there are three really
important ones:
Life cycle objectives:
Here, the life cycle in the spiral helps by ensuring that what we know is what we want to do and that
it can be done.
Life cycle architecture: Develop the way things will be built
Initial operation: Prepare the transfer to the client for location and training
[ CITATION csh18 \l 1033 ]
Firstly, risk management is divided into two parts which are given below:
1. Risk assessment
Risk assessment can be defined as identifying risk levels relevant to the situation, assessing,
assessing, comparing to standards, and determining acceptable risk levels. He studies risk and helps
development solve the risk. Risk assessment is further divided into the following three parts:

36
Risk identification
Risk identification is the first risk assessment process. You cannot find a better solution without
identifying the risks. You need to know what type of risk or type of risk will occur in the future so
that you can find the best solution to eliminate the risk.
Risk analysis
After identifying the risks, you need to analyze the identified risks. Deeper analysis is needed to
determine the main cause of the solution. Without analyzing the cause of the risk, you will not be
able to find the best solution to solve it. You must also analyze the problems that can occur in the
software if you do not resolve the risks, and the types of risks.
Risk prioritization
After risk analysis, risks should be prioritized based on importance, nature, or danger. Risks that are
very dangerous to the software or very important to the solution need to be resolved suddenly before
resolving another risk. Failure to prioritize risks can lead to major software problems in the future.
No future decision can be made unless it is resolved suddenly. Risk prioritization is therefore the
most important risk assessment process.
2. Risk control
Risk management is a way for companies to assess potential losses and take steps to mitigate or
eliminate such threats (Anon., N.d.). This is the most important part of risk management. Simply put,
risk is managed to control it. Without risk management, risk management is not used and other risks
occur regularly in the software. The different parts of risk management are listed below.
Planning
As we know, planning means thinking before doing anything. By managing risk, the first thing you
can do is plan. First, you need to plan how to manage or control risk. You need to plan your
development team appropriately and find the best solution to software risks.
Resolution
If the plan is successful, you need to proceed to the second stage decision. You need to advance your
risk management or risk management process and plan accordingly at this stage.
Monitoring

37
Finally, monitoring is the last important step in risk management. Must be tracked when resolving
risks. At this point, track and evaluate the risk level of the software. This is an ongoing risk
management process. After resolving the risk, you need to control it to resolve it properly.
Risks associated with each model and ways to mitigate / manage them in each model. As I described
different life cycle models with their advantages and disadvantages. We now list the different types
of risks included in each model and the related mitigation measures:
Risk associated with the spiral model:
• Software development is associated with uncertainty.

• This must be quantified.
• Can be used to choose between different alternatives: select the one where the expected loss
is lower.
Mitigating Measures
Software development is associated with uncertainty. The following measures must be taken to
mitigate the risks associated with the spiral model:
• Define the goals of the game you are playing

• Map implementation alternatives
• Be aware of the limitations of these alternatives
• Use prototypes, analysis, etc. Acquire the necessary knowledge and reduce risks
Plan the next step
• This must be quantified.

• Can be used to choose between different alternatives: select the one where the expected loss
is lower.
Risk involved in DSDM & Agile model

Because DSDM is also an agile framework for project implementation. Both have similar risks and
mitigation measures.
The two main sources of internal risk identified in the literature are the managers / project
management team. The customer is the main source of external risk.

38
Mitigating Measures:
Begin with an understanding of the project's objectives, context and context of risk, risk assessment
(identification of risk factors and appetite), risk adaptation (risk management integration). in an agile
process), risk management (identification, analysis, management and monitoring) of the resulting
risks. Optimized agile process.
Agile risk management is based on three principles: flow (ensuring that events do not hinder or delay
progress), balance (reward with less risk) and transparency (making all risky artifacts visible and
accessible).
Risks iinvolved iin iwaterfall imodel:

Mitigating imeasures:
Waterfall irisks iare imanaged ithrough itables. iThe iwaterfall irisk imaps iare idivided iinto ithree
iparts. iThe ifirst istarts iwhen ia irisk iis idetected iand iends iwhen ithe idevelopers istart ilooking
ifor ia isolution. iThe isecond iphase ilasts iuntil ia isolution iis ifound. iThe ithird iphase iis ithe irisk
ielimination iphase. iExpires iuntil ithe irisk iexpiry idate. iThis irisk imanagement imodel iallows
iWaterfall idevelopers ito iavoid imany ierrors iin itheir iproduction iand iimprove itheir iquality iand
iacceptance iof itheir icustomers.
M1 Model that I have chosen to build software for an Insurance company
While developing an application, we have to select the best model according to the demand of client
in the application. If the selection of model is best, then we can develop any application easily and
effectively. But the selection of model for development environment is not so easy. We should have
knowledge of every model and should know which model is best while developing an application. If
we are able to select the best model while developing an application then it helps to decrease
development time and price, manipulate vulnerability, restrict overhead and danger exposure and
also decorate quality in an application.
For the development environment, I would mostly select spiral model. It is an aggregate of a
waterfall version and iterative model. Each cycle of the spiral model is completed by a review
including plans for the next cycle. In the spiral lifecycle model, project monitoring is very easy and
effective. Spiral model has specially four phases i.e. Planning, risk analysis, engineering and

39
evaluation. While developing an application using spiral model, firstly we have to focus on the
planning. We have to gather the entire requirements from the client and also objects are identified,
elaborated and analyzed. After the successful gathering requirement, the planning is done where all
the features and facilities of an application are discussed. After planning, risk analysis which includes
identifying, estimating and monitoring the technical feasibility and management risks such as cost
overrun and schedule slippage are done. When the risk analysis done, the development stage begins
in which the features which are identified are developed and also verified through testing. Finally,
the evaluation stage is started. This is the last stage of spiral model in which maintenance and review
is also done. This type of model is specially used for big projects which involves continuous
enhancements. The vital evaluation among the spiral model and other models is its undeniable
acknowledgment of danger. A cycle of the spiral starts off evolved by means of explaining targets, as
an instance, execution and value. Spiral version is utilized for the most element in massive projects.
There is also many applicability of the spiral model over the development environment. Cost
estimation becomes easy in this model because the prototype building is done in small fragments.
Additional changes can be done at also later stage while using spiral model. When the requirement of
client in very complex then also the spiral model is very useful for developing the software
successfully including the complex requirement of the client. Thus, there are many applicability of
the spiral model over the development environment.
For example, in our scenario, there is one large insurance company while developing the software of
insurance company, we can use different model according to the features included in the software
and its nature. But according to me, spiral model is best for the development of insurance company
software. As we know, spiral mode is the It is an aggregate of a waterfall version and iterative model.
It has quality of both waterfall model and iterative model. Firstly, we have to gather the entire
information from the administrator of an insurance company like. After that we have to discuss and
plan among the team about the features and facilities include in the application like money payment,
news of insurance company, etc. After proper planning, we have to analyze the risk which could be
occurred in an application. We have to find out the different risk which could be occurred in an
application and also the best solution for the risk. After that we should more on towards the
engineering stage which we design and code for an application. Finally, we have to evaluate our
application from the clients. We can also take review from the administrator and user for the future
update. If we use this approach for the insurance company software development, then surely it
would be the best application for the entire insurance company. The spiral model would be the best
for the development environment than other model due to its many advantages.

40
Considering the application of spiral model and also the above example, there is many benefits of
using spiral model for the development environment. We give one fourth time for the risk analysis
due to which there is very less possibility or almost no possibility of risk or any types of error in an
application. Cost estimation also becomes easy in this model because the prototype building is done
in small fragments. Due to these reasons, I have selected spiral model for a development
environment.
Model Spiral Model Other traditional model

41
Conclusion
In this task, we first described the software development lifecycle. Later, the iteration model was
described, along with two iteration models and their plots, benefits, and limitations. An iterative model is
a specific implementation of the software development lifecycle, focusing on the initial simplified
implementation, gradually becoming more complex and extending the scope of functionality until
the final system is complete. Similarly, the number, benefits, and limitations of the sequential model
and the two continuous models were discussed. Later, we explained how to manage risks with a
spiral model. He also explained why insurance company software was used as an example to select the
spiral model for the development environment. Finally, we appreciate the benefits of using the
waterfall model in large software projects.Each iteration adds functionality to the previous version. This
is done by a cross-functional team that applies all features such as requirements
analysis,design,implementation, and testing. The final assembly contains all the specifications that
the client needs.

42
PART 2
Background
According to Wolfe (2017), a study aimed at determining the success of a project, taking into
account factors that affect the project, such as technology, law, and economic factors, is called a
feasibility study. It is It helps to outline the issues that lead to positive and negative outcomes of the
project and should pass as an important control point before investing much time and money. In
other words, the feasibility study is the feasibility of this idea.
A feasibility study is a document that reviews the proposed solution and evaluates whether it is
feasible under certain restrictions. These restrictions are financial, social, practical, environmental,
technical, legal, or other restrictions that may make the implementation of the solution impossible or
inappropriate. For example, in promoting company production, the CEO wants to save company
money. But is this a good idea? This step can bring a lot of money to the company and reduce the
savings in new locations. There are also environmental issues. You can squeeze out wild animals.
There are also tax cuts that may vary from place to place.
Some of the purposes of carrying our Feasibility study are enumerated below:
Purpose of feasibility study
There are different purposes of feasibility study which are given below: -
1. To define the potential solutions to the defined problems or needs
2. To explore the business opportunity and alternative paths available
3. To explore the different markets and targets audience
4. To prepare final draft of the project
5. To explore the price of the project that the targeted audience is ready to pay

43
6. To assist the management in implementing the desired system
1. To explore the different markets and targets audience
Another purpose of feasibility report is to explore the different markets and targets audience.
Feasibility reports also includes the demand of project in the markets by the clients or targeted
audience. If there is more demand of the projects in the market by the targeted audience, then the
project starts to complete as soon as possible. It includes different markets and targeted audience due
to which different market explores.
2. To prepare final draft of the project
After feasibility study before doing any project, a person knows everything about the projects such
as budget, manpower, time-durable, demand by clients, etc. After that they prepare the document on
the basis of their research. Thus, feasibility report helps to prepare the final draft of the projects.
3. To explore the price of the project that the targeted audience is ready to pay
While doing some project, it is difficult to fix the price of the project. Sometimes the price could be
fixing more which the targets audience denied to pay and sometimes the price of the project is fixed
less due to which he could have bear loss. Due to such problem, it would be very difficult to fix the
price of the project. But feasibility study makes document of each and every detail like manpower,
expenses, budget, etc. due to which it explores the price of the projects that the targeted audience is
ready to pay.
4. To assist the management in implementing the desired system
With the help of the feasibility report, a person can know each and every detail information about the
project which is being going to start. Due to this, it would be very easy to assist the management in
implementing the desired system otherwise a person has to face a lot of project while managing the
project. He should keep result of everything which is done on the regular basis and manage it so that
the client should not face problem on it.
In addition, feasibility studies can help indicate another problem with where in the software occurs.
Explain all solutions to the problem and point out economic, operational and technical capabilities.

44
Economic feasibility is related to costs, including all costs such as hardware costs, labor costs, and
operational costs. Operational feasibility determines how the solution fits into existing operations
and how technical feasibility—the solution fits into existing structures. Examine the main focus of
business opportunities and the alternative paths that follow. Feasibility studies are the most important
document for developing effective and successful software.
Importance of feasibility study:

It assists to provide the overview of the problem i.e. to determine both potential positive and
negative outcomes of a project and acts as an important checkpoint that should be completed before
investing considerable amount of time and money into it. It has several components which helps to
answer the following questions:
• Technology-can you run using the latest technology? If your technology is outdated or
updated and does not support backward compatibility
• Operation-OK, the software works but can the user use it? How many users can use at the same time?
• Timetable-can you complete the project on time?
• Economy-Does revenue exceed costs? Do you have the amount or funds needed to start
project predictions?
Technical solution is all about planning, Analyzing, designing, Implementing, testing. Also, it
considers how you deploy and maintain the product.
Describe how technical solutions can be compared.

Technical solution can be defined as one that requires a change only in the techniques of the natural
sciences, demanding little or nothing in the way of change in human values or ideas of morality.

45
Technical solution is basically done to develop, design and implement solutions according to the
requirements. It is very important to use technical solution for every problem so that it could be
easily solved. The technical solution process area is applicable at any level of the product
architecture and to every products and product related lifecycle process.
Comparison of technical solution
Technical solution can be compared on the basis of following points:
1. Budget
2. Performance
3. Efficiency
4. Automation
5. Legacy systems upgrade
6. Elimination of human errors
Budget
As you know, the budget is the amount required to successfully complete the application. Developers
can develop any type of application if the application development budget is large. The first thing
needed for software development is a budget. Everything you need for software development, such
as software developers, marketers, and technology purchases, needs money. It is also useful for
comparing technical solutions. For example, if you have a low developer budget when developing an
application, many problems will arise. He can't buy new technology, his friends and employees can
leave him, and if they aren't paid in time, he can't solve the problem correctly.
Performance
As everyone knows, productivity is the action or process that performs a task or function. This plays
an important role in comparative technology solutions. By analyzing performance, you can choose
the best solution from a variety of solutions. For example, an insurance company needs an
accountant. The company doesn't have a good accountant, so it faces big problems in financial

46
transactions. To solve this problem, they informed the insurance company about the possibility of
accounting employment. Many candidates can come to the interview, but they are always selected to
hold positions, their performance is higher than others, and each transaction can be tracked. In this
issue, performance plays an important role in solving technical problems.
Efficiency
Efficiency means productivity level and represents the use of a minimum amount of input to achieve
maximum output (Kenton, 2018). When solving a problem, you must consider the effectiveness of the
solution. For example, there was the problem of recording insurance company customer records in
newspapers. It is very difficult to store a record safely and determine if it is absolutely necessary. There
are several solutions to this problem, such as keeping more employees, keeping records by name, but the
best solution for insurance company effectiveness can be obtained every second as needed Is to install
digitally recorded customer software. Customer information. Efficiency is very important when
comparing technical solutions.
Automation
Automation is a technology that executes a process or process with minimal human assistance.
Automated or automated controls operate equipment such as machinery, factory processes, heat
treatment boilers and furnaces, the inclusion of telephone networks, management and stability of
ships, aircraft and other applications, and personnel minimization or reduction Refers to the use of
various control systems for. vehicle. intervention.
Other Examples
• Start tv from remote.
• Control ac from mobile etc.
• Code level Automation to reduce the number of maximum codes
There are many things people need to code in advance; in early assemblers and programming
languages, all routines must be written. But over the years, standardized component libraries have
emerged. Some compilers can provide pre-implemented standard data structures. Engineers are
better at "designing" the final software than those that implement the final software linked list. That
is, focus on the final functionality of the software, not every line of code.

47
Legacy systems upgrade
Legacy system upgrade is another important component by which technical solutions can be
compared. If we can upgrade the system from old to new by changing its parts, then it would be the
best options. We can save our lots of money by legacy systems upgrade. For example, we want a
new feature in the software of insurance company with new policy, offers, rules, etc. For this
purpose, if we upgrade the old software by upgrading the policy, offers, features, etc. rather than
developing the new software then it helps to save our lots of money as well as time. We can get a
better application in low budget and less time. Thus, legacy system upgrade is very important for
everyone.
Elimination of human errors
Human error means that something has been done that was "not intended by the actor; not desired by
a set of rules or an external observer; or that led the task or system outside its acceptable limits".
Examples of human errors:
1. Wrong Input in the Application
2. Wrong syntax in code level
3. Forgot to test the developed features in QA/Test Environment
1. Lack of knowledge. Software defects are introduced when one omits

related knowledge, or even does not realize related
knowledge is required. This error mode is prone to
appear especially when the problem is an
interdisciplinary problem.
2. Post completion error. The pattern of “post completion error” is that if the
ultimate goal is decomposed into several sub goals,

48
a sub goal is likely to be omitted under such

conditions: the sub goal is not a necessary condition
for the achievement of its corresponding
superordinate goal; the sub goal is to be carried out
at the end of the task.
3. Problem representation error Misunderstand task representation material and

simulate wrong situation model of the problem, due
to the ambiguity of the material.
Report on project Components of a feasibility report

49
Submitted To: CEO of an Insurance Company
Components of a feasibility report
Executive Summary:
This report provides an overview of initial project data, which is a description of products and
services, and an overview of the content included in the feasibility study.
INTRODUCTION

50
According to Wolfe (2017), a study aimed at determining the success of a project, taking into
account factors that affect the project, such as technology, law, and economic factors, is called a
feasibility study. It is It helps to outline issues that identify potential positive and negative outcomes
of a project and serves as an important management point that must be passed before investing much
time and money. In other words, the feasibility study is the feasibility of this idea.
Structure of Feasibility report:
A good feasibility study can help you objectively determine whether a proposed project is feasible or
useful to continue. After studying many examples of feasibility studies on the Internet and learning
how to prepare for a better feasibility study, we decided to include these key points in the feasibility
study discuss below:
Components of a Feasibility Study:
A feasibility study covers wide variety of topics that might have an impact on a new venture which
are also known as Feasibility criteria. There are different types of feasibility criteria that a feasibility
study examines which are described below:
There are many components of the feasibility reports which are given below: -
1. Introduction
2. Purpose
3. Methodologies
4. Background history
5. Document structure
6. Intended audience
7. Feasibility criteria
8. Outcome
9. Possible alternate solutions
10. Evaluation criteria
11. Feasible solution
12. Conclusion and recommendation

51
Introduction
It is the first components of the feasibility reports. We should always include introduction of the
project of which we check feasibility and make feasibility report. In this stage, there should be
explanation about the project and criteria which are used to check their feasibility. For example, if we
want to check the feasibility of the software based on insurance company then firstly we have to give
some introduction about software and the facilities which are used in the software. It helps in
development of the software effectively.
Purpose
After the introduction, the purpose of doing the project should be clearly explained. It explains
developer about all the features to be included in the project. It also includes the main reason of
developing doing the project. For example, if we want to develop the software based on the
insurance company then we have to example the purpose of developing that software. We have to
explain all the necessity and facilities available in the software due to which it would be beneficial
for insurance company.
Methodologies
Methodologies is the third components of the feasibility report. After explaining the purpose of
project, we have to find out or explain the methodologies of doing project. There are different
methodologies of doing projects according to their nature. For example, while developing the
software for the insurance company, we can choose one method among different methodologies like
waterfall mode, spiral model, prototype methodology, etc. according to the nature of the application.
We have to choose any one of these according to the nature of the application which can bring best
output after using. It plays a vital role to develop a best as well as worst application. If we choose the
method suitable for the application, then it can make the application very effective. In the same way,
if we choose method which is not suitable for the application then it can make the useless
application. Thus. Methodologies plays a vital role for an effective development of an application.
Background history
Background history is the another very important components of a feasibility report. While
developing an application, we should collect the background history of the company so that it would
be easy to develop an application and we can include every features which is required in a software.
For example, before developing an application of insurance company, we should collect each and
every information including background history related to the insurance company so that we can
know what features are important for the software and what features are not important. We can also

52
include a note about company including establish date, board of directors, manager, etc. from
beginning to till date if we know the background history of the company. Thus, a developer must
collect the background history for the development of better and effective application successfully.
Document structure
As we know document structure describes the organization of a document into graphical constituents
like sections, paragraphs, sentences, bulleted lists and figures. It is the most important components of
feasibility report. While working on the project, we should always keep in mind to have well-
structured document. It helps to complete the project effectively in the given time. For example,
while developing the software for the insurance company, a well-structured document should be
made so that there would not be any problem while developing a software.
Intended audience
Intended audience can be defined as the group of people for whom a service or product is designed.
A project should be complete in such a way that give best service to the client and satisfy them. If the
project is done without the satisfaction of client, then it would be just useless project. For example,
while developing the insurance company software, we should know that needs and demands of the
client in the software. We should research their satisfaction so that we can provide best service to the
clients. After that we can develop the best software which holds the entire services needed to the
clients of insurance company.
Feasibility criteria
Feasibility criteria plays a vital role while develop any application. As we know, there are different
feasibility criteria like economic criteria, technical criteria, operational criteria and many more.
Economic feasibility is related to the cost which includes the entire expenses such as cost of
hardware, salary of man power, operating expenses, etc. The operational feasibility addresses how
solution would be fitted into the existing operation and the technical feasibility addresses how the
solution will be fitted into the existing structure. In short, it helps to find the problem in an
application and also helps to solve it. For example, while developing an application, we have to be
feasible from everywhere i.e. economic, technical and also operational. There should not be any
problem of money in the development of application, there should be high technical equipment and
man power and the operational of software should be always good. If there are these feasibility
criteria, then no one could stop us from developing the best application.

53
Outcome
When the project is finish, we should be aware about the outcome. There could be some errors and
faults in the completed project in many case. It could bring lots of problem for the developer if he
does not solve the problem immediately. For example, if there is error while depositing money from
bank to insurance company from the software then there may be loss of money due to that software.
If such problem occur, then there would be very negative impression of software in front of the
clients. Thus, a developer must be aware about the outcome of the project.
Possible alternate solutions

If some errors or faults occurs in the outcome of the project, then there should be alternate solution to
solve that problem immediately. A developer must have different alternate solution so that he can
find and solve the problem in very less possible time. This would help developer to make the good
impression of software in front of clients. Possible alternate solution helps to increase the efficiency
of the developers and also software. It is also one of the most important components of the feasibility
report.
Evaluation criteria
Evaluation criteria can be defined as a standard measures established to evaluate the degree to which
an alternative solution, proposals, or individuals are able to meet expectations or objectives through
direct comparisons of their strength, weaknesses and trade-off. It is a benchmark or yardstick against
which accomplishment, conformance, performance and suitability of an individual, alternative,
product as well as risk reward ratio is measured. The evaluation criteria also play a vital role in a
development of an application. It helps to measure the risk or problem and bring the alternative
solutions of a problem and also helps to know the strength and weakness of the developing
application. Thus, evaluation criteria is one of the most important purpose of feasibility report.
Feasible solution
If there is some bugs or errors in the development of an application, then the developer always looks
for the feasible solution. The solutions for the problem should be always long lasting which do not
create any big problems in the future. In most of the case, developers solve problem for the
temporary period thinking that they will work on it later. But later it brings very big problem in an
application and the developer becomes unable to complete an application. To avoid such thing, we
should always look for the feasible solution which solves the problem completely and there would
not be any difficulties in the future.

54
Conclusion and recommendations

The last and important purpose of the feasibility report is conclusion and recommendations. We
should always include some recommendations and suggestion after the completion of an application
as a conclusion. It helps users to use the application effectively. They can know the features available
in an application and also how to use that application. If some error occurs in the future or at the time
of updating too, we get lots of help with recommendations at the conclusion. It plays a vital role to
develop an application successfully.

55
Part 3
Report on project management plan and schedule

56
Submitted To: CEO of an Insurance Company
Part 3
Current System
Identification of Requirements
Identification of Stakeholders Requirements
Identify the requirements of the client
Specification of scopes

57
Inputs, outputs, processes and the process descriptors
Consideration of alternative solutions
Security considerations
Use of quality assurance
Identification of different constraints
3.2 Background information
Problem statements
Data collection process
Interview
Questionnaire
Observation
Use appropriate software analysis tools/techniques to carry out a software investigation and
create supporting documentation.
Introduction
Data Flow Diagram (DFD):
Building block of DFD:
Data flow diagram Level 0
Context Diagram
Entity Relationship Diagram
Conclusion
M3 Analyze how software requirement can be traced throughout the software lifecycle.
Jira
Jira is our main source of information
Jira helps me organize my documentation tasks
Jira helps us track the progress of our documentation

58
Jira helps us to meet our documentation release deadlines
Jira helps us measure the time spent on documentation
Jira helps me get feedback fast
Trello
GitHub
Advantages of GitHub
Prototyping
Low fidelity prototype
Medium fidelity prototype
High fidelity prototype
M4 Discuss two approaches to improve software quality.
Employ test-oriented software development management
1. Test-driven development
Benefits of test driven development
Pair programming
Benefits of pair programming
Report bugs effectively
i. Communication basis
ii. Provide solutions if possible
iii. Reproduce a bug before reporting it
iv. Clarity
Part 3
Executive summary
This section should discuss software research to meet business needs, use appropriate software
analysis tools / methods for software research, and create support documentation. You must also
determine constraints such as cost, organizational strategy, legacy systems, and hardware
requirements. We also discussed the appropriate software analysis tools / methods for conducting

59
software surveys and creating support documentation. At last I also discuss about the software
requirements that can be traced throughout the software lifecycle.
Introduction:
The insurer has a traditional system software that manages the financial records of customers and
members and currently the system deals with various documents issued while maintaining and
updating the official online requirements. And as mentioned in the scenario, we are forced to design
and develop a simple and intuitive system, a software designed to meet the needs of the company.
The purpose of the system review is to identify the problems and opportunities of the existing
system, determine the scope of the project by assessing the complexity of the problem and the efforts
required to solve it, increasing user confidence by calming the problem. User analyst, who fully
understands the nature of the problem. It also helps to identify the risks and associated responses if a
solution is feasible or not. Therefore, in this task, I will study the system based on this
scenario.System analysis is a way to solve problems, such as investigating a broader system,
isolating components and determining their function, identifying goals, and creating systems and
procedures that can help you achieve them effectively. In short, this is a systematic approach that
uses various tools to clarify the goals of existing systems and develop new system specifications that
are easy for users to understand.
Current System
They use the department's traditional information system. This only manages and stores the
recording. The system is not digital. All employees have their own roles and responsibilities. For
non-digital systems, additional staff is required. In order to digitize the entire system, they felt they
needed software that could handle it. In this scenario, they also use traditional system models such as
Waterfall, but want to call the company to update the software and create new software with a
flexible model. Flexible mode is more flexible than other models.
Identification of Requirements
Reading the scenario and using various survey techniques such as interviews, study of current
documentation, observation, etc., I tried to identify the requirements of the stakeholders and the
specifications of the system requirements which I will discuss further:

60
Identification of Stakeholders Requirements

An actor is an individual, group, or organization that is interested in a project. Interesting parts of
portals designed and developed for insurance companies are general managers, employees and
customers. Auditors, developers, administrators, user product engineers, and members of each portal.
The needs collected by stakeholders (business units, workgroups, customers, users, communities, etc.)
are called stakeholder requirements. The stakeholders of the organization are:
1. Investors
An investor is a person who commits capital with the hope of receiving financial returns. They
utilize their money in order to gain profits or to provide an income during the retirement like
within an annuity. They typically generate returns by developing capital as either equity or debt
investments. In the insurance company too, there could be some investors who invest their
money at beginning for the development of company in order to gain profit in the future.
2. Board of directors
A board of directors is a team of people who are elected by a corporation’s shareholders to
represent the shareholders’ interests and ensure that the company’s management acts on their
behalf. The head of the board of directors can be called as the chairman or chairperson of the
board. The main purpose of the board of directors is to ensure the company’s prosperity by
collectively directly the company’s affairs. They are appointed to act on behalf of the
shareholders to run the day to day affairs of the business.
3. Employees
Employees are the person who is hired to provide services to a company on a regular basis in
exchange for compensation and who does not provide these services as part of an independent
business. An employee can be part-time or full-times whose main aim is to provide service to a
company by taking the salary. In every organization, there is important roles of employees for its
development. If the employees are hard-working and energetic then they can increase the
efficiency of a company in the very short time whereas if the employees are lazy then they can
decease the efficiency of an organization. So, the CEO of a company should always keep their
employees happy in order to develop the company.
4. Clients
Clients are the person who takes services from the company by paying some amount of money.
Without clients, there would be useless of having a company. In the case of insurance company,
there could be many clients who comes to do their life as well as their property insurance. They

61
pay certain amount of money yearly for the fix period of time and get some total of money in
returns. They are the most important person for the development of a insurance company. The
insurance company is developed more when there is many clients in a company.
5. Suppliers
A suppliers are the party who supplies goods and services to the clients. They can be
distinguished from a contractor or subcontractor, who commonly adds specialized input to
deliverables. A supplier can also be called as vendors or agents. In the insurance, there are some
agents who brings clients for the insurance company and gets come percentage of commissions
from the company. They are also important person for the development of a company.
Identify the requirements of the client

There are many requirement of the clients in the insurance company software which are given below:
1. Clients should able to see the present status of the company and different offers given by the
company from the system.
2. Clients should be able to see their due amount and also should be able to pay the due or premium
amount from the system.
3. There should be also facility of advance payment from the system.
4. Clients should be able to see their insurance starting date and also left time to get money from the
company.
5. Clients should be able to see their own status from the system even by staying in home.
Specification of scopes
Project scope can be defined as the part of project planning which involves determining and
documenting a list of specific project goals, features, tasks and ultimately costs. It is very important
to pin down the scope early in a project’s life cycle as it can greatly impact the schedule or cost of
the project down the track. It also defines the boundaries of a project, what features will be included
and implemented within this scope, what is the delivery dates and milestones need to be delivered as
well the required budget to deliver that scope. The people should be able to know the information of
their policy, buy and how to premium insurance guidelines through the help of internet.
Inputs, outputs, processes and the process descriptors

An input can be defined as the data and information which is send to a computer system for
processing whereas an output displays the results of that processing. A process is an instance of a
program which is running in a program whereas process descriptor is a set of information that
defines the status of resources allocated to a process. In a software of insurance company, the login is
62
the way to the framework which users, admins or agents enter their username/email and password to
access to the internal arrangement of the project. Admins can input the policy, offers, documents, etc.
to the software and users or agents can see the output from the software. I have shown the input,
output, process and process descriptor of the insurance company software in the table which are
given below:
S.N. Description Input Output Process Process descriptor

1. Premium Enter the Payment Checks the If the account details
payment receipt is policy holder and the bank
account details
shown in the name and the account along with
and amount of
registered id of code of the card card number are
money to pay by
software. provided by the match successfully
connecting to
company. then only the
any bank.
premium can be
paid otherwise it
would be
unsuccessful for
payment.
2. Currency Input the Show the Checks the rate If the foreign
exchange foreign currency amount which of foreign exchange detail is in
can be got by currency and the software then it
the foreign exchange it. shows the detailed
currency information
otherwise we have
to enter about the
currency detail in
the software.
Consideration of alternative solutions

Although there are many advantage of having insurance company software, there are also some of
the disadvantage due to which it is good to have alternative solutions rather than having the
insurance company software. It is need of lots of budget for the development of insurance company
software. Even we develop this software, it is not sure that the entire client will use this software.

63
Many clients are illiterate due to which they would not understand the functions of the software or
they would not be able to use the software. There would be need of some amount of money yearly
for the maintenance of the software. Due to such problems, it would not be much effective to use
insurance company software. In the alternative of this, we can use websites. In the website, we can
include all the policies and systems which are included in the software. It is very cheap then
developing the software. Also it supports in all the devices such as mobile, desktop, tablet, etc. and
everybody can learn it in very short period of time. We can also update the policies, rules or anything
in the websites and also information the latest offers to the clients. Thus, I think the best alternative
solution would be use of websites instead of developing a software.
Security considerations
Security can be defined as the defense of digital information or IT assets against internal and
external, malicious and accidental threats. It is very critical for enterprises and organization of all
sizes and in all industries. If there is weak security in the company then it compromised systems or
data, either by a malicious threat actor or an unintentional internet threat. For the best security of
insurance company software, we should not rely on a single test. We should test our software time to
time while developing. We should use the best server for proving the security to our software. Also
we should enforce the use of consistent coding standards, use automated testing tools, build and
share libraries for common tasks such as validating user input, add security related requirements and
test cases from the very beginning of the process, etc.
Use of quality assurance

We have applied the quality assurance while developing the software of insurance company. There is
proper user validation in the software. While requirement gathering, we check two times so that there
would not be mistake in the requirement gathering. To main the quality, we communicate among the
team member for the discussion almost every hour. We always discuss with the team members about
the new features or included features. We have followed best practice while coding in the software.
There is the use of every coding standard while development of a software. Also, we have regularly
test out software while in the developing process so that there would not be any problem in the
software when it is launch and used by the clients. We have not compromise in the quality
maintenance of the software. Thus, the quality assurance is applied in the software of insurance
company.
Identification of different constraints

A developer should face different constraints while developing a software which are given below:

64
1. Cost
As we know, cost is the most important things which be needed to be estimated while developing any
types of software either it is big or small. While developing the software of insurance company, there
was cost limitation of five lakhs. The software which we were going to develop was very big but it
had cost limitation of only five lakh rupees. Due to this, we have spent every money only after
planning and safely without wasting a single rupee and save some amount of money too. The cost
estimation while developing the software of insurance company is given below:
S.N Product/Services In NRs

1. Project manager 20000
2. System Analyst 50000
3. Senior Designer 60000
4. 2 trainer designer 25000*2
5. Senior Developer 60000
6. System Investigator 80000
7. Quality Assurance team 900000
8. Maintenance 40000
Total 450,000
In the above cost estimation table, I have shown the detail cost which was spent while developing
a software. We have not done any expenses on unnecessary things. Our main motive was to
complete the development of insurance company software successfully with the budget of Rs.
4,50,000 and in just three months. We have worked day/night to complete this software and
finally developed a successful software by saving some amount of money too.
2. Organizational policies
As we know that an organizational policy can be defined as a course or method of action selected,
usually by an organization, institution, university, society, etc. from among alternatives to guide and
determine present and future decisions and positions on matters of public interest or social concern.
Being a profitable business organization, the insurance company has its own policies which is
included in the software of insurance company. While developing an application, there should be
two-way communication between the developer and administrator in which the administrator
provides the important policy and other information about the company then the developer begins to
develop the software according to the policy of an organization. In the software of insurance
company, I have included the entire policy of the company according to the administrator of the

65
company. There low and policy in the software is exact as in the real life. The entire information’s,
laws and policies are properly documented in the software due to which there is not any limitation.
3. Legacy systems
A legacy system, in the context of computing, refers to outdated computer systems, programming
languages or application software that are used instead of available upgraded versions [ CITATION
Leg19 \l 1033 ]. While developing a software, we should make sure that it will run even in the old
system so that the software can be used by many people. The legacy system of the insurance
company software cannot be total replaced by the new software of insurance company because
some of function of such software should not be update. Some types of information like information
of clients, financial data of clients, etc. are very critical data which should be stored securely and
should not be affected while upgrading or maintaining the software. The legacy system us special
used because some data which are very critical might take years to get developed in a new system.
The advantages of legacy systems are given below:
i. It would not be problem while updating critical data in the legacy system.
ii. There would be less change of losing the important and critical information.
iii. It has low maintenance cost.
iv. There would be no problem in data storing technique.
4. Hardware requirements
While developing an application, the hardware requirement is a constraint because the

framework will work easily, if the hardware requirements support it. The smooth work of the
framework depends upon the hard which is used to help them. In the insurance company software
too, there are some hardware requirement to use the software which are given below:
For windows computers
 64-bit operating system is required.

 Compatible in Windows7, Windows 8, Windows 10 or so on.
 2GHz processor with Intel
 Hard Drive: Minimum 32 GB; Recommended 64 GB or more
 Minimum 4GB of RAM is required.

66
For Mac Computers
 An Intel Core 2 Duo, Core i3, Core i5, Core i7, or Xeon processor.
 Hard Drive: Minimum 32 GB; Recommended 64 GB or more
 2GB of ram
Background information
A big insurance company which is going to offer its products and services to many international
countries in tis drive to grow and become a large international company. This company is
predominantly operating in United Kingdom. The systems which has been using by this company to
keep track of customer enquiries about the information and buying of its products and services, etc.
will needed to be updated or a new system developed to reflect the changes in the way it will operate.
The company also will offer a much wider range of products and services to accommodate the needs
of the international market. Customers will be using a range of currencies to purchase the products
and the insurance company will need to allow for the fluctuating currency exchange rates in its new
system. The updated system insurance company should have facility of paying the premium from
home, paying the advance premium, clients can able to look the new policies and offers of the
insurance company form the system, clients should have facility of currency exchange in the system,
they can also evaluate their status in the company, etc. The old system of an insurance company
which were developed before couldn’t give the full services to more customer at one time. So the
new system that has been updated can give more services to more customer at the same time.
Problem statements
There was a problem and complain of the clients that they are facing difficulties to come in the
insurance company for every purpose like knowing new offers and policies, while paying the
premium, etc. They have to stay in the long line for hours and only get chance to pay the payment.
Considering such problems and complains of the users, we have developed the insurance company
software by which they can pay their premium easily, see the updated offers and policy, advance
payment of premium can be done and many more. Social, economic, and political systems in such
countries present are also serious problems to insurance companies. Even now, many people do not
know about the insurance company and the benefits of doing insurance of them and their entire
family. Thus, the insurance company have only limited clients.

67
Data collection process

Data collection is the process of gathering and measuring data, information or any variables of
interest in a standardized and established manner that enables the collector to answer or test
hypothesis and evaluate outcomes of the particular collection [ CITATION Dat19 \l 1033 ]. It is
concerned with the accurate acquisition of data, although methods may differ depending on the field,
the emphasis on ensuring accuracy remains the same. It is a component of research in all fields of
study including physical and social sciences, humanities and business. The main goal of data
collection is to capture quality evidence that allows analysis to lead to the formulation of convincing
and credible answers to the questions that have been posed. Before developing insurance company
software, I have collected data properly which helped to complete the software successfully. I have
used difference process for collecting of data which are given below:
Interview
An interview can be defined as a conservation between two or more people where question is asked
to a person to get the required responses or answers. In an interview, the person asking questions is
called as interviewer and the person answering the questions is called as interviewee. This is the most
important and effective process of collection of data. While developing a software of insurance
company, firstly I have taken interview with some selected clients, staff, manager and board of
directors. I have asked different question like what features they want in the software, the
requirements in the software, etc. I have collected lots of different and unique requirements form
board of directors, managers, staffs and clients which helped me while developing a software
effectively and successfully.
Questionnaire
Questionnaire can be defined as a research instrument consisting of a series of questions for the
purpose of gathering information from respondents. The biggest advantage of questionnaire over
some other data collection process is that they are cheap, do not requires as much effort as in the
interview or other process and it often have standardized answers that make it simple to compile
data. For collection of more data from rest of the staffs and clients, I have made questionnaire with
some important questions and send to staffs and some clients so they I can know their view or their
suggestions that can be included in the software. After some days, most of the questionnaire were

68
returned after filling it properly. I have got some new features and requirement which were not found
in the interview and also I have included that features in the software of insurance company.
Observation
Observation can be defined as the act of noticing something or a judgement or inference from
something seen or experienced. A person can learn or improve many things by observing other
properly. After interview and questionnaire, I began to observe the company for some day so that I
can add new features myself in the software. I used to go daily in the company and also done my
insurance so that I can think as a client of the company and observe properly. After some days, I have
got some new features which was liked by manager and also board of directors too. Thus,
observation plays a vital role for collection of data and information.
Use appropriate software analysis tools/techniques to carry out a software

investigation and create supporting documentation.
Introduction
System analysis is the problem-solving method that involves looking at the wider system, breaking
apart the parts and figuring out how it works in order to identify its goals and create systems and
procedures that will help to achieve those goals in an efficient way. In other words, it is a systematic
approach, which uses various tools to refine the objectives of an existing system and develop a new
system specification which can be easily understandable by the user.
Advantages of System Analysis are listed below:
 It offers assistance to learn and use new systems, reduced by somebody else and also helps in
minimizing errors while problem solving.
 In order to reduce risks or decrease the chances of a project being a failure while
implementing a new system, system analysis is crucial as it helps to give thorough knowledge
on how a system works and what procedures can be follow to bring more efficient output
from a system.

69
 As we all know the better understanding of a system, the less likely we are to encounter any
unexpected problems. Thus, system analysis leads to fewer mistakes while developing a
solution for a problem.
System analysis can be done using various tools and techniques such as context diagram, use case
diagram, data flow diagram, entity relationship diagram, etc. In this task, I will use appropriate
system analysis tools and techniques to carry out the investigation of system of the company.
Data Flow Diagram (DFD):

A picture is worth a thousand words. A data flow diagram (DFD) is the simplest form of a traditional
visual representation of information flow in a system. Simple and clear DFD can graphically depict
many system requirements. Shows how data flow occurs in the system, but in situations where DFD
focuses only on some important details, data flow does not occur.
Building block of DFD:

Some of the most important diagram notation of Data Flow Diagram are described below:
Process: A business activity or function where the manipulation and transformation of data takes
place.
External Entity: An external entity can represent a human, system or subsystem. It is where certain
data comes from or goes to.
Data Store: A data store represents the storage of persistent data required and/or produced by the
process.
Data Flow: A data flow represents the flow of the information. The arrows indicate the direction of
data flow from beginning to the ends.

Level 0 data flow diagram which is also known as context diagram are the most basic data flow
diagrams which provide a broad view that is easily digestible but offers little detail. It shows a
single process node and its connections to external entities. This is only one process in the system
and all the data flows either into or out of this process. While drawing level 0 data flow diagram,
firstly we have to identify the process, all the external entities and all the data flows. We also

70
have to state any assumptions we make about the systems. It is very important to draw level 0
data flow diagram before making rest of two levels of data flow diagram.

Level 1 data flow diagrams are still a general overview but they go into more detail than a
context diagram. The single process node from the level 1 data flow diagram is broken down into
sub processes in this data flow diagram. As these processes are added, this level of data flow
diagram needs additional data flow and data stores to link them together. The main aims of this
diagram is to give an overview of the full system. While drawing a level 1 data flow diagram,
firstly we have to start by examining the level 0 data flow diagram. In this level too, all entities,
data stores and processes must be labelled properly.

Level 2 data flow diagram breaks processes down into more detailed sub processes. It offers a
more detailed look at the processes that make up an information system than a level 1 data flow
diagram does. A level 2 data flow diagram can be used to plan or record the specific makeup of a
system. It is detailed enough that it doesn’t usually make sense to break them down further.
The insurance company system divides each visitor into three types. That is, unauthenticated users
who are not logged in, administrators, and regular users who are logged in but do not have
administrator privileges. Unauthenticated users can browse the system and view all published
content, such as webinars and blogs. If you need more features, such as creating your own blog or
commenting on other people's posts, you can log in to the system If you are an administrator, you
can manage and manage user and group data records and permissions. All information is stored in
the database and retrieved from the database after a database query.
The Data flow diagram which I have made of insurance company is illustrated in the figure shown
below:

71
Figure 1 Data flow diagram of insurance company
Context Diagram
Context Diagram is a common tool that Business Analyst use which shows the boundary between the
systems, or part of a system demonstrating the entities that interact with it under consideration as a
single high process (Adams, 2015). Also, it shows how the system will receive and send data flows
to the external entities involved. A context diagram assists in understanding the entire system by one
data flow diagram which gives the overview of the system. Context Diagram were created for system
analysis and design but, like many other tools they have been leveraged for other multiple purposes.
Some of the major advantages of Context Diagram are listed below:

72
 Demonstrates the scopes and boundaries of the system on a quick peek comprising the other
system that interfaces with it.
 Even with zero technical knowledge everybody can get the idea.
 Easy and simple to make changes.
 Because of its different levels of DFDs it is quite easy to expand.
Different entities are administrators, staff writers, community users and normal non-authenticated
users who just come to see some stuffs or gather some info. Clients ask for info and as per requested
software system of company display the requested information. Staffs and administrators manages
data and other material for stakeholders and make changes every time they perform financial tasks.
Entity Relationship Diagram

As stated by Lucidchart.com (2017), An Entity Relationship (ER) diagram is a visual representation
that illustrates different entities such as people, objects and how they relate to each other. Peter Chen
is credited with introducing the widely adopted ER model in his paper entitled “The Entity-
Relationship Model” (Creately.com, 2017). Different symbols such as rectangles, eclipse, diamonds,

73
connecting lines, etc. is used to portray the interconnectedness of entities, relationships among those
entities and their attributes.
The Entity Relationship Diagram which I have made of an insurance company is illustrated in
the figure shown below:

74
In above task, I had use various system analysis tools and techniques such as context diagram, use
case diagram, DFDs, process representation, etc. to carry out a system investigation. In this task, I
will evaluate, draw and justify the conclusions of the arguments or ideas presented.
As said earlier, system investigation is done in order to identify the problems and opportunities in the
existing system, determine the scope of the project by evaluating the complexity of the problem and
effort required to complete it, boost up user confidence by reassuring user analyst fully understands
the nature of the problem.
Often, the amount of information is so overwhelming that it’s difficult to make sense of it at all. Yes,
details are crucial and being extremely detailed-oriented helps to win the battles, but it may yet cause
system analyst to lose the war, by neglecting the important items. This is where system analysis tools
and techniques that I have used comes very handy and will save a project from very offensive
surprises. Ironically, all the tools and techniques that I have used can be done on very minimal
amount of time and money, yet they can prevent many hours of frustrating interactions that
inevitably follow the discovery of a large item that was neglected.
All those tools and techniques have been used to represent the traditional visual representation of the
system. As we all know, “A picture is worth a thousand words” and like all the best diagrams and
charts, diagrams used in system analysis tools and techniques can often visually say things that
would be hard to explain in words, and they work for both technical and nontechnical audience, from
developers to CEO.
DFDs have been used while analysis tools and techniques to carry out system investigation as it
shows how data flows occurs in a system but, doesn’t show when it occurs, under which
circumstances as DFD focuses only on a few important details. Context Diagram is a common tool
that Business Analyst use which shows the boundary between the systems, or part of a system
demonstrating the entities that interact with it under consideration as a single high process. Also, it
shows how the system will receive and send data flows to the external entities involved.
On the other hand, the Context Diagram shows the system under consideration as a single high-level
process and then shows the relationship that the system has with other external entities (systems,
organizational groups, external data stores, etc. Another name for a Context Diagram is a Context-
Level Data-Flow Diagram or a Level-0 Data Flow Diagram. Since a Context Diagram is a
specialized version of Data-Flow Diagram, understanding a bit about Data-Flow Diagrams can be

75
helpful. A context diagram assists in understanding the entire system by one data flow diagram which
gives the overview of the system.
Entity-Relationship diagrams (ERD) is used in structured analysis and conceptual modeling. While
carrying out system investigation, ERD is used to graphically illustrate different entities such as
people, objects and how they relate to each other.
Conclusion
Each diagram shows a different aspect of some complex system. Any system of sufficient complexity
can be derived from different diagrams. System Analyst must realize that to successfully analysis the
systems, they need to understand the main information they got from each diagramming tool. One
diagramming tool may not enough for analyzing the system and they may require using multiple
diagrams. Also, it is important to remember that diagrams are documentations. It is a means of
communication between groups of human beings and needs to be understandable to both senders and
receivers.
In conclusion, I have evaluated, drawn and justified the conclusions of the arguments or ideas
presented. Some or all of these techniques may be used in the investigation of the existing system or
to investigate a new system, and will result in a set of data flow diagrams representing the current
system, a logical data structure of the current system's data, and the initial problems/requirements list
for the project. These tools and techniques has assists me a lot to evaluate the whole system in very
easier way.
Excellent software quality will enable cost effectiveness and superior performance to deliver your
projects.
Finding ways to implement effective testing strategies at the earliest possible stage will help you
detect and solve defects. Solving problems at the earliest stage of project management creates a win-
win scenario. Increased efficiency results in better quality software and reduced costs. Conversely,
poor software quality exacerbates problems and can become a time-consuming and expensive
exercise.

76
Analyze how software requirement can be traced throughout the software

lifecycle.
Requirements tracing is the process of recording logical links between individual requirements and
other system elements [ CITATION How19 \l 1033 ]. In short, requirement tracing is one of the
processes in requirements management, controlling, tracing, prioritizing, analyzing and also
documenting. It is about understanding how high-level requirements i.e. goals, aims, objectives,
expectations, needs, aspirations, etc. are transformed into low-level requirements. Good
traceability practices allow for bidirectional traceability, meaning that the
traceability chains can be traced in both the forwards and backwards
directions as illustrated below.
The main motive of requirement tracing is to assure that the requirements continue to meet the needs
and expectations of its customers and stakeholders. We can trace a single functional requirement
backward to its origin, such as a use case, product feature or business rule. Also, we can trace that
functional requirement forward into the bits of design, code and tests that were created because of
that requirement. The analyst must write requirements in a fine-grained fashion and give every
requirement a unique and stable identifier in order to do requirements traceability. Most of the people
starts doing traceability by linking the functional requirements to an individual test which verify the

77
correct implementation of those requirements. The requirement tracing is specially done for
management of solution scope, quick evaluation of potential changes, reduction of project risk,
promoting consistency between requirements, allowing monitoring and controlling across the
lifecycle of requirements, etc. The requirement tracing provides benefits in two key areas which are
given below:
1. It provides context for the development team. Also, it defines the expectations of the testing
team to help implementation and specification.
2. It helps to ensure that the team is not only for building the product rights, but are also for
building the right product.
The importance of the requirements tracing are given below:
1. It complies with established industry standards.

2. It ensures that final deliverables directly tie to initial business needs.
3. Done properly, it ensures that organizations do not waste time and resources repeating research.
4. It also offers much easier impact analysis.
Establishing traceability correctly gives a timely view of the current state of the ‘Solution under
development’ and thereby helps Architect assess the stability of the Solution and help provide inputs
to the stakeholders of the Solution in terms of triple constraints viz., Resource, Schedule, and Scope.
One of the daily activities during the SDLC is to generate a report of the forward traceability and
backwards traceability of the Project. The adopted tool should support providing the report to
facilitate an understanding of the current state of the Project.
Jira
Jira is an issue-tracking tool that's mainly used by software developers to track, organize, and
prioritize bugs, new features, and improvements for certain software releases. Here at K15t
Software, we carefully organize the development process for every Scroll add-on. We have
multiple projects for each of our add-ons, and every project is sub-divided into 'issues'. These
issues can be of multiple types, for example:
 New Feature
 Improvement
 Bug
 Documentation tasks.

78
When the release date for a new piece of software draws near, our developers become
increasingly stressed as all remaining issues must be fixed before the specified date. It's the
same when it comes to documentation. As I work with a team of software developers, my life
also becomes extremely hectic as we approach the release date. Even when the big day is just
around the corner, the status of the documentation is often unclear, as it's hard to keep track
of everything.
Jira is our main source of information

Jira is a great source of information about the next release. When planning a new software
version, the whole product management team gets together to agree on the new features to be
implemented and the bugs to be fixed in the next release. Later, when we are writing the
documentation, we can check the status of each feature in Jira, and plan what we need to
document for which version. This is really useful – because while our developers might
forget to inform us about a new feature, they certainly won’t forget to track the feature in Jira.
The result: no more missing features in the documentation! Perfect.
Jira helps me organize my documentation tasks

Jira supports agile software development. And by using Jira, we can benefit from this agile
environment, too. Multiple tasks can be grouped together by assigning a version and due
date. This even enables us to deliver documentation for milestone releases, simply by linking
my tasks to the corresponding version. We guarantee our developer buddies will be delighted
if our work with the same tool, and get used to their work flows when releasing new versions.
What’s more, we can group my documentation tasks using the component functionality, and
we can create my own documentation epics. This brings us another step closer to a more
structured method of working.
Jira helps us track the progress of our documentation

Jira is also my source of information when we are checking the progress of the
documentation. Open tasks can be tracked within a single view, using one of the numerous
reporting features. Open documentation tasks are clearly visualized – and we can see at a
glance exactly how much work still needs to be done for each new version. And managers
like that, too

79
Jira helps us to meet our documentation release deadlines
We can define a specific due date, or deadline, for each documentation task. And of course,
we can configure Jira to give me notifications, to make sure we finish my work in good time.
This helps me meet deadlines for new product releases. No more waiting for documentation
to be finished – and no more releases without full documentation.
Jira helps us measure the time spent on documentation
With this useful add-on, I can measure exactly how much time I needed for each new release.
Moreover, it lets me track how long I spent on every single documentation task. This is great
when checking and reporting my work internally, and extremely practical when working for a
customer who requires an exact breakdown of the time spent on each task
Jira helps me get feedback fast

As we still write our documentation in Confluence, I can connect issues to the relevant
Confluence pages in just a few clicks. And – even better – if I find some information that
needs updating, I can simply create new issues directly from within Confluence. This not
only helps me in my own line of work, it’s also a highly effective way to obtain feedback
from my colleagues. They can highlight the relevant section of text and create a new Jira
documentation task with a single click. Feedback made simple.
Trello
Trello is a task management app that gives you a visual overview of what is being worked on
and who is working on it. It used the Kanban system, which was developed in Toyota as a
system to keep production levels high and maintain flexibility. It is best represented as a
whiteboard filled our admin and management board is fairly straightforward. Each team
member has three lists. We can assign cards to ourselves or to each other as well as converse
about issues involved in any of those tasks.
 To do list – Cards are placed here to assign new tasks

 Doing – The tasks that the person is currently working on.
 Done list – Completed tasks, archived at the end of each month.

80
It advantages are:
 We can use trello on about any size of screen. Its interface is much more different
from other services. Trelllo looks like an App, not a site.
 Real time updates is amazingly fast! Almost right away!
 A board for a project and you can see all the items on one page.
 Creating issues and assigned someone to those issues are simple and easy.
 Adding new member is easy. You can not only add existing user to your board but
also invite new users by type in emails.
Trello likes to keep things simple and only maintain one internal board, so there is only
one place to keep track of things.
 Incoming Bugs – The collect bug reports from twitter, email or something that
employees identify.
 Bugs for this week – The top priority bugs move to this list to be fixed as quickly
as possible.
 Planning – This list is for new features that need addition planning, research or
general figuring out how it will work.
 Doing – Bugs or features devs are currently working on.
 Waiting for test/review – Features and bugs awaiting code testing and QA.
 Ready for merge – These are moved to a staging server and tested to see if it works
well live or causes problems elsewhere in the app.
 Unshippable – If a new bug is discovered that makes the card unfit for release.
GitHub
GitHub, can be divided into the Git, and the Hub. The service includes access controls as well as a
number of collaboration features like tools for basic task management and for all projects you
handle. GitHub hosts your source code projects in a variety of different programming languages and
keeps track of the various changes made to every iteration. So, the “Git” implies the version control
system; a tool which allows developers to keep track of the constant revisions to their code. The
“Hub” is the community of like-minded individuals who participate. It is all about the collaborative
81
effort of the community, in reviewing, improving, and deriving new ideas from the uploaded code.
It’s definitely something worth looking into!
Advantages of GitHub
1. It makes easy to contribute to your open source projects

To be honest, nearly every open-source project uses GitHub to manage their project. Using GitHub is
free if your project is open source and includes a wiki and issue tracker that makes it easy to include
more in-depth documentation and get feedback about your project. If you want to contribute, you just
fork a project, make your changes and then send them a pull request using GitHub web interface.
2. Documentation
By using GitHub, you make it easier to get excellent documentation. Their help section and guides
have articles for nearly any topic related to git that you can think of.
3. Showcase your work

Are you a developer and wishes to attract recruiters? GitHub is the best tool you can rely on for this.
Today, when searching for new recruits for their project, most companies look into the GitHub
profiles. If your profile is available, you will have a higher chance of being recruited even if you are
not from a great university or college.
Prototyping
Prototyping refers to the early stage of software development, the core of prototyping is to test the
product and usually used for demonstration, testing, communication and so on.
Stages of prototype
Low fidelity prototype
To performance the key functions of the software and the basic interaction process, what’s more, it’s
easy to modify, fast to prototype and the production costs are lower than other prototypes.
Medium fidelity prototype
Medium fidelity prototype adds more details and the interaction is closer to the final product. In most
cases, medium fidelity prototype is enough for the user to fully experience the final product, you

82
can test the usability of the product and ensure that the major problems can’t be found in the
following development process.
High fidelity prototype
It’s the prototype that most close to the final product. rich in detail, including all the features of the
product and interaction. Making high-fidelity prototypes can significantly reduce communication
costs. And prototyping is more accurate and exquisite. However, the high fidelity means that you
need to spend more time and development effort, and it will be more time-consuming when you need
to make some adjustments.
Advantages of prototype
 Test the usability of the product to find problems
 Easy to communicate with users, leaders and other relevant people
 Improve the efficiency of product design
Discuss two approaches to improve software quality.
Many research has been done to identify the root cause of poor software quality. There are
many reasons found due to which the software has poor quality. While developing a software,
small mistakes can also lead big problem and also leads to large financial losses. Due to this,
we should be always careful while developing a software and always should follow the best
practices to improve the software quality. There are also many approaches to improve the
software quality. Among them, the best two approaches to improve the software quality are
given below:
Employ test-oriented software development management
Implementation of test-oriented software development management is one of the best approach

to improve the software quality. We can achieve the test oriented management by using an
extreme programming. An extreme programming can be defined as a software development
methodology which aims to produce higher quality software with the ability to adapt to
changing requirements. If we use extreme programming for implementing test-oriented
software development management then the quality of our software would be highly improved.

83
An entremets programming has main motive to provide iterative and frequent small releases
throughout the project by allowing both team members and customers to examine and review
the project’s progress throughout the entire software development lifecycle. It is intended to
improve the quality of software and also responsiveness to changing customer requirements.
The extreme programming practices are given below:
1. Test-driven development
Test driven development is a process of software development which relies on the repetition of
a very short development cycle i.e. firstly the developer of software writes an automated test
case which defines a desired improvement or new function, after that the developer produces
the minimum amount of code to pass that test and finally refactors the new code to acceptable
standards. It is related to the test- first programming evolved as part of extreme programming
concepts. The test-driven development process example is given below:
As seen in the figure, in the test driven development, firstly it adds a test. After that there
is a process of executing the test. If the execution of test is passed, it returns to the first
process i.e. add to test otherwise there would be need of making changes to the code.

84
After making changing in the code, it executes the test. If the execution of test is
successful, then test driven development is successfully executed otherwise it returns to
the third process i.e. make changes to the code. Thus, this is the process of test driven
development.
Benefits of test driven development

There are many benefits of test driven development which are given below:
a. There would be near zero defects from this process.
b. Tests become safety net.
c. Optimization of development costs.
d. Positive effects on productivity.
Pair programming
In the pair programming approach, it requires two engineers working in tandem at a single
computer in which one of them writes a code and another watches and makes suggestions
through the process. Such roles can be swapped at any time in this approach. Ideally, the two
engineer would be equally skilled and would each have time at the keyboard. If there is
necessary, the two engineer brainstorm on any challenging problem. They periodically switch
roles and work together an equals to develop a software. Pair programming plays a vital role for
improving the software quality. The following figure can describe the pair programming more
effectively:

85
Benefits of pair programming

There are many benefits of pair programming which are given below:
a. Better knowledge sharing among team members
b. People learn significantly more about the system and about software development.
c. The designs are better and code length shorter.
d. The projects end up with multiple people understanding each piece of the system.
e. There would be high code quality.
Report bugs effectively

A bugs can be defined as a coding error or issue in an application. It can be find out at any
stage during software development lifecycle. Reporting of bugs effectively also plays a vital
role to improve software quality. A good bug report will help while testing a software more
effectively by clearly identifying the problem and in this manner navigating the developer
towards solving it. If the bug report is bad then it can bring the serious misunderstandings.
There are some good guidelines for an effective bug report which are given below:
Communication basis
A bug report should be cornerstone and an efficient form of communication between a QA

specialist and developer. If there is good communication between a DA specialist and developer
while making a bug report, then there would not be any misunderstanding and the bugs would
be detecting very clearly from the application. Thus, it would be very easy for a developer
while solving a bugs from an application.
Provide solutions if possible
While making the bugs reports, there should be clear explanation of bugs detected in an
application and also should provide solutions for them like describing the needed behavior of
the feature. It there is such thing in the document, a developer can know easily the bugs in an

86
application and also a solution in case if he needed. Thus, it has to solve the bugs effectively
and improve the software quality.
Reproduce a bug before reporting it
We should always make sure that bugs are reproducible before reporting it. We should include a
clear instruction of how to reproduce a bug step by step without any confusion. We should
always be sure that the context is specified and also we should avoid the information that can
be interpreted differently. It also plays a vital role while improving the software quality.
Clarity
While making the bug reports, we should be sure that the report is clear which can be
understand by every person otherwise it would be useless of making the bug report. It should be
clear enough which can help developers to understand the failure and also should include
information about what QAs see and a statement of what they expect to see instead of bugs.
There should be clear documentation of what went wrong in the code of an application.
Conclusion
In this part, I have firstly explained about stakeholders. It is a party that has an interest in a company
and can either affect or be affected by the business. Also, I have explained different stakeholders
which includes BOD, clients, investors. etc. After that I have wrote the different requirement of the
clients in the software of insurance company and describe the specification of scope. Project scope
can be defined as the part of project planning which involves determining and documenting a list of
specific project goals, features, tasks and ultimately costs. Also, I have described the input, output,
process and process descriptor. In the same way, I have explained consideration of alternative
solution, security consideration, use of quality assurance, identification of different constraints which
includes cost, organizational policy, legacy system and hardware components, Background
information and also problem statement. After that I have explain the data collection process. It is the
process of gathering and measuring data, information or any variables of interest in a standardized
and established manner that enables the collector to answer or test hypothesis and evaluate outcomes

87
of the particular collection. The different types of data collection process are interview, observation,
questionnaire, etc. In the same way, I have explained entity relationship diagram and data flow
diagram including the data flow diagram and entity relationship diagram of insurance company
software. Also, I have written the summary where I have explained everything have done until now.
After that I have explain the requirement tracing by showing the example of how requirement is
traced in the login page of insurance company software. I have also explained the two approach by
which we can improve the quality of the software and finally I have described about how the use of
the function design paradigm in the software development lifecycle can improve the software
quality.The isystem ireview ialso ihelped ito iidentify ithe iproblems iand iopportunities iof ian
iexisting isystem, idetermining ithe iscope iof ia iproject iby iassessing ithe icomplexity iof ithe
iproblem iand ithe iefforts ineeded ito isolve iit, iimproving iuser iconfidence iby ireassuring iusers
ithat ithey iunderstand iit. ianalyst ihas ifully iunderstood ithe inature iof ithe iproblem. iHe ialso
ihelped iidentify ithe iassociated irisk iand iwhether ithe isolution iwas ifeasible ior inot. iSo, ias ia
iresult iof ithis iinvestigation, iI icame ito ithe iconclusion ithat ithis inew isystem iis, iin ithe icurrent
isituation, ia ivery ilarge ineed ifor ian iinsurance iorganization.

88
Part 4
Introduction
In this part, firstly we have to prepare a documentation that explains how user and software
requirements have been addressed. You should also create a table that contains the expected customer
requirements and actual results that show the products that will be developed after the appropriate
analysis. You will then need to explain the different ways to specify the software, suggest two ways
to specify the behavior of the software, and illustrate its use with examples related to projects that
need to be built in a particular context. We should also include flowcharts, pseudo code and formal
specification methods. After that we should differentiate between a finite state machine and an
extended finite state providing an application for both. Finally, we have to present a justification of
how data driven software can improve the reliability and effectiveness of the software.
Documentation of user and system requirements
I know that a document can be defined as a set of documents presented on paper, Internet, digital,
digital, or analog media (audio tape, CD, etc.). Examples of documentation include user manuals,
online help, technical documentation, and can be distributed through websites, software products,
and other online applications. When developing applications, you must carefully observe the system
and system requirements. You must make sure that all user and system requirements are implemented
correctly. It plays an important role in successfully completing applications and satisfying customers.
User Requirements

89
To achieve basic business needs, software projects should include tasks / activities that users must
complete. User requirements provide the scope and focus of this level project. In other words,
provide "what" to the software project. User requirements are related to the tasks that can be
completed and the expected results. For example, user requirements can determine the ability of
users to perform procurement process checks, record the results of these checks, send additional
validations or approvals, and generate reports based on metrics. User requirements may be
represented in many ways, depending on the software engineering methodologies employed and the
processes/tools used to capture, record and manage them. Among these representation frameworks
are use cases, user stories and event-response tables. A user story might be: “As a procurement
manager, I want to be able to “Approve” a procurement-process file review that has been referred to
me for a decision.” Software requirement management tools allow you to organize and group
requirements into documents to provide ready reference and use as a collaboration tool throughout
the life of the project.
Functional Requirements
The user-level experience may need to be described in terms of what the developer is supposed to
build. This task falls to functional requirements: they too provide the “what” information for the
software project, but in detailed terms relevant to a developer. For example, a functional
requirement might be: “The system shall require an approving manager to select one of three
approval decision options: Approve, Disapprove, Defer.” The primary audiences for functional
requirements are developers and testers. As a recommended good practice, each functional
requirement should be accompanied by a test case that can be used to unambiguously verify if
that requirement has been met.
Tabulation of the expected client requirements and the actual output of the product
S.N. Expected client requirements Actual output
1. Foreign currency exchange There is one special service for the user that
exchanging of the foreign currency can be
done all over the world.

90
2. Providing claims services Users can claim their share and property
through this software in an effective and easy
way.
3. Providing information of policies Every detailed policies of company such as

premium, compensations, advance payment,
etc. are properly explained.
4. Information in different languages Since customer could be from different

according to the client’s preferences countries, information is also provided in the
different languages.
The table above shows the expected customer needs and actual software results. As you develop your
application, you collect customer and user requirements, so the expected customer demand is almost
the same as the actual result. We created this app with all requirements in mind and fixed all bugs
after user and customer feedback. Users and customers need all the features and services of the
insurance company software, such as premiums, prepayment, ability to view current user status, new
policies and offers, and more. Therefore, all users and customers like this software.
Discuss about the different software specification methods and suggest two software
behavioral specification methods and illustrate their use with an example relevant to the
project that needs to be constructed for the given context.
Software specification
Software requirements specification establishes the basis for an agreement between customers and
contractors or suppliers on how the software product should function (in a market-driven project,
these roles may be played by the marketing and development divisions). Software requirements
specification is a rigorous assessment of requirements before the more specific system design stages,
and its goal is to reduce later redesign. It should also provide a realistic basis for estimating product

91
costs, risks, and schedules. Used appropriately, software requirements specifications can help prevent
software project failure. The software specification document lists sufficient and necessary
requirements for the project development. A software specification also leads benefits to client
because if the development cost is less, the developers will charge less amount to the clients. Some
of the most important benefits of the software specification are given below:
• It helps to minimize the cost of development.
• It helps to integrate with the development and test tools.
• It helps to describe what the software will do and how will be expected to perform.
• It helps to generate documents automatically.
There are different software specification methods which are given below:
Flow chart
A flowchart shows a process, system, or computer algorithm (Anon., N.d.). Investigate, document,
improve, and plan topics in clear and easy-to-understand topics that are used in various areas. It is
also a powerful business tool. By using flowcharts correctly, merchants can develop their business.
This flowchart can be used for business, marketing, engineers, students, manufacturing, etc. It has its
different types like document flowchart, system flowchart, data flowchart, etc. The most common
flowchart symbols which are used more in comparative to other are as follows: -
Terminator
Process

92
Document
Decision
Data
Database
Flow Arrow

93
Predefined process
On-page connector/ reference
Off-page connector/ reference

94
Example of flowchart

95
Pseudo code
Pseudocode is a detailed and readable description of what a computer program or algorithm should
do, expressed in a formal, stylized natural language (Rouse, n.d.) rather than a programming
language. This allows designers or key programmers to describe the design in detail and provide the
programmer with a detailed template for the next step of writing code in a specific programming
language. It is also used in combination with methods based on computer software development. The
main purpose of using pseudocode is to make it easier for people to understand than ordinary code in
programming languages, and to explain the key principles of algorithms in an efficient and
environmentally independent manner. Pseudocode is also useful for creating charts and draft
programs. Summarizes the planning process but does not include the main details. It is also used
when planning algorithms using sketches of the program structure before actual encoding takes
place. Some of the benefits of pseudocode are: It is understood by the programmers of all types.
i. It helps to create an outline or a rough draft of a programs.
ii. It helps to summarize a program’s flow.
The pseudo code for the insurance company software according to our scenario is given below:
i. To claim the insurance policy
[when proper evidence is show]
Evidence = true;
[when proper evidence is not shown]
Evidence = false;
If (Evidence = true) {

96
write in (“your claim is rewarded”);
Else {
write in (“sorry, you claim is not rewarded”);
ii. For exchange of foreign currency
[If foreign currency is over its limit]
Over limit = true;
[If foreign currency is over its limit]
Over limit – false;
If (Over limit = true) {
write in (“sorry, your currency is over limit”);
Else {

97
write in (“your currency is successfully exchanged”);
iii. For admin changing policy
[if want to change policy]

New policy = true;
[if does not want to change policy]

New policy = false;
If (New policy = true) {
write in (“Policy changed successfully”);
Else {
write in (“Policy does not change”)
iv)For Log out
[if log out button click]

98
Logout = true;
[if log out button is not click]
Logout = false;
If (Logout = true) {
write in (“your account is being successfully logout”);
Else {
write in (“Welcome to dashboard”);
In the above, I have made the pseudo code of the insurance company software according to our
scenario. I have made pseudo code of login, log out, changing policy, exchange currency and
insurance claiming. I have shown the work flow of software in the pseudo code when the user uses
software of insurance company. Without showing this, a user may feel confuse while using the
software. Thus, pseudo code is very important for the software.

99
Differentiate between a finite state machine (FSM) and an extended Finite State
providing an application for both.
Finite state machine (FSM)
A state machine (sometimes called a state machine) is a computational model that can be
implemented using hardware or software and can be used to model sequential logic and some
computer programs (Moore, Nd). It can be used to simulate problems in many areas such as
mathematics, artificial intelligence, games, linguistics. A computer is essentially a state machine, and
each machine instruction is an input that can change one or more states and cause other actions. A
state machine is a state machine with a limited number of possible states It can be used as a
development tool for approach and problem solving and as a formal way to describe future
developers and accompanying system solutions. Basically simple, efficient and easy to expand. Each
state in the state machine has a series of transitions, each associated with an input and indicating a
state. The state machine includes a number of extensions that can be encoded directly using your
own language or GUI tools. They are of two types:
i. Deterministic finite automata
ii. Nondeterministic finite state machines
Deterministic finite automation
Deterministic limited automation can be defined as a finite state machine that accepts or rejects
strings and generates a unique automatic calculation for each input string. This is an abstract
mathematical concept, but is usually implemented in hardware and software to solve a variety of
specific problems.
Nondeterministic finite automation

100
With non-deterministic and limited automation, there may be zero, one, two, or more transitions for
each state corresponding to a particular symbol. You can also use the null conversion shown when
shown. Zero conversion allows the machine to switch from one state to another without reading
characters. This final automation cannot determine the exact state of machine movement.
Applications of finite state machine
There are many applications of finite state machine which are given below:
i. Due to the simplicity of finite state machine, they are quick to design, implement and also in
execution.
ii. With the implementation of FSM, it shows a developer as concise and professional.
iii. Predictability in deterministic FSM given a set of inputs and a known current state, the state
transaction can be predicated, allowing for easy testing.
iv. It is easy for inexperienced developers to implement with little to almost no extra knowledge.
Extended finite state machine
In an extended state machine, a transformation can be represented by an “if” expression that

consists of a set of trigger conditions. When all of the trigger conditions are met, a transition
occurs, the machine moves from the current state to the next state, and the indicated operation is
also performed on the data. This is a model approach and can be used in various systems. An
extended state machine can reduce the number of states by introducing local variables. Reduce
the number of states by hiding less important information. Generally, the information which
doesn’t have strong impact on behavior are represented as a variable in the extended finite state
machine. It is basically need in the computer science and software engineering in the field of
program analysis and testing.

101
Application of extended finite state machine
i. It can be operated in various tools like metro passageway, alarm, home garage,
temperature controller, etc.
ii. It reduces number of states by hiding less important information.
iii. Since extended finite state machine is a modelling approach, it used for wide range of
systems.
Data driven software
Data driven is an adjective that refers to a process or action driven by data, as well as intuition and
personal experience (Anon., N.d.). Basically, data-driven means that the data determines what action
the person performing the event or process takes. This is most notable in the field of big data, where
data and information are the basis for all actions, and data collection and analysis are the main
drivers. Data-driven software does not determine the order of steps to be performed, but rather
describes the data that the program operator matches and the processing that is required. Usually
applied to structured data streams to filter, aggregate, transform, and call other programs. Data-
driven software usually performs default operations. That is, if no match is found, the linear-oriented
language outputs a line or delivers a message. This is a new way to implement business intelligence.
He uses machine learning to act automatically and perform his actions. It is integrated with the
software as an analytical and strategic direction service.

102
Difference between Finite and Extended Finite State Machine
Finite state machine Extended finite state machine
It is the composition model that is implemented It is the composition of the model where the
with the hardware or software that is used to transaction of the system is expressed in the
simulated sequential logic and some computer if statement consisting the set of the
programs. conditions that trigger the action of the
system
They are used in the many fields like They are widely used in the computer
mathematics, artificial intelligence, games and science and software engineering especially
linguistics. in the field of the program analysis and
testing.
They are simply used in the cases where the According to the trigger of the condition,
particular simple inputs can cause to change the the transaction is fired and then bringing the
state from one to another. machine to the next state and perform the
operation.
E.g.: (door lock and unlock) E.g. : (simple flight safety)
Some of the application of data driven software are given below:
i. It automatically generates the master data, models, schema and graphs as the user
searches and also collects data.
ii. It helps to making the information available within a single application.
iii. It operates on diverse data from many multichannel data sources.

103
Conclusion
In this task, I have firstly prepared documentation that explains how user and software requirements
have been addressed. Also, I have tabulated with the columns that has the expected client
requirements and the actual output of the product to be developed after the appropriate analysis.
After that I have explained the different software specification methods and also suggest two
software behavioral specification methods and illustrate their use with an example relevant to the
project that needs to be constructed for the given context. I have also included flowcharts, pseudo
code and formal specification methods. After that I have differentiate between a finite state machine
and an extended finite state providing an application for both. Finally, I have presented a justification
of how data driven software can improve the reliability and effectiveness of the software.
References
Adams, C. (2015). What is a Context Diagram and what are the benefits of creating one? > Business
Analyst Community & Resources | Modern Analyst. [online] Modernanalyst.com. Available at:
http://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/1433/What-is-a-Context-
Diagram-and-what-are-the-benefits-of-creating-one.aspx [Accessed 27 Nov. 2017].
Alwan, M. (2015). What is System Development Life Cycle?. [online] Airbrake Blog. Available at:
https://airbrake.io/blog/sdlc/what-is-system-development-life-cycle [Accessed 18 Nov. 2017].
Bucki, J. (2017). Learn About Quality Assurance — What It Is and Why It's Important. [online] The
Balance. Available at: https://www.thebalance.com/definition-of-quality-assurance-2533665
[Accessed 26 Nov. 2017].
Creately Blog. (2015). Use Case Diagram Tutorial ( Guide with Examples ) - Creately Blog. [online]
Available at: http://creately.com/blog/diagrams/use-case-diagram-tutorial/#extend [Accessed 27 Nov.
2017].

104
Creately Blog. (2017). ER Diagrams Tutorial | Complete Guide to ER Diagrams with Examples.
[online] Available at: http://creately.com/blog/diagrams/er-diagrams-tutorial/ [Accessed 27 Nov.
2017].
DeVault, G. (2017). Tame Your Focus Groups and Get Useful Insights. [online] The Balance.
Available at: https://www.thebalance.com/what-is-a-market-research-focus-group-2296907
Freetutes.com. (n.d.). The Spiral Life Cycle Model. [online] Available at:
http://www.freetutes.com/systemanalysis/sa2-spiral-model.html [Accessed 20 Nov. 2017].
Fryrear, A. (2017). What is a Feasibility Study, and How Surveys Can Help. [online] SurveyGizmo.
Available at: https://www.surveygizmo.com/survey-blog/what-is-a-feasibility-study/ [Accessed 29
Nov. 2017].
Ghahrai, A. (2008). Prototyping Model in Software Development and Testing. [online]

Testingexcellence.com. Available at: https://www.testingexcellence.com/prototyping-model-
software-development/ [Accessed 20 Nov. 2017].
Ghahrai, A. (2016). SDLC Methodologies – Advantages and Disadvantages. [online]

Testingexcellence.com. Available at: https://www.testingexcellence.com/sdlc-methodologies-
advantages-disadvantages/ [Accessed 20 Nov. 2017].
Lucidchart.com. (2017). What is an Entity Relationship Diagram?. [online] Available at:

https://www.lucidchart.com/blog/what-is-an-entity-relationship-diagram?drtb=4 [Accessed 27 Nov.
2017].
Olshavsky, R. (2003). Six Tips for Improving Your Design Documentation. [online] Boxes and
Arrows. Available at: http://boxesandarrows.com/six-tips-for-improving-your-designdocumentation/
Rouse, M. (2015). What is systems development life cycle (SDLC)? - Definition from WhatIs.com.
[online] SearchSoftwareQuality. Available at:
http://searchsoftwarequality.techtarget.com/definition/systems-development-life-cycle [Accessed 18
Nov. 2017].

105
Rouse, M. (2017). What is constraint (project constraint)? - Definition from WhatIs.com. [online]
WhatIs.com. Available at: http://whatis.techtarget.com/definition/constraint-project-constraint
Simplilearn.com. (2017). Why a Feasibility Study is Important in Project Management. [online]

Available at: https://www.simplilearn.com/feasibility-study-article [Accessed 29 Nov. 2017].
SolutionsIQ. (2017). Dynamic Systems Development Method (DSDM) - SolutionsIQ. [online]

Available at: https://www.solutionsiq.com/agile-glossary/dynamic-systems-development-method-
dsdm/ [Accessed 22 Nov. 2017].
Stackify. (2017). What is SDLC? Understand the Software Development Life Cycle. [online]
Available at: https://stackify.com/what-is-sdlc/ [Accessed 18 Nov. 2017].
Study.com. (2017). Systems Analysis: Definition & Example - Video & Lesson Transcript |
Study.com. [online] Available at: https://study.com/academy/lesson/systems-analysis-definition-
example.html [Accessed 27 Nov. 2017].
tutorialspoint.com. (2017). SDLC Agile Model. [online] Available at:

https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm [Accessed 22 Nov. 2017].
Wolfe, L. (2017). What Is a Feasibility Study and Why Is It so Important?. [online] The Balance.
Available at: https://www.thebalance.com/what-is-a-feasibility-study-3514853 [Accessed 22 Nov.
2017].
Kenton, W., 2018. Efficiency. [Online]

Available at: https://www.investopedia.com/terms/e/efficiency.asp
[Accessed 23 12 2018].
Moore, K., n.d. Finite State Machines. [Online]

Available at: https://brilliant.org/wiki/finite-state-machines/
[Accessed 28 01 2019].
Rouse, M., n.d. pseudocode. [Online]

Available at: https://whatis.techtarget.com/definition/pseudocode
[Accessed 30 01 2019].

106

107

Software Development Lifecycles: Subash Adhikari

Uploaded by

Copyright:

Available Formats

Software Development Lifecycles: Subash Adhikari

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Development Lifecycles: Subash Adhikari

Uploaded by

Copyright:

Available Formats

1/1/2019

HND/ Second Semester Sec-B)

Integration and Testing................................................................................................................7

Phase 1: Requirement collection and analysis:..........................................................................9

Phase 2: Feasibility study:...........................................................................................................9

Adaptive SDLC (System Development Life Cycle) model..........................................................13

Predictive SDLC (System Development Life Cycle) model........................................................13

Comparison between Adaptive SDLC model and Predictive SDLC model..............................13

Predictive Vs Adaptive, what will the best approach?................................................................14

Waterfall SDLC Model..............................................................................................................15

Iterative SDLC Model................................................................................................................17

Subash Adhikari (HND/ Second Semester Sec-B)

Spiral SDLC Model....................................................................................................................19

V-shaped SDLC Model..............................................................................................................20

Agile SDLC Model.....................................................................................................................22

Iterative Model - Design.................................................................................................................23

Iterative Model - Application........................................................................................................24

Iterative Model - Pros and Cons...................................................................................................25

Dynamic System Development Method (DSDM) Model............................................................25

Rapid Application Development (RAD).......................................................................................28

Identify and resolve risk............................................................................................................31

Risk management in spiral model:...........................................................................................32

Risk involved in DSDM & Agile model....................................................................................34

Risks iinvolved iin iwaterfall imodel:.......................................................................................35

M1 Model that I have chosen to build software for an Insurance company.............................35

Purpose of feasibility study............................................................................................................39

Importance of feasibility study:....................................................................................................41

2Describe how technical solutions can be compared...................................................................41

Comparison of technical solution..................................................................................................42

Examples of human errors:...........................................................................................................45

Components of a feasibility report................................................................................................47

Structure of Feasibility report:.....................................................................................................47

Components of a Feasibility Study:..............................................................................................47

Subash Adhikari (HND/ Second Semester Sec-B)

Possible alternate solutions........................................................................................................50

Conclusion and recommendations............................................................................................51

Identification of Stakeholders Requirements...............................................................................55

Identify the requirements of the client.....................................................................................57

Inputs, outputs, processes and the process descriptors..........................................................57

Consideration of alternative solutions......................................................................................58

Use of quality assurance............................................................................................................59

Identification of different constraints.......................................................................................59

3.2 Background information..........................................................................................................62

Data collection process...............................................................................................................62

Subash Adhikari (HND/ Second Semester Sec-B)

Data Flow Diagram (DFD):.......................................................................................................65

Building block of DFD:..............................................................................................................65

Data flow diagram Level 0........................................................................................................65

Data flow diagram Level 1........................................................................................................65

Data flow diagram Level 2........................................................................................................66

Entity Relationship Diagram.........................................................................................................68

Jira is our main source of information.....................................................................................74

Jira helps me organize my documentation tasks.....................................................................74

Jira helps us track the progress of our documentation..........................................................74

Jira helps us to meet our documentation release deadlines...................................................75

Jira helps us measure the time spent on documentation........................................................75

Jira helps me get feedback fast.................................................................................................75

Low fidelity prototype................................................................................................................77

Medium fidelity prototype.........................................................................................................78