Object Oriented Software

Engineering
Chapter 1: Introduction
Computer Software
Computer software is the product that software professionals build and
then support over the long term.
A textbook description of software might take the following form:

Software is:

1. Instructions (computer programs) that when executed provide

desired features, function, and performance;

2. Data structures that enable the programs to adequately manipulate

information, and

3. Descriptive information in both hard copy and virtual forms that

describes the operation and use of the programs.
Computer Software
Software has characteristics that are considerably different than those
of hardware:

1. Software is developed or engineered; it is not manufactured in the

classical sense.

2. Software doesn’t wear out, but it does deteriorate.

3. Although the industry is moving toward component-based

construction, most software continues to be custom built.
History of Software Engineering
● Programmers moved from machine language, to assembly language, to
high-level language. Also, the concern of organizational privacy increase
and the hardware manufacturing company stated to develop software for
their hardware product.

● In 1968, a NATO report coined the term "software engineering". It discuss

about the group work for software engineering in more systematic way.

● Hardware became faster and cheaper, outpacing the ability of software to

keep up

● By the 1980's the software cost of a system had risen to 80%, and many
experts pronounced the field "in crisis" because the software development
face the problem of not delivered on time, over budget, unmaintainable
due to poor design and documentation, and unreliable due to poor system
analysis and testing. Increase the use of object-oriented programming
● Java is developed and released in the mid-1990s. Increasing
attention paid to notions of software architecture. Client-server
distributed architectures are increasingly used. The UML is
proposed.
● Today, the use of integrated development environments becomes
more common. Use of stand-alone CASE tools declines. Use of the
UML becomes widespread. Increasing use of scripting languages
such as Python and PERL for software development. C# developed
as a competitor to Java.
Types of Software
Software is the collection of computer programs, procedures and
documentation that performs different tasks on a computer system.

The term 'software' was first used by John Tukey in 1958. At the very
basic level, computer software consists of a machine language that
comprises groups of binary values, which specify processor instructions.

The processor instructions change the state of computer hardware in a

predefined sequence.

Briefly, computer software is the language in which a computer speaks.

Computer software can be put into categories based on common
function, type, or field of use.
Types of Software
There are three broad classifications:
● Application Software: It enables the end users to accomplish certain
specific tasks. They include programs such as web browsers, office
software, games, and programming tools.
● System Software: It helps in running computer hardware and the
computer system. System software refers to the operating systems;
device drivers, servers, windowing systems and utilities (e.g. anti-
virus software, firewalls, disk defragmenters).
● Malicious Software or Malware: Malware refers to any malicious
software to harm and disrupt computers. Adware, spyware,
computer viruses, worms, Trojan horses and scareware are malware.
Software Engineering
Software engineering encompasses a process, a collection of methods
(practice) and an array of tools that allow professionals to build high quality
computer software in a timely manner.

Thus, the software engineering includes overall activities performed during the
production of software such as requirement analysis, planning, designing,
estimation, scheduling and module development, combination of modules for
overall product, testing the deliverables, delivery to the owner, and finally
feedback from the customers.

Now, the same cycle repeats again in response to the feedback for making the
software product more energetic and more perfect as the user requirement.
Role of Software Engineering in System Design

Software is what enables us to use computer hardware effectively and is needed

for our modern life. A software system is often a component of a much larger
system.

The software engineering activity is therefore a part of a much larger system

design activity in which the requirements of the software are balanced against
the requirements of other parts of system being designed e.g. a telephone
switching system consists of computers, telephone lines and cables, telephones,
satellites and finally software to control the various other components.

It is the combination of all these components that is expected to meet the

requirements of the whole system. Power plant or traffic monitoring system,
banking system, hospital administration system are other examples of systems
that exhibit the need to view the software as a component of a larger system.
Role of Software Engineering in System Design

Software Process

When you walk to build a product or system, it is important to go through a series

of predictable steps: a road map that helps you to create a timely, high quality
result. The road map that you follow is called a “Software Process”.

