Software Project Development Foundations

Introduction

Software projects transform needs, opportunities, or problems into working digital solutions. A project may produce a mobile application, an information system, an automation tool, a data-processing service, or a web platform. Although programming is central to implementation, successful development depends on much more than writing code. Teams must understand the problem, identify stakeholders, assess feasibility, select an appropriate life-cycle model, manage constraints, produce verifiable deliverables, and control technical and organizational risks.

Java and Python are particularly valuable in project development. Java is widely used for enterprise systems, Android-related development, backend services, and applications requiring portability, strong typing, and mature tooling. Python is prominent in automation, web development, data analysis, artificial intelligence, scientific computing, and rapid prototyping. Their roles differ in emphasis, but both support professional software engineering when combined with sound project practices.

This chapter establishes the foundation for later work in project development using Java and Python. It treats software development as both a technical and organizational activity.

Learning Objectives

After studying this chapter, you should be able to:

• define essential software-project terminology;
• distinguish projects from routine operational work;
• identify and analyse major project stakeholders;
• explain feasibility and its principal dimensions;
• compare common software life-cycle models;
• explain scope, time, cost, quality, risk, and resource constraints;
• distinguish requirements, products, documents, and other deliverables;
• describe the roles of Java and Python in modern solution development;
• apply foundational concepts to a realistic project scenario; and
• recognize ethical, security, governance, and sustainability responsibilities.

1. Understanding Software Projects

A project is a temporary endeavour undertaken to create a unique product, service, or result. “Temporary” means that the work has an intended beginning and end; it does not necessarily mean that the resulting system is short-lived. A university may run a project to develop a student-registration platform, after which the platform enters continuous operational maintenance.

A software project is a coordinated set of activities that produces or changes software and associated artefacts. These artefacts may include source code, executable packages, databases, test specifications, user documentation, deployment scripts, training materials, and support procedures.

A project differs from operations. Operations are ongoing and repetitive, such as monitoring a production server or processing daily transactions. A project may improve those operations by introducing a new monitoring system, but after implementation the system becomes part of operational work.

Important terminology includes:

A project normally has an intended value proposition. For example, an online appointment system may reduce telephone workload, shorten waiting times, improve data accuracy, and provide management information. A technically impressive system that does not solve a meaningful problem is not a successful project.

2. The Project Environment and Stakeholders

A stakeholder is a person, group, or organization that can affect, be affected by, or perceive itself to be affected by a project. Stakeholders may have different objectives. A customer may prioritize early delivery, users may prioritize simplicity, developers may prioritize maintainability, and a regulator may prioritize compliance.

Typical stakeholders include:

• Sponsor: provides authority, resources, funding, or organizational support.
• Customer or client: commissions the system or represents the paying organization.
• Project manager: coordinates scope, schedule, resources, communication, risk, and decisions.
• Product owner or business representative: prioritizes product value and clarifies business needs.
• End users: interact directly with the system and judge whether it supports their work.
• Developers: design, implement, integrate, and maintain software components.
• Testers and quality specialists: evaluate conformance, reliability, usability, and defects.
• System architects: make high-level decisions about structure, interfaces, technologies, and quality attributes.
• Operations or DevOps specialists: support deployment, monitoring, availability, and release automation.
• Security and privacy specialists: identify threats and protect information and systems.
• Suppliers and partners: provide platforms, services, data, or specialist capability.
• Regulators and auditors: impose or verify legal, professional, or organizational requirements.

Stakeholder analysis should begin early and continue throughout the project. A useful method is to record each stakeholder’s interests, influence, expected contribution, concerns, and preferred communication channel. A stakeholder with high influence and high interest generally requires close engagement. A person with low influence but high operational impact should not be ignored: users often reveal requirements and usability problems that senior decision-makers do not see.

Communication is a technical project activity, not merely an administrative one. Ambiguous communication creates ambiguous requirements, and ambiguous requirements create defects. Teams should use agreed terminology, written decisions, traceable requirements, demonstrations, and accessible progress information.

3. From Problem to Solution

Software development should begin with a problem or opportunity rather than with a preferred programming language. A problem statement describes the undesirable current condition and its effect. A solution concept proposes a possible response, but it should remain open to alternatives.

For example:

