SOFTWARE DEVELOPMENT

LIFE CYCLE (SDLC)

AGENDA
 Role of Technical Writer in IT Sector
 Waterfall Model
 Agile Model
 Difference between Waterfall vs Agile
 Scrum and its Keywords
 Role of TW In AGILE And SCRUM
 Common Docs in IT Sector...
 Discussion On API and API Docs with Images
 Purpose Of JIRA And CONFLUCNCE.
 Role of TW in Confluence And SEO
 Seo Writing
 Camtasia Purpose
 ROLE OF TW IN IT SECTOR
 Technical writers are professional writers who produce instructions and how-to guides for
consumers. Technical writers write the answers to frequently asked questions for
businesses and work directly with their clients to accurately create and write content for
them.
 A technical writer’s job involves researching, organizing, writing, editing, and formatting
technical information to produce high-quality documents for a specific audience. These
documents can range from user manuals, training materials, white papers, and technical
reports and documents such as instruction manuals, intermediate to end-user manuals,
reference guides, operating procedure guides, white papers, and specialized product
descriptions.
ROLE OF TW IN IT SECTOR
 WHAT IS SDLC ?
 Software development life cycle (SDLC) is a structured process that is used to design,
develop, and test good-quality software. SDLC, or software development life cycle, is a
methodology that defines the entire procedure of software development step-by-step.
 The goal of the SDLC life cycle model is to deliver high-quality, maintainable software that
meets the user’s requirements. SDLC in software engineering models outlines the plan for
each stage so that each stage of the software development model can perform its task
efficiently to deliver the software at a low cost within a given time frame that meets users’
requirements.
SDLC
RELATION BETWEEN SDLC AND TECHNICAL WRITING
 From a technical writing standpoint, SDLC provides a structured framework within which
documentation can be planned, developed, and maintained alongside the software itself.
 Technical writers and content developers benefit from understanding the Software
Development Life Cycle (SDLC) because it provides essential context for their work. Here’s
why:
 Clarity on Software Processes
 Documentation Throughout the Lifecycle
 Effective Communication
 Risk Mitigation
 Quality Assurance and Testing
 Change Management
 WATERFALL MODEL

 In the waterfall method, each step is

dependent on the output of the previous
step. There's a linear progression to the
way these projects unfold.
 The steps always follow in this order and
do not overlap. The developer must
complete every phase before the next
phase begins.
AGILE MODEL
 Agile model is a software development approach
that adapts to changing requirements and
feedback.
 It breaks down tasks into short iterations or time
boxes, each with a specific functionality and scope.
 It encourages teamwork, cross-training,
and customer involvement throughout the
project lifecycle.
 It was proposed in the mid-1990s as an alternative
to the rigid and linear waterfall model.
 It has advantages such as faster delivery, higher
quality, and lower risk of failure,
 It also has challenges such as lack of
documentation, stability, and scalability
DIFFERENCE BETWEEN AGILE AND
WATERFALL
ROLE OF TW IN AGILE
 In an Agile model, a technical writer must adapt efficiently and effectively as the software
develops. As a Technical Writer, you have to document in a limited time, which makes
the requirement gathering more challenging. You also have to depend on interacting
with project teams to gather requirements rather than reading the requirements.
 In the agile environment, the technical writers should get familiar with
developing documentation using XML based authoring tools. Most importantly, they should
be prepared for the following:
• Stay well-informed of the product changes.
• Keep the documentation ready for constant changes as the requirements.
• Reuse content using XML authoring tools such as Madcap Flare and Adobe FrameMaker, and create
editable content across a common repository for project teams, if the need arises for them to
provide inputs.
• Regular communication with the software developers and engage feedback in every SDLC stage
from daily sprint reviews and user acceptance testing to final product sign-off.
SCRUM
 Scrum is an agile project management framework that helps teams structure and manage
their work through a set of values, principles, and practices. Much like a rugby team (where
it gets its name) training for the big game, scrum encourages teams to learn through
experiences, self-organize while working on a problem, and reflect on their wins and losses
to continuously improve.
 Scrum is a framework used to manage product development and other knowledge work in
an agile way.
 Scrum is based on empiricism, which means that teams learn from experience and
experiments.
 Scrum involves breaking work into goals that are completed within time-boxed iterations,