Thus, a process is a collection of activities, actions, and tasks that are performed
when some work product is to be created. In the context of software engineering,
a process is not a rigid prescription for how to build computer software.

Rather, it is an adaptable approach that enables the people doing the work (the
software team) to pick and choose the appropriate set of work actions and tasks.

The intent is always to deliver software in a timely manner and with sufficient
quality to satisfy those who have sponsored its creation and those who will use it.
Role of Software Engineering in System Design

Software Process Framework

A process framework establishes the foundation for a complete software engineering

process by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.

In addition, the process framework encompasses a set of umbrella activities that are
applicable across the entire software process.

A generic process framework for software engineering encompasses five activities:

i. Communication: Before any technical work can commence, it is critically

important to communicate and collaborate with the customer and other stakeholders. A
stakeholder is anyone who has a stake in the successful outcome of the project—
business managers, end users, software engineers, support people, etc. The intent is to
understand stakeholders’ objectives for the project and to gather requirements that help
define software features and functions.
Role of Software Engineering in System Design

Software Process Framework

ii. Planning: As, any complicated journey can be simplified if a map

exists, a software project requires software project plan that defines the
software engineering work by describing the technical tasks to be
conducted, the risks that are likely, the resources that will be required,
the work products to be produced, and a work schedule.
Role of Software Engineering in System Design

Software Process Framework

iii.Modeling: As a bridge builder, or an architect, or carpenter etc.

work with models every day to understand the big picture about
product such as what it will look like architecturally, how the constituent
parts fit together, greater detail in an effort to better understand the
problem and how you’re going to solve it. A software engineer does the
same thing by creating models to better understand software
requirements and the design that will achieve those requirements.
Role of Software Engineering in System Design

Software Process Framework

iv.Construction: This activity combines code generation (either

manual or automated) and the testing that is required uncovering errors
in the code.

v. Deployment: The software (as a complete entity or as a partially

completed increment) is delivered to the customer who evaluates the
delivered product and provides feedback based on the evaluation.
Umbrella Activities
Software engineering process framework activities are complemented by a number of
umbrella activities.

In general, umbrella activities are applied throughout a software project and help a
software team manage and control progress, quality, change, and risk.

Typical umbrella activities include:

● Software project tracking and control
● Risk management
● Software quality assurance
● Technical reviews
● Measurement
● Software configuration management
● Reusability management
● Work product preparation and production

Thus, the umbrella activities occur throughout the software process to their need and then
follow it. In addition, the people who have requested the software help to management,
Generic Process Model
A generic process framework for software engineering defines five
framework activities—communication, planning, modeling, construction,
and deployment.

In addition, a set of umbrella activities are applied throughout the

process.

Now, one important aspect of the software process has not yet been
discussed, called process flow that describes how the framework
activities and the actions and tasks that occur within each framework
activity are organized with respect to sequence and time.
Generic Process Model
(a) Linear Process Flow

A linear process flow executes each of the five framework activities in

sequence, beginning with communication and culminating with
deployment.
Generic Process Model
(b) Iterative Process Flow An iterative process flow repeats one or more
of the activities before proceeding to the next.
 Generic Process Model
(c) Evolutionary Process Flow An evolutionary process flow executes the
activities in a “circular” manner. Each circuit through the five activities
leads to a more complete version of the software.
 Generic Process Model
(d) Parallel Process Flow A parallel process flow executes one or more
activities in parallel with other activities (e.g., modeling for one aspect
of the software might be executed in parallel with construction of
another aspect of the software).
Perspective Process Models
The software development life cycle (SDLC) illustrate us the general
prescriptive process model for the development of software product.

Prescriptive (Decided) or traditional process models were originally

proposed to bring order to the vague of software development.

They are called “Prescriptive” because they prescribe a set of process

elements such as framework activities, software engineering actions,
tasks, and work products, quality assurance, and change control
mechanism for each project.

History indicates that these traditional models have brought a certain