• Problem: small clinics lose appointment requests because telephone messages are incomplete or unanswered.
• Objective: provide a reliable appointment-request process that reduces missed requests and gives staff a searchable schedule.
• Possible solution: a web application with a Python-based service, a database, and secure staff access.
• Success measures: fewer missed requests, faster confirmation, acceptable response time, and compliance with privacy requirements.

A requirement should be sufficiently clear, necessary, feasible, verifiable, and traceable. Functional requirements describe what the system does, such as “The system shall allow an authorised receptionist to cancel an appointment.” Non-functional requirements describe qualities or constraints, such as security, performance, accessibility, reliability, legal compliance, or maintainability.

A useful distinction is between a requirement and a design decision. “Users must receive confirmation by email” is a requirement; “the application will use a particular email library” is a design decision. Mixing these levels too early can prevent better solutions from being considered.

Requirements may be represented as use cases, user stories, process models, prototypes, data models, acceptance criteria, or formal specifications. At diploma level, the essential practice is to connect each requirement to a stakeholder need and to a method of verification.

4. Feasibility Analysis

Feasibility analysis determines whether a proposed project is practical and worth pursuing. It is not a guarantee of success; it is a structured reduction of uncertainty. A feasibility study should identify evidence, assumptions, alternatives, major risks, and a recommendation.

Technical feasibility

Technical feasibility asks whether the organization can build, integrate, secure, deploy, and maintain the proposed system. Questions include:

• Are the required skills available?
• Can Java, Python, databases, cloud services, and interfaces support the requirements?
• Can the system integrate with existing platforms?
• Are performance, security, accessibility, and reliability targets achievable?
• Is the required data available and of sufficient quality?

A small prototype or proof of concept can test uncertain technical assumptions, but a prototype should not be mistaken for a production-ready system.

Economic feasibility

Economic feasibility considers whether expected benefits justify total costs. Costs may include development labour, hardware, cloud services, licenses, training, migration, support, security controls, and future maintenance. Benefits may be financial, operational, social, regulatory, or strategic.

A simple net-benefit calculation is:

Both benefits and costs should use the same time period and currency. This simple calculation is useful for an initial comparison, but it does not account for the timing of cash flows, uncertainty, or non-financial benefits. More advanced analysis may use discounted cash flow, but estimates must be treated cautiously because early project assumptions are often uncertain.

Operational feasibility

Operational feasibility asks whether the organization can adopt and use the solution. A technically successful system may fail if users cannot understand it, existing processes are incompatible, support is unavailable, or management does not provide authority for change.

Legal and regulatory feasibility

The project may need to comply with privacy, intellectual-property, accessibility, cybersecurity, records-management, sector-specific, or contractual requirements. Legal feasibility should be assessed before data is collected or external services are selected.

Schedule feasibility

Schedule feasibility asks whether the required outcome can be delivered within the available time. It should consider dependencies, approvals, recruitment, procurement, testing, migration, training, and contingency. Compressing a schedule by adding people is not always effective because communication and coordination costs may increase.

Organizational and ethical feasibility

The project must fit organizational authority, culture, governance, and ethical obligations. A proposed artificial-intelligence feature, for instance, may be technically possible but unacceptable if it produces discriminatory decisions or uses personal data without a legitimate basis.

5. Software Life-Cycle Models

A software life cycle describes how a project moves from an idea to operation and eventual retirement. A life-cycle model is not a rigid law; it is a management and engineering framework. The appropriate model depends on uncertainty, risk, regulatory obligations, team capability, product type, and stakeholder availability.

Waterfall and sequential models

In a sequential model, activities such as requirements, design, implementation, testing, and deployment are arranged largely in phases. A phase may require formal approval before the next begins.

Strengths include clear documentation, predictable review points, and suitability for stable requirements or regulated environments. Weaknesses include delayed user feedback, expensive late change, and the risk that misunderstood requirements remain hidden until testing.

A sequential model can still include iteration within phases. “Waterfall” should not be interpreted as meaning that learning is impossible; rather, it emphasizes controlled progression and formal baselines.

Iterative and incremental development

In iterative development, the team repeatedly revisits understanding and design. In incremental development, the product grows through additions. A release may deliver a small but useful subset, followed by further increments.

These approaches provide earlier feedback and allow high-risk features to be tested sooner. They require disciplined prioritization, integration, regression testing, and architectural attention. Incremental delivery is not an excuse to omit design, documentation, or quality assurance.

