SOFTWARE ENGINEERING & PROJECT

MANAGEMENT(BCS501)

Module-1
Software and Software
Engineering
TEXT BOOKS

• 1. Roger S. Pressman: Software Engineering-A

Practitioners approach, 7th Edition, Tata McGraw Hill.
• 2. Bob Hughes, Mike Cotterell, Rajib Mall: Software
Project Management, 6th Edition, McGraw Hill Education,
2018.
What is software engineering?
 The application of a systematic, disciplined, quantifiable approach to the development, operation, and
maintenance of software; that is, the application of engineering to software.

 Software engineering is the establishment and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on real machines.

 Software engineering is also:-

• A modeling activity
• A problem-solving activity
• A knowledge acquisition activity
• A rationale-driven activity
 Software engineers should adopt
• Systematic and organized approach to their work
• Use appropriate tools and techniques depending on the problem to be solved
• The development constraints and the resources available
 Software Engineering is the science and art of building (designing and writing
programs) a software systems that are:
• On time
• On budget
• With acceptable performance
• With correct operation
Software Products:
Software products may be developed for a particular customer or may
be developed for a general market.
Software products may be:
Generic
Bespoke
What are the attributes of good software?
Maintainability
Dependability
Efficiency
Usability
The Nature Of Software
Product:
As a product, it delivers the computing potential embodied
by computer hardware or more broadly, by a network of
computers that are accessible by local hardware.

Vehicle for delivering a product:

As the vehicle used to deliver the product, software acts as
the basis for the control of the computer , the communication
of information , and the creation and control of other
programs.
Some questions to software developer
Why does it take so long to get software finished?
(Complexity, Scope Creep, Testing and Debugging, Team
Coordination, Dependencies, User Feedback, Resource Constraints,
Unexpected Issues)

Why are development costs so high?

(Complexity of Requirements, Talent and Expertise, Development
Time, Testing and Quality Assurance, Infrastructure and Tools,
Maintenance and Support, Customization and Integration,
Regulatory and Compliance Requirements)
Some questions to software developer
Why can’t we find all errors before we give the software to our customers?
(Complexity and Scale, Incomplete Testing Coverage, Dynamic
Environments, Changing Requirements, Human Error, Complex Interactions,
Resource Constraints, User Behavior)
Why do we spend so much time and effort maintaining existing programs?
(Bug Fixes and Updates, Evolving Requirements, Security Patches,
Compatibility Issues, Performance Optimization, User Support and Training,
Regulatory and Compliance Changes, Documentation and Knowledge
Transfer, Legacy Code, Interdependencies, User Feedback and
Improvements)
Software Characteristics
Software is developed or engineered, it is not manufactured in
the classical sence.

 Although the industry is moving towards component based

assembly, most software continues to be custom to built.
Software Characteristics
Software doesn’t ―wear out‖.
Software applications Domains
System Software
Application Software
Engineering/Scientific Software
Embedded Software
Product-Line Software
Web Applications
Artificial Intelligence Software
New Challenges for Software Developers
Open-World Computing
Netsourcing
Open Source
Legacy Software
Dayani-Fard and his colleagues describe legacy software in
the following way:
―Legacy software systems . . . were developed decades ago
and have been continually modified to meet changes in business
requirements and computing platforms. The proliferation of such
systems is causing headaches for large organizations who find
them costly to maintain and risky to evolve.‖
Legacy Software
Legacy systems often evolve for one or more of the following
reasons:
The software must be adapted to meet the needs of new computing
environments or technology.
The software must be enhanced to implement new business
requirements.
The software must be extended to make it interoperable with other
more modern systems or databases.
The software must be re-architected to make it viable within a
network environment.
THE UNIQUE NATURE OF WEBAPPS
The following attributes are encountered in the vast majority of WebApps:
Network intensiveness
Concurrency
Unpredictable load
Performance
Availability
Data driven
Content sensitive
Continuous evolution
Immediacy
Security
Aesthetics
Challenges Faced to Build Software
Understand the problem before you build a solution.
Design is a pivotal software engineering activity.
Both quality and maintainability are an outgrowth of good
design.
A Layered Technology
 Software Engineering is a layered technology.

Quality focus:-
 Main principle of Software Engineering is Quality focus.
 An engineering approach must have a focus on quality.
 Total Quality Management(TQM), Six Sigma, ISO 9001, ISO 9000-3 , Capability Maturity Model(CMM) ,
CMMI & similar approaches encourages a continuous process improvement culture.

