Application Design, Delivery, and Emerging Practice

Introduction

Programming becomes professionally valuable when a developer can transform a real need into a reliable, usable, and maintainable application. Writing code is only one part of this process. A complete development activity includes understanding requirements, estimating work, selecting an appropriate design, implementing and testing the solution, delivering it to users, and evaluating its quality after release.

This chapter presents an end-to-end approach suitable for small Java or Python applications. It also considers contemporary development practices, including cloud deployment, automation, low-code platforms, data-driven development, and artificial-intelligence-assisted programming. These technologies can increase productivity, but they do not remove the need for sound reasoning, testing, security, documentation, or professional accountability.

Learning Objectives

By the end of this chapter, a learner should be able to:

• translate a simple problem statement into functional and non-functional requirements;
• estimate tasks, dependencies, effort, and risk for a small application;
• select and justify a suitable application structure;
• implement a small Java or Python application using appropriate development practices;
• apply testing, version control, documentation, and deployment procedures;
• evaluate application quality using evidence rather than intuition;
• explain the roles of cloud services, automation, low-code tools, data, and AI in modern development;
• identify ethical, security, privacy, and governance responsibilities.

1. From Requirement to Deliverable

A requirement describes a capability or constraint that stakeholders expect from a system. Functional requirements state what the system must do. For example, a library application may need to “record a book loan” and “display overdue items.” Non-functional requirements describe qualities or constraints, such as usability, security, performance, availability, portability, and maintainability.

A useful requirement should be clear, testable, and sufficiently specific. “The application should be fast” is weak because “fast” is undefined. “A search request should normally return results within two seconds on the stated test environment” is more useful because it can be evaluated.

A small project can express requirements through user stories:

As a library assistant, I want to record a member borrowing a book so that the current loan status is accurate.

A good user story is supported by acceptance criteria. For example:

• a valid member and available book can be selected;
• the loan date is recorded automatically;
• an unavailable book cannot be loaned;
• the operation produces a clear success or error message;
• the updated status remains available after the program is restarted, if persistence is required.

Acceptance criteria connect requirements to testing. Each criterion should have at least one verification method.

Scope and the Minimum Viable Product

Scope defines what is included in the release. A minimum viable product (MVP) contains the smallest coherent set of features that delivers useful value and permits meaningful feedback. For a small library application, an MVP might include adding books, registering members, issuing books, returning books, and listing current loans. Automated recommendations and mobile synchronization may be deliberately postponed.

Uncontrolled growth in scope, often called scope creep, creates schedule and quality problems. A change-control record should identify the requested change, its benefit, estimated effort, dependencies, and effect on the release date.

2. Planning and Estimating Work

Planning converts a desired outcome into activities that can be assigned, ordered, and monitored. A work breakdown structure divides the project into manageable tasks. A small application might contain:

Estimates should be treated as forecasts, not promises. A task estimate should state its assumptions. For example, “two hours to implement file storage, assuming the data format and directory permissions are already defined” is more informative than “file storage: two hours.”

A simple planning method uses optimistic, most likely, and pessimistic estimates. The three-point expected estimate is:

Here, E is the expected duration, O is the optimistic duration, M is the most likely duration, and P is the pessimistic duration. The method assumes that the three estimates are reasonable and that the most likely estimate deserves greater weight. It is a planning aid, not a guarantee of actual duration.

For example, if testing is estimated at O = 2 hours, M = 4 hours, and P = 8 hours:

E = (2 + 4×4 + 8) ÷ 6 = 26 ÷ 6 ≈ 4.33 hours.

The result should not be reported with false precision. “About four to five hours” is an appropriate practical interpretation.

Dependencies also matter. Database design may need to precede persistence code, while documentation can occur throughout the project. A critical path is a sequence of dependent tasks that determines the earliest possible completion time. Adding people does not always shorten a project, especially when communication and coordination increase.

Risk planning identifies uncertain events and responses. A simple risk priority score can be calculated as:

P is the estimated probability of occurrence and I is the estimated impact, both measured on a defined ordinal scale such as 1 to 5. The score is useful for ranking risks but is not a probability of loss and should not be interpreted as a precise statistical prediction.

