Chapter 5

Software Quality Assurance And Security (14Marks)

5.1 Project Scheduling: Basic principle, Work breakdown structure , Activity network
and critical path method, Scheduling techniques (CPM,PERT)
5.2 Project Tracking : Timeline charts, Earned Value Analysis, Gantt Charts
5.3 Software Quality Management Vs Software Quality Assurance. phases of software
quality assurance: Planning, Activites, Audits, and review
5.4 Quality Evaluation standards : Six sigma, ISO for software, CMMI: levels, Process
areas.
5.5 Software Security, Introduction to DevOps, Secure software engineering.
----------------------------------------------------------------------------------------------------------- -
Project Scheduling:
● Scheduling is the culmination of a planning activity that is a primary component of
software project management.
● When combined with estimation methods and Risk analysis, scheduling establishes
a road map for the project manager.
● It is one of the most difficult jobs for a project manager.
● It begins with process decomposition. It involves separating total work involved in
a project into separate activities and judging the time required to complete these
activities.
● Managers estimate time and resources required to complete activities and organize
them into a coherent sequence.
● When estimating schedules, you should NOT assume that every stage of the project
will be problem-free.
○ People may fall ill or may leave
○ Hardware may break down
○ Essential software/hardware may be delivered late
● If the project is new & technically advanced, Then certain parts of it may turn out
to be more difficult and take longer than originally anticipated.

Importance of Project Scheduling:

● Today’s software systems are large, sophisticated and complex
○ Many software engineering tasks occur in parallel
○ Result of work performed during one task may have a profound effect on work
conducted in another task.
○ Task interdependencies are very difficult to understand without a schedule
 ○ It is virtually impossible to assess progress on a large software project without
a detailed schedule

Why Are Software Projects Late?

● There are many reasons why software is delivered late…
❖ An unrealistic deadline established by someone outside the software
development group
❖ Changing customer requirements that are not reflected in schedule changes
❖ Risks not considered at the beginning of the project
❖ Miscommunications among project staff resulting in re-work & delay
❖ Honest under-estimation of the job
❖ Technical difficulties that could not have been foreseen in advance
❖ Human difficulties that could not have been foreseen in advance
❖ Project Management fails to track progress –
– Unaware the project is in behind the schedule & in trouble
– No corrective actions taken

What to do when face an Unrealistic Deadline?

● Perform a detailed estimate of effort and time using historical data
● Using an incremental process model, develop a strategy to deliver critical
functionality by the deadline – document the plan
● Meet with the customer and explain why the project is late
● Offer the incremental development strategy as an alternative

The Basic Principles of Software Project Scheduling:

1) Compartmentalization —Compartmentalize the project into a number of manageable
activities, actions & tasks
2) Interdependency —Indicate task interrelationship
3) Time allocation- Each task must be allocated some no. of work units with start date &
completion date
4) Effort validation —be sure resources are available
5) Defined responsibilities —Every task should be assigned to a specific team member
6) Defined outcomes —Each task must have an output (e.g. work product)
7) Defined milestones —Task(s) should be associated with a project milestone (A
milestone is accomplished when one or more work products has be reviewed for quality
and approved)
Process:
● The manager needs to estimate time and resources of project while scheduling
project.
● All activities in project must be arranged in a coherent sequence that means activities
should be arranged in a logical and well-organized manner for easy to understand.
● Initial estimates of project can be made optimistically which means estimates can
be made when all favorable things will happen and no threats or problems take place.
● The total work is separated or divided into various small activities or tasks during
project schedule.
● Then, Project manager will decide time required for each activity or task to get
completed.
● Even some activities are conducted and performed in parallel for efficient
performance.
● The project manager should be aware of fact that each stage of project is not
problem-free.
-------------------------------------------------------------------------------------------------------------------------------
Work Breakdown Structure:
● Dividing complex projects to simpler and manageable tasks is the process identified
as Work Breakdown Structure (WBS).
● Usually, the project managers use this method for simplifying the project execution.
In WBS, much larger tasks are broken down to manageable chunks of work. These
chunks can be easily supervised and estimated.
● WBS is not restricted to a specific field when it comes to application. This
methodology can be used for any type of project management.
● Following are a few reasons for creating a WBS in a project:
○ Accurate and readable project organization.
○ Accurate assignment of responsibilities to the project team.
○ Indicates the project milestones and control points.
 ○ Helps to estimate the cost, time and risk.
○ Illustrate the project scope, so the stakeholders can have a better understanding
of the same.
Construction of a WBS:
● Identifying the main deliverables of a project is the starting point for deriving a work
breakdown structure.
● This important step is usually done by the project managers and the subject matter
experts (SMEs) involved in the project.
● Once this step is completed, the subject matter experts start breaking down the
highlevel tasks into smaller chunks of work.
● In the process of breaking down the tasks, one can break them down into different
levels of detail. One can detail a high-level task into ten sub-tasks while another can
detail the same high-level task into 20 sub-tasks.
● Therefore, is no hard and fast rule on how you should breakdown a task in WBS.
Rather, the level of breakdown is a matter of the project type and the management
style followed for the project.
● In general, there are a few "rules" used for determining the smallest task chunk. In
"two weeks" rule, nothing is broken down smaller than two weeks worth of work.
● This means, the smallest task of the WBS is at least two-week long. 8/80 is another
rule used when creating a WBS. This rule implies that no task should be smaller
than 8 hours of work and should not be larger than 80 hours of work.
● One can use many forms to display their WBS. Some use tree structure to illustrate
the WBS, while others use lists and tables. Outlining is one of the easiest ways of
representing a WBS.
● Following example is an outlined WBS:

There are many design goals for WBS. Some important goals are as follows:
 ● Giving visibility to important work efforts.
