0% found this document useful (0 votes)
8 views

AIS Assignment

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

AIS Assignment

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Assignment

On

Course Title: Accounting Information Systems


Course Code: ACCT-6403

Topics: (Introduction to Systems Development, AIS Development Strategies


and Systems Design, Implementation and Operation)

Prepared By
Maria Ahmed Mim : M22020201538
Md. Pearu : M22020201540
Josephine Purification : M22020201196
Nabia Babul Riya : M22010201123
Md. Kawsar Hossain : M22010201158
2nd Batch & 4th Semester
Department of Accounting & Information Systems
Jagannath University

Prepared For
Dr. A.N.M. Asaduzzaman Fakir
Associate Professor
Department of Accounting & Information Systems
Jagannath University

Date of Submission: 22 March, 2024


Q-1. Show the phases of Systems Development Life Cycle.
The five stages in the systems development life cycle are:
▪ Systems analysis
▪ Conceptual design
▪ Physical design
▪ Implementation and conversion
▪ Operation and maintenance

Systems
Analysis

Operations and Conceptual


maintenance Design

Implementation
Physical Design
and conversion

Q-2. Explain how CASE is used to develop AIS and discuss the disadvantages of using this
method.

CASE (Computer-Aided Software Engineering): It is a methodology that involves the use of


software tools to assist in the development and maintenance of software systems. In the context of
developing Accounting Information Systems (AIS), CASE tools can be utilized to streamline
various stages of the software development lifecycle, including requirements gathering, design,
implementation, testing, and maintenance.
Here's how CASE can be used to develop AIS:
• Requirements Gathering:
CASE tools can assist in gathering and documenting requirements from stakeholders.
These tools may include features for creating diagrams, forms, and templates to facilitate
communication between developers and users.
• Analysis and Design:
CASE tools provide functionalities for modeling and designing AIS components. This
includes tools for creating entity-relationship diagrams, data flow diagrams, class
diagrams, and other modeling techniques to represent the structure and behavior of the
system.
Page|1
▪ Implementation:
Some CASE tools offer code generation capabilities, allowing developers to automatically
generate code based on the design models created earlier. This can speed up the
implementation process and reduce the likelihood of errors.

▪ Testing:
CASE tools often come with testing frameworks that enable developers to create and
execute test cases to ensure the correctness and reliability of the AIS. These tools may
include features for automated testing, regression testing, and performance testing.

▪ Maintenance:
During the maintenance phase, CASE tools can help developers in understanding the
existing codebase, making modifications, and documenting changes. This can improve the
maintainability of the AIS over its lifecycle.

Some disadvantages to using CASE for developing AIS:

▪ Complexity: CASE tools can be complex and require training to use effectively. Small
organizations or teams with limited resources may find it challenging to adopt and integrate
CASE tools into their development processes.

▪ Cost: High-quality CASE tools often come with a significant price tag, which may be
prohibitive for some organizations, especially smaller businesses or non-profit
organizations with limited budgets.

▪ Integration Issues: Integrating CASE tools with existing systems and processes can be
challenging. Compatibility issues may arise when trying to integrate CASE tools with other
software or databases used in the organization.

▪ Over-reliance on Automation: Relying too heavily on CASE tools for code generation
and other tasks can lead to a decrease in the quality of the resulting software. Developers
may become complacent and overlook potential design flaws or optimization
opportunities.

▪ Lack of Flexibility: Some CASE tools impose rigid methodologies or design patterns,
which may not always align with the specific needs or preferences of the development
team. This lack of flexibility can hinder creativity and innovation in the development
process.

Page|2
Q-3. Describe the phases of Systems Development Life Cycle.
The Systems Development Life Cycle (SDLC) for accounting information systems typically
consists of several phases, each aimed at ensuring that the system is developed, implemented, and
maintained effectively. Here are the phases commonly found in the SDLC for accounting
information systems: The five stages in the systems development life cycle are:
a) Systems analysis
b) Conceptual design
c) Physical design
d) Implementation and conversion
e) Operation and maintenance

a. Systems Analysis Phase:


