SOFTWARE PROCESS

GREESHMA K V
ASSISTANT PROFESSOR
CARMEL COLLEGE, MALA
SOFTWARE ENGINEERING DEFINITION
THE SEMINAL DEFINITION:
[SOFTWARE ENGINEERING IS] THE ESTABLISHMENT
AND USE OF SOUND ENGINEERING PRINCIPLES IN
ORDER TO OBTAIN ECONOMICALLY SOFTWARE
THAT IS RELIABLE AND WORKS EFFICIENTLY ON
REAL MACHINES.

The IEEE definition:

Software Engineering: The application of a
systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software;
that is, the application of engineering to software.
IMPORTANCE OF SOFTWARE ENGINEERING
• MORE AND MORE, INDIVIDUALS AND SOCIETY RELY ON
ADVANCED SOFTWARE SYSTEMS. WE NEED TO BE ABLE TO
PRODUCE RELIABLE AND TRUSTWORTHY SYSTEMS
ECONOMICALLY AND QUICKLY.

• IT IS USUALLY CHEAPER, IN THE LONG RUN, TO USE

SOFTWARE ENGINEERING METHODS AND TECHNIQUES FOR
SOFTWARE SYSTEMS RATHER THAN JUST WRITE THE
PROGRAMS AS IF IT WAS A PERSONAL PROGRAMMING
PROJECT. FOR MOST TYPES OF SYSTEM, THE MAJORITY OF
COSTS ARE THE COSTS OF CHANGING THE SOFTWARE AFTER
IT HAS GONE INTO USE.
FAQ ABOUT SOFTWARE ENGINEERING
ESSENTIAL ATTRIBUTES OF GOOD SOFTWARE
SOFTWARE ENGINEERING
A Layered Technology
 A LAYERED TECHNOLOGY
CONTINUE…

 ANY ENGINEERING APPROACH MUST REST ON ORGANIZATIONAL

COMMITMENT TO QUALITY WHICH FOSTERS A CONTINUOUS PROCESS
IMPROVEMENT CULTURE.
 PROCESS LAYER AS THE FOUNDATION DEFINES A FRAMEWORK WITH
ACTIVITIES FOR EFFECTIVE DELIVERY OF SOFTWARE ENGINEERING
TECHNOLOGY. ESTABLISH THE CONTEXT WHERE PRODUCTS (MODEL,
DATA, REPORT, AND FORMS) ARE PRODUCED, MILESTONE ARE
ESTABLISHED, QUALITY IS ENSURED AND CHANGE IS MANAGED.
 METHOD PROVIDES TECHNICAL HOW-TO’S FOR BUILDING SOFTWARE.
IT ENCOMPASSES MANY TASKS INCLUDING COMMUNICATION,
REQUIREMENT ANALYSIS, DESIGN MODELING, PROGRAM
CONSTRUCTION, TESTING AND SUPPORT.
 TOOLS PROVIDE AUTOMATED OR SEMI-AUTOMATED SUPPORT FOR THE
PROCESS AND METHODS.
•
SOFTWARE PROCESS
WHEN YOU WORK TO BUILD A PRODUCT OR A SYSTEM, IT’S
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 FOLLOWS IS CALLED A
SOFTWARE PROCESS.

• SOFTWARE PROCESS IS DEFINED AS A FRAMEWORK FOR THE TASKS

THAT ARE REQUIRED TO BUILD HIGH- QUALITY SOFTWARE.
 SOFTWARE PROCESS
CONTINUE..

• A PROCESS IS A COLLECTION OF ACTIVITIES, ACTIONS AND TASKS THAT ARE PERFORMED

WHEN SOME WORK PRODUCT IS TO BE CREATED

• ACTIVITY STRIVES TO ACHIEVE BROAD OBJECTIVE

• ACTION ENCOMPASSES A SET OF TASKS

• TASK FOCUSES ON A SMALL, BUT WELL DEFINED OBJECTIVE THAT PRODUCE A TANGIBLE OUTCOME.
 FIVE ACTIVITIES OF A GENERIC 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.

• FOR MANY SOFTWARE PROJECTS, THESE FRAMEWORK ACTIVITIES ARE