● Giving visibility to risky work efforts.
● Illustrate the correlation between the activities and deliverables. ● Show clear
ownership by task leaders.
WBS Diagram
● In a WBS diagram, the project scope is graphically expressed. Usually the diagram
starts with a graphic object or a box at the top, which represents the entire project.
Then, there are sub-components under the box.
● These boxes represent the deliverables of the project. Under each deliverable, there
are sub-elements listed. These sub-elements are the activities that should be
performed in order to achieve the deliverables.
● Although most of the WBS diagrams are designed based on the deliveries, some
WBS are created based on the project phases. Usually, information technology
projects are perfectly fit into WBS model.
● Therefore, almost all information technology projects make use of WBS.
● In addition to the general use of WBS, there is specific objective for deriving a WBS
as well. WBS is the input for Gantt charts, a tool that is used for project management
purpose.
● Following is a sample WBS diagram:

● The efficiency of a work breakdown structure can determine the success of a project.
 ● The WBS provides the foundation for all project management work, including,
planning, cost and effort estimation, resource allocation, and scheduling.
● Therefore, one should take creating WBS as a critical step in the process of project
management.
------------------------------------------------------------------------------------------------------------
Activity network
● It is a graphic representation of the task flow for a project.
● An Activity Network Diagram is a diagram of project activities that shows the
sequential relationships of activities using arrows and nodes.
● It depicts task length, sequence, concurrency, and dependency
● Points out inter-task dependencies to help the manager ensure continuous progress
toward project completion.
● An activity network diagram tool is used extensively in and is necessary for the
identification of a project’s critical path (which is used to determine the expected
completion time of the project).

Example: Suppose the team is tasked with improving the process of building a house. The
team lists the major steps involved – everything from the excavation step through the
landscaping step.

The team creates a chart – Activity Network Diagram – where the nodes (the boxes)
represent the nine major steps involved in building a house. Arrows that connect the nodes
show the flow of the process.
Some of the process steps (nodes A, B, and C) run in series, while other process steps
(nodes D, E, and F) run in parallel. Notice that Step B cannot happen until step A has been
completed. Likewise, step C cannot happen until step B has completed. Step H cannot
happen until steps D, E, and F have completed – and ALL need to be completed before
Step H. So, nodes A, B, and C are running in series. Nodes D, E, and F run in parallel. This
is important to know because those steps that are running in parallel most likely will have
different expected completion times.

Critical Path:
● The team’s job is to take note of which of the nodes D, E, and F, will be taking the
most amount of time, and which of those nodes is expected to take the least amount
of time. This is essential when creating the Critical Path.
● For instance, if node D is expected to take the most amount of time as compared
with nodes E and F, it is not important that nodes D and E start at the exact same
time as node F.
● Those steps can start later, but they have to be finished no later than the most time
consuming of the three steps that run in parallel.
● The team evaluates the nine steps and come to a consensus on how many days each
of the nine steps will take
● The critical path is a line that goes through all of the nodes that have the longest
expected completion times.

Most Likely Time:

● Nodes A, B, and C run in series, so the critical path is straightforward. Notice that
between the three nodes that run in parallel, (nodes D, E, and F) node D is expected
to take the longest to complete as compared to the other two nodes.
● The critical path would run through nodes D and G because those particular nodes
have the longest expected completion times.
● The line above shows the critical path. By looking at the Activity Network Diagram
 the team can easily see that the expected completion time as defined by the critical
path is 50 days. (5+2+12+9+10+7+5 = 50 days) That’s the MOST LIKELY time.

Optimistic Time:
● The team might want to know what the best case (Optimistic Time), in terms of
time, would be.
● To come up with that number, the team would decide upon the shortest possible time
for each of the nodes, and then add those up.
● The numbers in parenthesis are the most optimistic times.
(4+2+10+8+8+7+4 = 43)

Pessimistic Time:
● The team also might want to know what the worst case (Pessimistic Time), in terms
of time, would be.
● To come up with that number, the team would decide upon the longest possible time
for each of the nodes, and then add those up.
● Note: To determine the best case or the worst case, the critical path line must be
followed. The numbers in parentheses are the most pessimistic times.
(7+3+14+10+11+8+6 = 59)
● Remember, you are only calculating the numbers along the critical path when
calculating the most optimistic and pessimistic times.

Expected Time:
So what does all of this mean? It means the project most likely will take 50 days, but it
could take 59 days, or it can be done as soon as 43 days.

Control Bands:
We could calculate control bands around the average. Here’s how we do that:

For the critical path, we can expect the project to take from 47.6 days to 53.0 days
50.3 + 2.7 = 53 on the high side 50.3
– 2.7 = 47.6 on the low side.

Activity diagram link:

https://www.youtube.com/watch?v=bR2rAB1-4YI CPM
link
https://www.youtube.com/watch?v=YsHQD4F2a6U
PERT link
https://www.youtube.com/watch?v=_DOloCY7uCo
Gantt chart
https://www.youtube.com/watch?v=s8-1jloeOK4

------------------------------------------------------------------------------------------------------------
Project Tracking:
● Project Tracking is a method of project management for following the progress (or
lack thereof) of activities involved in projects.
● Potential issues can be spotted and solved by team members and leaders.
● Tracking projects from the beginning, dealing with problems quickly and
proactively making decisions is what successful project managers do.
 ● Managing all tasks and activities involved, handling multiple files involved and
most importantly, the people who make up the team make this incredibly
challenging.

Timeline charts:
● A timeline chart is an effective way to visualize a process using chronological order.
Since details are displayed graphically, important points in time can be easily seen
and understood.
● Often used for managing a project’s schedule, timeline charts function as a sort of
calendar of events within a specific period of time.
Need of Timeline Charts:
● Staying on track can be a struggle.
● By incorporating a timeline chart into your project, it becomes much easier to see
what needs to be done, how long it will take, and what the next steps are. ● Since
each steps is documented along an easy to follow timescale, there’s no
misunderstanding of when goals should be met and how many hours a project should
take.
How to make a timeline chart
1. Begin by listing each milestone throughout your project.
2. Place these milestones along a horizontal line, from start to finish.
3. Associate each step with a specific date to represent a deadline.
4. Include titles to clarify key points along the process (phases, testing, planning, etc.).