Process :-
 The foundation for software engineering is the process layer.
 Software engineering process is the glue that holds the technology layers together.
 Process defines a framework activities for effective delivery of software engineering technology.
 EX:Timely development of software,management & control of software projects.
Methods :-
 Software engineering methods provide the technical how-to's for building software.
 Methods encompass a broad array of tasks that include requirements analysis, design, program construction,
testing, and support.

Tools :-
 Software engineering tools provide automated or semi-automated support for the process and the methods.
 When tools are integrated so that information created by one tool can be used by another, a system for the support
of software development, called computer-aided software engineering, is established.
 CASE combines software, hardware, and a software engineering database (a repository containing important
information about analysis, design, program construction, and testing) to create a software engineering
environment analogous to CAD/CAE (computer-aided design/engineering) for hardware.
SOFTWARE PROCESS
Software process:-
A Process is a collection of activites,actions and tasks that are performed when some work product
is to be created.

Activity:An activity refers to a specific task or set of tasks that individuals or groups engage in to
accomplish a particular goal or objective.
Ex:Communication with stake holder.

Action:In a general sense, an action refers to the process of doing something, often in pursuit of a goal
or objective.
Ex:Architectural design.

Task:A task is a specific, individual piece of work or duty that needs to be completed as part of a larger
project or goal.
Ex:Conducting a Unit test.
Common Process Framework Activities
COMMUNICATION Communication with PLANNING Software Project Plan which
customers/ stackeholders defines workflow that is to
to understand project follow. It describes technical
requirements for defining task, risks, resources, product
software features. to be produced & work
schedule.
MODELING Creating models to CONSTRUCTIONS Code generation (manual or
understand requirements automated) & testing (to
and shows design of uncover errors in the code)
software to achieve
requirements.

DEPLOYMENT Deliver Software to

Customer collect
feedback from customer
based on evaluation
Software Support
Umbrella Activities
Software project tracking and control
 Assessing progress against the project plan.
 Take adequate action to maintain schedule.
Formal technical reviews
 Assessing software work products in an effort to uncover and remove errors before goes into next action or
activity.
Software quality assurance
 Define and conducts the activities required to ensure software quality.
Software configuration management
 Manages the effects of change.
Document preparation and production
 Help to create work products such as models, documents, logs, form and list.
Reusability management
 Define criteria for work product reuse
 Mechanisms to achieve reusable components.
Measurement
 Define and collects process, project, and product measures
 Assist the team in delivering software that meets customer’s needs.
Risk management
 Assesses risks that may effect that outcome of project or quality of product (i.e. software)
SOFTWARE ENGINEERING PRACTICE
In a classic book, How to Solve It, written before modern computers existed.
George Polya [Pol45] outlined the essence of problem solving, and consequently, the
essence of software engineering practice:

The Essence of Practice

 Understand the problem (communication and analysis).
 Plan a solution (modeling and software design).
 Carry out the plan (code generation).
 Examine the result for accuracy (testing and quality assurance).
SOFTWARE ENGINEERING PRACTICE
Understand the problem (communication and analysis).
 Who has a stake in the solution to the problem? That is, who are the
stakeholders?

 What are the unknowns? What data, functions, and features are required to
properly solve the problem?

 Can the problem be compartmentalized? Is it possible to represent smaller

problems that may be easier to understand?

 Can the problem be represented graphically? Can an analysis model be

created?
SOFTWARE ENGINEERING PRACTICE
Plan a solution (modeling and software design).
 Have you seen similar problems before?

 Has a similar problem been solved? If so, are elements of the solution
reusable?

 Can subproblems be defined? If so, are solutions readily apparent for the
subproblems?

 Can you represent a solution in a manner that leads to effective

implementation?Can a design model be created?
SOFTWARE ENGINEERING PRACTICE
Carry out the plan (code generation).
 Does the solution conform to the plan? Is source code traceable to the
designmodel?
 Is each component part of the solution provably correct? Have the design and
code been reviewed, or better, have correctness proofs been applied to the
algorithm?
Examine the result for accuracy (testing and quality assurance).
 Is it possible to test each component part of the solution?
 Does the solution produce results that conform to the data, functions, and
features that are required?
SOFTWARE ENGINEERING PRACTICE
General Principles
 The First Principle: The Reason It All Exists
A software system exists for one reason: to provide value to its users.

 The Second Principle: KISS (Keep It Simple, Stupid!)

All design should be as simple as possible, but no simpler.

 The Third Principle: Maintain the Vision

A clear vision is essential to the success of a software project.

 The Fourth Principle: What You Produce, Others Will Consume