called SPRINTS.
 Scrum also describes a set of meetings, tools, and roles that help teams structure and
manage their work.
THE AGILE – SCRUM FRAMEWORK
PRINCIPLES OF SCRUM

 Transparency

The team must work in an environment where everyone is aware of what issues
other team members are running into.
 Inspection

Frequent inspection points are built into the framework to allow the team an
opportunity to reflect on how the process is working. These inspection points include
the Daily Scrum meeting and the Sprint Review Meeting.
 Adaptation

The team constantly investigates how things are going and revises those items that
do not seem to make sense.
SCRUM PRACTICES/EVENTS

1. SPRINT
The Sprint is a timebox of one month or less during which the team produces a potentially
shippable product Increment. Typical characteristics of Sprints:
 Maintain a consistent duration throughout a development effort
 A new Sprint immediately follows the conclusion of the previous Sprint
 The start date and end date of Sprint are fixed

2. SPRINT PLANNING / SPRINT BACKLOG

 A team starts out a Sprint with a discussion to determine which items from the product backlog
they will work on during the Sprint. The end result of Sprint Planning is the Sprint Backlog.
 Sprint Planning typically occurs in two parts. In the first part, the product owner and the rest of the
team agree on which product backlog items will be included in the Sprint.
 In the Second Part of Sprint Planning, the team determines how they will successfully deliver the
identified product backlog items as part of the potentially shippable product increment.
CONT..

3. DAILY SCRUM
The Daily Scrum is a short (usually limited to 15 minutes) discussion where the team
coordinates their activities for the following day. The Daily Scrum is not intended to be
a status reporting meeting or a problem- solving discussion.

4. SPRINT REVIEW
At the end of the Sprint, the entire team (including the product owner) reviews the results of
the sprint with stakeholders of the product. The purpose of this discussion is to discuss,
demonstrate, and potentially give the stakeholders a chance to use, the increment in order to get
feedback. The Sprint Review is not intended to provide a status report.

5. SPRINT RETROSPECTIVE
At the end of the Sprint following the sprint review, the team (including the product owner)
should reflect upon how things went during the previous sprint and identify adjustments they
SCRUM ARTIFACTS
1. PRODUCT BACKLOG
The product backlog is an ordered list of all the possible changes that could be made to the product.
Items on the product backlog are options, not commitments in that just because they exist on the
Product Backlog does not guarantee they will be delivered. The Product Owner
maintains the product backlog on an ongoing basis including its content, availability, and ordering.

2. Sprint Backlog
The Sprint Backlog is the collection of product backlog items selected for delivery in the Sprint, and if the
team identifies tasks, the tasks necessary to deliver those product backlog items and achieve the Sprint
Goal.

3. Increment
The increment is the collection of the Product Backlog Items that meet the team’s Definition of Done by
the end of the Sprint. The Product Owner may decide to release the increment or build upon it in future
Sprints.

4. Definition of Done
The definition of done is a team’s shared agreement on the criteria that a Product Backlog Item must
meet before it is considered done.
SCRUM ROLES
 THE PRODUCT OWNER

The product owner is a role team responsible for managing the product backlog in order to
achieve the desired outcome that the team seeks to accomplish. The product owner role
exists in Scrum to address challenges that product development teams had with multiple,
conflicting directions or no direction at all with respect to what to build.
 THE SCRUM MASTER

The scrum master is the team role responsible for ensuring the team lives agile values and
principles and follows the processes and practices that the team agreed they would use. The
name was initially intended to indicate someone who is an expert at Scrum and can therefore
coach others. The role does not generally have any actual authority.
 THE DEVELOPMENT TEAM

The development team consists of the people who deliver the product increment inside a
Sprint. The main responsibility of the development team is to deliver the increment that
delivers value to every Sprint. How the work is divided up to do that is left up to the team to
determine based on the conditions at that time.
 SCRUM LIFECYCLE
 Scrum is a framework that allows development teams the flexibility to respond to changing