Gantt Chart:
● Gantt charts was devised by Henry Gantt (1917). It represents project schedule with
respect to time periods. It is a horizontal bar chart with bars representing activities
and time scheduled for the project activities.
● A Gantt Chart is a timeline that is used as a project management tool to illustrate
how the project will run.
○ You can view individual tasks, their durations and the sequencing of these
tasks.
○ View the overall timeline of the project and the expected completion date.
○ As the project moves forward with actual performance updated, the Gantt
Chart will adjust simultaneously displaying an up-to-date project schedule
with new start and finish dates for incomplete tasks and record the original
baseline of your plan.
Benefits using a Gantt Chart

1. The Gantt Chart could be used to communicate with your clients. You could show
them your project plan and the expected completion date. Your clients can visually
see each stage of the project and have a better understanding of the project and key
milestone.
2. You could provide this Gantt Chart in a tender proposal. Your tender response will
look appealing when complimented with a professional Gantt Chart program. It can
be used to show your understanding of the requirements of the project, and can
demonstrate your ability to plan and manage in the eyes of the tender evaluation
panel.
3. Assist in Communication with Staff and Contractors. You could supply this Gantt
Chart to staff and contractors to communicate when their services are required.
4. Run your project with greater efficiency with improved cost and time outcomes.

What does a Gantt Chart Consist of?

If you are new to Gantt chart, you might have been confused about the colorful bars with
different lengths. You may ask what the bars or lines mean. After knowing the basic
concept of it, you will find it extremely simple and easy-to-understand.
Basically, a Gantt chart consists of 4 parts:
● Milestones
● Tasks
● Dependencies
 ● Resources

Gantt Chart Examples:

1. New Software Development Gantt Chart Example

2. Show Planning Gantt Chart Example

3. Interior Decoration Gantt Chart Example

4. New Product Launch Gantt Chart Example

------------------------------------------------------------------------------------------------------------

Earned Value Analysis:

Earned Value Analysis (EVA) is one of the key tools and techniques used in Project
Management, to have an understanding of how the project is progressing. EVA implies
gauging the progress based on earnings or money. Both, schedule and cost are calculated
on the basis of EVA.
Features of EVA:
● Earned Value Analysis is an objective method to measure project performance in
terms of scope, time and cost.
● EVA metrics are used to measure project health and project performance.
● Earned Value Analysis is a quantitative technique for assessing progress as the
software project team moves through the work tasks, allocated to the Project
Schedule.
● EVA provides a common value scale for every project task.
● Total hours to complete the project are estimated and every task is given an Earned
Value, based on its estimated (%) of the total.
● Earned Value is a measure of ‘Progress’ to assess ‘Percentage of Completeness’
Need for EVA:
 ● EVA provides different measures of progress for different types of tasks. It is the
single way for measuring everything in a project.
● Provides an ‘Early Warning’ signal for prompt corrective action. The types of
signals can be the following:
a) Bad news does not age well – Holding on to the bad news does not
help. The project manager needs to take an immediate action.
b) Still time to recover – In case, the project is not going as per schedule
and may get delayed, the situation is needed to be taken care of by finding
out the reasons that are causing delay and taking the required corrective
action.
c) Timely request for additional funds – While there is time to recover,
the need for additional resources or funds can be escalated with an early
warning.
● It allows ‘rolling up’ the progress of many tasks into an overall project status.
● It provides a uniform unit of measure (dollars or work-hours) for the progress.
Key Elements of EVA
● Planned Value (PV) – The approved cost baseline for the work package. It was
earlier known as Budgeted Cost of Work Scheduled (BCWS).
● Earned Value (EV) – The budgeted value of the completed work packages. It used
to be known as Budgeted Cost of Work Performance at a specified point (BCWP).
● Actual Cost (AC) – The actual cost incurred during the execution of work packages
up to a specified point in time. It was previously called Actual Cost of Work
Performed (ACWP).
Tools And Techniques:
There are several software packages available which will prepare an earned value analysis,
as follows:

● Schedulemaker
● Planisware OPX2
● RiskTrak
● Winsight
● Primavera
------------------------------------------------------------------------------------------------------------

Software Quality Management:

● It is a process that ensures the required level of software quality is achieved when it
reaches the users, so that they are satisfied by its performance.
● The process involves quality assurance, quality planning, and quality control.
 ● Software Quality management should be independent of project management to
ensure independence of cost and schedule adherences.
● It directly affects the process quality and indirectly affects the product quality.
● Activities of Software Quality Management:
○ Quality Assurance - QA aims at developing Organizational procedures and
standards for quality at Organizational level.
○ Quality Planning - Select applicable procedures and standards for a particular
project and modify as required to develop a quality plan.
○ Quality Control - Ensure that best practices and standards are followed by the
software development team to produce quality products.

Software Quality Assurance (SQA):

● It is simply a way to assure quality in the software.
● It is the set of activities which ensure processes, procedures as well as standards
suitable for the project and implemented correctly.
● It is a process which works parallel to development of a software. It focuses on
improving the process of development of software so that problems can be prevented
before they become a major issue.
● It is a kind of an Umbrella activity that is applied throughout the software process.
● Software Quality Assurance have:
1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism ● Major Software
Quality Assurance Activities:
1. SQA Management Plan:
Make a plan how you will carry out the SQA throughout the project. Think which
set of software engineering activities are the best for project.check level of sqa
team skills.
2. Set The Check Points: SQA team should set checkpoints. Evaluate the
performance of the project on the basis of collected data on different
checkpoints.
3. Multi testing Strategy: Do not depend on a single testing approach.
When you have a lot of testing approaches available, use them.
4. Measure Change Impact:
 The changes for making the correction of an error sometimes re-introduces more
errors to keep the measure of impact of change on the project. Reset the new
change to check the compatibility of this fix with the whole project.
5. Manage Good Relations:
In the working environment managing good relations with other teams involved
in project development is mandatory. Bad relations of the SQA team with the
programmers team will impact directly and badly on the project. Don’t play
politics.

● Benefits of Software Quality Assurance (SQA):

1. SQA produces high quality software.
2. High quality application saves time and cost.
3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for a long time.
5. High quality commercial software increases the market share of a
company.
6. Improving the process of creating software.
7. Improves the quality of the software.