Agile approaches

Agile development emphasizes early and continuous delivery of value, collaboration with stakeholders, responsiveness to change, and frequent working software. Scrum, Kanban, and extreme programming are examples of approaches associated with agile practice, although agile is broader than any one framework.

A sprint is a timeboxed period in some agile frameworks. A product backlog contains potential work, ordered by value and risk. Acceptance criteria describe conditions that must be satisfied. A retrospective examines how the team can improve.

Agile is most effective when stakeholders are available, priorities can be adjusted, and the team can deliver integrated increments. It can be difficult where requirements are fixed by law, procurement contracts demand extensive upfront specification, or stakeholders cannot provide timely decisions. Agile projects still need architecture, security, documentation, planning, and governance.

Spiral and risk-driven models

A spiral model organizes development around repeated identification and reduction of major risks. Each cycle may involve objectives, alternatives, risk analysis, development, and review. This is useful for large, novel, or safety-critical systems, but it requires mature risk management and may be excessive for a small application.

DevOps and continuous delivery

DevOps integrates development and operations practices. Automation may support building, testing, security checks, deployment, monitoring, and rollback. Continuous delivery means that software is maintained in a releasable state; continuous deployment goes further by automatically releasing changes when defined controls pass.

Automation improves repeatability but does not remove responsibility. A pipeline can rapidly deploy a defect if tests are weak or requirements are misunderstood. Human review, access control, audit records, and production monitoring remain important.

6. Project Constraints and Trade-offs

The traditional project constraint model identifies scope, time, and cost as closely related constraints, with quality influenced by decisions concerning all three. Adding functionality may require more time or money. Reducing time may require additional resources, reduced scope, or increased risk. Quality should not be treated as an optional fourth corner: inadequate quality creates rework, operational loss, and reputational damage.

Other important constraints include:

• available skills and team capacity;
• technology and infrastructure;
• security and privacy obligations;
• accessibility requirements;
• organizational policies;
• supplier and platform dependencies;
• data quality and migration complexity;
• environmental and sustainability expectations; and
• uncertainty and external change.

A scope baseline identifies approved work. Scope creep occurs when work is added without corresponding evaluation of time, cost, resources, or risk. Change is not inherently bad; uncontrolled change is the problem. A change-control process should record the requested change, rationale, impact, decision authority, and updated plans.

Quality has both verification and validation dimensions. Verification asks whether the product was built according to specified requirements. Validation asks whether the right product was built for the users’ actual needs. Reviews, static analysis, unit tests, integration tests, system tests, usability evaluation, security testing, and user acceptance testing support these goals.

Risk management normally involves identification, analysis, response planning, monitoring, and review. A risk register may record a description, cause, potential effect, probability, impact, owner, response, and status. Responses may include avoiding, reducing, transferring, accepting, or exploiting a risk. Probability and impact ratings are useful for prioritization, but they are estimates rather than precise facts.

7. Deliverables and Project Control

A deliverable is a verifiable product, result, or capability produced by project work. Deliverables may be internal or external and may be temporary or final.

Typical software-project deliverables include:

1. project charter or initiation document;
2. stakeholder and communication plan;
3. feasibility report;
4. requirements specification or prioritised backlog;
5. user journeys, use cases, or process models;
6. architecture and design documentation;
7. source code and configuration;
8. database schema and migration scripts;
9. test plan, test cases, and test results;
10. packaged release or deployed service;
11. user and administrator documentation;
12. training and support materials;
13. security and privacy assessment;
14. operational runbook and monitoring configuration; and
15. acceptance record and lessons-learned report.

A deliverable should have an owner, due date, quality criteria, review method, and acceptance authority. The phrase “finished” should be defined. A feature is not necessarily finished merely because its code compiles. A stronger definition may require code review, automated tests, security checks, documentation, deployment readiness, and stakeholder acceptance.

Configuration management controls versions of source code, requirements, dependencies, environments, and documentation. Version control supports collaboration and traceability. Branching strategies should be simple enough for the team to understand, and commits should communicate meaningful changes. Reproducible builds and dependency locking reduce the risk that a project works only on one developer’s machine.

8. The Roles of Java and Python

Programming languages are tools selected in relation to requirements, team capability, ecosystem, operational context, and long-term maintenance. Neither Java nor Python is universally superior.