APPLIED ITERATIVELY AS A PROJECT PROGRESSES. EACH ITERATION
PRODUCES A SOFTWARE INCREMENT THAT PROVIDES A SUBSET OF
OVERALL SOFTWARE FEATURES AND FUNCTIONALITY.
FIVE ACTIVITIES OF A GENERIC PROCESS FRAMEWORK
• COMMUNICATION: COMMUNICATE WITH CUSTOMER TO
UNDERSTAND OBJECTIVES AND GATHER REQUIREMENTS

• PLANNING: CREATES A “MAP” DEFINES THE WORK BY DESCRIBING

THE TASKS, RISKS AND RESOURCES, WORK PRODUCTS AND WORK
SCHEDULE.

• MODELING: CREATE A “SKETCH”, WHAT IT LOOKS LIKE

ARCHITECTURALLY, HOW THE CONSTITUENT PARTS FIT TOGETHER
AND OTHER CHARACTERISTICS.

• CONSTRUCTION: CODE GENERATION AND THE TESTING.

• DEPLOYMENT: DELIVERED TO THE CUSTOMER WHO EVALUATES THE

PRODUCTS AND PROVIDES FEEDBACK BASED ON THE EVALUATION.
 UMBRELLA ACTIVITIES
COMPLEMENT THE FIVE PROCESS FRAMEWORK ACTIVITIES AND
HELP TEAM TO MANAGE AND CONTROL PROGRESS, QUALITY,
CHANGE, AND RISK.

• SOFTWARE PROJECT TRACKING AND CONTROL: ASSESS PROGRESS

AGAINST THE PLAN AND TAKE ACTIONS TO MAINTAIN THE
SCHEDULE.

• RISK MANAGEMENT: ASSESSES RISKS THAT MAY AFFECT THE

OUTCOME AND QUALITY.

• SOFTWARE QUALITY ASSURANCE: DEFINES AND CONDUCT

ACTIVITIES TO ENSURE QUALITY.

• TECHNICAL REVIEWS: ASSESSES WORK PRODUCTS TO UNCOVER

AND REMOVE ERRORS BEFORE GOING TO THE NEXT ACTIVITY.
 UMBRELLA ACTIVITIES
• MEASUREMENT: DEFINE AND COLLECTS PROCESS, PROJECT,
CONTINUE…
AND PRODUCT MEASURES TO ENSURE STAKEHOLDER’S NEEDS
ARE MET.

• SOFTWARE CONFIGURATION MANAGEMENT: MANAGE THE

EFFECTS OF CHANGE THROUGHOUT THE SOFTWARE PROCESS.

• REUSABILITY MANAGEMENT: DEFINES CRITERIA FOR WORK

PRODUCT REUSE AND ESTABLISHES MECHANISM TO ACHIEVE
REUSABLE COMPONENTS.

• WORK PRODUCT PREPARATION AND PRODUCTION: CREATE

WORK PRODUCTS SUCH AS MODELS, DOCUMENTS, LOGS,
FORMS AND LISTS.
 SOFTWARE MYTHS

• WIDELY HELD BUT FALSE VIEW

• PROPAGATE MISINFORMATION AND CONFUSION

• THREE TYPES OF MYTH

 MANAGEMENT MYTH
 CUSTOMER MYTH
 PRACTITIONER’S MYTH

MANY SOFTWARE PROFESSIONALS RECOGNIZE THE FALLACY

OF THE MYTHS. RECOGNITION OF SOFTWARE REALITIES IS THE FIRST
STEP TOWARD FORMULATION OF PRACTICAL SOLUTIONS FOR
SOFTWARE ENGINEERING.
 MANAGEMENT MYTHS
 MYTH(1)
-THE AVAILABLE STANDARDS AND PROCEDURES
FOR SOFTWARE ARE ENOUGH.
REALITY:
THE BOOK OF STANDARDS MAY VERY WELL EXIST, BUT IS IT USED?
ARE SOFTWARE PRACTITIONERS AWARE OF ITS EXISTENCE? DOES IT
REFLECT MODERN SOFTWARE ENGINEERING PRACTICE? IS IT
COMPLETE? IS IT ADAPTABLE? IN MANY CASES, THE ANSWER TO ALL
OF THESE QUESTIONS IS “NO.”
 MANAGEMENT MYTHS
 MYTH(2)