● Disadvantage of SQA:
1. Adding more resources,
2. Employing more workers to help maintain quality.

Phases of software quality assurance:Planning, Activities, Audit, Reviews

Planning phase of SQA:
● Planning the quality management approach for the project is accomplished in
parallel with developing the scope and requirements for the product and the project.
● The Project Assumptions, dependencies, and risks are inputs to the test strategy.
Other inputs include application and architecture models as well as integration
requirements.
● Development activities during the planning phase, such as conducting a proof of
concept or demonstrating a prototype, provide opportunities to assess whether the
project requires changes and additions to existing quality policies, test
environments, test tools, and test methodologies.
● The fundamental quality outputs from the planning phase are the anal quality policy
(quality standards) for the project and the test strategy derived from the functional
and nonfunctional requirements.
 ● Planning for quality assurance and quality control is incomplete until resources are
assigned to the quality tasks in the work breakdown structure (project schedule).
Planning the QA tests and user acceptance tests should be coordinated to avoid
unnecessary duplication of effort.

SQA Activities:
The SEI (Software Engineering Institute) recommends a set of SQA activities that address
quality assurance planning, record keeping, analysis, and reporting.
Following activities are performed by an independent SQA group:
1. Prepares an SQA plan for a project: The program is developed during project
planning and is reviewed by all stakeholders. The plan governs quality assurance
activities performed by the software engineering team and the SQA group. The plan
identifies calculations to be performed, audits and reviews to be performed,
standards that apply to the project, techniques for error reporting and tracking,
documents to be produced by the SQA team, and amount of feedback provided to
the software project team.
2. Participates in the development of the project's software process description:
The software team selects a process for the work to be performed. The SQA group
reviews the process description for compliance with organizational policy, internal
software standards, externally imposed standards (e.g. ISO-9001), and other parts
of the software project plan.
3. Reviews software engineering activities to verify compliance with the defined
software process: The SQA group identifies, reports, and tracks deviations from
the process and verifies that corrections have been made.
4. Audits designated software work products to verify compliance with those
defined as a part of the software process: The SQA group reviews selected work
products, identifies, documents and tracks deviations, verify that corrections have
been made, and periodically reports the results of its work to the project manager.
5. Ensures that deviations in software work and work products are documented
and handled according to a documented procedure: Deviations may be
encountered in the project method, process description, applicable standards, or
technical work products.
6. Records any noncompliance and reports to senior management: Non-
compliance items are tracked until they are resolved.

Audit:
 ● Audit is an independent examination of a work product or set of work products, to
verify whether or not the product is in compliance with policies, specifications,
standard contractual agreements, or other criteria.
● Audits should be planned on a regular basis. High-risk areas should be audited more
often to ensure conformance. Audits are also used to check any previously Identified
non-conformances.
● It is always best to choose a team of auditors from within the organization; your
audit team should comprise people from all areas and levels of the company. Audits
need to be documented.
● During an audit, evidences are used to verify that the processes are being done in
accordance to the procedures and policies. Evidence.should be recorded against each
section being audited.
● Recording of evidence needs to have description of the documentation sighted,
number, date and any other information that will assist in identifying that document.
● Non-conformances found should be reported for further action. A date should be
established for the correction, a follow-up audit should be carried out to ensure that
the non-conformance has been fixed.
● Quality Audit Documentation:
Audit documentation does not need to be complicated, normally there are
three documents namely, the audit plan, audit notes and audit report.
1. The Audit Plan: The audit plan is sent to the department being audited a few
days prior, it should include the date of the audit, the planned time, duration,
auditor's names, location and the policies and procedures that will be used during
the audit. It should also mention any non-conformances that were found during
the last audit.
2. Audit Notes: The notes are the Auditor's questions that will be asked during the
audit. It should include references to particular policies and procedures and what
will be asked during the audit. The same document should be used to record the
findings and any comments during the audit.
3. Audit Report: The audit report should include details of the audit, date,
Auditor's name, policies and procedures and findings against them.

Review:
● Software reviews are a filter for the software engineering process. Reviews are
applied at various points to find the errors before they are passed on to another
software engineering activity or released to the customer.
● Reviews provide a powerful way to improve quality by providing a means by which
defects can be detected (and corrected) early in development.
 ● A review is away to:
1. Point out needed improvements in the product. .
2. Confirm those parts of a product in which improvement is either not desired or
not needed.
● Objectives of Review:
1. To uncover errors in function, logic, or implementation for any representation of
the software.
2. To verify that the software under review meets its requirements.
3. To ensure that the software has been represented according to predefined
standards.
4. To achieve software that is developed in a uniform manner.
5. To Make Projects More Manageable.
● Classes of Review:
Reviews are divided into following classes:
1. Informal Reviews:
● An informal meeting is a form of review if technical problems are discussed.
● It is also called peer-review i.e. simply giving a document to a colleague and
asking them to look at it closely which will identify defects we might never
find on our own.
● It is generally a one-on-one meeting between the author of a work product
and a peer. No agenda is required and results are also not formally reported:
2. Formal reviews:
● A formal review can range from a simple meeting between two programmers to a
detailed inspection of the code.
------------------------------------------------------------------------------------------------------------

Quality Assurance v/s Quality control

Quality Assurance Quality Control

 Quality Assurance (QA) is the set of actions Quality Control (QC) is described as
including facilitation, training, measurement, the processes and methods used to
and analysis needed to provide adequate compare product quality to
confidence that processes are established and requirements and applicable
continuously improved to produce products or standards, and the actions are taken
services that conform to specifications and are when a nonconformance is detected.
fit for use.

QA is an activity that establishes and calculates QC is an activity that demonstrates

the processes that produce the product. If there whether or not the product produced
is no process, there is no role for QA. met standards.

QA helps establish process QC relates to a particular product or

service

QA sets up a measurement program to evaluate QC verified whether particular

processes attributes exist, or do not exist, in a
explicit product or service.

QA identifies weakness in processes and QC identifies defects for the primary