Java

Java is a statically typed, object-oriented language designed around portability through the Java Virtual Machine. Its major strengths include:

• strong compile-time checking;
• mature enterprise libraries and frameworks;
• concurrency and scalability support;
• extensive tooling, testing, and monitoring ecosystems;
• portability across operating systems through the JVM; and
• suitability for long-lived systems with large development teams.

Java is commonly used in enterprise services, financial systems, large-scale backend applications, Android-related development, distributed systems, and educational programming. Its explicit types can make interfaces and contracts clearer, although they may require more code than a dynamically typed alternative.

Python

Python is a high-level, dynamically typed language emphasizing readability and developer productivity. Its strengths include:

• concise syntax and rapid prototyping;
• extensive libraries for data analysis, automation, scientific computing, and machine learning;
• strong web-development frameworks;
• effective scripting and integration capabilities; and
• accessibility for learners and multidisciplinary teams.

Python is widely used for automation, data pipelines, web services, testing tools, research, and artificial-intelligence applications. Dynamic typing increases flexibility but places greater responsibility on tests, documentation, type hints where appropriate, and disciplined interfaces.

Using both languages

A project may use Java and Python together. For example, a Java service may provide a stable transaction-processing backend while Python supports data preparation, reporting, model development, or automation. Integration can occur through HTTP APIs, messaging systems, scheduled jobs, or shared data stores.

Using two languages introduces additional build systems, deployment environments, skills requirements, security updates, and monitoring needs. The decision should therefore be justified by clear value rather than novelty. Teams should define interface contracts, data formats, error handling, authentication, logging, ownership, and version compatibility.

Regardless of language, professional practice requires readable code, automated tests, secure dependency management, code review, documentation, observability, and maintainable architecture.

9. Ethical, Security, and Governance Responsibilities

Software decisions can affect employment, education, healthcare, finances, safety, and personal privacy. Developers and project managers therefore have responsibilities beyond satisfying a client’s immediate request.

Key principles include:

• collect only necessary personal data;
• define legitimate purposes and retention periods;
• protect confidentiality, integrity, and availability;
• apply least-privilege access;
• validate inputs and handle failures safely;
• protect secrets and credentials from source repositories;
• maintain auditability without excessive surveillance;
• design for accessibility and inclusive use;
• evaluate bias in data-driven or automated decisions;
• respect licenses and intellectual-property rights; and
• provide mechanisms for correction, appeal, and human oversight where decisions affect people.

Security should be integrated throughout the life cycle. Threat modelling during design is usually less expensive than responding to a breach after deployment. Dependency scanning, secure coding, code review, testing, patch management, backups, incident response, and monitoring form complementary controls.

Artificial intelligence can assist with coding, testing, documentation, and analysis, but generated output may contain defects, insecure patterns, licensing concerns, or fabricated explanations. Human review, testing, confidentiality controls, and organizational policy remain necessary. AI should support professional judgement rather than replace accountability.

10. Illustrative Case: Community Clinic Appointment System

Background

A community clinic currently receives appointment requests by telephone and paper form. Staff manually enter information into a spreadsheet. Patients often wait for confirmation, duplicate entries occur, and managers cannot easily determine demand by service.

Problem and stakeholders

The clinic proposes a secure appointment-request system. Stakeholders include patients, receptionists, clinicians, the clinic manager, an IT support provider, and a privacy officer. Patients need accessible submission and confirmation. Receptionists need search, modification, and cancellation functions. Managers need reports. The privacy officer requires appropriate handling of health-related information.

Feasibility analysis

Technical feasibility appears reasonable: a web interface, relational database, authentication, and email notification are established technologies. A short prototype should test integration with the clinic’s existing calendar system. Operational feasibility depends on staff training and a transition plan from the spreadsheet. Legal and privacy feasibility requires data minimisation, access control, retention rules, secure transmission, and documented consent or other lawful processing basis. Schedule feasibility is improved by delivering request and confirmation functions before advanced reporting.

Proposed approach

An incremental life cycle is appropriate because staff can review early versions. The first increment includes patient request submission, receptionist review, confirmation, and cancellation. A later increment adds reporting and calendar integration. Python could support a web service and reporting scripts, while Java could be selected for an existing enterprise integration service if the clinic’s provider already operates a Java platform. Alternatively, using one language may be simpler if integration does not justify both.