-ADDING MORE PROGRAMMERS WHEN THE WORK IS BEHIND SCHEDULE
CAN CATCH UP.
REALITY:
AS NEW PEOPLE ARE ADDED, PEOPLE WHO WERE
WORKING MUST SPEND TIME EDUCATING THE NEWCOMERS, THEREBY
REDUCING THE AMOUNT OF TIME SPENT ON PRODUCTIVE DEVELOPMENT
EFFORT. PEOPLE CAN BE ADDED BUT ONLY IN A PLANNED AND WELL
COORDINATED MANNER.

 MYTH(3)
-OUTSOURCING THE SOFTWARE PROJECT TO THIRD PARTY, WE CAN
RELAX AND LET THAT PARTY BUILD IT
REALITY:
IF AN ORGANIZATION DOES NOT UNDERSTAND HOW TO
MANAGE AND CONTROL SOFTWARE PROJECTS INTERNALLY, IT WILL
INVARIABLY STRUGGLE WHEN IT OUTSOURCES SOFTWARE PROJECTS.
 CUSTOMER MYTH
• MYTH(1)
- GENERAL STATEMENT OF OBJECTIVE IS ENOUGH TO BEGIN WRITING PROGRAMS,
THE DETAILS CAN BE FILLED IN LATER.
REALITY:
UNAMBIGUOUS REQUIREMENTS ARE DEVELOPED ONLY THROUGH EFFECTIVE AND
CONTINUOUS COMMUNICATION BETWEEN CUSTOMER AND DEVELOPER.

• MYTH(2)
-SOFTWARE IS EASY TO CHANGE BECAUSE SOFTWARE IS FLEXIBLE.
REALITY :
IT IS TRUE THAT SOFTWARE REQUIREMENTS CHANGE, BUT THE IMPACT
OF CHANGE VARIES WITH THE TIME AT WHICH IT IS INTRODUCED.
• MYTH(1)
PRACTITIONER’S MYTH
-ONCE THE PROGRAM IS WRITTEN, THE JOB HAS BEEN DONE.
REALITY:
INDUSTRY DATA INDICATE THAT BETWEEN 60 AND 80 PERCENT OF
ALL EFFORT EXPENDED ON SOFTWARE WILL BE EXPENDED AFTER IT IS
DELIVERED TO THE CUSTOMER FOR THE FIRST TIME.

• MYTH(2)
-UNTIL THE PROGRAM IS RUNNING, THERE IS NO WAY OF ASSESSING
THE QUALITY.
REALITY:
SOFTWARE REVIEWS ARE A “QUALITY FILTER” THAT HAVE BEEN
FOUND TO BE MORE EFFECTIVE THAN TESTING FOR FINDING CERTAIN
CLASSES OF SOFTWARE DEFECTS.
• MYTH(3)
PRACTITIONER’S MYTH
-THE ONLY DELIVERABLE WORK PRODUCT IS THE WORKING PROGRAM
REALITY:
A WORKING PROGRAM IS ONLY ONE PART OF A SOFTWARE
CONFIGURATION THAT INCLUDES MANY ELEMENTS. A VARIETY OF WORK PRODUCTS
(E.G., MODELS, DOCUMENTS, PLANS) PROVIDE A FOUNDATION FOR SUCCESSFUL
ENGINEERING AND, MORE IMPORTANT, GUIDANCE FOR SOFTWARE SUPPORT.
• MYTH(4)
-SOFTWARE ENGINEERING CREATES VOLUMINOUS AND UNNECESSARY
DOCUMENTATION AND INVARIABLY SLOWS DOWN SOFTWARE DEVELOPMENT.
REALITY:
SOFTWARE ENGINEERING IS NOT ABOUT CREATING DOCUMENTS. IT
IS ABOUT CREATING A QUALITY PRODUCT. BETTER QUALITY LEADS TO REDUCED REWORK.
AND REDUCED REWORK RESULTS IN FASTER DELIVERY TIMES.