Inside Application Development: Internal and External Workflows

UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 7.1 Free with a free account

Inside Application Development: Internal and External Workflows

System Analysis and Design · Chapter 7: Implementation, Testing, and MaintenanceSection 7.1 · lesson 46 of 698 min · free with a free account

← The Implementation and Coding Phase in the SDLCNext lesson: Writing It Down: Documentation and Communication Best Practices →

Earn 3 college credits for System Analysis and DesignRecommended for credit by NCCRS · Computer Science 390 · self-paced · one payment, lifetime access
Enroll in System Analysis and Design · $250 →Download the syllabus (PDF)

In this lesson

The internal and external workflows that get a release out the door.

  • Explain how version control and branching let a team change code safely
  • Describe the role of code review and CI/CD pipelines
  • Walk through a client change request, from submission to sign-off
  • Explain release management, and the risks of third-party vendors and APIs

Transcript

Everything said in the video, section by section (1,104 words). Read along, or search it.

Implementation, Testing, and Maintenance

Inside Application Development

Building software involves two workflows running side by side. This section looks inside both. First, how a team manages code internally. Version control, branching, code review, and automated pipelines. Then, how it works with the outside world. Client change requests, release management, and third-party vendors.

2 Workflows

Running Side by Side

The internal workflow governs how the development team manages and ships code, without stepping on each other's work. The external workflow governs how the team communicates and coordinates with the client, and with outside parties its software depends on. Both have to run smoothly. Otherwise a release goes out late, or it goes out on time, but does not match what was actually agreed to.

Internal Workflow

Version Control and Branching

Start with the foundation of the internal workflow, version control. A version control system records every change made to a codebase over time, along with who made it, and why. That gives a team three abilities. Several people can work on the same code at once. A change that broke something can be rolled back. And anyone can see exactly what changed between any two points in the project's history. On top of version control, teams adopt a branching strategy. It is a set of rules for how a team creates, names, and merges parallel lines of development.

Figure 1

A Common Branching Strategy

Here is a common branching strategy. There is a stable main branch at the top, and a develop branch below it. For each new piece of work, a short-lived feature branch is created from develop. The work happens on the feature branch, away from everyone else's changes. Once reviewed, the feature branch merges back into develop. The merges are the teal arrows. Here, two features go through that cycle, one after the other. Periodically, develop merges into main, for a release. So main only ever receives work that has already been reviewed and combined on develop.

Internal Workflow

Code Review

Code review is the practice of having at least one other developer read and approve a change, before it merges into a shared branch. The obvious benefit is catching bugs. A second reader sees what the author missed. But it does more than that. It spreads knowledge of the codebase across the team, so no single person is the only one who understands a part of it. And it keeps the code consistent with the team's standards. Imagine a developer merging a feature straight into main, skipping develop and skipping review. No one else has checked the change, and unfinished work could reach the stable branch and affect a release.

Figure 2

The CI/CD Pipeline

A continuous integration and continuous delivery pipeline, or C I C D pipeline, automates the steps a change must pass through. It builds, tests, and deploys the code every time it changes, rather than relying on someone to remember to do it by hand. A developer commits a change. The pipeline builds it, and runs automated tests against the build. The change is deployed to staging, and only after that does it reach production and real users. A failure at any stage stops the pipeline, and notifies the team. So a commit that builds, but fails its tests, never proceeds to staging or production. The problem is caught automatically, instead of relying on someone to notice later.

External Workflow

A Client Change Request

Now to the external workflow, starting with client change requests. A change request is a formal ask from the client to add, remove, or modify something, after requirements were already agreed on. It starts with the submission itself. Then, before any work begins, an analyst assesses its cost, its risk, and its impact on the schedule. Next, the client signs off on that scope and cost, so both sides agree on what is being built, and why. Then the team delivers the change. And a second sign-off confirms the client is satisfied with the result. Skip the first sign-off, and start building on a verbal request, and trouble follows. The two sides can later disagree about what was requested, what it should cost, or whether it was in scope at all.

External Workflow

Release Management