improves them goals of correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

------------------------------------------------------------------------------------------------------------
Quality Evaluation standards:
Six sigma:
 ● Six Sigma is the process of improving the quality of the output by identifying and
eliminating the cause of defects and reducing variability in manufacturing and
business processes.
● The maturity of a manufacturing process can be defined by a sigma rating indicating
its percentage of defect-free products it creates.
● A six sigma method is one in which 99.99966% of all the opportunities to produce
some features of a component are statistically expected to be free of defects (3.4
defective features per million opportunities).

History of Six Sigma

● Six-Sigma is a set of methods and tools for process improvement.
● It was introduced by Engineer Sir Bill Smith while working at Motorola in 1986.
● Six Sigma was adopted by Bob Galvin, the CEO of Motorola in 1986 and registered
as a Motorola Trademark on December 28, 1993, then it became a quality leader.
Characteristics of Six Sigma:
1. Statistical Quality Control:
● Six Sigma is derived from the Greek Letter σ (Sigma) from the Greek
alphabet, which is used to denote Standard Deviation in statistics.
● Standard Deviation is used to measure variance, which is an essential tool for
measuring non-conformance as far as the quality of output is concerned.
2. Methodical Approach:
● The Six Sigma is not a merely quality improvement strategy in theory, as it
features a well defined systematic approach of application in DMAIC and
DMADV which can be used to improve the quality of production.
● DMAIC is an acronym for Design-Measure- Analyze-Improve-Control.
● The alternative method DMADV stands for Design-Measure-
AnalyzeDesign-Verify.
3. Fact and Data-Based Approach:
● The statistical and methodical aspect of Six Sigma shows the scientific basis
of the technique.
● This accentuates essential elements of the Six Sigma that is a fact and
databased.
4. Project and Objective-Based Focus:
● The Six Sigma process is implemented for an organization's project tailored
to its specification and requirements.
● The process is flexed to suit the requirements and conditions in which the
projects are operating to get the best results.
5. Customer Focus:
● The customer focus is fundamental to the Six Sigma approach.
● The quality improvement and control standards are based on specific
customer requirements.
6. Teamwork Approach to Quality Management:
● The Six Sigma process requires organizations to get organized when it comes
to controlling and improving quality.
● Six Sigma involves a lot of training depending on the role of an individual in
the Quality Management team.

Six Sigma Methodologies:

Six Sigma projects follow two project methodologies:
1. DMAIC (Design-Measure- Analyze-Improve-Control)
2. DMADV (Design-Measure- Analyze-Design-Verify)

DMAIC:
● It specifies a data-driven quality strategy for improving processes. This
methodology is used to enhance an existing business process. ● The DMAIC project
methodology has five phases:

1. Define: It covers the process mapping and flow-charting, project charter

development, problem-solving tools, and so-called 7-M tools.
 2. Measure: It includes the principles of measurement, continuous and discrete data,
and scales of measurement, an overview of the principle of variations and
repeatability and reproducibility (RR) studies for continuous and discrete data.
3. Analyze: It covers establishing a process baseline, how to determine process
improvement goals, knowledge discovery, including descriptive and exploratory
data analysis and data mining tools, the basic principle of Statistical Process Control
(SPC), specialized control charts, process capability analysis, correlation and
regression analysis, analysis of categorical data, and non-parametric statistical
methods.
4. Improve: It covers project management, risk assessment, process simulation, and
design of experiments (DOE), robust design concepts, and process optimization.
5. Control: It covers process control planning, using SPC for operational control and
PRE-Control.

DMADV:
● It specifies a data-driven quality strategy for designing products and processes.
● This method is used to create new product designs or process designs in such a way
that it results in a more predictable, mature, and defect free performance. ● The
DMADV project methodology has five phases:

1. Define: It defines the problem or project goal that needs to be addressed.

2. Measure: It measures and determines the customer's needs and
specifications.
3. Analyze: It analyzes the process to meet customer needs.
4. Design: It can design a process that will meet customer needs.
 5. Verify: It can verify the design performance and ability to meet customer
needs. ------------------------------------------------------------------------------------------------
------------ ISO for software:
ISO 9000 Certification
● ISO (International Standards Organization) is a group or consortium of 63 countries
established to plan and foster standardization.
● ISO declared its 9000 series of standards in 1987.
● It serves as a reference for the contract between independent parties.
● The ISO 9000 standard determines the guidelines for maintaining a quality system.
● The ISO standard mainly addresses operational methods and organizational methods
such as responsibilities, reporting, etc.
● ISO 9000 defines a set of guidelines for the production process and is not directly
concerned about the product itself.

Types of ISO 9000 Quality Standards

The ISO 9000 series of standards is based on the assumption that if a proper stage is
followed for production, then good quality products are bound to follow automatically. The
types of industries to which the various ISO standards apply are as follows.
1. ISO 9001: This standard applies to the organizations engaged in design,
development, production, and servicing of goods. This is the standard that applies
to most software development organizations.
2. ISO 9002: This standard applies to those organizations which do not design
products but are only involved in the production. Examples of these category
industries contain steel and car manufacturing industries that buy the product and
plants designs from external sources and are engaged in only manufacturing those
products. Therefore, ISO 9002 does not apply to software development
organizations.
3. ISO 9003: This standard applies to organizations that are involved only in the
installation and testing of the products. For example, Gas companies.
How to get ISO 9000 Certification?
An organization determines to obtain ISO 9000 certification applies to ISO registrar office
for registration. The process consists of the following stages:

1. Application: Once an organization decides to go for ISO certification, it applies to

the registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the
organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews
the document submitted by the organization and suggests an improvement.
4. Compliance Audit: During this stage, the registrar checks whether the organization
has compiled the suggestion made by it during the review or not.
5. Registration: The Registrar awards the ISO certification after the successful
completion of all the phases.
6. Continued Inspection: The registrar continued to monitor the organization time by
time.
------------------------------------------------------------------------------------------------------------
CMMI: levels
The CMMI (Capability Maturity Model Integration):
● It is a procedure and software developmental model. It assists in organizing and
streamlining the software development process.
● It advances and boosts the development process and reduces threats in software and
system.
● Established by the Software Engineering Institute at Carnegie Mellon University, It
was developed as a process enhancement tool for software development. It is now
managed by the CMMI Institute.
 ● CMMI analyses your existing processes and classifies their flaws and strengths. In
