Syllabus

BCO232A Software Engineering and Project Management 3-0-0 [3]

Introduction- Introduction to Software Engineering, Software Components, Software Characteristics, Software Crisis,
UNIT 1 Engineering aspects of Software production – necessity of automation .Job responsibilities of Programmers and
Software Engineers as Software developers. Software Development Life Cycle (SDLC)
Process Models and Program Design Techniques- Software Development Process Models – Code & Fix model,
Waterfall model, Incremental model, Rapid Prototyping model, Spiral (Evolutionary) model. Software Requirement
UNIT 2 Specifications (SRS), Management of User Needs, Data Flow Diagrams, Entity Relationship Diagrams, Decision Tables,
SRS Document, Design Techniques – Structured Programming, Coupling and Cohesion, Abstraction and Information
Hiding, Software Modeling Tools –Data flow Diagrams, UML and XML.
Software Testing: Testing Objectives, Unit Testing, Integration Testing, Acceptance Testing, Regression Testing,
Verification and Validation: Testing of Software Products – Black-Box Testing and White-Box Testing, Static Analysis,
UNIT 3
Symbolic Execution and Control Flow Graphs –Cyclomatic Complexity. Maintainence and its need and types of
maintenance. CASE tools & graphical reporting tools.
Project Management: project, project specification parameters, principle &life cycle of project management, project
management Plan, why the project is delayed? and scheduling activities, Task Network & scheduling methods, critical
UNIT 4
Path, PERT& CPM. Effort Estimation Techniques Monitoring & Control: Change Control, Software Configuration
Management (SCM). Risk Analysis and Management, RMMM, Software Metrices.
Quality Management and People Management- Introduction, Understanding Behavior, Organizational Behavior,
Selecting The Right Person For The Job, Motivation, The Old man – Hackman Job Characteristics Model , Working in
Groups, Organization and team structures, Decision Making, Leadership, Organizational Structures, Stress, Health And
UNIT 5
Safety.

JECRC University
 Mapping of CO with PO

Program
Course Program Outcome Specific
Outcome Outcome
PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2 PSO3

CO1 L H M L

CO2 H H M M

CO3 H M L H

CO4 L L L M L

JECRC University
DEFINITION OF SOFTWARE
PROCESS
• A framework for the activities, actions, and tasks that are required
to build high-quality software.

• SP defines the approach that is taken as software is engineered.

• Is not equal to software engineering, which also encompasses

technologies that populate the process– technical methods and
automated tools.
 PROCESS MODEL
• A process model is a formal way of representing how a business
operates

• Data flow diagramming shows business processes and the data

that flows between them

• Logical process models describe processes without suggesting

how they are conducted

• Physical models include information about how the processes

are implemented
Timeline of Methodologies

1950s Code & Fix

1960s Design-Code-Test-Maintain
1970s Waterfall Model
1980s Spiral Model
1990s Rapid Application Development, V Model
2000s Agile Methods
 1. The Waterfall Model

• The waterfall model is the classic

lifecycle
model – it is widely known, understood
and (commonly?) used.
• In some respect, waterfall is the
”common
sense” approach.
• Introduced by Royce 1970.

JECRC University
User Requirements phase User Requirements Document
output

Software Requirements
Software Requirements
Document

Architectural Design
Architecture Design
Document

”Swimming
upstream” Detailed design & Coding Detailed
Design
& Code

Testing
The Waterfall
Lifecycle Workflow

Delivery

Time

JECRC University
 Advantages
1. Easy to understand and implement.
2. Widely used and known (in theory!)
3. Reinforces good habits: define-before- design,
design-before-code
4. Identifies deliverables and milestones
5. Document driven, URD, SRD, … etc. Published
documentation standards, e.g. PSS-05.
6. Works well on mature products and weak teams.
 Disadvantages
1. Idealised, doesn’t match reality well.

2. Doesn’t reflect iterative nature of exploratory development.

3. Unrealistic to expect accurate requirements so early in

project

4. Software is delivered late in project, delays discovery of