amount of useful structure to software engineering work & have provided
a reasonably effective road map for software team.
Perspective Process Models
a. The Waterfall Model: The waterfall model, sometimes called the
classic life cycle, suggests a systematic, sequential approach to
software development that begins with customer specification of
requirements and progresses through planning, modeling, construction,
and deployment, culminating in ongoing support of the completed
software.
Perspective Process Models
a. The Waterfall Model

The linear process flow model will be appropriate when:

● User requirements are clearly defined
● Less number of staffing to do simultaneous work on that project in
the organization
● No much re-useable components
● Sufficient time for software development
● Less communication between customer and developer
● Software engineer have clear idea to do the prescribed task
Perspective Process Models
b. V Model

A variation in the representation of the waterfall model is called the V-model.

The Vmodel provides a way of visualizing how verification and validation
actions are applied to earlier engineering work.

The V-model depicts the relationship of quality assurance actions to the

actions associated with communication, modeling, and early construction
activities.

As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical
representations of the problem and its solution.

Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that
validate each of the models created as the team moved down the left side
Perspective Process Models
b. V Model
Perspective Process Models
b. Rapid Application Development (RAD) Model:

The incremental model or Rapid application development (RAD) model

combines elements of linear and parallel process flows discussed.
Incremental development is particularly useful when staffing is
unavailable for a complete implementation by the business deadline
that has been established for the project. If the core product is well
received, then additional staff (if required) can be added to implement
the next increment. In addition, increments can be planned to manage
technical risks.
Perspective Process Models
b. Rapid Application Development (RAD) Model:
Perspective Process Models
b. Rapid Application Development (RAD) Model:

The RAD model will be appropriate when:

i.This is appropriate both for less staffing (manually work on small

module) or large staffing (parallel work on project).

ii. We have to develop the application in short period of time.

iii. Customer clearly defined their requirements.

iv. No much re-useable components or no chances of outsourcing in

organization.
Perspective Process Models
c. Evolutionary Process Models:

Evolutionary models are iterative which is much suitable for new

systems where no clear idea of the requirements, inputs and outputs
parameters. It produces an increasingly more complete version of the
software with each iteration.

The evolutionary process models are appropriate in following situation:

● No clear idea about the product for both customers and developers.
● Good communication between the customers and developers.
● Sufficient time for the software development
● Less chances of outsourcing and availability of re-usable
components
The two common evolutionary process models are:

i. Prototyping

Although prototyping can be used as a stand-alone process model, it

assists you and other stakeholders to better understand what is to be
built when requirements are fuzzy. The prototyping paradigm begins with
communication to stakeholders. Then, prototyping iteration is planned
quickly, and modeling occurs. The quick design leads to the construction
of a prototype. The prototype is deployed and evaluated by stakeholders,
who provide feedback that is used to further refine requirements
Based upon the user feedback
the, requirements are redefined
and this cycle continue until the
user accepts the prototype. The
actual system is then developed
using the classical waterfall
approach or may be other
prescriptive model
ii. The Spiral Model.

The spiral model was originally proposed by Barry Boehm, is an evolutionary software
process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.

It provides the potential for rapid development of increasingly more complete versions of
the software.

The spiral model is a realistic approach to the development of large-scale systems and
software.

Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.

The spiral model uses prototyping as a risk reduction mechanism but, more important,
enables you to apply the prototyping approach at any stage in the evolution of the
product.

It maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that more realistically reflects the real world.

The spiral model demands a direct consideration of technical risks at all stages of the
ii. The Spiral Model.
Specialized Process Models
Specialized process models is applied when a specialized or narrowly defined
software engineering approach is chosen.

These model have the characteristics of one or more of the traditional models
presented above.

a. Component-Based Development

A component is a modular building block for computer software. Commercial off-

the-shelf (COTS) software components, developed by vendors who offer them as
products, provide targeted functionality with well-defined interfaces that enable the
component to be integrated into the software that is to be built. The component-
based development model incorporates many of the characteristics of the spiral
model. The component-based development model leads to software reuse, and
reusability provides software engineers with a number of measurable benefits.
Modeling and construction activities begin with the identification of
candidate components. These components can be designed as either
conventional software modules or object oriented classes or packages of
classes.

Regardless of the technology, the component-based development model