So, always specify,design, and implement knowing someone else will
have to understand what you aredoing.
SOFTWARE ENGINEERING PRACTICE
General Principles
 The Fifth Principle: Be Open to the Future
Never design yourself into a corner.Always ask ―what if,‖ and prepare for
all possible answers by creating systems that solve the general problem, not just
the specific one.

 The Sixth Principle: Plan Ahead for Reuse

Planning ahead for reuse reduces the cost and increases the value of both
the reusable components and the systems into which they are incorporated.

 The Seventh principle: Think!

Placing clear, completethought before action almost always produces better
results.
SOFTWARE MYTHS
Software myths are commonly held misconceptions about software
development that can lead to misunderstandings and poor practices.

There are 3 types of Software Myths

 Management Myth
 Customer Myth
 Developers/Practioners Myth
SOFTWARE MYTHS
Management Myth
Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they
need to know?

Myth: If we get behind schedule, we can add more programmers and catch
up(sometimes called the ―Mongolian horde‖ concept).

Myth: If I decide to outsource the software project to a third party, I can just
relax and let that firm build it.
SOFTWARE MYTHS

Customer Myth
Myth: A general statement of objectives is sufficient to begin writing programs—
we can fill in the details later.

Myth: Software requirements continually change, but change can be

easilyaccommodated because software is flexible.
SOFTWARE MYTHS

Developers/Practioners Myth
Myth: Once we write the program and get it to work, our job is done.

Myth: Until I get the program ―running‖ I have no way of assessing its quality.

Myth: The only deliverable work product for a successful project is the working
program.

Myth: Software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down.
PROCESS FLOW
Process flow describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect to
sequence and time.
It is often represented visually through flowcharts or diagrams, which help
clarify the process, making it easier to understand, analyze, and optimize.
Differeny types of Process flow available such as,
• Linear process flow: It executes each activity listed above in sequence form.

• Iterative Process flow: This flow repeats one or more activities that are listed above
before starting the next activity.
• Evolutionary Process flow: This flow carries out the activities listed above in a
circular manner. Each circle leads to the more complete version of the software
Parallel process flow: This flow executes the activities listed above in parallel with
each other activites.
How does a framework activity change as the nature of the
project changes?

1. Make contact with stakeholder via telephone.

2. Discuss requirements and take notes.

3. Organize notes into a brief written statement of requirements.

4. E-mail to stakeholder for review and approval.

IDENTIFYING A TASK SET
 A task set defines the actual work to be done to accomplish the
objectives of a software engineering action.

 A list of the task to be accomplished

 A list of the work products to be produced
 A list of the quality assurance filters to be applied
PROCESS PATTERNS

 A process pattern
 describes a process-related problem that is encountered during
software engineering work,
 identifies the environment in which the problem has been
encountered, and
 suggests one or more proven solutions to the problem.
 Stated in more general terms, a process pattern provides you with a
template [Amb98]—a consistent method for describing problem
solutions within the context of the software process.
PROCESS PATTERN TYPES

 Stage patterns—defines a problem associated with a framework activity

for the process.
 Task patterns—defines a problem associated with a software
engineering action or work task and relevant to successful software
engineering practice
 Phase patterns—define the sequence of framework activities that
occur with the process, even when the overall flow of activities is
iterative in nature.
PROCESS ASSESSMENT AND IMPROVEMENT
 Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides
a five step process assessment model that incorporates five phases: initiating, diagnosing,
establishing, acting and learning.
 CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
—provides a diagnostic technique for assessing the relative maturity of a software
organization; uses the SEI CMM as the basis for the assessment [Dun01]
 SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for
software process assessment. The intent of the standard is to assist organizations in
developing an objective evaluation of the efficacy of any defined software process.
[ISO08]

 ISO 9001:2000 for Software—a generic standard that applies to any organization that
wants to improve the overall quality of the products, systems, or services that it provides.
Therefore, the standard is directly applicable to software organizations and companies.
[Ant06]
PRESCRIPTIVE MODELS
 Prescriptive process models advocate an orderly approach to software
engineering
That leads to a few questions …
 If prescriptive process models strive for structure and order, are they
inappropriate for a software world that thrives on change?
 Yet, if we reject traditional process models (and the order they imply) and
replace them with something less structured, do we make it impossible to
achieve coordination and coherence in software work?
WATERFALL MODEL
WHAT IS V-MODEL

• V- model means Verification and Validation model.

• V-Shaped life cycle is a sequential path of execution of processes.

• Each phase must be completed before the next phase starts.

• Testing of the product is planned in parallel with a corresponding phase of development.