situations. The Scrum Lifecycle starts with a prioritized backlog but does not provide any guidance
as to how that backlog is developed or prioritized. The Scrum Lifecycle consists of a series of
Sprints, where the end result is a potentially shippable product increment.
1. Establish the Product Backlog.
2. The product owner and development team conduct Sprint Planning. Determine the scope of the Sprint in the
first part of Sprint Planning and the plan for delivering that scope in the second half of Sprint Planning.
3. As the Sprint progresses, the development team performs the work necessary to deliver the selected product
backlog items.
4. On a daily basis, the development team coordinates their work in a Daily Scrum.
5. At the end of the Sprint, the development team delivers the Product Backlog Items selected during Sprint
Planning. The development team holds a Sprint Review to show the customer the increment and get
feedback. The development team and product owner also reflect on how the Sprint has proceeded so far and
adapted their processes accordingly during a retrospective.
6. The Team repeats steps 2–5 until the desired outcome of the product has been met.
API DOCUMENTATION

• API documentation, also known as API docs, is a crucial resource for developers who want to use and
integrate with an application programming interface (API).
• API documentation should be clear, concise, and visual. It should include a clear explanation of
what the method/resource does, call-outs that share important information with developers, including
warnings and errors, and a sample call with the correlating media type body. API documentation can
be made up of a single document or be divided into multiple, connected parts. It is recommended that
the root OpenAPI document be named openapi.json or openapi.yaml. There are four common types of
API documentation:
• Reference documentation
• Tutorials
• Examples and code samples
• Error Messages
TOOLS FOR API DOCUMENTATION
 A well-crafted API documentation empowers developers and ensures successful API
integration! 🚀 If you’re interested in creating your own API docs, tools like Postman and
Stoplight can help you get started.

 Purpose of API Documentation

1. Explanation: API documentation provides human-readable instructions on how to work with a
specific API.
2. Content: It includes details about available endpoints, methods, resources, authentication
protocols, parameters, headers, and examples of common requests and responses.
3. Benefits: Effective API documentation improves the developer experience, streamlines
collaboration, reduces support tickets, and increases API adoption.
EXAMPLES
 Google Maps API's Documentation looks similar to other pages you'll find in the Google
network. With its white background and famous font, this documentation is easy to read
and feels instantly familiar. Finding the information you require for Google Maps API is
simple.
 Twilio’s API Documentation starts with an introductory page that lists different
documents for all of its product's capabilities. Clicking on one of these documents will take
you to a separate page with a menu on the leftmost side of the screen that lists topics and
subtopics, making it easy to find the content you need.
JIRA AND CONFLUENCE

• Jira and Confluence are work collaboration tools developed by Atlassian.

• Confluence is designed for documentation and allows you to create and share
information, brainstorm ideas, and manage projects
• Jira is primarily intended for project management and issue tracking. It helps teams plan
and track project work
DIFFERENCE BETWEEN CONFLUENCE AND JIRA
ROLE OF TECHNICAL WRITER IN CONFLUENCE

 We needs a great technical writing tool to sync with product and development teams.
That’s where Confluence comes into play. With more people switching to online
documentation and collaborative tools like Confluence, technical writers need to
understand the best practices that come with using such platforms.
THINGS TO KEEP IN MIND WHILE USING CONFLUENECE

Following the best practices for technical writers can make their content organized, explicit,
and easier to navigate. Here are some tips to make the most out of Confluence:

 Find a responsible person who can ensure content accuracy.

 Use macros and content elements (like tables or lists) in Confluence to format the content.
 The Confluence team offers various templates. Use them to create a consistent design for
your technical documentation.
 Add labels to categorize and organize the documents.
 Use the inclusive library to hold the content you want to reuse in one place. Reuse the
content wisely.
 Create page templates to be used as a guide for each record.
 Ensure you adhere to security policies and guidelines when sharing documents with other
teams.
 Regularly review the content and update it as needed.
 Employ third-party tools, like Talk – Advanced Inline Comments, to make your content more
interactive and engaging.
DEVELOP TECHNICAL DOC WITH CONFLUENCE

 Confluence is a flexible platform with a range of features and Marketplace apps that can help you capture,
distribute, and update your technical documentation. Below are some tips to help you get your technical
documentation site started, and to save you time and effort managing your documentation's life cycle.

 Create your Documentation Space

 Save time by re-using content
 Create an inclusions library (optional)
 Use page templates
 Draft your work
 Use links and anchors
 Useful macros
 Keep track of page updates
 Customize PDF export
THANK YOU