incorporates the following steps:

1. Available component-based products are researched and evaluated for

the application domain in question.

2. Component integration issues are considered.

3. A software architecture is designed to accommodate the components.

4. Components are integrated into the architecture.

5. Comprehensive testing is conducted to ensure proper functionality.

b. The Formal Methods Model

The formal methods model providing a mathematically based approach

to program modeling and the ability to verify that the model is correct.

Formal methods eliminate many of the problems such as ambiguity,

incompleteness, and inconsistency that are difficult to overcome using
other software engineering paradigms.

A variation on this approach, called cleanroom software engineering is

currently applied by some software development organizations.
Cleanroom software engineering makes use of a specialized version of
the incremental software model.

A “pipeline of software increments” is developed by small independent

software teams.

As each increment is certified, it is integrated into the whole. Hence,

functionality of the system grows with time.
c. Aspect-Oriented Software Development
Aspect-oriented software development (AOSD), often referred to as
aspect-oriented programming (AOP), is a relatively new software
engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing
aspects.
The aspect is customer requirements solely defined for their software
system.
The aspects may be user interfaces, collaborative work, distribution,
persistency, memory management, transaction processing, security,
integrity and so on.
Components may provide or require one or more “aspect details”
relating to a particular aspect, such as a viewing mechanism,
extensible affordance and interface kind (user interface aspects);
event generation, transport and receiving (distribution aspects); data
store/retrieve and indexing (persistency aspects); authentication,
 Unified Process and UML
UML Fundamentals

The Unified Modeling Language (UML) is a standard language for writing

software blueprints.

The UML may be used to visualize, specify, construct, and document the
artifacts of a softwareintensive system, as well as for business modeling
and other non-software systems.

The UML is appropriate for modeling systems ranging from enterprise

information systems to distributed Web-based applications and even to
hard real time embedded systems.

It is a very expressive language, addressing all the views needed to

develop and then deploy such systems.
 Unified Process and UML
It most directly unifies the methods of Booch, Rumbaugh (OMT), and Jacobson (Objectory),
but its reach is wider than that.

By 1997, it become a de facto standard in the domain of objectoriented analysis and

design founded on a wide base of user experience.

The UML is called a modeling language, not a method. Most methods consist, at least in
principle, of both a modeling language and a process.

The modeling language is the (mainly graphical) notation that methods use to express
designs. The process is their advice on what steps to take in doing a design.

Unified: Combines main preceding OO methods (Booch by Grady Booch, OMT by James
Rumbaugh and OOSE by Ivar Jacobson).

Modeling: Primarily used for visually modeling systems. Many system views are supported
by appropriate model.
The UML is a language for:
● Visualizing: The UML is more than just a bunch of graphical symbols.
Rather, behind each symbol in the UML notation is a well-defined
semantics. In this manner, one developer can write a model in the UML,
and another developer, or even another tool, can interpret that model
unambiguously
● Specifying: means building models that are precise, unambiguous, and
complete.
● Constructing: the UML is not a visual programming language, but its
models can be directly connected to a variety of programming languages
● Documenting: a healthy software organization produces all sorts of
artifacts in addition to raw executable code. These artifacts include:
Requirements, Architecture, Design, Source code, Project plans, Tests,
Prototypes, and Releases.
Unified Process
UML provided the necessary technology to support object-oriented software
engineering practice, but it did not provide the process framework to guide
project teams in their application of the technology.

Over the next few years, Jacobson, Rumbaugh, and Booch developed the Unified
Process, a framework for objectoriented software engineering using UML.

The phases of unified process are similar to the generic framework activities as
shown in figure.

Today, the Unified Process (UP) and UML are widely used on object-oriented
projects of all kinds.

The iterative, incremental model proposed by the UP can and should be adapted
to meet specific project needs.
System Flowchart
A system flowchart shows the path taken by data in a system and
the decisions made during different levels.

Different symbols are strung together to show data flow, including