Example: a dependency failure assessed as P = 3 and I = 5 has R = 15. It may deserve more attention than a usability issue assessed as P = 4 and I = 2, which has R = 8. The team should still examine the underlying descriptions rather than relying only on scores.

3. Choosing an Application Design

Design decisions should be justified by requirements, constraints, and anticipated change. A small program does not require an elaborate enterprise architecture, but it does benefit from separation of concerns.

A basic layered structure is:

1. Presentation layer: accepts input and displays results.
2. Application or service layer: coordinates use cases and business rules.
3. Domain layer: represents important concepts and validations.
4. Persistence layer: stores and retrieves data.

For a command-line Python application, these layers may be separate modules rather than separate deployed services. In Java, they may be represented by packages and classes. The purpose is not the number of files; it is the clarity of responsibilities.

A domain object such as Book should represent book-related state and rules. A service such as LoanService may determine whether a book can be issued. A repository such as BookRepository may read or write data. The interface should not contain database logic if that logic can be isolated.

Design Alternatives

A file-based design is simple, portable, and suitable for a single-user prototype. Its limitations include weak concurrent access, limited querying, and greater responsibility for data consistency. A relational database provides structured queries, constraints, and transaction support, but introduces configuration and operational complexity.

A monolithic application packages the system as one deployable unit. For a small certificate-level project, this is usually more appropriate than microservices. Microservices may provide independent scaling and deployment, but they also introduce network communication, monitoring, service discovery, distributed failure, and operational overhead.

A design justification should therefore answer:

• What requirement does the decision support?
• What alternatives were considered?
• What assumptions are being made?
• What risks or maintenance costs result?
• Can the design be changed later without excessive rework?

4. Implementation Practices in Java and Python

Java and Python support the same fundamental programming ideas but encourage different styles. Java commonly emphasizes explicit types, interfaces, classes, packages, and compile-time checking. Python commonly emphasizes concise syntax, dynamic typing, modules, and rapid experimentation. Neither language automatically produces better software; quality depends on design and development discipline.

Useful implementation practices include:

• meaningful names for variables, functions, classes, and modules;
• small functions with one clear responsibility;
• validation at system boundaries;
• avoidance of duplicated business rules;
• explicit handling of expected errors;
• configuration outside the source code where practical;
• comments that explain decisions rather than restating syntax;
• consistent formatting and style checks;
• removal of unused code and temporary debugging output.

Input validation should distinguish invalid format from valid but unacceptable values. For example, an empty member identifier is a format or presence error, while a valid identifier belonging to a suspended member is a business-rule error. Error messages should help the user recover without exposing confidential information or internal stack traces.

A small application should also make its environment clear. A Python project may use a virtual environment and a dependency declaration such as requirements.txt or a modern project configuration file. A Java project may use Maven or Gradle to declare dependencies, compile code, run tests, and create a package. Dependencies should be versioned and obtained from trusted sources.

5. Testing and Quality Evaluation

Testing provides evidence that software behaves as intended under selected conditions. It cannot prove that a program has no defects, because the set of all possible inputs and environments is usually too large. However, systematic testing reduces uncertainty.

Unit tests examine a small unit, such as a function or class, in isolation. Integration tests examine interactions, such as a service with a repository. System or acceptance tests examine behavior from a user or external-system perspective.

A useful test case records input, preconditions, expected result, actual result, and status. Test categories include:

• normal valid input;
• boundary values, such as zero or maximum permitted quantity;
• invalid and missing input;
• duplicate records;
• unavailable resources;
• persistence and restart behavior;
• authorization and sensitive-data handling;
• failure of external services.

For a function that accepts a quantity from 1 through 10, values 1 and 10 test boundaries, while 0 and 11 test nearby invalid values. This is more informative than testing only the value 5.

Quality is multidimensional. A practical evaluation may examine:

Measurements require context. A response time measured on a developer laptop cannot automatically represent cloud performance. Quality claims should state the test environment, sample conditions, and limitations.

6. Version Control, Automation, and Delivery

Version control records changes and supports collaboration. A repository should contain source code, tests, documentation, configuration templates, and appropriate ignore rules. It should not contain passwords, private keys, production database credentials, or personal data.

