Software Engineering Notes
Software Engineering Notes
SOFTWARE ENGINEERING
Table of Contents
SOFTWAREOVERVIEW ......................................................................................... 1
DEFINITIONS ............................................................................................................................................. 1
SOFTWARE EVOLUTION .......................................................................................................................... 2
SOFTWARE EVOLUTIONLAWS ................................................................................................................ 3
E-TYPESOFTWARE EVOLUTION.............................................................................................................. 3
SOFTWARE PARADIGMS ......................................................................................................................... 4
SoftwareDevelopmentParadigm ..................................................................................... 4
SoftwareDesignParadigm .............................................................................................. 5
ProgrammingParadigm .................................................................................................. 5
NEED OFSOFTWAREENGINEERING ....................................................................................................... 5
CHARACTERISTICS OFGOODSOFTWARE ............................................................................................... 6
Operational .................................................................................................................... 6
Transitional .................................................................................................................... 6
Maintenance .................................................................................................................. 6
SOFTWARE DEVELOPMENT LIFECYCLE ......................................................................... 8
SDLCACTIVITIES ..................................................................................................................................... 8
Communication .............................................................................................................. 8
Requirement Gathering .................................................................................................. 8
FeasibilityStudy .............................................................................................................. 9
System Analysis............................................................................................................. 9
SoftwareDesign.............................................................................................................. 9
Coding ........................................................................................................................... 9
Testing ........................................................................................................................... 9
Integration .................................................................................................................... 10
Implementation ............................................................................................................ 10
OperationandMaintenance ........................................................................................... 10
SOFTWARE DEVELOPMENTPARADIGM ............................................................................................... 10
WaterfallModel ............................................................................................................. 10
IterativeModel .............................................................................................................. 11
SpiralModel .................................................................................................................. 12
V –model...................................................................................................................... 12
BigBangModel.............................................................................................................. 14
SOFTWAREPROJECTMANAGEMENT ............................................................................. 15
SOFTWARE PROJECT ............................................................................................................................ 15
NEED OF SOFTWAREPROJECT MANAGEMENT .................................................................................... 15
SOFTWARE PROJECTMANAGER .......................................................................................................... 16
ManagingPeople .......................................................................................................... 16
ManagingProject .......................................................................................................... 17
SOFTWARE MANAGEMENTACTIVITIES ................................................................................................ 17
PROJECTPLANNING ............................................................................................................................... 17
SCOPEMANAGEMENT............................................................................................................................ 17
PROJECT ESTIMATION .......................................................................................................................... 18
PROJECT ESTIMATIONTECHNIQUES.................................................................................................... 19
DecompositionTechnique ............................................................................................. 19
EmpiricalEstimationTechnique ..................................................................................... 19
PROJECT SCHEDULING ......................................................................................................................... 20
RESOURCE MANAGEMENT .................................................................................................................... 20
PROJECT RISK MANAGEMENT ............................................................................................................. 21
RiskManagementProcess ............................................................................................ 21
PROJECT EXECUTIONAND MONITORING ............................................................................................ 21
PROJECT COMMUNICATION MANAGEMENT........................................................................................ 22
CONFIGURATIONMANAGEMENT ........................................................................................................... 23
Baseline ....................................................................................................................... 23
ChangeControl ............................................................................................................. 23
PROJECTMANAGEMENTTOOLS............................................................................................................ 24
Gantt Chart .................................................................................................................. 24
PERTChart .................................................................................................................. 25
ResourceHistogram ..................................................................................................... 25
CriticalPath Analysis .................................................................................................... 26
SOFTWAREREQUIREMENTS ........................................................................................... 27
REQUIREMENT ENGINEERING .............................................................................................................. 27
REQUIREMENT ENGINEERING PROCESS ............................................................................................ 27
Feasibilitystudy ............................................................................................................ 27
Requirement Gathering ................................................................................................ 28
Software RequirementSpecification(SRS) .................................................................... 28
SoftwareRequirement Validation .................................................................................. 28
REQUIREMENT ELICITATION PROCESS............................................................................................... 29
REQUIREMENT ELICITATION TECHNIQUES ......................................................................................... 29
Interviews..................................................................................................................... 30
Surveys........................................................................................................................ 30
Questionnaires ............................................................................................................. 30
Taskanalysis ................................................................................................................ 30
DomainAnalysis ........................................................................................................... 30
Brainstorming ............................................................................................................... 30
Prototyping................................................................................................................... 31
Observation ................................................................................................................. 31
SOFTWARE REQUIREMENTS CHARACTERISTICS............................................................................... 31
SOFTWARE REQUIREMENTS ................................................................................................................ 31
FunctionalRequirements .............................................................................................. 32
Non-FunctionalRequirements....................................................................................... 32
USER INTERFACE REQUIREMENTS ...................................................................................................... 33
SOFTWARE SYSTEM ANALYST ............................................................................................................. 33
SOFTWARE METRICSAND MEASURES ................................................................................................ 34
ii
SOFTWAREDESIGNBASICS ............................................................................................ 36
SOFTWARE DESIGNLEVELS ................................................................................................................. 36
MODULARIZATION .................................................................................................................................. 37
CONCURRENCY...................................................................................................................................... 37
Example ....................................................................................................................... 37
COUPLINGANDCOHESION ..................................................................................................................... 38
COHESION .............................................................................................................................................. 38
COUPLING ............................................................................................................................................... 39
DESIGNVERIFICATION ........................................................................................................................... 39
SOFTWARE ANALYSIS ANDDESIGNTOOLS .................................................................. 41
DATAFLOW DIAGRAM............................................................................................................................. 41
TypesofDFD................................................................................................................. 41
DFD Components ........................................................................................................ 41
Levelsof DFD ............................................................................................................... 42
STRUCTURECHARTS ............................................................................................................................. 43
HIPODIAGRAM ...................................................................................................................................... 45
Example ....................................................................................................................... 46
STRUCTUREDENGLISH.......................................................................................................................... 47
Example ....................................................................................................................... 47
PSEUDO-CODE ...................................................................................................................................... 48
Example ....................................................................................................................... 49
DECISIONTABLES................................................................................................................................... 49
CreatingDecisionTable ................................................................................................. 49
Example ....................................................................................................................... 50
ENTITY-RELATIONSHIP MODEL ............................................................................................................ 50
DATADICTIONARY .................................................................................................................................. 51
Requirement ofDataDictionary ..................................................................................... 51
Contents ...................................................................................................................... 52
Example ....................................................................................................................... 52
DataElements .............................................................................................................. 52
Data Store.................................................................................................................... 53
DataProcessing............................................................................................................ 53
SOFTWAREDESIGNSTRATEGIES ................................................................................... 54
STRUCTUREDDESIGN ........................................................................................................................... 54
FUNCTIONORIENTEDDESIGN ............................................................................................................... 55
DesignProcess ............................................................................................................. 55
OBJECTORIENTED DESIGN .................................................................................................................. 55
DesignProcess ............................................................................................................. 56
SOFTWARE DESIGNAPPROACHES....................................................................................................... 57
TopDownDesign .......................................................................................................... 57
Bottom-upDesign ......................................................................................................... 57
SOFTWARE USERINTERFACE DESIGN .......................................................................... 58
COMMAND LINEINTERFACE(CLI) ........................................................................................ 58
CLI Elements ............................................................................................................... 59
iii
iv
Software Engineering
Tutorial
Software Overview
1
LetusunderstandwhatSoftwareEngineeringstandsfor.Thetermismadeoftwo words,
software andengineering.
Engineering on the other hand, is all about developing products, using well-
defined, scientific principles and methods.
Definitions
IEEE defines software engineering as:
Software Engineering
Tutorial
SoftwareEvolution
The process of developing a software product using software engineering
principles and methods is referred to as Software Evolution. This includes the
initial development of software and its maintenance and updates, till desired
software product is developed, which satisfies the expected requirements.
Evolution starts from the requirement gathering process. After which developers
create a prototype of the intended software and show it to the users to get their
feedback at the early stage of the software product development. The users
suggestchanges,onwhichseveralconsecutiveupdatesandmaintenancekeepon
changing too. This process changes to the original software, till the desired
software isaccomplished.
Even after the user has the desired software in hand, the advancing technology
andthechangingrequirementsforcethesoftwareproducttochangeaccordingly. Re-
creating software from scratch and to go one-on-one with the requirementis
Software Engineering
Tutorial
not feasible. The only feasible and economical solution is to update the existing
software so that it matches the latest requirements.
Software EvolutionLaws
Lehmanhasgivenlawsforsoftwareevolution.Hedividedthesoftwareintothree
differentcategories:
E-Type softwareevolution
Lehman has given eight laws for E-Type software evolution -
Software Engineering
Tutorial
Software Paradigms
Software paradigms refer to the methods and steps, which are taken while
designingthesoftware.Therearemanymethodsproposedandareimplemented. But,
we need to see where in the software engineering concept, these paradigms
stand. These can be combined into various categories, though each of them is
contained in oneanother:
Software Engineering
Tutorial
Requirementgathering
Softwaredesign
Programming
Design
Maintenance
Programming
Programming Paradigm
This paradigm is related closely to programming aspect of software development.
This includes –
Coding
Testing
Integration
Need of SoftwareEngineering
The need of software engineering arises because of higher rate of change in user
requirements and environment on which the software is working. Following are
some of the needs stated:
Cost- As hardware industry has shown its skills and huge manufacturing
haslowerdownthepriceofcomputerandelectronichardware.But,costof the
software remains high if proper process is notadapted.
Software Engineering
Tutorial
Characteristics of goodsoftware
A software product can be judged by what it offers and how well it can be used.
This software must satisfy on the following grounds:
Operational
Transitional
Maintenance
Well-engineered and crafted software is expected to have the following
characteristics:
Operational
This tells us how well the software works in operations. It can be measured on:
Budget
Usability
Efficiency
Correctness
Functionality
Dependability
Security
Safety
Transitional
This aspect is important when the software is moved from one platform to
another:
Portability
Interoperability
Reusability
Adaptability
Maintenance
This aspect briefs about how well the software has the capabilities to maintain
itself in the ever-changing environment:
Modularity
Maintainability
Flexibility
Scalability
Software Engineering
Tutorial
Software Engineering
Tutorial
SDLC Activities
SDLC provides a series of steps to be followed to design and develop a software
product efficiently. SDLC framework includes the following steps:
Communication
This is the first step where the user initiates the request for a desired software
product. The user contacts the service provider and tries to negotiate the terms,
submits the request to the service providing organization in writing.
Requirement Gathering
This step onwards the software development team works to carry on the project.
The team holds discussions with various stakeholders from problem domain and
tries to bring out as much information as possible on their requirements. The
requirements are contemplated and segregated into user requirements, system
requirements and functional requirements. The requirements are collected using
a number of practices as given -
Software Engineering
Tutorial
Feasibility Study
After requirement gathering, the team comes up with a rough plan of software
process. At this step the team analyzes if a software can be designed to fulfill all
requirementsoftheuser,andifthereisanypossibilityofsoftwarebeingnomore useful.
It is also analyzed if the project is financially, practically, and
technologicallyfeasiblefortheorganizationtotakeup.Therearemanyalgorithms
available, which help the developers to conclude the feasibility of a software
project.
System Analysis
Atthisstepthedevelopersdecidearoadmapoftheirplanandtrytobringupthe best
software model suitable for the project. System analysis includes understanding
of software product limitations, learning system related problems
orchangestobedoneinexistingsystemsbeforehand,identifyingandaddressing
theimpactofprojectonorganizationandpersonneletc.Theprojectteamanalyzes the
scope of the project and plans the schedule and resourcesaccordingly.
Software Design
Next step is to bring down whole knowledge of requirements and analysis on the
desk and design the software product. The inputs from users and information
gathered in requirement gathering phase are the inputs of this step. The output
ofthisstepcomesintheformoftwodesigns;logicaldesign,andphysicaldesign.
Engineers produce meta-data and data dictionaries, logical diagrams, data-flow
diagrams, and in some cases pseudocodes.
Coding
This step is also known as programming phase. The implementation of software
design starts in terms of writing program code in the suitable programming
language and developing error-free executable programs efficiently.
Testing
An estimate says that 50% of whole software development process should be
tested. Errors may ruin the software from critical level to its own removal.
Software testing is done while coding by the developers and thorough testing is
conducted by testing experts at various levels of code such as moduletesting,
Software Engineering
Tutorial
program testing, product testing, in-house testing, and testing the product at
user’s end. Early discovery of errors and their remedy is the key to reliable
software.
Integration
Software may need to be integrated with the libraries, databases, and other
program(s). This stage of SDLC is involved in the integration of software with
outer world entities.
Implementation
This means installing the software on user machines. At times, software needs
post-installation configurations at user end. Software is tested for portability and
adaptability and integration related issues are solved during implementation.
Software DevelopmentParadigm
The software development paradigm helps a developer to select a strategy to
developthesoftware.Asoftwaredevelopmentparadigmhasitsownsetoftools,
methods, and procedures, which are expressed clearly and defines software
development life cycle. A few of software development paradigms or process
models are defined asfollows:
Waterfall Model
Waterfall model is the simplest model of software development paradigm. All the
phasesofSDLCwillfunctiononeafteranotherinlinearmanner.Thatis,whenthe first
phase is finished then only the second phase will start and soon.
10
Software Engineering
Tutorial
This model assumes that everything is carried out and taken place perfectly as
planned in the previous stage and there is no need to think about the past issues
that may arise in the next phase. This model does not work smoothly if there are
some issues left at the previous step. The sequential nature of model does not
allow us to go back and undo or redo our actions.
This model is best suited when developers already have designed and developed
similar software in the past and are aware of all its domains.
Iterative Model
This model leads the software development process in iterations. It projects the
processofdevelopmentincyclicmannerrepeatingeverystepaftereverycycleof
SDLCprocess.
The software is first developed on very small scale and all the steps are followed
which are taken into consideration. Then, on every next iteration, more features
andmodulesaredesigned,coded,tested,andaddedtothesoftware.Everycycle
produces a software, which is complete in itself and has more features and
capabilities than that of the previousone.
Aftereachiteration,themanagementteamcandoworkonriskmanagementand
prepareforthenextiteration.Becauseacycleincludessmallportionofwhole
11
Software Engineering
Tutorial
softwareprocess,itiseasiertomanagethedevelopmentprocessbutitconsumes
moreresources.
Spiral Model
Spiralmodelisacombinationofboth,iterativemodelandoneoftheSDLCmodel. It can
be seen as if you choose one SDLC model and combined it with cyclic process
(iterativemodel).
Thismodelconsidersrisk,whichoftengoesun-noticedbymostothermodels.The model
starts with determining objectives and constraints of the software at the
startofoneiteration.Nextphaseisofprototypingthesoftware.Thisincludesrisk
analysis. Then one standard SDLC model is used to build the software. In the
fourth phase of the plan of next iteration isprepared.
V – model
The major drawback of waterfall model is we move to the next stage only when
the previous one is finished and there was no chance to go back if something is
12
Software Engineering
Tutorial
At every stage, test plans and test cases are created to verify and validate the
product according to the requirement of that stage. For example, in requirement
gatheringstagethetestteampreparesallthetestcasesincorrespondencetothe
requirements. Later, when the product is developed and is ready for testing, test
casesofthisstageverifythesoftwareagainstitsvaliditytowardsrequirementsat
thisstage.
Thismakesbothverificationandvalidationgoinparallel.Thismodelisalsoknown as
verification and validationmodel.
13
Software Engineering
Tutorial
For this model, very small amount of planning is required. It does not follow any
process, or at times the customer is not sure about the requirements and future
needs. So the input requirements are arbitrary.
This model is not suitable for large software projects but good one for learning
and experimenting.
14
Software Engineering
Tutorial
SoftwareCreation
Software ProjectManagement
A project is well-defined task, which is a collection of several operations done in
order to achieve a goal (for example, software development and delivery). A
Project can be characterized as:
Software Project
A Software Project is the complete procedure of software development from
requirement gathering to testing and maintenance, carried out according to the
execution methodologies, in a specified period of time to achieve intended
software product.
15
Software Engineering
Tutorial
The image above shows triple constraints for software projects. It is an essential
part of software organization to deliver quality product, keeping the cost within
client’s budget constrain and deliver the project as per scheduled. There are
several factors, both internal and external, which may impact this tripleconstrain
triangle. Any of the three factors can severely impact the othertwo.
Managing People
Act as projectleader
Lesion withstakeholders
Managing humanresources
Setting up reporting hierarchyetc.
16
Software Engineering
Tutorial
Managing Project
Defining and setting up projectscope
Managing project managementactivities
Monitoring progress andperformance
Risk analysis at everyphase
Take necessary step to avoid or come out ofproblems
Act as projectspokesperson
ProjectPlanning
ScopeManagement
ProjectEstimation
ProjectPlanning
Software project planning is task, which is performed before the production of
software actually starts. It is there for the software production but involves no
concrete activity that has any direct connection with the software production;
rather it is a set of multiple processes, which facilitates software production.
Project planning may include the following:
Scope Management
It defines scope of the project; this includes all the activities, process need to be
done in order to make a deliverable software product. Scope management is
essential because it creates boundaries of the project by clearly defining what
would be done in the project and what would not be done. This makes project to
containlimitedandquantifiabletasks,whichcaneasilybedocumentedandinturn
avoids cost and timeoverrun.
Define thescope
Decide its verification andcontrol
Divide the project into various smaller parts for ease ofmanagement.
17
Software Engineering
Tutorial
Verify thescope
Control the scope by incorporating changes to thescope
ProjectEstimation
Foraneffectivemanagement,accurateestimationofvariousmeasuresisamust. With
the correct estimation, managers can manage and control the project more
efficiently andeffectively.
Software sizeestimation
SoftwaresizemaybeestimatedeitherintermsofKLOC(KiloLineofCode) or by
calculating number of function points in the software. Lines of code
depend upon coding practices. Function points vary according to the user
or softwarerequirement.
Effortestimation
Timeestimation
Once size and efforts are estimated, the time required to produce the
software can be estimated. Efforts required is segregated into sub
categories as per the requirement specifications and interdependency of
various components of software. Software tasks are divided into smaller
tasks, activities or events by Work Breakthrough Structure (WBS). The
tasks are scheduled on day-to-day basis or in calendar months.
Thesumoftimerequiredtocompletealltasksinhoursordaysisthetotal time
invested to complete theproject.
Costestimation
18
Software Engineering
Tutorial
Size of thesoftware
Softwarequality
Hardware
Additional software or tools, licensesetc.
Skilled personnel with task-specificskills
Travelinvolved
Communication
Training andsupport
Project EstimationTechniques
Wediscussedvariousparametersinvolvingprojectestimationsuchassize,effort, time
andcost.
Project manager can estimate the listed factors using two broadly recognized
techniques –
Decomposition Technique
This technique assumes the software as a product of various compositions.
PutnamModel
19
Software Engineering
Tutorial
ProjectScheduling
Project Scheduling in a project refers to roadmap of all activities to be done with
specified order and within time slot allotted to each activity. Project managers
tend to define various tasks, and project milestones and then arrange them
keeping various factors in mind. They look for tasks like in critical path in the
schedule, which are necessary to complete in specific manner (because of task
interdependency) and strictly within the time allocated. Arrangement of tasks
which lies out of critical path are less likely to impact over all schedule of the
project.
Resource management
All elements used to develop a software product may be assumed as resourcefor
that project. This may include human resource, productive tools, and software
libraries.
The resources are available in limited quantity and stay in the organization as a
poolofassets.Theshortageofresourceshampersdevelopmentoftheprojectand it can
lag behind the schedule. Allocating extra resources increases development cost
in the end. It is therefore necessary to estimate and allocate adequate resources
for theproject.
20
Software Engineering
Tutorial
Project RiskManagement
Riskmanagementinvolvesallactivitiespertainingtoidentification,analyzingand
making provision for predictable and non-predictable risks in the project. Risk
may include thefollowing:
Identification - Make note of all possible risks, which may occur in the
project.
Categorize - Categorize known risks into high, medium and low risk
intensity as per their possible impact on theproject.
Monitor - Closely monitor the potential risks and their early symptoms.
Also monitor the effective steps taken to mitigate or avoidthem.
21
Software Engineering
Tutorial
Communicationcanbeoralorwritten.Communicationmanagementprocessmay
have the followingsteps:
Closure - At the end of each major event, end of a phase of SDLC or end
oftheprojectitself,administrativeclosureisformallyannouncedtoupdate
everystakeholderbysendingemail,bydistributingahardcopyofdocument or
by other mean of effectivecommunication.
22
Software Engineering
Tutorial
Configuration Management
Configurationmanagementisaprocessoftrackingandcontrollingthechangesin
software in terms of the requirements, design, functions and development of the
product.
IEEEdefinesitas“theprocessofidentifyinganddefiningtheitemsinthesystem,
controlling the change of these items throughout their life cycle, recording and
reportingthestatusofitemsandchangerequests,andverifyingthecompleteness and
correctness ofitems”.
Generally,oncetheSRSisfinalizedthereislesschanceofrequirementofchanges from
user. If they occur, the changes are addressed only with prior approval of higher
management, as there is a possibility of cost and timeoverrun.
Baseline
A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement
that defines completeness of a phase. A phase is baselined when all activities
pertainingtoitarefinishedandwelldocumented.Ifitwasnotthefinalphase,its output
would be used in next immediatephase.
Change Control
Change control is function of configuration management, which ensures that all
changes made to software system are consistent and made as per organizational
rules and regulations.
23
Software Engineering
Tutorial
Control-Iftheprospectivechangeeitherimpactstoomanyentitiesinthe system
or it is unavoidable, it is mandatory to take approval of high authorities
before change is incorporated into the system. It is decided if the change
is worth incorporation or not. If it is not, change request is
refusedformally.
There are tools available, which aid for effective project management. A few
described are:-
Gantt Chart
Gantt chart 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.
24
Software Engineering
Tutorial
PERT Chart
ProgramEvaluation&ReviewTechnique)(PERT)chartisatoolthatdepictsproject as
network diagram. It is capable of graphically representing main events of project
in both parallel and consecutive ways. Events, which occur one after another,
show dependency of the later event over the previousone.
Events are shown as numbered nodes. They are connected by labeled arrows
depicting the sequence of tasks in the project.
Resource Histogram
Thisisagraphicaltoolthatcontainsbarorchartrepresentingnumberofresources
(usually skilled staff) required over time for a project event (or phase). Resource
Histogram is an effective tool for staff planning andcoordination.
25
Software Engineering
Tutorial
The events are arranged according to their earliest possible start time. Path
between start and end node is critical path which cannot be further reduced and
all events require to be executed in same order.
26
Software Engineering
Tutorial
Software Requirements
4
The software requirements are description of features and functionalities of the
target system. Requirements convey the expectations of users from the software
product. The requirements can be obvious or hidden, known or unknown,
expected or unexpected from client’s point of view.
RequirementEngineering
The process to gather the software requirements from client, analyze, and
document them is known as requirement engineering.
FeasibilityStudy
RequirementGathering
Software RequirementSpecification
Software Requirement Validation
Let us see the process briefly-
Feasibility study
When the client approaches the organization for getting the desired product
developed, it comes up with a rough idea about what all functions the software
must perform and which all features are expected from the software.
This feasibility study is focused towards goal of the organization. This study
analyzes whether the software product can be practically materialized in termsof
implementation, contribution of project to organization, cost constraints, and as
per values and objectives of the organization. It explores technical aspects ofthe
91
Software Engineering
Tutorial
projectandproductsuchasusability,maintainability,productivity,andintegration
ability.
The output of this phase should be a feasibility study report that should contain
adequatecommentsandrecommendationsformanagementaboutwhetherornot the
project should beundertaken.
RequirementGathering
If the feasibility report is positive towards undertaking the project, next phase
starts with gathering requirements from the user. Analysts and engineers
communicate with the client and end-users to know their ideas on what the
software should provide and which features they want the software to include.
SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of software
across various platforms, maintainability, speed of recovery after crashing,
Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the
responsibility of the system analyst to document the requirements in technical
language so that they can be comprehended and used by the software
development team.
Technicalrequirementsareexpressedinstructuredlanguage,whichisused
inside theorganization.
28
Software Engineering
Tutorial
in cost if not nipped in the bud. Requirements can be checked against following
conditions -
Requirementsgathering-Thedevelopersdiscusswiththeclientandend
users and know their expectations from thesoftware.
There are various ways to discover requirements. Some of them are explained
below:
29
Software Engineering
Tutorial
Interviews
Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:
Oralinterviews
Written interviews
One-to-one interviews which are held between two persons across the
table.
Surveys
Organizationmayconductsurveysamongvariousstakeholdersbyqueryingabout their
expectation and requirements from the upcomingsystem.
Questionnaires
A document with pre-defined set of objective questions and respective options is
handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in
the questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain
operation, it is studied and requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people in thedomain
can be a great help to analyze general and specificrequirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
30
Software Engineering
Tutorial
Prototyping
Prototyping is building user interface without adding detail functionality for user
to interpret the features of intended software product. It helps giving better idea
of requirements. If there is no software installed at client’s end for developer’s
reference and the client is not aware of its own requirements, the developer
creates a prototype based on initially mentioned requirements. The prototype is
shown to the client and the feedback is noted. The client feedback serves as an
input for requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They observe the
actualworkingoftheexistinginstalledsystems.Theyobservetheworkflowatthe
client’s end and how execution problems are dealt. The team itself draws some
conclusions which aid to form requirements expected from thesoftware.
Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Crediblesource
Software Requirements
We should try to understand what sort of requirements may arise in the
requirement elicitation phase and what kinds of requirement are expected from
the software system.
31
Software Engineering
Tutorial
Functional Requirements
Requirements, which are related to functional aspect of software fall into this
category.
They define functions and functionality within and from the software system.
EXAMPLES -
Search option given to user to search from variousinvoices.
Users can be divided into groups and groups can be given separaterights.
Non-Functional Requirements
Requirements,whicharenotrelatedtofunctionalaspectofsoftware,fallintothis
category. They are implicit or expected characteristics of software, which users
make assumptionof.
Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disasterrecovery
Accessibility
Requirements are categorized logically as:
32
Software Engineering
Tutorial
easy tooperate
quick in response
effectively handling operationalerrors
providing simple yet consistent userinterface
User acceptance majorly depends upon how user can use the software. UI is the
only way for users to perceive the system. A well performing software system
must also be equipped with attractive, clear, consistent, and responsive user
interface. Otherwise the functionalities of software system can not be used in
convenient way. A system is said to be good if it provides means to use it
efficiently. User interface requirements are briefly mentioned below –
Contentpresentation
EasyNavigation
Simpleinterface
Responsive
Consistent UIelements
Feedbackmechanism
Defaultsettings
Purposefullayout
Strategical use of color andtexture.
Provide helpinformation
User centricapproach
Group based viewsettings.
33
Software Engineering
Tutorial
Validation ofrequirement
Software Metrics provide measures for various aspects of software process and
software product.
According to Tom DeMarco, a (Software Engineer), “You cannot control what you
cannotmeasure.”Byhissaying,itisveryclearhowimportantsoftwaremeasures are.
34
Software Engineering
Tutorial
Thenumberofdefectsfoundindevelopmentprocessandnumberofdefects
reported by the client after the product is installed or delivered at client-
end, define quality of theproduct.
ProcessMetrics-InvariousphasesofSDLC,themethodsandtoolsused, the
company standards and the performance of development are software
processmetrics.
35
Software Engineering
Tutorial
Software design is the first step in SDLC (Software Design Life Cycle), which
moves the concentration from problem domain to solution domain. It tries to
specify how to fulfill the requirements mentioned in SRS.
Software DesignLevels
Software design yields three levels of results:
91
Software Engineering
Tutorial
Modularization
Modularization is a technique to divide a software system into multiple discrete
and independent modules, which are expected to be capable of carrying out
task(s)independently.Thesemodulesmayworkasbasicconstructsfortheentire
software.Designerstendtodesignmodulessuchthattheycanbeexecutedand/or
compiled separately andindependently.
Modular design unintentionally follows the rule of ‘divide and conquer’ problem-
solving strategy, this is because there are many other benefits attached with the
modular design of asoftware.
Advantage ofmodularization:
Concurrency
Back in time, all software are meant to be executed sequentially. By sequential
execution, we mean that the coded instruction will be executed one afteranother
implying only one portion of program being activated at any given time. Say, a
software has multiple modules, then only one of all the modules can be found
active at any time ofexecution.
Example
The spell check feature in word processor is a module of software, which runs
along side the word processor itself.
37
Software Engineering
Tutorial
Coupling andCohesion
When a software program is modularized, its tasks are divided into several
modules based on some characteristics. As we know, modules are set of
instructions put together in order to achieve some tasks. They are though,
consideredasasingleentitybut,mayrefertoeachothertoworktogether.There are
measures by which the quality of a design of modules and their interaction
amongthemcanbemeasured.Thesemeasuresarecalledcouplingandcohesion.
Cohesion
Cohesion is a measure that defines the degree of intra-dependability within
elementsofamodule.Thegreaterthecohesion,thebetteristheprogramdesign.
38
Software Engineering
Tutorial
Coupling
Couplingisameasurethatdefinesthelevelofinter-dependabilityamongmodules of a
program. It tells at what level the modules interfere and interact with each
other. The lower the coupling, the better theprogram.
Commoncoupling-Whenmultiplemoduleshavereadandwriteaccessto some
global data, it is called common or globalcoupling.
Data coupling- Data coupling is when two modules interact with each
other by means of passing data (as parameter). If a module passes data
structure as parameter, then the receiving module should use all its
components.
DesignVerification
The output of software design process is design documentation, pseudo codes,
detailed logic diagrams, process diagrams, and detailed description of all
functional or non-functional requirements.
The next phase, which is the implementation of software, depends on all outputs
mentioned above.
It is then becomes necessary to verify the output before proceeding to the next
phase. The early any mistake is detected, the better it is or it might not be
detected until testing of the product. If the outputs of design phase are in formal
notationform,thentheirassociatedtoolsforverificationshouldbeusedotherwise a
thorough design review can be used for verification andvalidation.
39
Software Engineering
Tutorial
40
Software Engineering
Tutorial
Software Analysisand
Design Tools 6
Softwareanalysisanddesignincludesallactivities,whichhelpthetransformation of
requirement specification into implementation. Requirement specifications
specify all functional and non-functional expectations from the software. These
requirement specifications come in the shape of human readable and
understandable documents, to which a computer has nothing todo.
Software analysis and design is the intermediate stage, which helps human-
readable requirements to be transformed into actual code.
Let us see few analysis and design tools used by software designers:
Data FlowDiagram
Data Flow Diagram (DFD) is a graphical representation of flow of data in an
information system. It is capable of depicting incoming data flow, outgoing data
flow, and stored data. The DFD does not mention anything about how data flows
through the system.
ThereisaprominentdifferencebetweenDFDandFlowchart.Theflowchartdepicts flow
of control in program modules. DFDs depict flow of data in the system at various
levels. It does not contain any control or branchelements.
Types of DFD
Data Flow Diagrams are either Logical or Physical.
Logical DFD - This type of DFD concentrates on the system process, and
flowofdatainthesystem.Forexampleinabankingsoftwaresystem,how data is
moved between differententities.
Physical DFD - This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the
implementation.
DFD Components
DFD can represent source, destination, storage, and flow of data using the
following set of components -
91
Software Engineering
Tutorial
Process-ActivitiesandactiontakenonthedataarerepresentedbyCircle or
Round-edgedrectangles.
Data Storage - There are two variants of data storage - it can either be
represented as a rectangle with absence of both smaller sides or as an
open-sided rectangle with only one sidemissing.
Levels of DFD
Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which
depicts the entire information system as one diagram concealing all the
underlying details. Level 0 DFDs are also known as context levelDFDs.
Level 1 - The Level 0 DFD is broken down into more specific, Level 1DFD.
Level 1 DFD depicts basic modules in the system and flow of data among
various modules. Level 1 DFD also mentions basic processes and sources
ofinformation.
42
Software Engineering
Tutorial
Level 2 - At this level, DFD shows how data flows inside the modules
mentioned in Level1.
Higher level DFDs can be transformed into more specific lower level DFDs
with deeper level of understanding unless the desired level of specification
is achieved.
Structure Charts
Structure chart is a chart derived from Data Flow Diagram. It represents the
system in more detail than DFD. It breaks down the entire system into lowest
functional modules, describes functions and sub-functions of each module of the
system to a greater detail than DFD.
43
Software Engineering
Tutorial
Jump - An arrow is shown pointing inside the module to depict that the
control will jump in the middle of thesub-module.
44
Software Engineering
Tutorial
Data flow - A directed arrow with empty circle at the end represents data
flow.
Control flow - A directed arrow with filled circle at the end represents
controlflow.
HIPODiagram
Hierarchical Input Process Output (HIPO) diagram is a combination of two
organized methods to analyze the system and provide the means of
documentation. HIPO model was developed by IBM in year 1970.
HIPOdiagramrepresentsthehierarchyofmodulesinthesoftwaresystem.Analyst
usesHIPOdiagraminordertoobtainhigh-levelviewofsystemfunctions.It
45
Software Engineering
Tutorial
In contrast to Input Process Output (IPO) diagram, which depicts the flow of
control and data in a module, HIPO does not provide any information about data
flow or control flow.
Example
BothpartsofHIPOdiagram,Hierarchicalpresentation,andIPOChartareusedfor
structure designing of software program as well as documentation of thesame.
46
Software Engineering
Tutorial
StructuredEnglish
Most programmers are unaware of the large picture of software so they only rely
on what their managers tell them to do. It is the responsibility of higher software
management to provide accurate information to the programmers to develop
accurate yet fast code.
Hence, analysts and designers of the software come up with tools such as
Structured English. It is nothing but the description of what is required to code
and how to code it. Structured English helps the programmer to write error-free
code. Here, both Structured English and Pseudo-Code tries to mitigate that
understanding gap.
StructuredEnglishusesplainEnglishwordsinstructuredprogrammingparadigm. It is
not the ultimate code but a kind of description what is required to code and how
to code it. The following are some tokens of structuredprogramming:
IF-THEN-ELSE,
DO-WHILE-UNTIL
Analyst uses the same variable and data name, which are stored in Data
Dictionary, making it much simpler to write and understand the code.
Example
We take the same example of Customer Authentication in the online shopping
environment. This procedure to authenticate customer can be written in
Structured English as:
Enter Customer_Name
ELSE
PRINT error message
ENDIF
47
Software Engineering
Tutorial
The code written in Structured English is more like day-to-day spoken English. It
can not be implemented directly as a code of software. Structured English is
independent of programming language.
Pseudo-Code
Pseudocodeiswrittenmoreclosetoprogramminglanguage.Itmaybeconsidered as
augmented programming language, full of comments, anddescriptions.
Pseudo code avoids variable declaration but they are written using some actual
programming language’s constructs, like C, Fortran, Pascal, etc.
48
Software Engineering
Tutorial
Example
Program to print Fibonacci up to n numbers.
if a greater than b
Increase b by a;
Print b;
}
increase a by b;
print a;
}
Decision Tables
A Decision table represents conditions and the respective actions to be taken to
address them, in a structured tabular format.
Itisapowerfultooltodebugandpreventerrors.Ithelpsgroupsimilarinformation into a
single table and then by combining tables it delivers easy and convenient
decision-making.
49
Software Engineering
Tutorial
Example
Let us take a simple example of day-to-day problem with our Internet
connectivity.Webeginbyidentifyingallproblemsthatcanarisewhilestartingthe
internet and their respective possiblesolutions.
Welistallpossibleproblemsundercolumnconditionsandtheprospectiveactions under
columnActions.
Conditions/Actions Rules
Shows Connected N N N N Y Y Y Y
Opens Website Y N Y N Y N Y N
Do no action
Entity-RelationshipModel
Entity-Relationshipmodelisatypeofdatabasemodelbasedonthenotionofreal
worldentitiesandrelationshipamongthem.Wecanmaprealworldscenarioonto ER
database model. ER Model creates a set of entities with their attributes, a set of
constraints and relation amongthem.
50
Software Engineering
Tutorial
ER Model is best used for the conceptual design of database. ER Model can be
represented as follows :
Mapping cardinalities:
one toone
one tomany
many toone
many tomany
Data Dictionary
Data dictionary is the centralized collection of information about data. It stores
meaningandoriginofdata,itsrelationshipwithotherdata,dataformatforusage,
etc.Datadictionaryhasrigorousdefinitionsofallnamesinordertofacilitateuser and
softwaredesigners.
51
Software Engineering
Tutorial
Contents
Data dictionary should contain information about the following:
DataFlow
DataStructure
DataElements
DataStores
DataProcessing
Data Flow is described by means of DFDs as studied earlier and represented in
algebraic form as described.
= Composed of
{} Repetition
() Optional
+ And
[/] Or
Example
Address = House No + (Street / Area) + City + State
Data Elements
Data elements consist of Name and descriptions of Data and Control Items,
Internal or External data stores etc. with the following details:
PrimaryName
Secondary Name(Alias)
Use-case (How and where touse)
52
Software Engineering
Tutorial
Data Store
It stores the information from where the data enters into the system and exists
out of the system. The Data Store may include -
Files
o Internal tosoftware.
o External to software but on the samemachine.
o External to software and system, located on differentmachine.
Tables
o Namingconvention
o Indexingproperty
Data Processing
There are two types of Data Processing:
53
Software Engineering
Tutorial
There are multiple variants of software design. Let us study them briefly:
StructuredDesign
Structured design is a conceptualization of problem into several well-organized
elements of solution. It is basically concerned with the solution design. Benefit of
structured design is, it gives better understanding of how the problem is being
solved.Structureddesignalsomakesitsimplerfordesignertoconcentrateonthe
problem moreaccurately.
These modules are arranged in hierarchy. They communicate with each other. A
good structured design always follows some rules for communication among
multiple modules, namely -
91
Software Engineering
Tutorial
Function OrientedDesign
In function-oriented design, the system comprises of many smaller sub-systems
known as functions. These functions are capable of performing significant task in
the system. The system is considered as top view of all functions.
This design mechanism divides the whole system into smaller functions, which
provides means of abstraction by concealing the information and their operation.
These functional modules can share information among themselves by means of
information passing and using information available globally.
Design Process
Thewholesystemisseenashowdataflowsinthesystembymeansofdata
flowdiagram.
DFD depicts how functions change data and state of the entiresystem.
The entire system is logically broken down into smaller units known as
functions on the basis of their operation in thesystem.
Object OrientedDesign
Object Oriented Design (OOD) works around the entities and their characteristics
instead of functions involved in the software system. This design strategies
focuses on entities and its characteristics. The whole concept of softwaresolution
revolves around the engagedentities.
Objects - All entities involved in the solution design are known as objects.
For example, person, banks, company, and customers are treated as
objects. Every entity has some attributes associated to it and has some
methods to perform on theattributes.
55
Software Engineering
Tutorial
Design Process
Software design process can be perceived as series of well-defined steps.Though
itvariesaccordingtodesignapproach(functionorientedorobjectoriented,yetIt may
have the following stepsinvolved:
56
Software Engineering
Tutorial
Top-down design takes the whole software system as one entity and then
decomposesittoachievemorethanonesub-systemorcomponentbasedonsome
characteristics. Each sub-system or component is then treated as a system and
decomposed further. This process keeps on running until the lowest level of
system in the top-down hierarchy isachieved.
Top-downdesignstartswithageneralizedmodelofsystemandkeepsondefining the
more specific part of it. When all the components are composed the whole
system comes intoexistence.
Top-downdesignismoresuitablewhenthesoftwaresolutionneedstobedesigned from
scratch and specific details areunknown.
Bottom-up Design
The bottom up design model starts with most specific and basic components. It
proceedswithcomposinghigherlevelofcomponentsbyusingbasicorlowerlevel
components. It keeps creating higher level components until the desired system
is not evolved as one single component. With each higher level, the amount of
abstraction isincreased.
Both,top-downandbottom-upapproachesarenotpracticalindividually.Instead, a
good combination of both isused.
57
Software Engineering
Tutorial
Userinterfaceispartofsoftwareandisdesignedinsuchawaythatitisexpected to
provide the user insight of the software. UI provides fundamental platform for
human-computerinteraction.
Attractive
Simple touse
Responsive in shorttime
Clear tounderstand
Consistent on all interfacing screens
UI is broadly divided into twocategories:
Command LineInterface
Graphical UserInterface
CLI provides a command prompt, the place where the user types the command
and feeds to the system. The user needs to remember the syntax of command
anditsuse.EarlierCLIwerenotprogrammedtohandletheusererrorseffectively.
91
Software Engineering
Tutorial
Acommandisatext-basedreferencetosetofinstructions,whichareexpectedto be
executed by the system. There are methods like macros, scripts that make it
easy for the user tooperate.
CLI Elements
59
Software Engineering
Tutorial
Graphical UserInterface
GraphicalUserInterface(GUI)providestheusergraphicalmeanstointeractwith the
system. GUI can be combination of both hardware and software. Using GUI, user
interprets thesoftware.
Typically, GUI is more resource consuming than that of CLI. With advancing
technology, the programmers and designers create complex GUI designs that
work with more efficiency, accuracy, and speed.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Everygraphicalcomponentprovidesawaytoworkwiththesystem.AGUIsystem has
following elements suchas:
60
Software Engineering
Tutorial
Icon-Aniconissmallpicturerepresentinganassociatedapplication.When
theseiconsareclickedordoubleclicked,theapplicationwindowisopened.
Icondisplaysapplicationandprogramsinstalledonasystemintheformof
smallpictures.
Cursor - Interacting devices such as mouse, touch pad, digital pen are
represented in GUI as cursors. On screen cursor follows the instructions
fromhardwareinalmostreal-time.CursorsarealsonamedpointersinGUI
systems. They are used to select menus, windows and other application
features.
DialogueBox-Itisachildwindowthatcontainsmessagefortheuserand request
for some action to be taken. For Example: Application generate a dialogue
to get confirmation from user to delete afile.
Buttons - They imitate real life buttons and are used to submit inputs to
thesoftware.
61
Software Engineering
Tutorial
List-box-Provideslistofavailableitemsforselection.Morethanoneitem can
beselected.
Sliders
Combo-box
Data-grid
Drop-downlist
62
Software Engineering
Tutorial
A model used for GUI design and development should fulfill these GUI specific
steps.
GUI Requirement Gathering - The designers may like to have list of all
functional and non-functional requirements of GUI. This can be taken from
user and their existing softwaresolution.
UserAnalysis-ThedesignerstudieswhoisgoingtousethesoftwareGUI. The
target audience matters as the design details change according to the
knowledge and competency level of the user. If user is technical savvy,
advanced and complex GUI can be incorporated. For a novice user, more
information is included on how-to ofsoftware.
63
Software Engineering
Tutorial
Testing - GUI testing can be done in various ways. Organization can have
in-houseinspection,directinvolvementofusersandreleaseofbetaversion are
few of them. Testing may include usability, compatibility, user
acceptanceetc.
GUI implementation tools provide powerful array of GUI controls. For software
customization, designers can change the code accordingly.
There are different segments of GUI tools according to their different use and
platform.
Example
MobileGUI,ComputerGUI,Touch-ScreenGUIetc.Hereisalistoffewtoolswhich come
handy to buildGUI:
FLUID
AppInventor(Android)
LucidChart
Wavemaker
VisualStudio
64
Software Engineering
Tutorial
Offersimpleerrorhandling-Asmuchaspossible,designthesystemso the
user will not make a serious error. If an error is made, the system should
be able to detect it and offer simple, comprehensible mechanisms for
handling theerror.
Permiteasyreversalofactions-Thisfeaturerelievesanxiety,sincethe
userknowsthaterrorscanbeundone.Easyreversalofactionsencourages
exploration of unfamiliar options. The units of reversibility may be a single
action, a data entry, or a complete group ofactions.
65
Software Engineering
Tutorial
66
Software Engineering
Tutorial
Halstead's ComplexityMeasures
In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software
complexity. Halstead’s metrics depends upon the actual implementation of
program and its measures, which are computed directly from the operators and
operands from source code, in static manner. It allows to evaluate testing time,
vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code.
AccordingtoHalstead,“Acomputerprogramisanimplementationofanalgorithm
considered to be a collection of tokens which can be classified as eitheroperators
or operands”. Halstead metrics think a program as sequence of operators and
their associatedoperands.
91
Software Engineering
Tutorial
Parameter Meaning
When we select source file to view its complexity details in Metric Viewer, the
following result is seen in Metric Report:
n Vocabulary n1 + n2
N Size N1 + N2
Cyclomatic ComplexityMeasures
Everyprogramencompassesstatementstoexecuteinordertoperformsometask and
other decision-making statements that decide, what statements need to be
executed. These decision-making constructs change the flow of theprogram.
If we compare two programs of same size, the one with more decision-making
statements will be more complex as the control of program jumps frequently.
68
Software Engineering
Tutorial
McCabe,in1976,proposedCyclomaticComplexityMeasuretoquantifycomplexity of a
given software. It is graph driven model that is based on decision-making
constructsofprogramsuchasif-else,do-while,repeat-until,switch-caseandgoto
statements.
V(G) = e – n + 2
Where:
e = 10
n=8
Cyclomatic Complexity = 10 - 8 + 2
69
Software Engineering
Tutorial
=4
Function Point
It is widely used to measure the size of software. Function Point concentrates on
functionalityprovidedbythesystem.Featuresandfunctionalityofthesystemare used
to measure the softwarecomplexity.
External Input
Every unique input to the system, from outside, is considered as external input.
Uniqueness of input is measured, as no two inputs should have same formats.
These inputs can either be data or control parameters.
70
Software Engineering
Tutorial
External Output
All output types provided by the system are counted in this category. Output is
considered unique if their output format and/or processing are unique.
External Inquiry
An inquiry is a combination of input and output, where user sends some data to
inquire about as input and the system responds to the user with the output of
inquiry processed. The complexity of a query is more than External Input and
External Output. Query is said to be unique if its input and output are unique in
terms of format and data.
Simple - if query needs low processing and yields small amount of output
data
Complex - if query needs high process and yields large amount of output
data
71
Software Engineering
Tutorial
Eachoftheseparametersinthesystemisgivenweightageaccordingtotheirclass
andcomplexity.Thetablebelowmentionstheweightagegiventoeachparameter:
Inputs 3 4 6
Outputs 4 5 7
Enquiry 3 4 6
Files 7 10 15
Interfaces 5 7 10
The table above yields raw Function Points. These function points are adjusted
according to the environment complexity. System is described using fourteen
different characteristics:
Datacommunications
Distributedprocessing
Performanceobjectives
Operation configurationload
Transactionrate
Online dataentry,
End userefficiency
Onlineupdate
Complex processinglogic
Re-usability
Installationease
Operationalease
Multiplesites
Desire to facilitatechanges
These characteristics factors are then rated from 0 to 5, as mentioned below:
Noinfluence
72
Software Engineering
Tutorial
Incidental
Moderate
Average
Significant
Essential
All ratings are then summed up as N. The value of N ranges from 0 to 70 (14
types of characteristics x 5 types of ratings). It is used to calculate Complexity
Adjustment Factors (CAF), using the following formulae:
Then,
Cost = $ /FP
Productivity = FP /person-month
73
Software Engineering
Tutorial
SoftwareImplementation
10
In this chapter, we will study about programming methods, documentation and
challenges in software implementation.
StructuredProgramming
In the process of coding, the lines of code keep multiplying, thus, size of the
software increases. Gradually, it becomes next to impossible to remember the
flow of program. If one forgets how software and its underlying programs, files,
procedures are constructed, it then becomes very difficult to share, debug, and
modifytheprogram.Thesolutiontothisisstructuredprogramming.Itencourages the
developer to use subroutines and loops instead of using simple jumps in the
code, thereby bringing clarity in the code and improving its efficiency Structured
programming also helps programmer to reduce coding time and organize code
properly.
Structured programming states how the program shall be coded. It uses three
main concepts:
1. Top-downanalysis-Asoftwareisalwaysmadetoperformsomerational
work.Thisrationalworkisknownasprobleminthesoftwareparlance.Thus it is
very important that we understand how to solve the problem. Under top-
down analysis, the problem is broken down into small pieces where each
one has some significance. Each problem is individually solved and steps
are clearly stated about how to solve theproblem.
91
Software Engineering
Tutorial
FunctionalProgramming
Functional programming is style of programming language, which uses the
concepts of mathematical functions. A function in mathematics should always
produce the same result on receiving the same argument. In procedural
languages, the flow of the program runs through procedures, i.e. the control of
program is transferred to the called procedure. While control flow is transferring
from one procedure to another, the program changes its state.
75
Software Engineering
Tutorial
Common Lisp, Scala, Haskell, Erlang, and F# are some examples of functional
programming languages.
Programmingstyle
Programmingstyleissetofcodingrulesfollowedbyalltheprogrammerstowrite the
code. When multiple programmers work on the same software project, they
frequently need to work with the program code written by some other developer.
This becomes tedious or at times impossible, if all developers do not follow some
standard programming style to code theprogram.
Coding Guidelines
Practiceofcodingstylevarieswithorganizations,operatingsystemsandlanguage of
codingitself.
Indenting - This is the space left at the beginning of line, usually 2-8
whitespace or singletab.
Linelengthandwrapping-Defineshowmanycharactersshouldbethere
inoneline,mostlyalineis80characterslong.Wrappingdefineshowaline should
be wrapped, if is toolong.
76
Software Engineering
Tutorial
SoftwareDocumentation
Software documentation is an important part of software process. A well written
documentprovidesagreattoolandmeansofinformationrepositorynecessaryto know
about software process. Software documentation also provides information about
how to use theproduct.
Requirementdocumentation-Thisdocumentationworksaskeytoolfor
software designer, developer, and the test team to carry out their
respective tasks. This document contains all the functional, non-functional
and behavioral description of the intendedsoftware.
Source of this document can be previously stored data about the software,
already running software at the client’s end, client’s interview,
questionnaires, and research. Generally it is stored in the form of
spreadsheet or word processing document with the high-end software
management team.
SoftwareDesigndocumentation-Thesedocumentationscontainallthe
necessary information, which are needed to build the software. It
contains: (a) High-level software architecture, (b) Software design
details, (c) Data flow diagrams, (d) Databasedesign
77
Software Engineering
Tutorial
Technicaldocumentation-Thesedocumentationsaremaintainedbythe
developers and actual coders. These documents, as a whole, represent
information about the code. While writing the code, the programmers also
mentionobjectiveofthecode,whowroteit,wherewillitberequired,what it does
and how it does, what other resources the code uses,etc.
There are various automated tools available and some comes with the
programming language itself. For example java comes JavaDoc tool to
generate technical documentation of code.
78
Software Engineering
Tutorial
79
Software Engineering
Tutorial
SoftwareValidation
Validation is process of examining whether or not the software satisfies the user
requirements. It is carried out at the end of the SDLC. If the software matches
requirements for which it was made, it is validated.
SoftwareVerification
Verification is the process of confirming if the software is meeting the business
requirements, and is developed adhering to the proper specifications and
methodologies.
Verificationanswersthequestion–"Arewedevelopingthisproductbyfirmly
following all design specifications?"
Errors-Theseareactualcodingmistakesmadebydevelopers.Inaddition,
thereisadifferenceinoutputofsoftwareanddesiredoutput,isconsidered as
anerror.
91
Software Engineering
Tutorial
Fault - When error exists fault occurs. A fault, also known as a bug, is a
result of an error which can cause system tofail.
Manual Vs AutomatedTesting
Testing can either be done manually or using an automated testing tool:
Manualtestingistimeandresourceconsuming.Thetesterneedstoconfirm
whether or not right test cases are used. Major portion of testing involves
manualtesting.
A test needs to check if a webpage can be opened in Internet Explorer. This can
be easily done with manual testing. But to check if the web-server can take the
load of 1 million users, it is quite impossible to test manually.
There are software and hardware tools which helps tester in conducting load
testing, stress testing, regression testing.
Testing Approaches
Tests can be conducted based on two approaches –
1. Functionalitytesting
2. Implementationtesting
When functionality is being tested without taking the actual implementation in
concern it is known as black-box testing. The other side is known as white-box
testingwherenotonlyfunctionalityistestedbutthewayitisimplementedisalso
analyzed.
Exhaustive tests are the best-desired method for a perfect testing. Every single
possible value in the range of the input and output values is tested. It is not
81
Software Engineering
Tutorial
possibletotesteachandeveryvalueinrealworldscenarioiftherangeofvalues is large.
Black-box testing
It is carried out to test functionality of the program and also called ‘Behavioral’
testing. The tester in this case, has a set of input values and respective desired
results. On providing input, if the output matches with the desired results, the
program is tested ‘ok’, and problematic otherwise.
In this testing method, the design and structure of the code are not known tothe
tester, and testing engineers and end users conduct this test on the software.
Boundary values - The input is divided into higher and lower end values.
If these values pass the test, it is assumed that all values in between may
pass too.
White-box testing
It is conducted to test program and its implementation, in order to improve code
efficiency or structure. It is also known as ‘Structural’ testing.
82
Software Engineering
Tutorial
In this testing method, the design and structure of the code are known to the
tester. Programmers of the code conduct this test on the code.
Data-flow testing - This testing technique emphasis to cover all the data
variables included in the program. It tests where the variables were
declared and defined and where they were used orchanged.
TestingLevels
Testing itself may be defined at various levels of SDLC. The testing process runs
parallel to software development. Before jumping on the next stage, a stage is
tested, validated and verified.
Testing separately is done just to make sure that there are no hidden bugs or
issues left in the software. Software is tested on various levels -
Unit Testing
While coding, the programmer performs some tests on that unit of program to
know if it is error free. Testing is performed under white-box testing approach.
Unit testing helps developers decide that individual units of the program are
working as per requirement and are error free.
Integration Testing
Even if the units of software are working fine individually, there is a need to find
outiftheunitsifintegratedtogetherwouldalsoworkwithouterrors.Forexample,
argument passing and data updationetc.
83
Software Engineering
Tutorial
System Testing
The software is compiled as product and then it is tested as a whole. This can be
accomplished using one or more of the following tests:
Functionalitytesting-Testsallfunctionalitiesofthesoftwareagainstthe
requirement.
Performance testing - This test proves how efficient the software is. It
teststheeffectivenessandaveragetimetakenbythesoftwaretododesired task.
Performance testing is done by means of load testing and stress testing
where the software is put under high user and data load under various
environmentconditions.
Security&Portability-Thesetestsaredonewhenthesoftwareismeant to
work on various platforms and accessed by number ofpersons.
Acceptance Testing
Whenthesoftwareisreadytohandovertothecustomerithastogothroughlast phase of
testing where it is tested for user-interaction and response. This is important
because even if the software matches all user requirements and ifuser does not
like the way it appears or works, it may berejected.
Regression Testing
Whenever a software product is updated with new code, feature or functionality,
itistestedthoroughlytodetectifthereisanynegativeimpactoftheaddedcode. This is
known as regressiontesting.
TestingDocumentation
Testing documents are prepared at different stages -
84
Software Engineering
Tutorial
Before Testing
Testing starts with test cases generation. Following documents are needed for
reference –
Test Policy document - This describes how far testing should take place
before releasing theproduct.
Testdescription-Thisdocumentisadetaileddescriptionofalltestcases and
procedures to executethem.
Test case report - This document contains test case report as a result of
the test.
Test logs - This document contains test logs for every test casereport.
After Testing
The following documents may be generated after testing :
Testsummary-Thistestsummaryiscollectiveanalysisofalltestreports and
logs. It summarizes and concludes if the software is ready to be launched.
The software is released under version control system if it is ready
tolaunch.
85
Software Engineering
Tutorial
Testingvs.QualityControl&AssuranceandAudit
We need to understand that software testing is different from software quality
assurance, software quality control and software auditing.
Softwareaudit-Thisisareviewofprocedureusedbytheorganizationto
developthesoftware.Ateamofauditors,independentofdevelopmentteam
examinesthesoftwareprocess,procedure,requirementsandotheraspects of
SDLC. The purpose of software audit is to check that software and its
development process, both conform standards, rules andregulations.
86
Software Engineering
Tutorial
ClientRequirements-Overthetime,customermayaskfornewfeatures or
functions in thesoftware.
Types ofmaintenance
In a software lifetime, type of maintenance may vary based on its nature. It may
be just a routine maintenance tasks as some bug discovered by some user or it
may be a large event in itself based on maintenance size or nature. Followingare
some types of maintenance based on theircharacteristics:
CorrectiveMaintenance-Thisincludesmodificationsandupdationsdone in
order to correct or fix problems, which are either discovered by user or
concluded by user errorreports.
91
Software Engineering
Tutorial
Cost ofMaintenance
Reports suggest that the cost of maintenance is high. A study on estimating
software maintenance found that the cost of maintenance is as high as 67% of
the cost of entire software process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC
phases. There are various factors, which trigger maintenance cost go high, such
as:
Older softwares, which were meant to work on slow machines with less
memory and storage capacity cannot keep themselves challenging against
newly coming enhanced softwares on modernhardware.
88
Software Engineering
Tutorial
Most maintenance engineers are newbie and use trial and error method to
rectifyproblem.
Often, changes made can easily hurt the original structure of the software,
making it hard for any subsequentchanges.
Changes are often left undocumented which may cause more conflicts in
future.
ProgrammingLanguage
Dependence on externalenvironment
Maintenance Activities
IEEE provides a framework for sequential maintenance process activities. It can
be used in iterative manner and can be extended so that customized items and
processes can be included.
Identification&Tracing -Itinvolvesactivitiespertainingtoidentification
ofrequirementofmodificationormaintenance.Itisgeneratedbyuseror
89
Software Engineering
Tutorial
Implementation-Thenewmodulesarecodedwiththehelpofstructured
design created in the design step.Every programmer is expected to dounit
testing in parallel.
Delivery - After acceptance test, the system is deployed all over the
organization either by small update package or fresh installation of the
system. The final testing takes place at client end after the software is
delivered.
SoftwareRe-engineering
When we need to update the software to keep it to the current market, without
impactingitsfunctionality,itiscalledsoftwarere-engineering.Itisathorough
process where the design of software is changed and programs arere-written.
90
Software Engineering
Tutorial
Legacy software cannot keep tuning with the latest technology available in the
market. As the hardware become obsolete, updating of software becomes a
headache. Even if software grows old with time, its functionality does not.
For example, initially Unix was developed in assembly language. When language
Ccameintoexistence,Unixwasre-engineeredinC,becauseworkinginassembly
language wasdifficult.
Other than this, sometimes programmers notice that few parts of software need
more maintenance than others and they also need re-engineering.
Re-Engineering Process
Decide what to re-engineer. Is it whole software or a part ofit?
91
Software Engineering
Tutorial
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing,
understanding the existing system. This process can be seen as reverse SDLC
model, i.e. we try to get higher abstraction level by analyzing lower abstraction
levels.
Program Restructuring
Itisaprocesstore-structureandre-constructtheexistingsoftware.Itisallabout re-
arranging the source code, either in same programming language or from one
programming language to a different one. Restructuring can have either source
code-restructuring and data-restructuring orboth.
Re-structuring does not impact the functionality of the software but enhance
reliability and maintainability. Program components, which cause errors very
frequently can be changed, or updated with re-structuring.
Forward Engineering
Forward engineering is a process of obtaining desired software from the
specificationsinhandwhichwerebroughtdownbymeansofreverseengineering. It
assumes that there was some software engineering already done in thepast.
92
Software Engineering
Tutorial
Component reusability
A component is a part of software program code, which executes an independent
task in the system. It can be a small module or sub-system itself.
Example
Theloginproceduresusedonthewebcanbeconsideredascomponents,printing system
in software can be seen as a component of thesoftware.
Components have high cohesion of functionality and lower rate of coupling, i.e.
they work independently and can perform tasks without depending on other
modules.
InOOP,theobjectsaredesignedareveryspecifictotheirconcernandhavefewer
chances to be used in some othersoftware.
In modular programming, the modules are coded to perform specific tasks which
can be used across number of other software programs.
Reuse Process
Two kinds of method that can be adopted: either by keeping requirements same
and adjusting components or by keeping components same and modifying
requirements.
93
Software Engineering
Tutorial
IncorporateComponents-Allmatchedcomponentsarepackedtogether to
shape them as completesoftware.
94
Software Engineering
Tutorial
CASETools
CASE tools are set of software application programs, which are used to automate
SDLC activities. CASE tools are used by software project managers, analysts and
engineers to develop software system.
There are number of CASE tools available to simplify various stages of Software
DevelopmentLifeCyclesuchasAnalysistools,Designtools,Projectmanagement tools,
Database Management tools, Documentation tools are to name afew.
UseofCASEtoolsacceleratesthedevelopmentofprojecttoproducedesiredresult and
helps to uncover flaws before moving ahead with next stage in software
development.
Components of CASETools
CASE tools can be broadly divided into the following parts based on their use ata
particular SDLC stage:
100
Software Engineering
Tutorial
Upper Case Tools - Upper CASE tools are used in planning, analysis and
design stages ofSDLC.
LowerCaseTools-LowerCASEtoolsareusedinimplementation,testing
andmaintenance.
IntegratedCaseTools-IntegratedCASEtoolsarehelpfulinallthestages of
SDLC, from Requirement gathering to Testing anddocumentation.
CASE tools can be grouped together if they have similar functionality, process
activities and capability of getting integrated with other tools.
Scope of CaseTools
The scope of CASE tools goes throughout the SDLC. Now we briefly go through
various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow
among various software components and system structure in a graphical form.
For example, Flow Chart Maker tool for creating state-of-the-art flowcharts.
101
Software Engineering
Tutorial
Documentation Tools
Documentation in a software project starts prior to the software process, goes
throughout all phases of SDLC and after the completion of the project.
Documentation tools generate documents for technical users and end users.
Technical users are mostly in-house professionals of the development team who
refer to system manual, reference manual, training manual, installation manuals
etc. The end user documents describe the functioning and how-to of the system
such as user manual. For example, Doxygen, DrExplain, Adobe RoboHelp for
documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any
inconsistency, inaccuracy in the diagrams, data redundancies or erroneous
omissions. For example, Accept 360, Accompa, CaseComplete for requirement
analysis, Visible Analyst for total analysis.
Design Tools
These tools help software designers to design the block structure of thesoftware,
which may further be broken down in smaller modules using refinement
techniques. These tools provides detailing of each module and interconnections
among modules. For example, Animated Software Design.
102
Software Engineering
Tutorial
Programming Tools
These tools consist of programming environments like IDE (Integrated
Development Environment), in-built modules library and simulation tools. These
toolsprovidecomprehensiveaidinbuildingsoftwareproductandincludefeatures for
simulation and testing. For example, Cscope to search code in C,Eclipse.
Prototyping Tools
Software prototype is simulated version of the intended software product.
Prototypeprovidesinitiallookandfeeloftheproductandsimulatesfewaspectof
actualproduct.
Prototyping CASE tools essentially come with graphical libraries. They can create
hardware independent user interfaces and design. These tools help us to build
rapid prototypes based on existing information. In addition, they provide
simulation of software prototype. For example, Serena prototype composer,
Mockup Builder.
Maintenance Tools
Software maintenance includes modifications in the software product after it is
delivered.Automaticlogginganderrorreportingtechniques,automaticerror
103
Software Engineering
Tutorial
ticketgenerationandrootcauseAnalysisarefewCASEtools,whichhelpsoftware
organization in maintenance phase of SDLC. For example, Bugzilla for defect
tracking, HP QualityCenter.
104