the next steps, measures are taken to convert the weaknesses into strength.
● CMMI is both a process model and a behavioral model. It can be used to manage
the logistics of refining performance by creating determinate standards; it can also
develop a structure for boosting prolific and effective behavior throughout the
system.

The CMMI model is divided into five maturity levels:

1. Initial Level:
At this level of CMMI, the processes are rather unpredictable and reactive. These are the
levels that consume extra time to complete the work. At this level, the organization is at its
worst with an unpredictable environment and increased chances of risks and incompetence.
2. Managed:
The processes have already passed level one and are now better planned, performed,
measured and controlled but still is not free from issues and there are lot many issues to
address.
CMMI Maturity Level 2 – Managed
REQM – Requirements Management
PP – Project Planning
CM – Configuration Management
MA – Measurement and Analysis
PPQA – Process and Product Quality Assurance
PMC – Project Monitoring and Control
SAM – Supplier Agreement Management 3.
Defined:
By now the organizations are more pre-emptive than responsive. There’s a set of
“organization-wide standards” to “provide guidance across projects, programs and
portfolios.” By now organizations understand their shortcomings and way to deal with
them to improve their processes
CMMI Maturity Level 3 – Defined
RD – Requirements Development
DAR – Decision Analysis and Resolution
OPF – Organizational Process Focus
IPM – Integrated Project Management +IPPD
OT – Organizational Training
OPD – Organizational Process Definition +IPPD
PI – Product Integration
RSKM – Risk Management
VAL – Validation
TS – Technical Solution
VER – Verification
4. Quantitatively Managed:
The organization at this level reaches a high maturity level where it is in a stage to
determine predictable processes based on stakeholders requirements. The processes are
more managed, dignified and precise. The organization is now ahead of threats and follows
the data-driven approach for process deficiencies.
CMMI Maturity Level 4 – Quantitatively Managed
OPP – Organizational Process Performance
QPM – Quantitative Project Management 5.
Optimizing:
Now the organization is at a stage of stability and flexibility. Now the organization is
constantly heading towards improvement and retorting opportunities. At level 5 or
optimizing level of CMMI, the organization follows “agility and innovation,” in an
anticipated environment.
CMMI Maturity Level 5 – Optimizing
OID – Organizational Innovation and Deployment
CAR – Causal Analysis and Resolution
When organizations enter Levels 4 and 5, they enter a high maturity level, constantly
growing, acclimatizing and developing to meet the needs of investors and clients.” Finally,
they are on the verge of attaining the goals of CMMI.

CMMI tools
There are various CMMI tools available in the market. Choice of these tools depends on
the business’s needs. During the Maturity level 2 or 3, you can take the help of your CMMI
consultant to design customized tools. You might have to consider the following tools:
● Bug tracker
● Project and document management

● Requirement and design management

● Metrics tools

● Estimation

● Integration application

● Decision and analysis tools

Process Areas:
● Key Process Areas (KPA) of a software organization:
● Except for CMMI level 1, each maturity level is featured by several Key Process
Areas (KPAs) that contains the areas an organization should focus on improving its
software process to the next level.
● The focus of each level and the corresponding key process areas are shown in the
fig.
 ● SEI CMM provides a series of key areas on which to focus to take an organization
from one level of maturity to the next.
● Thus, it provides a method for gradual quality improvement over various stages.
● Each step has been carefully designed such that one step enhances the capability
already built up.
------------------------------------------------------------------------------------------------------------
Software Security:
Software security is an idea implemented to protect software against malicious attack and
other hacker risks so that the software continues to function correctly under such potential
risks.
Security is necessary to provide integrity, authentication and availability.
Need of security:
● Due to heavy dependence of computer network-based applications on various
software and software controlled systems, software security has become an essential
issue.
● Almost every software controlled system faces potential threats from system user,
both insiders and outsiders. It is well accepted that "the root of most security
problems is software that fails in unexpected ways when under attack". Therefore,
software must be engineered with protection mechanisms against attacks.
● Software should be designed with the objective not only of implementing the quality
functionalities required for their users, but also of combating potential and
unexpected threats.
 ● The principal objectives of software security engineering need to be reinvestigated,
and a methodology is required that can be employed for building secure software
systems.
● Software security engineering is a practice to address software security issues in a
systematic manner.
Core Security Properties of Secure Software:
Following are the consequences based on security basics:
1. Integrity: Verification that the information contained in the message is not
tampered accidentally or deliberately, during transmission.
2. Non-repudiation: There can be no denial on the part of the sender of having sent a
message that is digitally signed.
3. Confidentiality: Means that the information contained in the message is kept
private and only the sender and the intended recipient will be able to read it.
4. Authentication: Verification that the people with whom we are corresponding
actually are who they claim to be.
5. Availability: Availability is defined as the requirements should focus on how
available resource should be for authorized users.
Fig below depicts the stages of Software Security Life Cycle (SSLC). Recently, the most
of the researchers have shifted from a project-oriented view to a product life cycle oriented
view of software security and trying to understand the characteristics of security demands.

The SSLC Model and Security Management Framework:

The Software Security Life Cycle is confined to project level Figure 2 has mainly four
stages. The characteristics and function of the stages are as under:
Introduction Stage: The users, in this stage, are those who devoted S/W. During this stage
the major concerns are how to make the software works. The security mechanism is
concern in this stage.
Growth Stage: In this stage, system usage is up and the number of system attacks reported
is important. As the software enters this stage, the monitoring of system attacks and users
problem reports is an important concern. In order to manage the increasing security
demand, it is critical to allocate more programmers copying with the increasing
countermeasure requests to prevent accumulating dissatisfaction. The Security tolerance is
the main concern in this stage.
Maturity Stage: After deploying the system, the users experience the growth of
enhancement requests in the maturity phase. At this stage, the focus is enhancement of
projects. Security experts are expanding the software functions and trying to prolong the
life of the software.
Decline Stage: At this stage, the software is easy to vulnerate, and attackers can easily
exploit it. The users require software renovation. In this phase, the production team must
choose between integrating the software with other security mechanisms or developing a
substitute software.
------------------------------------------------------------------------------------------------------------
Introduction to DevOps:
● The field of DevOps has become popular and commonplace in recent years. DevOps
has provided speed and quality benefits with continuous development and
deployment methods, but It does not guarantee the security of an entire organization.
● The word "DevOps" is a combination of the words "Development" and "Operation”.
The goal of DevOps is to shorten the systems development lifecycle while also
 delivering features, fixes, and updates frequently in close alignment with business
objectives.
● DevOps is a set of practices intended to reduce the time between committing a
change to a system and the change being placed into normal production, while
ensuring high quality.
● DevOps security refers to the discipline and practice of safeguarding the entire
DevOps environment through strategies, policies, processes, and technology.
Security should be built into every part of the DevOps lifecycle, including inception,
design, build, tests, release, support, maintenance, and beyond.

● Above figure showing DevOps as the intersection of Development, Operations and

Quality Assurance

Above figure shows DevOps life cycle

The DevOps lifecycle includes seven phases as given below:
1) Continuous Development:
This phase involves the planning and coding of the software. The vision of the project is
decided during the planning phase. And the developers begin developing the code for the
application. There are no DevOps tools that are required for planning, but there are several
tools for maintaining the code.
2) Continuous Integration:
This stage is the heart of the entire DevOps lifecycle. It is a software development practice
in which the developers require to commit changes to the source code more frequently.
This may be on a daily or weekly basis. Then every commit is built, and this allows early
detection of problems if they are present. Building code is not only involved compilation,
but it also includes unit testing, integration testing, code review, and packaging. The
code supporting new functionality is continuously integrated with the existing code.
Therefore, there is continuous development of software. The updated code needs to be
integrated continuously and smoothly with the systems to reflect changes to the end-users.

Jenkins is a popular tool used in this phase. Whenever there is a change in the Git
repository, then Jenkins fetches the updated code and prepares a build of that code, which
is an executable file in the form of war or jar. Then this build is forwarded to the test server
or the production server.
3) Continuous Testing:
This phase, where the developed software is continuously testing for bugs. For constant
testing, automation testing tools such as TestNG, JUnit, Selenium, etc are used. These
tools allow QAs to test multiple code-bases thoroughly in parallel to ensure that there is no
flaw in the functionality. In this phase, Docker Containers can be used for simulating the
test environment.
Selenium does the automation testing, and TestNG generates the reports. This entire testing
phase can automate with the help of a Continuous Integration tool called Jenkins.
Automation testing saves a lot of time and effort for executing the tests instead of doing
this manually. Apart from that, report generation is a big plus. The task of evaluating the
test cases that failed in a test suite gets simpler. Also, we can schedule the execution of the
test cases at predefined times. After testing, the code is continuously integrated with the
existing code.
4) Continuous Monitoring:
Monitoring is a phase that involves all the operational factors of the entire DevOps process,
where important information about the use of the software is recorded and carefully
processed to find out trends and identify problem areas. Usually, the monitoring is
integrated within the operational capabilities of the software application.
It may occur in the form of documentation files or maybe produce large-scale data about
the application parameters when it is in a continuous use position. The system errors such
as server not reachable, low memory, etc are resolved in this phase. It maintains the security
and availability of the service.
5) Continuous Feedback:
The application development is consistently improved by analyzing the results from the
operations of the software. This is carried out by placing the critical phase of constant
feedback between the operations and the development of the next version of the current
software application.
The continuity is the essential factor in the DevOps as it removes the unnecessary steps
which are required to take a software application from development, using it to find out its
issues and then producing a better version. It kills the efficiency that may be possible with
the app and reduce the number of interested customers.
6) Continuous Deployment:
In this phase, the code is deployed to the production servers. Also, it is essential to ensure
that the code is correctly used on all the servers.
The new code is deployed continuously, and configuration management tools play an
essential role in executing tasks frequently and quickly. Here are some popular tools which
are used in this phase, such as Chef, Puppet, Ansible, and SaltStack.
Containerization tools are also playing an essential role in the deployment phase. Vagrant
and Docker are popular tools that are used for this purpose. These tools help to produce
consistency across development, staging, testing, and production environment. They also
help in scaling up and scaling down instances softly.
Containerization tools help to maintain consistency across the environments where the
application is tested, developed, and deployed. There is no chance of errors or failure in
the production environment as they package and replicate the same dependencies and
packages used in the testing, development, and staging environment. It makes the
application easy to run on different computers.
7) Continuous Operations:
All DevOps operations are based on the continuity with complete automation of the release
process and allow the organization to accelerate the overall time to market continuingly. It
is clear from the discussion that continuity is the critical factor in the DevOps in removing
steps that often distract the development, take it longer to detect issues and produce a better
version of the product after several months. With DevOps, we can make any software
product more efficient and increase the overall count of interested customers in your
product.
------------------------------------------------------------------------------------------------------------
Secure software engineering.
● Security is considered as a very critical issue for software engineering. Software is
itself a resource and thus must be afforded appropriate security.
● The engineering of secure software software / systems emphasizes security
from a software engineering perspective and deals with technical, as well as
managerial aspects of software security.
● Secure software engineering approach is actually the most structured way of
developing secure software by taking the security right from requirement to the
design, implementation and testing stages of software development ● Defining
Properties of Secure Software:
1. A set of core properties whose presence (or absence) are the ground truth that
makes software secure (or not), and
2. A set of influential properties that do not directly make software secure but
do make it possible to characterize how secure software is.
● There is a difference between software security and application security. Software
security is concerned with addressing the security in the development phases of
the software whereas application security is concerned with protecting the
software after the development phase by means of various protection mechanisms
like intrusion detection, firewalls etc.
● Secure software development focuses on the security issues right from the
beginning from requirement, design and implementation phases of SDLC. Many
ideas of Secure Software Development (SSD) methods have been proposed.
● However, the process of software development still follows the conventional
SDLC models and process. The secure software development lifecycle is
comprised of phases such as Software Security Requirements,Secure Software
architecture and Design,Secure Software Implementation and Coding and Security
Assurance.
● Fig. above shows the stages for secure software development process with the core
activities to be carried out at each of the stage. These stages only tell what is to be
achieved not the how it can be achieved .
● The lifecycle in order to develope the secure software is due to multifaceted nature
of the software security.
● It is a complex problem to identify which factors constitute to the security of the
system, also the software system have different environment factors under which
they operate.
● The difficulty behind the specification of operations that can be performed in each
of the stages of.
● There are various security specification languages such as UMLsec, secureUM,
SecureTropos, MisuseCase, AbuseCase,UMlintr and AsmlSec.
● Design is the blueprint of the overall structure of the software, it address the
definition of the overall structure of the software. The incorporation of security
into the software design process is influenced by both the software design concepts
and security methods.
● Defining the overall structure of the software from the security perspective entails
identifying those components whose correct functioning is essential to security and
identifying design techniques that will assure its security.
● For the secure software development process the security needs to be taken into
consideration from the requirement taken to design followed by the
implementation (coding). Secure software implementation (coding) involves the
process and application of secure coding standards and guidelines, application of
 security testing tools including “fuzzing”, static-analysis code scanning tools, and