A useful commit records one coherent change and has a meaningful message. Branching strategies should be proportionate to project size. A small individual project may use a main branch with short-lived feature branches; a larger team may require pull requests and review rules.

Continuous integration (CI) automatically performs activities such as dependency installation, compilation, linting, testing, and packaging when changes are submitted. Continuous delivery extends this approach by keeping software in a releasable state and automating release preparation. Continuous deployment automatically releases changes after required checks, but it requires stronger controls and monitoring.

Automation reduces repeated manual work, but a pipeline is not automatically correct. It must be tested, access-controlled, and monitored. A failed test should normally prevent delivery when the failure indicates a release risk. Secrets should be supplied through secure environment or secret-management mechanisms rather than hard-coded in scripts.

Deployment options include a local executable, a packaged desktop application, a web application on a server, or a container deployed to a cloud platform. The correct option depends on users, budget, data sensitivity, availability requirements, and operational skills. Cloud services can provide managed storage, hosting, monitoring, and scaling, but they introduce provider dependence, recurring cost, configuration risk, and data-location considerations.

A reproducible delivery process should specify:

• required runtime and dependency versions;
• installation and configuration steps;
• database or file-storage initialization;
• health checks and logging;
• backup and recovery procedures;
• rollback or removal steps;
• ownership of post-release support.

7. An Illustrative Case: Community Library Loan Application

Background and Problem

This fictional case concerns a small community library currently recording loans in a spreadsheet. Staff report duplicate entries, difficulty identifying overdue books, and uncertainty about whether data has been saved. The library requests a modest application that can run on one computer and later be hosted for several staff members.

Analysis

The initial requirements are:

• register books and members;
• issue an available book to an active member;
• record the issue date and due date;
• return a book;
• list current and overdue loans;
• preserve data between executions;
• provide understandable error messages.

The MVP excludes online payments, automated email, recommendation algorithms, and integration with external library systems. These exclusions protect the schedule and reduce privacy and operational complexity.

Design Approach

A small layered Python application is selected. A command-line interface is sufficient for the first release, and SQLite is selected instead of a text file because it provides structured records and basic transaction support without requiring a separate database server. The design contains Book, Member, and Loan concepts; a service module enforces issuing and returning rules; repository functions handle database access.

The choice is justified by the single-site scale, low infrastructure budget, and need for reliable persistence. If simultaneous multi-site access becomes necessary, the repository layer can later be adapted to a hosted relational database and the interface can be replaced by a web front end.

Implementation and Testing

The service rejects an issue request when the member does not exist, the member is inactive, the book does not exist, or the book is already on loan. Tests cover each rejection and a successful issue-return cycle. An integration test verifies that a loan remains present after the application is closed and reopened.

The team uses a repository containing source code, tests, setup instructions, and a sample database schema. A CI workflow runs the test suite on every change. The sample data contains fictional records only.

Delivery and Outcome

The first release is installed on the library computer using a documented setup script. Staff test common tasks using acceptance criteria. Feedback reveals that the phrase “operation failed” is unhelpful, so messages are revised to identify the actionable problem, such as “Book is already on loan.”

The outcome is not merely a working program. It is a documented, tested, reproducibly installed application with known limitations. Future development may add a web interface, role-based access, backups, and reporting, but each addition requires new requirements and tests.

Learning Points

The case demonstrates that design quality depends on fit rather than sophistication. A simple architecture can be professional when its assumptions are explicit, its risks are controlled, and its behavior is tested. It also shows why deployment, feedback, and maintenance must be considered from the beginning.

8. Emerging Development Practices

Cloud and Platform Services

Cloud computing changes the location and management of infrastructure. Infrastructure as a service provides virtualized computing and networking; platform as a service manages more of the runtime environment; software as a service delivers a complete application. Cloud development can improve elasticity and availability, but users remain responsible for application security, configuration, identity management, cost control, and lawful data handling.

Low-Code and No-Code Development

Low-code tools provide visual components, workflow designers, and generated code or configurations. They are valuable for forms, approvals, dashboards, and routine internal processes. Risks include vendor lock-in, limited customization, hidden performance constraints, weak version control, and insufficient understanding of generated behavior. Low-code does not eliminate the need for requirements analysis, testing, access control, and data governance.