what happens to data and where it goes.
When to use flowchart
Agile Development
Agile software engineering combines a philosophy and a set of development guidelines to
develop the software project as customer need.
The philosophy encourages customer satisfaction and early incremental delivery of software;
small, highly motivated project teams; informal methods; minimal software engineering work
products; and overall development simplicity.
The development guidelines stress delivery over analysis and design, and active and continuous
communication between developers and customers.
The change management is a primary goal of this philosophy.
The changes may be from employ turnover, change of customer need, technology change,
stakeholder decision change etc.
Agile Development
Software engineers and other project stakeholders (managers, customers, end users)
work together on an agile team—a team that is self-organizing and in control of its
own destiny.

An agile team fosters communication and collaboration among all who serve on it.

The basic framework activities—communication, planning, modeling, construction,

and deployment—are remains the same for agile development but they transform into
a minimal task set that pushes the project team toward construction and delivery.
The conventional wisdom in software
development is that the cost of change
increases non-linearly as a project
progresses.
An agile process reduces the cost of
change because software is released in
increments and change can be better
controlled within an increment.
The increment indicates the software
modules developed by different team
in various time interval.
1. Agile Process
Any agile software process is characterized in a manner that addresses a number of key
assumptions about the majority of software projects:
● It is difficult to predict in advance which software requirements will persist and which will
change. It is equally difficult to predict how customer priorities will change as the project
proceeds.

● For many types of software, design and construction are interleaved. That is, both
activities should be performed in tandem so that design models are proven as they are
created. It is difficult to predict how much design is necessary before construction is used
to prove the design.

● Analysis, design, construction, and testing are not as predictable (from a planning point of
view) as we might like.
These three assumptions indicates the problem of unpredictability on software
engineering process and hence an agile process must be adapt the hidden
changes.

An agile software process adapt incrementally with the help of regular customer
feedback.

An effective catalyst for customer feedback is an operational prototype or a

portion of an operational system.

Hence, an incremental development strategy should be instituted.

Software increments (executable prototypes or portions of an operational

system) must be delivered in short time periods so that adaptation keeps pace
with change (unpredictability).

This iterative approach enables the customer to evaluate the software

increment regularly, provide necessary feedback to the software team, and
influence the process adaptations that are made to accommodate the feedback.
2. Agility Principles

The Agile Alliance defines 12 agility principles for those who want to achieve agility:

1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes

harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
2. Agility Principles

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers,

and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. The best architectures, requirements, and designs emerge from self-organizing
teams.

12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
3. Agile Process Models
The history of software engineering taught the lesion that “The “winners” evolve into
best practice, while the “losers” either disappear or merge with the winning models.”
With the introduction of a wide array of agile process models (all follows the principle
and paradigms of Agile Software Development), the most common are:
● Extreme Programming (XP),
● Adaptive Software Development (ASD),
● Scrum,
● Dynamic Systems Development Method (DSDM),
● Crystal,
● Feature Drive Development (FDD),
● Lean Software Development (LSD),
● Agile Modeling (AM), and
● Agile Unified Process (AUP).
A. Extreme Programming (XP)

Extreme Programming (XP) is a most widely used approach to agile

software development.

The ideas and methods associated with XP was written by Kent Beck
during the late 1980s.

More recently, a variant of XP, called Industrial XP (IXP) that refines XP

and targets the agile process specifically for use within large
organizations.
The XP Process

Extreme Programming uses an

object-oriented approach as its
preferred development paradigm
and encompasses a set of rules and
practices that occur within the
context of four framework
activities: planning, design, coding,
and testing. Figure illustrates the
XP process and notes some of the
key ideas and tasks that are
associated with each framework
activity.
 B. ASD (Adaptive Software Development)
ASD has been proposed by Jim Highsmith
as a technique for building complex
software and systems.

The philosophical underpinnings of ASD

focus on human collaboration and team
self-organization.

ASD “life cycle” that incorporates three

phases, speculation, collaboration, and
learning.

During speculation, the project is initiated

and adaptive cycle planning is conducted.

Adaptive cycle planning uses project