conducting code reviews in order to eliminate the vulnerabilities in the code.

● Fig. above shows the various security measures to be taken at each phase of SDLC
in software engineering.
1. Security in Requirements Phase:
● Building a 100% secure system is hardly possible. In SDLC a lot of
problems arise because of inadequate Requirements Analysis. It is one of
the main causes of over budgeted and delayed projects.
● Also problems at this phase cause poor quality applications and have
reduced scope. So, this phase should be given the utmost importance. From
this layer itself, security features should be planned. Detailed requirements
of specific systems with respect to security police should be specified.
● Recommendations for this phase includes policy on disclosure of
information, Authentication and password management, Authorization and
role management, Network and data security, Cryptography and key
management and so on.
2. Security in design phase:
● At the design and architecture level, a system must be coherent and present
a unified security architecture that takes into account security. Designers,
architects, and analysts must clearly document assumptions and identify
possible attacks.
● Recommendations for this phase includes:
(i) Risk should be covered using multiple defensive strategies. In case one
layer of protection turns out to inadequate, the next level of defensive
strategy will prevent full breach.
(ii) Secure design guidelines and principles should be followed while
developing the initial design. Secure design patterns should either be
followed or used for guidance. Secure design decisions should be
specified using a secure design specification language.
 (iii) To identify security errors.
(iv) Threat Analysis (risk analysis) should be undertaken that helps
identifying issues before code is committed so that they can be
mitigated in early SDLC. It involves identifying the conditions that
cause incidents and analyzing them.
(v) Standard proven security toolkits (cryptographic and protocol
libraries) should be selected.
3. Security in Implementation Phase:
● For the implementation phase, a secure programming languages should be
selected to minimize security errors, Moreover, secure coding standards
and guidelines should be followed.
● This phase also requires full consideration as per security is concerned.
Here, the focus must be on implementation flaws. One may make use of
tools that scan source code and detect common vulnerabilities. A security
team should perform a code walkthrough with the developers and,in some
cases, the system architects.
● Recommendations for this phase includes:
(i) Use of unsafe functions should be avoided or minimized. Look for
potential buffer overflows, array out of bound errors, integer underflow
and overflow, as well as data truncation errors.
(ii) Latest compiler toolset should be used.
(iii) Manual code review must be done. Identify malicious behavior.
Know what good traffic looks like.
(iv) All inputs and outputs must be validated.
(v) Static and dynamic code analysis tools can be used to aid code review
process to find vulnerabilities. Static analysis tool, also called source
code analyzer examine a program's text without attempting to execute
it.
Dynamic analysis requires actually running the code.

4. Security in Testing Phase:

● During this phase, various tests are conducted to check the security aspect of
software being built. A good testing program engages a security team that is
predominantly made up of the development team itself. Testing for security
involves various techniques.
● Recommendations for this phase includes:
 (i) Risk-based security testing based on attack patterns and threat models. It
involves creating security abuse/misuse cases, performing architectural risk
analysis risk-based security test plans.
(ii) Testing security functionality with standard functional testing techniques.
Security test plans are prepared for both the strategies.
(iii) Penetration testing should be done. While the application may be secure, a
small aspect of the configuration could still be at a default install stage and
vulnerable to exploitation.
(iv) Fuzz testing should also be done that provides invalid, unexpected, or
random data to the inputs of a program. If the program fails (for example,
by crashing or failing) the defects can be noted.
(v) Operations people should carefully monitor fielded systems during use for
security breaks. So monitoring software behavior is an excellent defensive
technique.
(vi) Usage of automated testing tools is also recommended.

Advantages of Secure Software Development:

● Software engineering, well-designed techniques for designing news of software or
enhancing existing software, is not a new field, but the problems and solutions of
vulnerability to malicious attack have only recently been extensively explored.
● Robust software, in the context of secure software engineering, is software that
continues to function correctly whilst under such attacks. Identification of actual
or potential vulnerabilities in design or code should be incorporated throughout all
stages of the software development cycle and constitutes the practice of secure
software engineering.
● This idea of secure and robust software is not new. But what has caused the recent
surge of interest in secure software engineering? Some factors include:
1. Improved Connectivity: With increased connectivity between systems
through the Internet, attacking a system or software at a remote location is not
difficult anymore.
2. Complex Software: With improvements in software technology, complex
software with intricate functionalities can be developed. However, as the
complexity increases, loopholes which may cause security breaches can easily be
overlooked.
3. Reactive Approach to Security: Current software products follow a
reactive approach to security in that they deal with threats only after the attack,
instead of being prepared in advance to function under any adverse condition.