Systems Development and Program
ACTIVITY No. 7
I. SDLC vs Agile methodologies in software and systems development
Explain the difference of SDLC and Agile implementation, it’s approach, advantages and
disadvantages.
The Software Development Life Cycle (SDLC) is a systematic process used by software
development organizations to plan, design, build, test, and deploy software products efficiently and
quality. It includes stages like planning, requirement definition, product architecture design,
development, testing, deployment, and maintenance. Agile, a popular technique, emphasizes iterative
development, low cycle times, feedback integration, and adaptability, making it a popular methodology
for continuous delivery environments. It entails self-organizing cross-functional teams working together
to deliver solutions efficiently, making it a popular methodology among many development teams
striving for continuous delivery environments.
To make a comparison, SDLC is a process of designing and developing a product or service,
whereas agile is a methodology for project management that employs an iterative approach. The
former is simple to understand and requires minimal systematic method for implementation, but the
latter is easier to use and apply. SDLC takes a systematic approach, can be utilized for any size
project, and does not allow changes after the initial stage. Meanwhile, Agile takes a speedier approach,
is better suited to small-scale projects, and allows for dynamic changes in requirements. Furthermore,
SDLC is organized in stages and requires close project manager engagement. Agile, on the other
hand, works in a continuous cycle and involves close client interaction.
SDLC's structured framework provides unique advantages in effective planning and risk
management. SDLC promotes consistency by following an established set of processes, allowing
teams to identify and resolve any risks early in the development process. This systematic strategy also
improves cost-effectiveness by reducing unforeseen adjustments and rework. However, SDLC's rigidity
can cause delays, particularly when needs changes or unforeseen challenges develop. Furthermore, its
emphasis on adhering to a set method may inhibit innovation by limiting the room for experimentation
or divergence from standard procedures.
Agile methodology, on the other hand, excels in adapting to change and focusing on client
engagement. Agile teams can respond rapidly to changing requirements and customer input since the
development process is broken down into smaller, iterative cycles. This encourages a collaborative
environment that increases production and ensures that the finished product fulfills client expectations.
Furthermore, Agile improves project visibility, allowing stakeholders to track progress in real time.
However, Agile's emphasis on regular communication and collaboration might be difficult for teams who
are unfamiliar with such an approach. Furthermore, estimating effort effectively in Agile projects can be
challenging, especially when dealing with uncertainty or changing needs.
II. Systems Analysis
Consider the following dialogue between a system professional, Joe Pugh, and a manager of a
department targeted for a new information system, Lars Meyer:
Pugh: The way to go about the analysis is to first examine the old system, such as reviewing key
documents and observing the workers perform their tasks. Then we can determine which aspects are
working well and which should be preserved.
Meyer: We have been through these types of projects before and what always ends up happening is
that we do not get the new system we are promised; we get a modified version of the old system.
Pugh: Well, I can assure you that will not happen this time. We just want a thorough understanding of
what is working well and what is not.
Systems Development and Program
ACTIVITY No. 7
Meyer: I would feel much more comfortable if we first started with a list of our requirements. We should
spend some time up-front determining exactly what we want the system to do for my department. Then
you systems people can come in and determine what portions to salvage if you wish. Just don’t
constrain us to the old system!
Required:
a. Obviously, these two workers have different views on how the systems analysis phase should
be conducted. Comment on whose position you sympathize with the most.
While both perspectives have merit, I sympathize more with Lars Meyer’s position in this
scenario. Meyer’s viewpoint highlights the potential drawbacks of spending too much time
analyzing the old system. He expresses a legitimate concern that an excessive focus on “what
is” may hinder the exploration of innovative solutions and opportunities for improvement. He
also advocates for a clean slate approach, which encourages creativity and the pursuit of
transformative solutions that better meet the department’s need. More so, Meyer’s viewpoint
highlights the potentially being constrained by the old system resonates with the need for
innovation and looking forward-thinking in system development. While understanding the old
system is important, it’s equally crucial to avoid getting stuck in the status quo and to explore
new possibilities.
b. What method would you propose they take? Why?
I suggest that they should conduct a fundamental analysis of the current system within a
specified time frame, focusing on identifying users’ likes and dislikes. This strategy guarantees
that all stakeholders have the chance to contribute and convey their problems, present trouble
areas, desired improvements, and specific requirements for the new system. By prioritizing user
input, the strategy guarantees that the new system is driven by the department's users' unique
requirements and preferences rather than the restrictions of the previous system. More so, the
old system should be examined with an emphasis on understanding its operations, identifying
areas of strength and weakness, and analyzing user preferences and dislikes. While it is crucial
to learn from the previous system, this stage should not be time-consuming or restricted. This
technique points out for an iterative requirements analysis process that allows for continuous
refining and validation of requirements in response to stakeholder feedback and changing
priorities.
III. Systems Design
Robin Alper, a manager of the credit collections department for ACME Building Supplies, is extremely
unhappy with a new system that was installed 3 months ago. Her complaint is that the data flow from
the billing and accounts receivable departments are not occurring in the manner originally requested.
Further, the updates to the database files are not occurring as frequently as she had envisioned. Thus,
the hope that the new system would provide more current and timely information has not materialized.
She claims that the systems analysts spent 3 days interviewing her and other workers. During that time,
she and the other workers thought they had clearly conveyed their needs. She feels as if their needs
were ignored and their time was wasted.
Required:
a. What went wrong during the systems design process?
Several issues have been seen during the systems design process. This includes, first, Ms.
Alper and her co-workers may not have effectively communicated their requirements to the
systems analysts, leading to a lack of clarity and potential misunderstandings. Similarly, the
systems analysts may not have fully understood the requirements provided by Ms. Alper and
her co-workers, possibly due to ambiguous or incomplete information during the requirements
gathering process.
More so, the processing and output specifications lacked sufficient detail, resulting in
ambiguity about the system's functionality and output requirements. Furthermore, the absence
Systems Development and Program
ACTIVITY No. 7
of end-user review, including input from Ms. Alper and her co-workers, meant that potential
discrepancies or gaps in the specifications were not identified and rectified before
implementation. Lastly, the system that was implemented does not fully meet all of the design
specifications. This indicates a failure to ensure that the final system design accurately reflects
the requirements and expectations outlined during the design phase.
b. What suggestions would you make for future projects?
For future projects, it's important to consult end-users again after the initial meeting to
verify that the design specifications accurately reflect their needs. If any discrepancies are
found, adjustments to the specifications should be made accordingly. Utilizing a Joint
Application Development (JAD) session with Computer-Aided Software Engineering (CASE)
tools and incorporating prototyping would be ideal, provided resources allow. JAD sessions
enable collaborative decision-making and allow for real-time modifications to design
specifications, while prototyping enables stakeholders to visualize and provide feedback on the
proposed solution early in the development process. This approach ensures better alignment
between system design and user requirements, leading to more successful implementations.
IV. Scope Creep
Explain what is scope creep and its impact in project implementations.
Scope creep occurs when too many or too major changes are made to a project, causing its
scope to expand well beyond what was originally agreed upon. It is the uncontrolled growth of product
or project scope without regard to time, cost, or resources. Simply put, it refers to performing additional
work that was not originally planned for a project. Scope creep can have a wide range of undesirable
implications, including rework and project failure. It affects not only the project manager, but also
everyone else involved in the project, as well as the project itself. Scope creep, which is adverse to
project success, causes missed deadlines, budget overruns, worse final quality, ineffective multitasking,
demotivation, and overload in project teams. Expanding workloads need additional time and/or
resources, which may result in compromised outcomes, delayed delivery, and increased expenses.
Missed deadlines, budget overruns, disengaged teams, and stakeholder misconceptions are just a few
of the issues that project managers encounter, and if not addressed right away, they risk losing project
control and their professional reputation.
V. Audit of Systems Development
The Balcar Company’s auditors are developing an audit plan to review the company’s systems
development procedures. Their audit objectives are to ensure that:
1. The system was judged necessary and justified at various checkpoints throughout the SDLC.
2. Systems development activities are applied consistently and in accordance with management’s
policies to all systems development projects.
3. The system as originally implemented was free from material errors and fraud.
4. System documentation is sufficiently accurate and complete to facilitate audit and maintenance
activities.
The following six controllable activities have been identified as sources of audit evidence for
meeting these objectives: systems authorization, user specification, technical design, internal audit
participation, program testing, and user testing and acceptance.
Required:
a. Explain the importance of each of the six activities in promoting effective control.
Systems Authorization Activities
Systems Development and Program
ACTIVITY No. 7
Ensuring that all systems are properly authorized helps to evaluate their economic
justification and feasibility. The formal environment where users submit requests in written form
ensures accountability and aligns system initiatives with organizational goals.
User Specification Activities
Active involvement of users in the development process ensures that their needs are
accurately captured. Users should provide detailed written descriptions of their requirements, and
joint efforts between users and systems professionals facilitate the creation of a user specification
document that accurately reflects user needs.
Technical Design Activities
Technical design activities, including systems analysis and feasibility analysis, ensure
system design effectively meets user needs, resulting in high-quality documentation reflecting the
adequacy of the design process.
Internal Audit Participation
Internal audit departments, independent, objective and technically qualified in accordance
with SOX, play a crucial role in ensuring governance-related expectations are met during systems
development. Their involvement, particularly in understanding both technology and business
problems, adds value to the organization and enhances controls throughout the SDLC phases.
Program Testing
Thorough testing of program modules is essential to identify and correct errors before
implementation. Internal auditors verify that all branches of the application's logic are tested and
that meaningful test data is used. Having a basis for comparison allows auditors to quickly verify the
integrity of program code and ensure its reliability.
User Test and Acceptance Procedures
The system undergoes rigorous testing by a team of user personnel, systems professionals,
and internal auditors to ensure its functionality and reliability before deployment, ensuring its
compliance with requirements. This procedure ensures the system's functionality and reliability
before deployment.
b. Outline the tests of controls that the auditor would perform in meeting audit objectives.
To meet the audit objectives, the auditor would use a combination of application control
tests and substantive tests on transaction details and account balances. For example, they would
go over the audit chain of software modifications, validating version numbers and confirming
maintenance authorizations. Furthermore, they would uncover application flaws by comparing
source code, reviewing test results, and re-testing the software. These techniques ensure a
thorough examination of both control effectiveness and the correctness of transactional data and
account balances, offering complete confidence in the audited systems and processes.