As organizations grow and change, they may need more or better information. Systems
analysis is the first step. It includes:
▪ Initial investigation: Involves gathering the information needed to buy or develop a new
system and determining whether it is a priority.
▪ Systems survey:
If the system is a priority, survey the existing system to define the nature and scope of
the project and identify the strengths and weaknesses of the system.
▪ Feasibility study:
Involves an in-depth study of the proposed system to determine whether it’s feasible.

▪ Determination of information needs and system requirements:


Involves finding out and documenting what users and management need. This is the
most important aspect of systems analysis.

▪ Delivery of systems requirements:


Involves preparation of a report summarizing the systems analysis work. This report is
submitted to the information systems steering committee.

b. Conceptual design phase, the company decides how to meet user needs. Tasks in this
phase include:

▪ Identify and evaluate design alternatives


▪ Develop design specifications:
Involves writing up details of what the system is to accomplish and how it is to be
controlled and developed.

▪ Deliver conceptual design requirements


These requirements will be forwarded to the information systems steering committee.

Page|3
c. In the physical design phase, the broad, user-oriented requirements of the conceptual
design are translated into detailed specifications that can be used by programmers to
code the programs. Tasks include:

▪ Design outputs, database, and inputs


▪ Develop programs
▪ Develop procedures
▪ Design controls
▪ Deliver developed system
▪ Goes to information systems steering committee

d. In the Implementation and conversion phase, this is the capstone phase during which
everything comes together. Tasks include:

▪ Develop an implementation and conversion plan.


▪ Needed because of the complexity and importance of this phase.
▪ Install any new hardware and software.
▪ Train personnel.
▪ New employees may need to be hired and trained or existing employees relocated.
▪ Test the system and make any needed modifications.
▪ Complete the documentation.
▪ Convert from the old to the new system.
▪ Deliver operational system.
▪ Send the final report to the IS steering committee.

e. In the Operations and Maintenance phase. Once the system is up and running, operations
and monitoring continue. Tasks include:

▪ Fine-tune and do post-implementation review.


▪ Operate the system.
▪ Periodically, review and modify the system.
▪ Do ongoing maintenance.
▪ Deliver improved system.

Page|4
Q-4. Explain the various types of feasibility analysis and how to calculate economic
feasibility.

Feasibility analysis is a crucial step in evaluating the viability of a project or business venture before
committing resources to it. There are several types of feasibility analysis, including
1. Economic feasibility
2. Technical feasibility
3. Operational feasibility
4. Legal feasibility and
5. Scheduling feasibility.

Economic Feasibility:
Economic feasibility analysis examines whether a project or business venture is financially viable.
It involves estimating the costs associated with the project (including initial investment, operating
expenses, and maintenance costs) and comparing them with the expected benefits (such as revenue,
cost savings, and increased efficiency). Key components of economic feasibility analysis include:
• Cost-benefit analysis: This involves quantifying the costs and benefits of the project and
comparing them to determine whether the benefits outweigh the costs.
• Return on Investment (ROI): ROI measures the profitability of an investment by
comparing the net profit generated to the initial investment. It's calculated as (Net Profit /
Initial Investment) * 100.
• Payback Period: This indicates the time it takes for the project's net cash inflows to equal
the initial investment. A shorter payback period is generally more favorable.
• Net Present Value (NPV): NPV calculates the present value of all cash inflows and
outflows associated with the project, discounted at an appropriate rate. A positive NPV
indicates that the project is financially viable.

Technical Feasibility:
Technical feasibility analysis evaluates whether the project can be successfully implemented from
a technical standpoint. It assesses factors such as technology requirements, availability of
resources, and expertise needed to execute the project.

Operational Feasibility:
Operational feasibility analysis examines whether the project fits within the existing operations
and processes of the organization. It considers factors such as organizational structure, personnel
capabilities, and potential disruptions to current operations.

Legal Feasibility:
Legal feasibility analysis assesses whether the project complies with relevant laws, regulations,
and legal requirements. It involves identifying potential legal obstacles and ensuring that the
project adheres to all applicable legal standards.