serious errors.

5. Difficult to integrate risk management

 2. Code-and-Fix Model
This model starts with an informal general product
idea and just develops code until a product is
”ready” (or money or time runs.

out). Work is in random order.

Corresponds with no plan! (Hacking!)

 Advantages
1. No administrative overhead

2. Signs of progress (code) early.

3. Low expertise, anyone can use it!

4. Useful for small “proof of concept” projects,

e.g. as part of risk reduction.
 Disadvantages
1. Dangerous!
1. No visibility/control
2. No resource planning
3. No deadlines
4. Mistakes hard to detect/correct

2. Impossible for large projects,

communication breakdown, chaos.
 3. Spiral Model
Since end-user requirements are hard to obtain/define, it is natural to
develop software in an experimental way: e.g.

1. Build some software

2. See if it meets customer requirements

3. If no goto 1 else stop.

This loop approach gives rise to structured iterative lifecycle models.

In 1988 Boehm developed the spiral model as an iterative model which

includes risk analysis and risk management.

Key idea: on each iteration identify and solve

the sub-problems with the highest risk.

 Cumulative cost
Determine objectives,
Evaluate alternatives,
alternatives & constraints Identify & resolve
risks

Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment RequirementsConcept Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Testing
End Acceptance Develop & verify
Plan next phase
Testing next-level product
Each cycle follows a waterfall model by:
1. Determining objectives
2. Specifying constraints
3. Generating alternatives
4. Identifying risks
5. Resolving risks
6. Developing next-level product
7. Planning next cycle
 Advantages
1. Realism: the model accurately reflects the iterative
nature of software development on projects with
unclear requirements
2. Flexible: incoporates the advantages of the waterfal
and rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.
 Disadvantages
• Needs technical expertise in risk analysis to really
work
• Model is poorly understood by non-technical
management, hence not so widely used
• Complicated model, needs competent
professional management. High administrative
overhead.
 4. Rapid Prototyping

Key idea: Customers are non-technical and

usually don’t know what they want/can have.

Rapid prototyping emphasises requirements

analysis and validation, also called:
• customer oriented development,
• evolutionary prototyping
Requirements Capture

Iterate
Quick Design

Build Prototype

Customer Evaluation of
Prototype

The Rapid Engineer Final

Product
Prototype Workflow
 Advantages
1. Reduces risk of incorrect user requirements

2. Good where requirements are

changing/uncommitted

3. Regular visible progress aids management

4. Supports early product marketing

 Disadvantages
1. An unstable/badly implemented prototype often becomes the
final product.

2. Requires extensive customer collaboration

Costs customers money
Needs committed customers
Difficult to finish if customer withdraws
May be too customer specific, no broad market

3. Difficult to know how long project will last

4. Easy to fall back into code-and-fix without proper

requirements analysis, design, customer evaluation and
feedback.
 5. Incremental Model
• Combine the advantages of Waterfall and
Evolutionary Model.

Requirements Split into Design

Outline increments System
Architecture

Develop Validate Integrate Validate

Increment Increment Increment System

Final
System
 Cont…
• Each increment is a mini-waterfall.
 Cont…
• Prioritizes the services to be provided by the
system.
• Maps these requirements to Increment
based on priority.
• Freezes requirement for the current
Increment.
Requirements for the later increments can evolve
concurrently.
• Each Increment release is a working system:
Allows user to experiment.
Can be put into service right away.
 Advantages
• Early utilization:
the 1st increment satisfies the most critical requirement.

• Early increments can serves as prototypes.

• Lower risk of overall project failure.

• Most crucial and basic services are implemented first

→ receives multiple testing throughout development.
 Disadvantages
• Hard to map requirement into small increments (< 20,000
lines of code).
• Hard to define the basic services that are shared by all
subsequent increments.
• Popular variant:
AGILE method:
• eXtreme Programming (XP)
• Not covered here.
 6. RAD Model

WHAT IS RAD ???

 RAD model is Rapid Application Development model.

 It is a type of Incremental model.

 In RAD the Components are developed in