The project team defines acceptance criteria such as:

• an authorised receptionist can locate an appointment by approved search fields;
• a patient receives a confirmation only after staff approval;
• unauthorised users cannot view another patient’s information;
• cancellation records retain an appropriate audit trail; and
• the system remains usable with keyboard navigation and assistive technology.

Outcome

In this illustrative case, the first release reduces manual duplication and provides a traceable workflow. The project does not immediately automate every decision; staff retain control over appointment allocation. A post-release review identifies improvements to reminder timing and reporting.

Learning points

The case demonstrates that feasibility includes legal and operational dimensions, not only technical possibility. It also shows the value of incremental delivery, explicit acceptance criteria, stakeholder involvement, data protection, and proportionate technology selection.

11. Best Practices for Diploma-Level Project Work

1. Start with the problem, users, and measurable objectives.
2. Record assumptions and validate the most uncertain ones early.
3. Define scope boundaries and use a controlled change process.
4. Select a life-cycle model according to context rather than fashion.
5. Deliver small, testable increments where uncertainty is high.
6. Link requirements to design elements, tests, and acceptance evidence.
7. Use version control and reproducible development environments.
8. Treat security, accessibility, privacy, and quality as design concerns.
9. Choose Java, Python, or both based on requirements and total ownership cost.
10. Demonstrate working software regularly to real stakeholders.
11. Document important decisions and unresolved risks.
12. Review the project after delivery and apply lessons to future work.

Challenges and Limitations

Project models simplify reality. A life-cycle label cannot resolve conflicting stakeholder interests, poor data, inadequate skills, or unrealistic deadlines. Estimates are uncertain, particularly when requirements or technology are new. Agile practices can become unstructured if prioritization and quality controls are weak; sequential practices can become bureaucratic if documentation is produced without useful decisions. Automation can improve consistency while also scaling mistakes. Java and Python ecosystems provide substantial capability but introduce dependencies, vulnerabilities, and maintenance obligations. Sound judgement, evidence, communication, and ethical responsibility remain essential.

Chapter Summary

Software project development is a coordinated process for creating a unique product or result within a changing organizational and technical environment. Projects must be distinguished from ongoing operations and understood through concepts such as scope, requirements, stakeholders, risks, issues, assumptions, dependencies, milestones, and deliverables.

Feasibility analysis examines technical, economic, operational, legal, schedule, organizational, and ethical considerations. Sequential, iterative, incremental, agile, spiral, and DevOps-oriented life-cycle models provide different ways to organize work; the appropriate choice depends on uncertainty, risk, governance, and stakeholder participation.

Scope, time, cost, quality, resources, security, privacy, and compliance create interrelated constraints. Deliverables require clear ownership and acceptance criteria, while configuration management, testing, traceability, and change control support professional delivery. Java offers strong typing, portability, mature enterprise support, and scalability. Python offers readability, rapid development, automation, web, data, and AI capabilities. Either language, or both together, can support successful solutions when selected according to requirements and maintained with disciplined engineering practices.

Finally, software professionals are responsible for more than functionality. They must consider privacy, security, accessibility, fairness, intellectual property, sustainability, and the consequences of automated decisions. Effective project development combines technical competence with stakeholder understanding, governance, communication, and ethical judgement.

Key Terms

Project: A temporary endeavour that creates a unique product, service, or result.

Software project: Coordinated work that produces or changes software and associated artefacts.

Stakeholder: A person, group, or organization affected by or able to affect a project.

Sponsor: The person or organization providing authority, support, or resources.

Requirement: A needed capability, condition, or constraint of a system.

Scope: The defined boundaries of project work and deliverables.

Feasibility: An assessment of whether a proposed project is practical and worthwhile.

Life-cycle model: A framework for organizing software-development activities.

Agile development: An approach emphasizing collaboration, frequent delivery, and responsiveness to change.

Increment: A usable addition to a product.

Risk: An uncertain event or condition that may affect objectives.

Issue: A current problem or decision requiring action.

Deliverable: A verifiable product, result, or capability produced by project work.

Milestone: A significant project event or decision point.

Baseline: An approved reference used to monitor and control change.

Technical debt: Future maintenance cost created by expedient technical decisions.

Configuration management: Control of versions and relationships among project artefacts.