initiation information—the customer’s
mission statement, project constraints
(e.g., delivery dates or user descriptions),
C. Scrum
Scrum (the name is derived from an activity that occurs during a rugby match) is an
agile software development method that was conceived by Jeff Sutherland in the early
1990s.
Scrum principles are consistent with the agile manifesto or platform and are used to
guide development activities within a process that incorporates the following framework
activities: requirements, analysis, design, evolution, and delivery.
Scrum emphasizes the use of a set of software process patterns that have proven
effective for projects with tight timelines, changing requirements, and business
criticality.
C. Scrum
Each of these process patterns defines a set of development actions:
Backlog—a prioritized list of project requirements or features that provide business value for the
customer. Items can be added to the backlog at any time.
Sprints—consist of work units that are required to achieve a requirement defined in the backlog
that must be fit into a predefined time-box i.e. a period of time allocated to accomplish some task.
Changes (e.g., backlog work items) are not introduced during the sprint because the sprint allows
team members to work in a short-term, but stable environment.
Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum team. A team
leader, called a Scrum master, leads the meeting and assesses the responses from each person. The
Scrum meeting helps the team to uncover potential problems as early as possible. Also, these daily
meetings lead to “knowledge socialization” and thereby promote a self-organizing team structure.

Demos—deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer.
Scrum
D. DSDM (Dynamic System Development Method)

DSDM provides a framework for building and maintaining systems which

meet tight time constraints through the use of incremental prototyping in a
controlled project environment.
The DSDM philosophy is borrowed from a modified version of the Pareto
principle—80 percent of an application can be delivered in 20 percent of the
time it would take to deliver the complete (100 percent) application.
DSDM also can be combined with XP to provide a combination approach.
D. DSDM (Dynamic System Development Method)
The DSDM Consortium (www.dsdm.org) is a worldwide group of member companies that collectively take
on the role of “keeper” of the method. The consortium has defined an agile process model, called the DSDM
life cycle that defines three different iterative cycles, preceded by two additional life cycle activities:

Feasibility study—establishes the basic business requirements and constraints associated with the
application to be built and then assesses whether the application is a viable candidate for the DSDM process.

Business study—establishes the functional and information requirements that will allow the application to
provide business value.

Functional model iteration—produces a set of incremental prototypes that demonstrate functionality for the
customer. The intent during this iterative cycle is to gather additional requirements by eliciting feedback
from users as they exercise the prototype.

Design and build iteration—revisits prototypes built during functional model iteration to ensure that each
has been engineered in a manner that will enable it to provide operational business value for end users. In
some cases, functional model iteration and design and build iteration occur concurrently.
E. Feature Driven Development(FDD)
FDD was originally conceived by Peter Coad as a practical process model for object-
oriented software engineering and then extended and improved using agile process. This
model can applied to moderately sized and larger software projects. FDD adopts a
philosophy that

(1) emphasizes collaboration among people on an FDD team;

(2) manages problem and project complexity using feature-based decomposition followed
by the integration of software increments, and

(3) communication of technical detail using verbal, graphical, and text-based means.

FDD emphasizes software quality assurance activities by encouraging an incremental

development strategy, the use of design and code inspections, the application of software
quality assurance audits, the collection of metrics, and the use of patterns (for analysis,
design, and construction).
E. Feature Driven Development(FDD)
F. Lean Software Development (LSD)
Lean Software Development (LSD) has adapted the principles of lean manufacturing to the world of software
engineering. The lean principles that inspire the LSD process can be summarized, as eliminate waste, build
quality in, create knowledge, defer commitment, deliver fast, respect people, and optimize the whole.
Each of these principles can be adapted to the software process. For example, eliminate waste within the context
of an agile software project can be interpreted to mean:
1. Adding no extraneous features or functions,

2. Assessing the cost and schedule impact of any newly requested requirement,

3. Removing any superfluous process steps,

4. Establishing mechanisms to improve the way team members find information,

5. Ensuring the testing finds as many errors as possible,

6. Reducing the time required to request and get a decision that affects the software or the process that is
applied to create it, and

7. Streamlining the manner in which information is transmitted to all stakeholders involved in the process.