parallel Manner.

 It is a faster software development process.

 PHASES IN RAD

 Requirements Planning phase

 User design phase

 Construction phase

 Cutover phase
 1. Requirements Planning phase

 Users, managers, and IT staff members discuss on

Business needs.

 They discuss on System requirements.

 They also discuss on Project scope

 It decide who will generate software.

 It tells what software will do.

 2. User design phase

 It is also called as Modeling phase.

 User Design phase is a continuous interactive process.

 During this phase, users interact with software model.

 It allows users to understand, modify the System.

 It approve a working model of the system that meets

• their needs.
 3. Construction phase
 Focuses on program and application development
task.

 Tasks are

* Programming and application development,

* Coding,

* Unit-integration and

* System testing.
 4. Cutover phase

 It is the final ( Phase ) tasks in the System Development

Life Cycle (SDLC).

 Its tasks are

* Data conversion,
* Full-scale testing,
* System change over,
* User training.

 In this phase the new system is built, and delivered.

RAD Model Diagram
 Advantages

 RAD reduces the development time.

 Increases reusability of components.

 Greater Customer Satisfaction.

 Faster Delivery Time.

 Simple and Better Quality.

 Disadvantages

 Requires highly skilled developers/designers.

 RAD is not appropriate when technical risk are high.

 Cant use for small projects.

 Absence of reusable component can lead to failure

of the project.
 7. Agile Model
• Agile model is a combination of iterative and incremental process
model.

• focus on process adaptability and customer satisfaction.

• It is intended to be a collection of values, principles, and practices

for modeling software.

• Agile works by breaking down the project into smaller chunks and
then continuously delivering them in short two weeks cycles called
iterations
JECRC University
JECRC University
The main agile methodologies that are
being used todays are:-
re :xtreme Programming (XP) and
SCRUM.
• Extreme Programming (XP) is the
coding of what the customer specifies,
and the testing of that code. Extreme
programming is a software development
methodology intended to improve
software quality. It is a powerful tool when
the customer is not sure about the
functionality of the system.
• Scrum consists of Scrum Teams and their
associated roles, events, artifacts, and
rules.
JECRC University
 Advantages

Advantages of Agile model:

• Customer satisfaction by rapid,
continuous delivery of useful software.
• People and interactions are emphasized
rather than process and tools.
• Customers, developers and testers
constantly interact with each other.
• Working software is delivered frequently
(weeks rather than months).

JECRC University
 Disadvantages
Disadvantages of Agile model:
•In case of some software deliverables, especially the large
ones, it is difficult to assess the effort required at the
beginning of the software development life cycle.
•There is lack of emphasis on necessary designing and
documentation.
•The project can easily get taken off track if the customer
representative is not clear what final outcome that they
want.
•Only senior programmers are capable of taking the kind of
decisions required during the development process. Hence
it has no place for newbie programmers, unless combined
with experienced resources.

JECRC University
DATA FLOW DIAGRAM

A data flow diagram (DFD) maps out the flow of

information for any process or system. It uses
defined symbols like rectangles, circles and
arrows, plus short text labels, to
show data inputs, outputs, storage points and the
routes between each destination.

JECRC University
Data Flow Diagrams Symbols
System – a group of interrelated
Source/ procedures used for a business
Sink function, with an identifiable
boundary, working together for some
purpose.
Analysis – separation of a whole into its
0.0
component parts
Process Design – to create, fashion, execute, or
construct according to plan

Physical Data Flow Diagrams – show how

DATA STORE
the current system flows

Data Flow Lines

Logical Data Flow Diagrams – show the data
flow, structure, and requirements of a new
system
JECRC University
Data Flow Diagrams Symbols

Source/ Source/Sink – help to establish the

Sink boundaries of the system. A source identifies
the origin of data inflow to the system. A sink
identifies the outflow of a system, many times
as information.
0.0 Sometimes referred to an entity, a source
Process
may be a customer, vendor, employee, or
even another system. A single entity can be
both a source and a sink.
DATA STORE