Data-Driven Development

Applications increasingly use logs, usage measurements, and business data to guide decisions. Data-driven development requires attention to data quality, representativeness, lineage, retention, and privacy. A dashboard can make poor data appear authoritative; measurement design is therefore part of software quality.

AI-Assisted Development

AI tools can generate code, tests, documentation, explanations, and refactoring suggestions. They can accelerate routine work and help learners explore alternatives. However, generated output may contain defects, insecure practices, licensing concerns, fabricated application-programming interfaces, or inappropriate assumptions. Developers remain responsible for reviewing, testing, and understanding submitted code.

Good practice includes avoiding confidential prompts, checking generated dependencies, reviewing security-sensitive code manually, testing edge cases, recording material AI assistance where organizational policy requires it, and ensuring that human decisions remain accountable. AI should support engineering judgment, not replace it.

9. Ethical, Security, and Governance Responsibilities

Even a small application may process personal information. Developers should collect only necessary data, restrict access, protect credentials, and define retention and deletion practices. Privacy obligations depend on jurisdiction, but principles such as purpose limitation, data minimization, accuracy, and secure processing are broadly useful.

Threat modeling asks what could go wrong, who could cause it, and how the impact can be reduced. Common risks include injection through unvalidated input, exposed secrets, excessive privileges, insecure dependencies, inadequate backups, and leakage through logs. Passwords must never be stored as plain text; authentication systems should use established, appropriately configured password-hashing mechanisms.

Accessibility is also a quality responsibility. Interfaces should provide understandable labels, adequate contrast, keyboard access where relevant, and messages that do not rely only on color. Professional conduct includes accurate claims about system capability, disclosure of limitations, and prompt correction of serious defects.

Challenges and Limitations

Small projects face limited time, incomplete requirements, changing priorities, and uneven technical experience. Estimates may be inaccurate because unfamiliar tasks contain hidden work. Automated tests may miss misunderstood requirements. Cloud deployment may fail because of configuration or network assumptions. AI-generated code may appear plausible while violating business rules.

These limitations cannot be removed completely. They can be managed through incremental delivery, explicit assumptions, review, risk registers, automated checks, documentation, backups, and feedback from real users. A mature developer treats uncertainty as something to expose and manage rather than conceal.

Best-Practice Checklist

Before release, confirm that:

• requirements and acceptance criteria are written and prioritized;
• scope and assumptions are explicit;
• the design separates major responsibilities appropriately;
• source code is under version control;
• tests cover normal, boundary, invalid, and failure cases;
• dependencies and runtime versions are documented;
• secrets and personal data are protected;
• installation, configuration, backup, and rollback procedures exist;
• users have tested realistic workflows;
• known limitations and support responsibilities are recorded;
• any AI or generated component has been reviewed and tested.

Chapter Summary

Application development is an end-to-end professional activity. It begins with clear, testable requirements and continues through scope management, estimation, design, implementation, testing, delivery, and evaluation. A small application benefits from simple separation of concerns, explicit assumptions, version control, automated checks, and reproducible deployment.

Java and Python provide suitable foundations for certificate-level applications, but language choice alone does not determine quality. Design decisions should be justified by user needs, constraints, risks, and future change. Cloud services, low-code platforms, data-driven methods, and AI-assisted tools can improve productivity, yet they introduce new issues involving cost, privacy, security, dependency, bias, and accountability. Professional developers therefore combine technical skill with evidence-based evaluation, ethical judgment, and continuous learning.

Key Terms

Requirement: A desired capability, behavior, or constraint of a system.

Functional requirement: A statement of what a system must do.

Non-functional requirement: A quality or constraint such as security, usability, or performance.

Acceptance criterion: A condition used to determine whether a requirement is satisfied.

Minimum viable product: The smallest useful release that can generate meaningful feedback.

Scope creep: Uncontrolled expansion of project requirements.

Work breakdown structure: A decomposition of project work into manageable tasks.

Critical path: The dependency sequence determining the earliest possible completion time.

Risk: An uncertain event that may affect objectives.

Layered architecture: A design that separates presentation, application, domain, and persistence responsibilities.

Persistence: The storage of data beyond the execution of a program.

Unit test: A test of a small isolated software component.