Page|5
Scheduling Feasibility:
Scheduling feasibility analysis evaluates whether the project can be completed within the specified
timeframe. It involves creating a realistic project schedule, considering factors such as resource
availability, dependencies between tasks, and potential delays.
To calculate economic feasibility, you typically follow these steps:
• Estimate Costs: Determine all costs associated with the project, including initial investment,
operating expenses, maintenance costs, and any other relevant expenditures.
• Estimate Benefits: Identify and quantify the potential benefits of the project, such as revenue
generation, cost savings, increased efficiency, and other tangible or intangible gains.
• Conduct Cost-Benefit Analysis: Compare the total costs with the total benefits to assess the
project's financial viability. Use tools such as ROI, NPV, and payback period to analyze the
cost-benefit relationship.
• Adjust for Risk: Consider any uncertainties or risks associated with the project and adjust
the financial analysis accordingly. This may involve sensitivity analysis or scenario planning
to assess the project's resilience to potential challenges.

• Make a Decision: Based on the economic feasibility analysis, make an informed decision
about whether to proceed with the project or business venture. If the benefits outweigh the
costs and the project meets the organization's objectives, it may be deemed economically
feasible. Otherwise, adjustments or reconsideration may be necessary.

Q-5. Explain the principles and challenges of business process reengineering.


Business Process Reengineering (BPR) is a management approach aimed at redesigning and
improving business processes to achieve dramatic improvements in performance, efficiency, and
quality. The seven principles of BPR provide a framework for organizations to follow when
undertaking process reengineering efforts. These principles are:

1. Organize around outcomes, not tasks.


2. Require those who use the output to perform the process.
3. Require those who produce information to process it.
4. Centralize and disperse data.
5. Integrate parallel activities
6. Empower workers, use built-in controls, and flatten the organization chart.
7. Capture data once, at its source.

Organize around outcomes, not tasks:

• Focus on defining the desired results or outcomes first.


• Align tasks and activities to these outcomes, rather than organizing based on specific tasks
or functions.
• Encourage a more holistic and flexible approach to problem-solving, allowing teams to
adapt their methods to best achieve the desired outcomes.

Page|6
Require those who use the output to perform the process:

• Encourage accountability by involving end-users in the process.


• Those who will benefit from the output should have a stake in its creation, ensuring that it
meets their needs and expectations.
• This involvement can lead to better understanding, collaboration, and ultimately, higher-
quality outcomes.
Require those who produce information to process it:

• Encourage a deeper level of engagement and understanding among those producing


information.
• Instead of merely generating data or information, individuals should analyze and interpret
it, extracting insights that can drive decision-making.
• This approach fosters a culture of critical thinking and problem-solving, empowering
individuals to contribute meaningfully to the organization's goals.

Centralize and disperse data:


• Centralize core data repositories to ensure consistency, accuracy, and security.
• Disperse data access to relevant stakeholders across the organization, enabling them to
leverage information effectively in their roles.
• Implement robust data governance practices to maintain data integrity while allowing for
accessibility and utilization.

Integrate parallel activities:


• Identify and streamline parallel activities within processes to eliminate duplication of effort
and reduce inefficiencies.
• Integrate systems and workflows to enable seamless coordination between different teams
or departments working on related tasks.
• Foster communication and collaboration to ensure smooth transitions between parallel
activities and minimize delays or bottlenecks.

Empower workers, use built-in controls, and flatten the organization chart:
• Empower employees by providing them with the autonomy and resources needed to make
decisions and take ownership of their work.
• Implement built-in controls and checkpoints within processes to ensure compliance,
quality assurance, and risk management without relying solely on hierarchical oversight.
• Flatten the organization chart by reducing unnecessary layers of management and
bureaucracy, promoting a more agile and responsive organizational structure.

Capture data once, at its source:


• Establish systems and processes to capture data at its point of origin to minimize errors,
redundancies, and inconsistencies.
• Integrate data capture mechanisms into existing workflows to streamline operations and
reduce manual data entry.
• Ensure data quality and accuracy by implementing validation checks and controls at the
source of data capture.
Page|7
Challenges of business process reengineering
Business Process Reengineering (BPR) can be a complex and challenging endeavor for
organizations. Some of the key challenges associated with BPR include:

• Resistance to Change: Implementing BPR often requires significant changes to existing