Data Flow Lines

JECRC University
Data Flow Diagrams Symbols

Source/ Processes – are the activities (manual and

Sink automated) that transform the inputs,
transport data from process to process,
stores the data, and produce the outputs of a
system.
0.0
Processes are used on every DFD starting
Process
with an over all process on the context level
diagram, the system. The system is then
decomposed until a primitive level is
DATA STORE obtained. The primitive level is the point in
which the relevant activities of a process are
identified.
Data Flow Lines

JECRC University
Data Flow Diagrams Symbols

Source/ Data Store – is the resting place of the data

Sink in a system. A data store can be in the form
of paper, a disk file or any other media.
Normally the word ‘data’ does not appear in
the title of a data store. Some examples of
0.0 data stores are Customer Order, Payment,
Process
Invoice, Time Card……

DATA STORE

Data Flow Lines

JECRC University
Data Flow Diagrams Symbols

Source/ Data Flow – is the data in motion. Data can

Sink move from the outside (source) into a
process. Once the inside of a system data
must flow from place to place through a
process, the flow lines show this movement.
0.0
Process
The lines are labeled to provide clarity and
meaning to the data moving through the
system.

DATA STORE

Data Flow Lines

JECRC University
 Data Flow Diagrams Levels
Context Level DFD

Source/ Source/ Sink

Data Flow 0.0
Source/ Sink
Process
Sink Data Flow
Data Flow

Level 0 DFD
0.0
1.0
Process Process
Data Flow Data Flow
Data Flow

DATA STORE 2.0

Source/ Sink Source/ Sink
Process
Data Flow Data Flow

Data Flow
Data Flow Lines
3.0
Process Data Flow

JECRC University
 Data Flow Diagrams Levels
Source
Level 1 DFD (and on)
Data Flow
Source/
Sink

1.1
DATA STORE
Process

0.0
Process Source
1.2
Data Flow Process

DATA STORE

Data Flow
Data Flow Lines
Sink

JECRC University
JECRC University
JECRC University
 SRS

1. “The SRS must correctly define all of the

software requirements, but no more.”

2. “The SRS should not describe design,

verification, or project management details,
except for required design constraints

JECRC University
CHARACHTERSTICS OF GOOD SRS

1. Unambiguous
2. Complete
3. Verifiable
4. Consistent
5. Modifiable
6. Traceable
7. Usable during the Operation and Maintenance
Phase

JECRC University
 ER Diagram
• 1976 proposed by Peter Chen

• ER diagram is widely used in database design

Represent conceptual level of a database system

Describe things and their relationships in high level

 Basic Concepts
• Entity set – an abstraction of similar things, e.g.
cars, students
An entity set contains many entities

• Attributes: common properties of the entities in a

entity sets

• Relationship – specify the relations among entities

from two or more entity sets
An Example
 Decision Tables
• A matrix representation of the logic of a decision

• Specifies the possible conditions and the resulting actions

• Best used for complicated decision logic

• Consists of three parts
Condition stubs
• Lists condition relevant to decision
Action stubs
• Actions that result from a given set of conditions
Rules
• Specify which actions are to be followed for a given set of conditions
 Cont…
• Indifferent Condition
Condition whose value does not affect which action is taken
for two or more rules
• Standard procedure for creating decision tables
Name the condition and values each condition can assume
Name all possible actions that can occur
List all rules
Define the actions for each rule
Simplify the table
 Example

Figure:- Complete decision table for payroll system example

 Constructing a Decision Table

• PART 1. FRAME THE PROBLEM.

Identify the conditions (decision criteria). These are the factors that will influence the
decision.
• E.g., We want to know the total cost of a student’s tuition. What factors are
important?
Identify the range of values for each condition or criteria.
• E.g. What are they for each factor identified above?
Identify all possible actions that can occur.
• E.g. What types of calculations would be necessary?

• PART 2. CREATE THE TABLE.