Java: A statically typed language and JVM-based platform widely used in enterprise and distributed systems.

Python: A high-level language widely used for automation, web development, data, science, and AI.

DevOps: A set of practices integrating software development, operations, automation, and feedback.

Review Questions

Short Answer Questions

1. What is the difference between a software project and software operations?
2. Define a stakeholder and name four common software-project stakeholders.
3. What is meant by technical feasibility?
4. Distinguish a requirement from a design decision.
5. What is a deliverable, and why should it have acceptance criteria?

Long Answer Questions

1. Compare sequential, iterative, incremental, agile, and spiral life-cycle models. Identify an appropriate context for each.
2. Explain how scope, time, cost, quality, and risk interact in software projects.
3. Discuss the principal dimensions of feasibility and explain why technical feasibility alone is insufficient.
4. Compare Java and Python in terms of typing, development speed, ecosystems, and suitable project contexts.
5. Explain how security, privacy, accessibility, and ethics should influence the software life cycle.

Analytical / Application Questions

1. A college wants a system to manage student attendance, but requirements are uncertain and lecturers are available for weekly demonstrations. Which life-cycle approach would you recommend, and why?
2. A project is two weeks from its deadline when a stakeholder requests three major features. Analyse the request using scope, time, cost, quality, and risk considerations, and propose a responsible response.
3. Design a preliminary feasibility-analysis plan for a Python automation tool that processes employee records. Identify stakeholders, technical questions, legal or privacy concerns, risks, and evidence that should be collected.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a project from operations?

A. A project is temporary and creates a unique result, whereas operations are ongoing activities.

B. A project always uses more staff than operations.

C. Operations never require software maintenance.

D. A project cannot produce a long-lived product.

Correct Answer: A. A project is temporary and creates a unique result, whereas operations are ongoing activities.

Question 2

Which stakeholder normally provides authority, support, or project resources?

A. End user

B. Project sponsor

C. Software tester

D. Database administrator

Correct Answer: B. Project sponsor

Question 3

What is the main purpose of feasibility analysis?

A. To guarantee that a project will succeed

B. To replace all requirements analysis

C. To assess whether a proposed project is practical and worthwhile

D. To select a programming language without considering context

Correct Answer: C. To assess whether a proposed project is practical and worthwhile

Question 4

Which requirement is non-functional?

A. The system shall allow a receptionist to cancel an appointment.

B. The system shall generate a monthly report.

C. The system shall allow users to reset a password.

D. The system shall respond to a standard request within two seconds under defined load.

Correct Answer: D. The system shall respond to a standard request within two seconds under defined load.

Question 5

Which life-cycle approach is generally most suitable when requirements are uncertain and stakeholders can provide frequent feedback?

A. Agile or iterative development

B. Purely sequential development with no reviews

C. No-life-cycle development

D. Retirement before implementation

Correct Answer: A. Agile or iterative development

Question 6

What is scope creep?

A. The removal of all project requirements

B. The addition of work without properly evaluating its impacts

C. The testing of software after deployment

D. The use of multiple programming languages

Correct Answer: B. The addition of work without properly evaluating its impacts

Question 7

Which statement about Java is most accurate?

A. Java is commonly used only for spreadsheet formulas.

B. Java is dynamically interpreted with no compile-time type checking.

C. Java offers strong typing and a mature ecosystem for enterprise and distributed systems.

D. Java cannot be used for backend services.

Correct Answer: C. Java offers strong typing and a mature ecosystem for enterprise and distributed systems.

Question 8

Which is a common strength of Python?

A. Rapid development and extensive libraries for automation and data work

B. Guaranteed absence of runtime errors

C. Inability to integrate with other systems

D. Exclusive use for operating-system kernels

Correct Answer: A. Rapid development and extensive libraries for automation and data work

Question 9

What does verification primarily ask?

A. Whether the right business problem was selected

B. Whether the product was built according to specified requirements

C. Whether the project has no stakeholders

D. Whether all risks have been eliminated

Correct Answer: B. Whether the product was built according to specified requirements

Question 10

Which practice best supports protection of sensitive project data?

A. Storing credentials in public source-code repositories

B. Giving every user administrator access

C. Applying least privilege, secure transmission, and appropriate access controls

D. Disabling audit records in all environments

Correct Answer: C. Applying least privilege, secure transmission, and appropriate access controls