processes, roles, and structures within the organization. Employees may resist these changes
due to fear of job loss, uncertainty about new roles, or simply discomfort with change.
• Lack of Leadership Support: BPR initiatives require strong leadership support to drive
them forward and ensure that resources are allocated appropriately. Without visible support
from top management, BPR efforts may struggle to gain traction and momentum.

• Inadequate Planning and Communication: Effective BPR requires thorough planning and
clear communication throughout the organization. Failure to adequately plan or
communicate the reasons behind the changes can lead to confusion, frustration, and
resistance among employees.

• Scope Creep: BPR initiatives may suffer from scope creep, where the project expands
beyond its original objectives, leading to delays, increased costs, and reduced effectiveness.
It's essential to define clear boundaries and goals for the reengineering effort from the outset.

• Technology Constraints: Implementing new technologies and systems is often a key


component of BPR. However, organizations may face challenges related to the compatibility
of existing systems, the availability of suitable technology solutions, and the costs associated
with implementation and maintenance.

• Lack of Skills and Expertise: BPR requires a diverse set of skills, including process
analysis, change management, and project management. Organizations may struggle to find
or develop employees with the necessary expertise to lead and support BPR initiatives
effectively.
• Measurement and Evaluation: Measuring the success of BPR initiatives can be
challenging, particularly if organizations fail to establish clear performance metrics and
benchmarks. Without robust measurement and evaluation mechanisms in place, it can be
difficult to assess the impact of reengineering efforts accurately.
• Cultural Issues: Organizational culture plays a significant role in the success of BPR
initiatives. Resistance to change, siloed thinking, and lack of collaboration can all undermine
efforts to streamline processes and improve efficiency.

Page|8
Q-6. What are the steps that followed when developing and testing software programs?
Explain the four conversion approaches for systems implementation.

When developing and testing software programs, the process typically follows a structured
approach, often referred to as the Software Development Life Cycle (SDLC). Here are the typical
steps involved:

• Determine user needs: This step involves gathering requirements from stakeholders to
understand the functionalities and features expected from the software. This could involve
meetings, surveys, interviews, and other forms of communication to gather comprehensive
user needs.
• Develop a plan: Once user needs are determined, a development plan is created. This plan
outlines the scope of the project, timelines, resource allocation, budget, and other important
aspects of the development process.

• Write program instructions (code): In this step, developers write the actual code that
implements the functionalities outlined in the requirements. This involves translating the
design and requirements into programming languages such as Java, Python, C++, etc.

• Test the program: Testing is a crucial phase where the developed software is evaluated to
ensure it meets the specified requirements and functions correctly. This involves various
testing techniques such as unit testing, integration testing, system testing, and user acceptance
testing (UAT).

• Document the program: Documentation is essential for understanding the software's


functionalities, architecture, and usage. This includes creating technical documentation such
as design documents, user manuals, API documentation, and other relevant materials.

• Train program users: Once the software is developed and tested, users need to be trained on
how to use it effectively. Training sessions may be conducted to familiarize users with the
software's features, interface, and functionalities.

• Install and use the system: Finally, the software is installed and deployed in the production
environment. This involves setting up the necessary infrastructure, configuring the software,
and ensuring it runs smoothly. Users can then start using the system for its intended purpose.

Regarding the four conversion approaches for systems implementation, these are:

Parallel Conversion:

• Involves running the old and new systems simultaneously for a certain period.
• Allows for comparison and validation of results between the two systems.
• Can be resource-intensive and may require duplicate efforts during the transition period.

Page|9
Direct Conversion:

• Involves switching from the old system to the new system abruptly.
• Requires careful planning and coordination to minimize disruption to operations.
• Can be high-risk due to the sudden change, and may result in temporary setbacks or
challenges.

Phased Conversion:

• Involves implementing the new system in phases or modules over time.


• Allows for gradual adoption and adjustment, reducing the risk of disruption.
• Requires careful sequencing and planning to ensure smooth transition between phases.

Pilot Conversion:

• Involves implementing the new system in a limited area or department first.


• Allows for testing and validation in a controlled environment before full deployment.
• Can help identify and address issues early on, minimizing the impact on the entire
organization.

Best of Luck!

Page|10

You might also like