Release management is the coordinated process of deciding what goes into a release, when it ships, and how to recover if something goes wrong. It typically includes three practices. Versioning identifies exactly which release is which. Release notes tell stakeholders what changed. And a rollback plan stands ready in case the release needs to be reversed. Suppose a release goes out, and immediately causes errors for users. The rollback plan exists for exactly that moment. It restores the previous working version, rather than leaving users stuck while a fix is developed.

Third-Party Vendors and APIs

Risks You Plan Around, Not Prevent

Many systems depend on code or services the team does not control, such as a payment processor, or a mapping service reached through an A P I. That brings risks the team cannot fully manage on its own. A vendor may update or retire an endpoint the system relies on. Teams monitor vendor changelogs, and avoid depending on undocumented behavior. A vendor may enforce a rate limit, capping how many requests the system can make in a given time. Teams cache responses where possible, and handle a hit limit gracefully. And a vendor's service may go down. Teams define a fallback behavior, so one outage cannot take down the whole system. When a vendor tightens a rate limit, that is not a defect in the team's own code. But a well-planned integration would have anticipated it, rather than assuming the vendor's limits would never change.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Version control records every change made to a codebase, and who made it. A branching strategy is a set of rules for creating, naming, and merging parallel lines of development. A C I C D pipeline automatically builds, tests, and deploys code every time it changes. A change request is a formal ask to change agreed scope. A sign-off is the client's formal agreement. Release management decides what ships, when, and how to roll back. And a rate limit is a vendor's cap, on how many A P I requests a system can make, in a given time.

Key Takeaways

What to Carry Forward

To pull this together. Version control and branching strategies let a team change code in parallel, without overwriting each other's work. Code review and C I C D pipelines both catch problems before they reach users. One through human judgment, the other through automation. A client change request moves through assessment, sign-off on scope and cost, delivery, and a second sign-off. Release management coordinates what ships, when, and how to roll back if something goes wrong. And third-party vendors and A P Is bring risks, such as changes, rate limits, and outages, that a team has to plan around rather than prevent.

About System Analysis and Design at UPI Study

System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take System Analysis and Design with UPI Study

From business problem to working systemSystem Analysis and Design teaches how analysts study a business need and turn it into a system design: requirements, UML and data-flow models, interface and database design, implementation and project management. It is a core course in information systems and IT degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Inside Application Development: Internal and External Workflows

What is a branching strategy in version control?
A branching strategy is a set of rules for how a team creates, names, and merges parallel lines of development. In a common approach, a stable main branch sits above a develop branch, and each new piece of work gets a short-lived feature branch created from develop. After review, the feature merges back into develop, and develop periodically merges into main for a release.
What does a CI/CD pipeline do?
A CI/CD pipeline, short for continuous integration and continuous delivery, automatically builds, tests, and deploys code every time it changes. After a developer commits, the pipeline builds the change, runs automated tests, deploys to staging, and then to production. A failure at any stage stops the pipeline and notifies the team, so a commit that fails its tests does not reach real users.
What are the steps in handling a client change request?
A client change request moves through submission, assessment, sign-off, delivery, and a second sign-off. After the request is submitted, an analyst assesses its cost, risk, and schedule impact. The client then signs off on the scope and cost before work begins. The team delivers the change, and a final sign-off confirms the client is satisfied. Building on a verbal request invites later disputes about scope and price.
How should a system handle risks from third-party APIs?
Risks from third-party APIs are planned around rather than prevented, because the team does not control the vendor. Teams monitor vendor changelogs and avoid undocumented behavior in case an endpoint changes or is retired. They cache responses and handle rate limits gracefully. They also define fallback behavior so a vendor outage, such as a payment processor going down, does not take down the whole system.

About the System Analysis and Design course

How many college credits is System Analysis and Design?
System Analysis and Design (Computer Science 390) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does System Analysis and Design cost and what is included?
$250, paid once, with lifetime access: all 69 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does System Analysis and Design take?
It is self-paced with no deadlines. The 69 lessons total about 9 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in System Analysis and Design.

69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in System Analysis and Design →Download the syllabusEvery course with PRO →
System Analysis and Design
3 credits · NCCRSEnroll →