Create a table with 4 quadrants.
• Put the conditions in the upper left quadrant. One row per condition.
• Put the actions in the lower left quadrant. One row per action.
List all possible rules.
• Alternate values for first condition. Repeat for all values of second condition. Keep
repeating this process for all conditions.
• Put the rules in the upper right quadrant.
Enter actions for each rule
• In the lower right quadrant, determine what, if any, appropriate actions should be
taken for each rule.
Reduce table as necessary.
 Modularity
• A concept closely tied to abstraction
• Modularity supports independence of models
• Modules support abstraction in software
• Supports hierarchical structuring of programs
• Modularity enhances design clarity, eases
implementation
• Reduces cost of testing, debugging and
maintenance
• Cannot simply chop a program into modules to
get modularly
• Need some criteria for decomposition
Desired Class/Object Interaction

• Maximize internal interaction (cohesion)

easier to understand
easier to test
• Minimize external interaction (coupling)
can be used independently
easier to test
easier to replace
easier to understand
 Characteristics of Good Design

• Component independence
High cohesion

Low coupling

• Exception identification and handling

• Fault prevention and fault tolerance

Coupling: Degree of
dependence among components

No dependencies Loosely coupled-some dependencies

High coupling makes modifying

parts of the system difficult, e.g.,
modifying a component affects all
the components to which the
Highly coupled-many dependencies
component is connected.
 Coupling

• Coupling addresses the attribute of “degree of

interdependence” between software units, modules or
components.
Content Coupling Accessing the internal data or procedural information

Data coupling is
coupling where
Common Coupling

Levels of
lowest
Lower the better
Control Coupling

Stamp Coupling

Data Coupling
Passing only the necessary information
Ideal, but not practical
No Coupling
 Content Coupling
• Definition: A module directly references the
content of another module
module p modifies a statement of module q

Module p refers to local data of module q (in terms of

a numerical displacement)

Module p branches to a local label of module q

Content Coupling (cont…)
● Content coupled modules are inextricably
interlinked
– Change to module p requires a change to module
q (including recompilation)
– Reusing module p requires using module q also
– Typically only possible in assembly languages

JECRC University
 Common Coupling
• Using global variables (i.e., global coupling)
• All modules have read/write access to a global data
block

• Modules exchange data using the global data block

(instead of arguments)

• Single module with write access where all other

modules have read access is not common coupling
Common Coupling (cont…)
• Have to look at many modules to determine the
current state of a variable
• Side effects require looking at all the code in a
function to see if there are any global effects

• Changes in one module to the declaration requires

changes in all other modules

• Identical list of global variables must be declared

for module to be reused

• Module is exposed to more data than is needed

 Control Coupling
• Definition: Component passes control parameters to
coupled components.

• May be either good or bad, depending on situation.

Bad when component must be aware of internal structure and
logic of another module

Good if parameters allow factoring and reuse of functionality

 Example
• Acceptable: Module p calls module q and q
returns a flag that indicates an error (if any)
• Not Acceptable: Module p calls module q and q
returns a flag back to p that says it must output
the error “I goofed up”
 Stamp Coupling
• Definition: Component passes a data structure to
another component that does not have access to the
entire structure.
• Requires second component to know how to
manipulate the data structure (e.g., needs to know
about implementation)
• May be necessary due to efficiency factors: this is a
choice made by insightful designer, not lazy
programmer.
 Data Coupling
• Definition: Two components are data coupled if there
are homogeneous data items.
• Every argument is simple argument or data structure
in which all elements are used
• Good, if it can be achieved.
• Easy to write contracts for this and modify component
independently.
 Cohesion
• Definition: The degree to which all elements of a component are
directed towards a single task and all elements directed towards that
task are contained in a single component.

• Cohesion of a unit, of a module, of an object, or a component

addresses the attribute of “ degree of relatedness” within that unit,
module, object, or component.

• Internal glue with which component is constructed

• All elements of a component are directed toward and essential for

performing the same task

• High is good
Range of Cohesion
Functional High Cohesion

Informational

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental Low
 Coincidental Cohesion
• Definition: Parts of the component performs multiple,
completely unrelated actions
• May be based on factors outside of the design:

skillset or interest of developers

avoidance of small modules

• No reusability

• Difficult corrective maintenance or enhancement

• Elements needed to achieve some functionality are scattered throughout the system.

• Accidental Worst form

• Example : an "Utilities" class

 Logical Cohesion
• Definition: Elements of component are related logically and not
functionally.

• Several logically related elements are in the same component and one
of the elements is selected by the caller.
• May include both high and low-level actions in the same class

• May include unused parameters for certain uses

• Interface is difficult to understand

in order to do something you have to wade through a lot of unrelated
possible actions

• Example: grouping all mouse and keyboard input handling routines

 Temporal Cohesion

• Definition: Elements of a component are related by timing.

• Difficult to change because you may have to look at

numerous components when a change in a data structure
is made.

• Increases chances of regression fault

• Component unlikely to be reusable.

• Often happens in initialization or shutdown

• Example: a function which is called after catching an exception which closes open
files, creates an error log, and notifies the user
 Procedural Cohesion
• Definition: Elements of a component are related only
to ensure a particular order of execution.
• Actions are still weakly connected and unlikely to be
reusable
• Changes to the ordering of steps or purpose of steps
requires changing the module abstraction
• Example: a function which checks file permissions and
then opens the file
 Communicational
Cohesion
• Definition: Module performs a series of actions related
by a sequence of steps to be followed by the product
and all actions are performed on the same data
• Action based on the ordering of steps on all the same
data
• Actions are related but still not completely separated

• Module cannot be reused

 Sequential Cohesion
• Methods are together in a class because the output
from one part is the input to another part like an
assembly line

• The output of one component is the input to another.

• Occurs naturally in functional programming languages

• Good situation
• Example: a function which reads data from a file and processes
the data
 Informational Cohesion

• Definition: Module performs a number of actions,

each with its own entry point, with independent
code for each action, all performed on the same
data.
• Different from logical cohesion
Each piece of code has single entry and single exit
In logical cohesion, actions of module intertwined

• ADT and object-oriented paradigm promote

 Functional Cohesion
• Definition: Every essential element to a single
computation is contained in the component.

• Every element in the component is essential to the

computation.

• Ideal situation.

• Example: tokenizing a string of XML

 UML
•Define an easy-to-learn but semantically rich visual modeling
language
•Unify the Booch, OMT, and Objectory modeling languages

•Include ideas from other modeling languages

•Incorporate industry best practices

•Address contemporary software development issues

•scale, distribution, concurrency, executability, etc.

•Provide flexibility for applying different processes

•Enable model interchange and define repository interfaces

JECRC University
 What is XML
• XML stands for eXtensible Markup Language.

• A markup language is used to provide information about a

document.

• Tags are added to the document to provide the extra

information.

• HTML tags tell a browser how to display the document.

• XML tags give a reader some idea what some of the data
means.
 What is XML Used For?

• XML documents are used to transfer data from one

place to another often over the Internet.
• XML subsets are designed for particular applications.
• One is RSS (Rich Site Summary or Really Simple
Syndication ). It is used to send breaking news
bulletins from one web site to another.
• A number of fields have their own subsets. These
include chemistry, mathematics, and books
publishing.
• Most of these subsets are registered with the
W3Consortium and are available for anyone’s use.
 Advantages of XML
• XML is text (Unicode) based.
Takes up less space.
Can be transmitted efficiently.

• One XML document can be displayed differently in

different media.
Html, video, CD, DVD,
You only have to change the XML document in order to change all the
rest.

• XML documents can be modularized. Parts can be

reused.
Example of an XML
Document
<?xml version=“1.0”/>

<address>

<name>Alice Lee</name>

<email>alee@aol.com</email>

<phone>212-346-1234</phone>

<birthday>1985-03-22</birthday>

</address>
Difference Between HTML and XML

• HTML tags have a fixed meaning and browsers know

what it is.

• XML tags are different for different applications, and

users know what they mean.

• HTML tags are used for display.

• XML tags are used to describe documents and data.