Integration test: A test of interactions between components.

Continuous integration: Automated building and testing of software changes.

Continuous delivery: Keeping software in a releasable state through automated processes.

Cloud computing: On-demand computing resources delivered through networked services.

Low-code development: Software development using visual tools and limited handwritten code.

Data governance: Policies and controls for data quality, access, use, retention, and protection.

Threat modeling: A structured analysis of possible threats and mitigations.

Technical debt: Future maintenance cost created by expedient or inadequate technical choices.

Review Questions

Short Answer Questions

1. Distinguish between a functional requirement and a non-functional requirement.
2. What is the purpose of acceptance criteria?
3. Name four layers commonly used in a small application design.
4. What is the difference between a unit test and an integration test?
5. State two risks associated with AI-assisted programming.

Long Answer Questions

1. Explain how a requirement can be transformed into implementation and test activities.
2. Discuss the advantages and limitations of using a file-based design, SQLite, and a hosted database for a small application.
3. Explain why version control and continuous integration improve software delivery.
4. Describe the responsibilities of a developer when an application processes personal data.
5. Compare cloud, low-code, and conventional development approaches for an internal business application.

Analytical / Application Questions

1. A student team proposes building a multi-service cloud architecture for a single-user library prototype. Evaluate the proposal and recommend a more appropriate design, giving reasons.
2. Using O = 3 hours, M = 6 hours, and P = 9 hours, calculate the three-point expected estimate for a testing task and explain how the result should be used in planning.
3. Design a test strategy for the library loan application. Include normal, boundary, invalid, persistence, security, and acceptance tests, and explain the evidence each category provides.

Multiple Choice Questions with Answers

Question 1

Which statement is a non-functional requirement?

A. The system records a returned book.

B. The system registers a new member.

C. The system normally responds to a search within two seconds.

D. The system lists current loans.

Correct Answer: C. The system normally responds to a search within two seconds.

Question 2

What is the main purpose of acceptance criteria?

A. To choose a programming language

B. To determine whether a requirement has been satisfied

C. To replace all unit tests

D. To estimate cloud storage cost

Correct Answer: B. To determine whether a requirement has been satisfied

Question 3

Using E = (O + 4M + P) ÷ 6, what is the expected estimate when O = 3, M = 6, and P = 9 hours?

A. 5 hours

B. 6 hours

C. 7 hours

D. 9 hours

Correct Answer: B. 6 hours

Question 4

Which layer should primarily handle saving and retrieving records?

A. Presentation layer

B. Persistence layer

C. User-interface styling layer

D. Documentation layer

Correct Answer: B. Persistence layer

Question 5

Which test examines whether a loan remains after the application is closed and reopened?

A. Unit test only

B. Integration or persistence test

C. Syntax test

D. Usability survey only

Correct Answer: B. Integration or persistence test

Question 6

What is a principal benefit of continuous integration?

A. It removes the need for requirements.

B. It automatically tests and checks submitted changes.

C. It guarantees that software has no defects.

D. It prevents all future maintenance.

Correct Answer: B. It automatically tests and checks submitted changes.

Question 7

Which practice is safest for application secrets?

A. Hard-code them in a public repository.

B. Place them in comments for convenience.

C. Use an appropriate secure configuration or secret-management mechanism.

D. Store them in user-visible error messages.

Correct Answer: C. Use an appropriate secure configuration or secret-management mechanism.

Question 8

Why might SQLite be appropriate for the first release of a small library application?

A. It requires a large distributed cluster.

B. It provides structured persistence without a separate database server.

C. It automatically solves every access-control problem.

D. It is always superior to hosted databases.

Correct Answer: B. It provides structured persistence without a separate database server.

Question 9

Which is a limitation of AI-generated code?

A. It can never produce syntactically valid code.

B. It may contain insecure or incorrect assumptions.

C. It cannot generate documentation.

D. It eliminates the need for human review.

Correct Answer: B. It may contain insecure or incorrect assumptions.

Question 10

What does scope creep mean?

A. Reducing the number of requirements before release

B. Uncontrolled expansion of project requirements

C. Automating a test suite

D. Separating application layers

Correct Answer: B. Uncontrolled expansion of project requirements