WHEN TO USE THE V-MODEL?

• The V-shaped model should be used for small to medium sized projects where

requirements are clearly defined and fixed.

• The V-Shaped model should be chosen when sample technical resources are available

with needed technical expertise.

PHASES

There are two phases

• Verification Phase

• Validation Phase
PICTORIAL VIEW OF V-MODEL
VERIFICATION PHASE

• Requirements Analysis:
the first step in the verification process, the requirements of the system are collected by
analyzing the needs of the user.

• System design:

In this phase system engineers analyze and understand the business of the proposed
system by studying the user requirements document.
VERIFICATION PHASE

• Architecture design
The baseline in selecting the architecture is that it should realize all which typically consists of
the list of modules, brief functionality of each module, their interface
relationships, dependencies, database tables, architecture diagrams, technology details etc.
The integration testing design is carried out in the particular phase.
VERIFICATION PHASE

• Module design
The module design phase can also be referred to as low-level design. The designed system is
broken up into smaller units or modules and each of them is explained so that the
programmer can start coding directly. The low level design document or program
specifications will contain a detailed functional logic of the module, in pseudo-code:
database tables, with all elements, including their type and size
all interface details with complete API references
all dependency issues
error message listings
complete input and outputs for a module.
CODING

• This is at the bottom of the V-Shape model. Module design is converted into code
by developers.
VALIDATION PHASE

• Unit testing

Unit Test Plans (UTPs) are developed during module design phase. These UTPs
are executed to eliminate bugs at code level or unit level.

A unit is the smallest entity which can independently exist, e.g. a program
module. Unit testing verifies that the smallest entity can function correctly when
isolated from the rest of the codes/units.
VALIDATION PHASE

• Integration testing
Integration Test Plans are developed during the Architectural Design Phase. These tests
verify that units created and tested independently can coexist and communicate among
themselves.

• System testing
System Tests Plans are developed during System Design Phase. Unlike Unit and
Integration Test Plans, System Test Plans are composed by client's business team. System
Test ensures that expectations from application developed are met.
VALIDATION PHASE

• User acceptance testing

User Acceptance Test (UAT) Plans are developed during the Requirements Analysis
phase. Test Plans are composed by business users. UAT is performed in a user
environment that resembles the production environment, using realistic data.
MERITS

• Simple and easy to use.

• Testing activities like planning, test designing happens well before coding.
• This saves a lot of time. Hence higher chance of success over the waterfall model.
• Proactive defect tracking – that is defects are found at early stage.

• Avoids the downward flow of the defects.

• Works well for small projects where requirements are easily understood.
DEMERITS

• Very rigid and least flexible.

• Software is developed during the implementation phase, so no early prototypes
of the software are produced.
• If any changes happen in midway, then the test documents along with
requirement documents has to be updated.
THE V-MODEL
THE INCREMENTAL MODEL
EVOLUTIONARY MODELS: THE SPIRAL
STILL OTHER PROCESS MODELS
 Component based development—the process to apply when reuse is a
development objective
 Formal methods—emphasizes the mathematical specification of
requirements
 AOSD—provides a process and methodological approach for defining,
specifying, designing, and constructing aspects
 Unified Process—a ―use-case driven, architecture- centric, iterative and
incremental‖ software process closely aligned with the Unified Modeling
Language (UML)
THE UNIFIED PROCESS (UP)

elaboration

inception
UP WORK PRODUCTS
PERSONAL SOFTWARE PROCESS (PSP)
 Planning. This activity isolates requirements and develops both size and resource estimates. In
addition, a defect estimate (the number of defects projected for the work) is made. All metrics
are recorded on worksheets or templates. Finally, development tasks are identified and a project
schedule is created.
 High-level design. External specifications for each component to be constructed are developed
and a component design is created. Prototypes are built when uncertainty exists. All issues are
recorded and tracked.
 High-level design review. Formal verification methods (Chapter 21) are applied to uncover
errors in the design. Metrics are maintained for all important tasks and work results.
 Development. The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
 Postmortem. Using the measures and metrics collected (this is a substantial amount of data
that should be analyzed statistically), the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its
effectiveness.
TEAM SOFTWARE PROCESS (TSP)
 Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams (IPT) of
three to about 20 engineers.
 Show managers how to coach and motivate their teams and how to help them sustain peak
performance.
 Accelerate software process improvement by making CMM Level 5 behavior normal
and expected.
 The Capability Maturity Model (CMM), a measure of the effectiveness of a software
process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity organizations.
 Facilitate university teaching of industrial-grade team skills.