SOFTWARE ENGINEERING

AND
PROJECT MANAGEMENT
(BCS501)

Prepared by,
Kavya Jayaprasad
Assistant Professor
AI&ML department
AIEMS, Bidadi
Syllabus
 Course Outcomes

Learning Resources
 Module 1
Software and Software
Engineering
 Introduction

What is Software?
⚫ Software is a set of instructions to acquire inputs and to
manipulate them to produce the desired output in terms of
functions and performance as determined by the user of the
software.
⚫ Also it includes a set of documents, such as the software
manual, meant for users to understand the software system.
 Software and Software Engineering
 Software Engineering is the product of two words : software and
engineering.
 Software is more than just a program code. A program is an executable
code, which serves some computational purpose.
 Software is considered to be a collection of executable programming
code, associated libraries and documentations.
 Software, when made for a specific requirement is called a software
product.
 Engineering on the other hand, is all about developing products, using
well-defined, scientific principles and methods.
 Software Engineering is an engineering branch associated with
development of software product using well-defined scientific
principles, methods and procedures. The outcome of software
engineering is an efficient and reliable software product.
 Nature of Software

 Software takes on a dual role: It is a Product and at the same time a Vehicle
(Process) for delivering a product.
 As a Product, it produces, manages, modifies, acquires and displays the
information
 As a Vehicle (Process) used to deliver the product, Software acts as the basis
for:
 Control of other computer (Operating Systems), Communication of Information
(Networks) and Creation and control of other programs (Software Tools and
Environment).
 Software delivers the most important product of our time -information.
 It transforms personal data so that the data can be more useful in a local context.
 Defining Software

Software is defined as

Instructions: Programs that when executed provide desired function,

features, and performance.

Data structures: Enable the programs to adequately manipulate the

information.

Documents: Descriptive information in both hard copy and virtual forms

that describes the operation and use of the programs.
 Software Characteristics

⚫ Software has characteristics that differ considerably from those of hardware:

1. Software is developed or engineered; it is not manufactured in the classical

sense.

2. Software doesn’t “wear out”.

3. Although the industry is moving toward component-based construction,

most software continues to be custom built.
 Software Characteristics
1. Software is developed or engineered; it is not manufactured in the
classical Sense.
 Although some similarities exist between software development and
hardware manufacturing, the two activities are fundamentally different.

 In both activities, high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality problems
that are nonexistent or easily corrected for software.

 Both the activities are dependent on people, but the relationship

between people and work accomplished is totally varying.

 Software costs are concentrated in engineering.

 Software Characteristics
2. Software doesn’t “wear out”:
 The Hardware failure relationship, often called the “bathtub curve,” indicates
that hardware exhibits relatively high failure rates early in its life . Later, defects
are corrected and the failure rate drops to a steady-state level for some period of
time.
 As time passes, The failure rate rises again as hardware components suffer from
the cumulative effects of dust, vibration, abuse, temperature extremes, and many
other environmental maladies. The hardware begins to wear out as shown in
Figure 1.
 Software is not susceptible to the environmental maladies that cause hardware to
wear out. In theory, therefore, the failure rate curve for software should take the
form of the “idealized curve” shown in Figure 2.

 FIGURE 1: Failure curve for hardware FIGURE 2: Failure curve for software
 Software Characteristics
3. Most Software is custom-built rather than being assembled
from components:

 A software part should be planned and carried out with the goal
that it tends to be reused in various projects (algorithms and data
structures).

 Today software industry is trying to make library of reusable

components. For example, Software GUI is built using the
reusable components such as message windows, pull down menu
and many more such components.
 Software Application Domains

Challenges are faced by the software engineers in the following categories:

❑ System Software - A collection of programs written to service other

programs at system level.
• For example: compiler, operating systems.

❑ Application Software- Stand-alone programs that solve a specific business need.

• Used to control business functions in real time.

❑ Engineering and Scientific Software - Software using “number

crunching” algorithms for different science and applications.
• Ex: System simulation, computer-aided design.

❑ Embedded Software - It resides within a product or system and is used to

implement and control features and functions for the end user and for the system
itself.
 Software Application Domains

❑ Product line Software - Designed to provide a specific capability for use by

many different customers.

❑ Web Applications- It is a client-server computer program that the client runs

on the web browser.
❑ These applications are called “WebApps,” this network-centric software
category spans a wide array of applications.

❑ Artificial Intelligence (AI) Software - Programs make use of AI or non-

numerical algorithms to solve complex problems.
❑ Applications within this area include robotics, expert systems, pattern
recognition (image and voice), artificial neural networks, theorem proving,
and game playing.
 New Software Challenges

 Open-world computing: Creating software to allow machines of all

sizes to communicate with each other across vast networks
(Distributed computing—wireless networks).

 Net sourcing: Architecting simple and sophisticated applications

that benefit targeted end- user markets worldwide (the Web as a
computing engine).

 Open Source: Distributing source code for computing applications

so customers can make local modifications easily and reliably
(“free” source code open to the computing community).
 Legacy software
 Legacy software is older programs that are developed decades ago.
 The quality of legacy software is poor because it has inextensible design,
convoluted code, poor and nonexistent documentation, test cases and
results that are not achieved.
 As time passes legacy systems evolve due to following reasons:
 The software must be adapted to meet the needs of new computing
environment or technology.
 The software must be enhanced to implement new business requirements.
 The software must be extended to make it interoperable with more modern
systems or database.
 The software must be re-architected to make it viable within a network
environment.
 Unique Nature of Web Apps
 In the early days of the World Wide Web, websites consisted
of little more than a set of linked hypertext files (HTML)
that presented information using text and limited
graphics.
 As time passed, the augmentation of HTML by
development tools (e.g., XML, Java) enabled Web
engineers to provide computing capability along with
informational content.
 Today, WebApps have evolved into sophisticated computing
tools that not only provide stand-alone function to the end
user, but also have been integrated with corporate databases
and business applications.
 Unique Nature of Web Apps
Attributes encountered in majority of WebApps are :
 Network intensiveness. A WebApp resides on a network and must serve the
needs of a diverse community of clients. The network may enable worldwide
access and communication (i.e., the Internet) or more limited access and
communication (e.g., a corporate Intranet).
 Concurrency. A large number of users may access the WebApp at one time. In
many cases, the patterns of usage among end users will vary greatly.
 Unpredictable load. The number of users of the WebApp may vary by orders of
magnitude from day to day. One hundred users may show up on Monday; 10,000
may use the system on Thursday.
 Performance. WebApp should work effectively in terms of processing speed. If a
WebApp user must wait too long he or she may decide to go elsewhere.
 Availability. Although expectation of 100 percent availability is un reasonable,
users of popular WebApps often demand access on a 24/7/365 basis .
 Data driven. The primary function of many WebApps is to use hypermedia to
present text, graphics, audio and video content to the end user. In addition,
WebApps are commonly used to access information that exists on databases that
are not an integral part of the Web- based environment.
 Unique Nature of Web Apps
 Content sensitive. The quality and aesthetic nature of content remains an
important determinant of the quality of a WebApp.

 Continuous evolution. Unlike conventional application software that

evolves over a series of planned, chronologically spaced releases, Web
applications evolve continuously.

 Immediacy. Although immediacy - the compelling need to get software to

market quickly - is a characteristic of many application domains, WebApps
often exhibit a time- to- market that can be a matter of a few days or weeks.

 Security. Because WebApps are available via network access, it is difficult,

if not impossible, to limit the population of end users who may access the
application. In order to protect sensitive content and provide secure modes.

 Aesthetics. An undeniable part of the appeal of a WebApp is its look and

feel. When an application has been designed to market or sell products or
ideas, aesthetics may have as much to do with success as technical design.
Software Engineering -A Layered Technology

 In order to build software that is ready to meet the challenges of the 21st
century, few simple realities must be recognized.

 Problems should be understood before a software solution is developed.

 Design is a pivotal Software Engineering activity.

 Software should exhibit high quality.

 Software should be maintainable.

 These simple realities lead to one conclusion: Software in all of its forms
and across all of its application domains should be engineered.
 Software Engineering Definitions
 Software Engineer, Fritz Bauer defined SE as:
 Software engineering is the establishment and use of sound engineering principles
in order to obtain software that is reliable and works efficiently on real machines in
economical manner.

 IEEE has developed a more comprehensive definition as:

 Software engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software (Application
of Engineering to software).
 The study approaches as in (1)
 Software Engineering is a layered technology. It encompasses a Process,
Methods for managing and engineering software and tools.
Layered Technology of Software Engineering

Fig: Software Engineering Layers

 Software Engineering Layers
⚫ Software engineering is a fully layered technology.
⚫ To develop a software; we need to go from one layer to another. All the layers are
connected and each layer demands the fulfillment of the previous layer.
• The bedrock that supports software engineering is a quality focus.
• The foundation for software engineering is the process layer.
• The software engineering process is the glue that holds the technology layers
together and enables rational and timely development of computer software.
• Process defines a framework that must be established for effective delivery of
software engineering technology.
• Software engineering methods provide the technical how-to’s for building software.
• Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
support.
• 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.
 Software Process
• A process is a collection of activities, actions, and tasks that
are performed when some work product is to be created.

• An activity strives to achieve a broad objective and is applied

regardless of the application domain, size of the project,
complexity of the effort, or degree of rigor with which software
engineering is to be applied.

• An action encompasses a set of tasks that produce a major work

product.

• A task focuses on a small, but well-defined objective (e.g.,

conducting a unit test) that produces a tangible outcome.
 Software Process
Process Framework:
A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.

A generic process framework for software engineering encompasses five activities:

Communication: Before any technical work can commence, it is critically important
to communicate and collaborate with the customer, to ‘understand stakeholders’ objectives
for the project and to gather requirements that helps to define software features and
functions.
Planning: A software project is a complicated journey, and the planning activity
creates a “map” that helps guide the team. The map- called a software project plan-
defines the software engineering work by describing the technical tasks to be conducted,
the risks that are likely, the resources that will be required, the work products to be
produced, and a work schedule.
Modeling: Creation of models to help developers and customers understand the
requirements and software design.
Construction: This activity combines code generation and the testing that is
required to uncover errors in the code.
Deployment: The software is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation.
 Software Process
The process framework encompasses a set of umbrella activities which includes:

• Software project tracking and control: allows the software team to assess progress against the
project plan and take any necessary action to maintain the schedule.

• Risk management: assesses risks that may affect the outcome of the project or the quality of the
product.

• Software quality assurance: defines and conducts the activities required to ensure software quality.

• Technical reviews: assesses software engineering work products in an effort to uncover and remove
errors before they are propagated to the next activity.

• Measurement: defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders needs; can be used in conjunction with all other
framework and umbrella activities.

• Software configuration management: manages the effects of change throughout the software
process.

• Reusability management: defines criteria for work product reuse and establishes mechanisms to
achieve reusable components.

• Work product preparation and production: encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.
 Software Process
 The Software Engineering process is not rigid. It should be agile and
adaptable.
 Therefore, a process adopted for one project might be significantly different
than a process adopted for another project.

 Among the differences are:

 Overall flow of activities, actions, tasks and level of interdependencies
among tasks
 Degree to which work tasks are defined within each framework activity
 Degree to which work products are identified and required
 Manner in which quality assurance activities are applied
 Manner in which project tracking and control activities are applied
 Overall degree of detail and rigor of process description
 Degree to which stakeholders are involved in the project
 Level of autonomy given to project team
 Degree to which team organization and roles are prescribed
SOFTWARE ENGINEERING PRACTICE

The Essence of Practice (Generic concepts and principles

that apply to framework activities):

 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
 Who are the stakeholders?
 What are the Unknowns? What functions and features are required to solve the
problem?
 Is it possible to create smaller problems that are easier to understand?
 Can a graphic analysis model be created?
Plan the Solution
 Have you seen similar problems before? Is there existing software that implements
these features.
 Has a similar problem been solved? Can readily solvable sub problems be defined?
 Can a design model be created? –Effective implementation.
Carry Out the Plan
 Does solution conform to the plan? Is source code traceable to the design model?
 Is each solution component provably, correct? Have design and code be reviewed?
Examine the Result
 Is it possible to test each component part of the solution?
 Does the solution produce results that conform to the data, functions, and features
required?
 Software General Principles
 The word Principle can be defined as “an important underlying law or assumption
required in a system of thought.”
David Hooker has Proposed seven principles that focus on software Engineering practice.
 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!)
 Software design is not a haphazard process. There are many factors to consider in any design effort.
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. Without one, a project almost
unfailingly ends up being “of two [or more] minds” about itself.
 The Fourth Principle: What You Produce, Others Will Consume
 Always specify, design, and implement knowing someone else will have to understand what you are
doing.
 The Fifth Principle: Be Open to the Future A system with a long lifetime has more value.
Never design yourself into a corner. Before beginning a software project, be sure the software
has a business purpose and that users perceive value in it.
 The Sixth Principle: Plan Ahead for Reuse: Reuse saves time and effort. 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, complete thought before action almost always
produces better results. When you think about something, you are more likely to do it right.
 Software Myths
 Software Myths- beliefs about software and the process used to build
it - can be traced to the earliest days of computing.

 Myths have a number of attributes that have made them insidious.

 For instance, myths appear to be reasonable statements of fact, they

have an intuitive feel, and they are often promulgated by
experienced practitioners who “know the score”.
 Software Myths
 Management Myths:
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?
 Reality:
 The book of standards may very well exist, but is it used?
 Are software practitioners aware of its existence?
 Does it reflect modern software engineering practice?
 Is it complete? , Is it adaptable?
 Is it streamlined to improve time to delivery while still maintaining a focus on Quality?
 In many cases, the answer to this entire question is NO.
Myth: If we get behind schedule, we can add more programmers and catch up
 Reality: Software development is not a mechanistic process like manufacturing. “Adding
people to a late software project makes it later.”, As new people are added, people who were
working must spend time educating the newcomers, thereby reducing the amount of time spent
on productive development effort.
 People can be added but only in a planned and well-coordinated manner.
Myth: If we decide to outsource the software project to a third party, I can just relax and let that
firm build it.
 Reality: If an organization does not understand how to manage and control software project
internally, it will invariably struggle when it out sources’ software project.
 Software Myths
Customer Myths:
 Myths led to false expectations and ultimately, dissatisfaction with the
developers.
Myth: A general statement of objectives is sufficient to begin writing
programs - we can fill in details later.
 Reality: Although a comprehensive and stable statement of requirements
is not always possible, an ambiguous statement of objectives is a recipe
for disaster. Unambiguous requirements are developed only through
effective and continuous communication between customer and developer.
Myth: Project requirements continually change, but change can be easily
accommodated because software is flexible.
 Reality: It’s true that software requirement change, but the impact of
change varies with the time at which it is introduced. When requirement
changes are requested early, cost impact is relatively small. However, as
time passes, cost impact grows rapidly – resources have been committed, a
design framework has been established, and change can cause upheaval
that requires additional resources and major design modification.
 Software Myths
Practitioner's myths
Myth: Once we write the program and get it to work, our job is done.
 Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll
take you to get done.” Industry data indicate that between 60 and 80 percent of all
effort consumed on software will be consumed after it is delivered to the customer
for the first time.
Myth: Until I get the program "running" I have no way of assessing its quality.
 Reality: One of the most effective software quality assurance mechanisms can be
applied from the inception of a project—the formal technical review. Software
reviews are a "quality filter" that have been found to be more effective than testing
for finding certain classes of software defects.
Myth: The only deliverable work product for a successful project is the working
program.
 Reality: A working program is only one part of a software configuration that includes
many elements. Documentation provides a foundation for successful engineering and,
more important, guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
 Reality: Software engineering is not about creating documents. It is about creating
quality. Better quality leads to reduced rework. And reduced rework results in faster
delivery times. Recognition of software realities is the first step toward formulation
of practical solutions for software engineering.
 A GENERIC PROCESS MODEL

 A process was defined as a collection of work activities, actions and tasks that are
performed when some work product is to be created.

 Each of these activities, actions and tasks reside within a framework or model that
defines their relationship with the process and with one another.

 Each framework activity is populated by a set of software engineering actions.

 Each software engineering action is defined by a task set that identifies the work
tasks that are to be completed, the work products that will be produced, the
quality assurance points that will be required and the milestones that will be used
to indicate progress.
Software Process Framework
 Process Flow
 A generic process framework for software engineering defines five
framework activities: communication, planning, modeling,
construction and deployment.

 In addition, a set of umbrella activities: project tracking and control,

risk management, quality assurance, configuration management,
technical reviews and others are applied throughout the process.

 The important aspect of software process is “Process Flow” which

describes how the framework activities and the actions and tasks that
occur within each framework activity are organized with respect to
sequence and time .
 Process Flow
 A linear process flow [Fig:(a)] executes each of the five framework activities
in sequence, beginning with communication and culminating with deployment.
 An iterative process flow [Fig:2.2(b)] repeats one or more of the activities
before proceeding to the next.
 Process Flow
 An evolutionary process flow [Fig:(c)] executes the activities in a “circular”
manner. Each circuit through the five activities leads to a more complete version
of the software.
 A parallel process flow [Fig:(d)] executes one or more activities in parallel
with other activities.
 Defining a Framework Activity

 For small software project requested by one person with simple, straight forward
requirements, the communication activity might encompass little more than a
phone call with appropriate stake holder such as:
 Make contact with stakeholder via telephone.
 Discuss requirements and take notes.
 Organize notes into a brief written statement of requirements.
 E-mail to stakeholder for review and approval.
 If the project was considerably more complex with many stakeholders,
each with a different set of requirements, the communication activity
might have six distinct actions: inception, elicitation, elaboration,
negotiation, specification, and validation.
 Each of these software engineering actions would have many work tasks and
a number of distinct work products.
 *Note: Additional Information

•Inception – Establishing the initial understanding of the project scope and objectives.
Stakeholders identify the core goals, constraints, and high-level expectations.
Question answered: Why are we building this system?
•Elicitation – Actively gathering requirements from all stakeholders using interviews,
questionnaires, workshops or observations.
Question answered: What do stakeholders need?
•Elaboration – Refining and analyzing the gathered requirements to remove ambiguities,
identify priorities, and capture use cases or scenarios.
Question answered: How will the requirements fit together?
•Negotiation – Reconciling conflicting requirements from different stakeholders and
prioritizing them according to feasibility, cost, and value.
Question answered: Which requirements are most important and achievable?
•Specification – Documenting the agreed-upon requirements clearly, often in the form of a
Software Requirements Specification (SRS), models, or user stories.
Question answered: What exactly should be built?
•Validation – Ensuring that the documented requirements accurately reflect stakeholder
needs and are testable, consistent, and complete.
Question answered: Did we capture the right requirements?
 Identifying a Task Set

 Each software engineering action can be represented by a number of different

task sets:
 A collection of software engineering work tasks,
 related work products,
 quality assurance points, and
 project milestones.

 Choose a task set that best accommodates the needs of the project and the
characteristics of software team.

 This implies that a software engineering action can be adapted to the

specific needs of the software project and the characteristics of the project
team.
 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.

 In some cases, a pattern might be used to describe a problem (and solution)

associated with a complete process model.

 In other situations, patterns can be used to describe a problem (and solution)

associated with a framework activity (e.g., planning) or an action within a
framework activity (e.g., project estimating).
 Process Patterns

 Ambler has proposed a template for describing a process pattern:
1. Pattern Name. The pattern is given a meaningful name describing it within the
context of the software process (e.g., Technical Reviews).
2. Forces. The environment in which the pattern is encountered and the issues that
make the problem visible and may affect its solution.
3. Type. The pattern type is specified. Ambler suggests three types:
1) Stage pattern—Defines a problem associated with a framework activity for
the process.
2) Task pattern—Defines a problem associated with a software engineering
action or work task and relevant to successful software engineering practice
(e.g., Requirements Gathering).
3) Phase pattern—Defines the sequence of framework activities that occurs
within the process, even when the overall flow of activities is iterative in nature.
4. Initial context. Describes the conditions under which the pattern applies. Prior to the
initiation of the pattern:
 What organizational or team-related activities have already occurred?
 What is the entry state for the process?
 What software engineering information or project information already exists?
 Process Patterns

5. Problem. The specific problem to be solved by the pattern.

6. Solution. Describes how to implement the pattern successfully. It also
describes how software engineering information or project information that is
available before the initiation of the pattern is transformed as a consequence of
the successful execution of the pattern.
7. Resulting Context. Describes the conditions that will result once the
pattern has been successfully implemented. Upon completion of the pattern:
 What organizational or team-related activities must have occurred?
 What is the exit state for the process?
 What software engineering information or project information has been
developed?
8. Related Patterns. Provide a list of all process patterns that are directly
related to this one. This may be represented as a hierarchy or in some other
diagrammatic form.
9. Known Uses and Examples. Indicate the specific instances in which the
pattern is applicable.
 Conclusion on Process patterns

 Provide an effective mechanism for addressing problems associated with

any software process.

 The patterns enable you to develop a hierarchical process description that

begins at a high level of abstraction (a phase pattern).

 The description is then refined into a set of stage patterns that describe
framework activities

 Once process patterns have been developed, they can be reused for the
definition of process variants.
 Process Assessment and Improvement

 A number of different approaches to software process assessment and improvement
have been proposed over the past few decades:

 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. The SCAMPI method uses the SEI
CMMI as the basis for assessment [SEI00].

 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 .

 SPICE (ISO/IEC15504)—a standard that 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 .
 Prescriptive process models
 Prescriptive process models were originally proposed to bring order to the
chaos (disorder) of software development.
 These models have brought a certain amount of useful structure to software
engineering work and have provided a reasonably effective road map for
software teams.
 The edge of chaos is defined as “a natural state between order and chaos, a
grand compromise between structure and surprise”.
 The prescriptive process approach is in which order and project consistency
are dominant issues.
 “Prescriptive” means to prescribe a set of process elements:
 framework activities,
 software engineering actions,
 tasks,
 work products,
 quality assurance, and
 change control mechanisms for each project.
 Process models

⚫ Waterfall model
⚫ Incremental process models
⚫ Evolutionary Process Models
• Prototyping
• Spiral model
⚫ Concurrent models
 Waterfall Model
• Sometimes called the classic life cycle.
• Work flows from communication through deployment in a reasonably linear
fashion.
• Suggests a systematic, sequential approach to software development that begins
with customer specification of requirements and progresses through planning,
modeling, construction, and deployment.
 WATERFALL MODEL
* Additional information
 Waterfall Drawbacks
⚫ All projects cannot follow linear process
⚫ All requirements must be known upfront
⚫ The customer must have patience
⚫ A working version of the program will not be available
until late in the project time-span.
⚫ Leads to ‘blocking states’
⚫ Inappropriate to changes
When to use the Waterfall Model

⚫ Requirements are very well known

⚫ Product definition is stable
⚫ Technology is understood
⚫ New version of an existing product
⚫ Porting an existing product to a new platform
V-Model
 V-Model
 A variation in the representation of the waterfall model is called the V-model.
 The V-model depicts the relationship of quality assurance actions to the
actions associated with communication, modeling, and early construction
activities.
 As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical
representations of the problem and its solution.
 Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests that validate each of the models
created as the team moved down the left side.
 The V-model provides a way of visualizing how verification and validation
actions are applied to earlier engineering work.
 Incremental model
 The incremental model combines elements of linear and parallel
process flows.
 The incremental model applies linear sequences in a staggered fashion
as calendar time progresses.
 Each linear sequence produces deliverable “increments” of the
software in a manner that is similar to the increments produced by an
evolutionary process flow.
 For example, word-processing software developed using the
incremental paradigm might deliver:
 basic file management, editing, and document production functions in the
first increment;
 more sophisticated editing and document production capabilities in the
second increment;
 spelling and grammar checking in the third increment; and
 advanced page layout capability in the fourth increment.
 Incremental model
 When an incremental model is used, the first increment is often a core
product. That is, basic requirements are addressed but many supplementary
features remain undelivered. The core product is used by the customer .
 As a result of use and/or evaluation, a plan is developed for the next
increment. The plan addresses the modification of the core product to better
meet the needs of the customer and the delivery of additional features and
functionality. This process is repeated following the delivery of each
increment, until the complete product is produced.
 Incremental process model focuses on the delivery of an operational product
with each increment.
 Incremental development is particularly useful when staffing is unavailable for
a complete implementation by the business deadline that has been established
for the project.
 Early increments can be implemented with fewer people. If the core product is
well received, then additional staff (if required) can be added to implement the
next increment.
 In addition, increments can be planned to manage technical risks.
Incremental model
 Evolutionary models
 Evolutionary models are iterative.
 Since software evolves over a period of time, a process model is
needed which can be explicitly designed to accommodate a product
that evolves over time.
 Evolutionary models are characterized in a manner that will enable
us to develop increasingly more complete versions of the software.

 Two common evolutionary process models are:

 Prototyping
 The Spiral Model
 Evolutionary models
Prototyping:
 Often, a customer defines a set of general objectives for software, but does
not identify detailed requirements for functions and features.
 In other cases, the developer may be unsure of the efficiency of an
algorithm, the adaptability of an operating system, or the form that
human-machine interaction should take.
 In these, and many other situations, a prototyping paradigm may offer the best
approach.
 Although prototyping can be used as a stand-alone process model, it is
more commonly used as a technique that can be implemented within the
context of any one of the process models.
 Prototyping will assist the stakeholders to better understand what is to be
built when requirements are fuzzy.
 Evolutionary models
Prototyping:
 Evolutionary models
Prototyping:
 The prototyping paradigm begins with communication - Communicating with
other stakeholders to define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is
mandatory.
 A prototyping iteration is planned quickly, and modeling ( “quick design”) occurs.
 A quick design focuses on a representation of those aspects of the software that
will be visible to end users.
 The quick design leads to the construction of a prototype.
 The prototype is deployed and evaluated by stakeholders, who provide feedback
that is used to further refine requirements.
 Iteration occurs as the prototype is tuned to satisfy the needs of various
stakeholders, while at the same time enabling us to better understand what needs to
be done.
 Ideally, the prototype serves as a mechanism for identifying software requirements.
 Evolutionary models- Prototyping
 Prototyping can be problematic for the following reasons:
 Stakeholders see what appears to be a working version of the software,
unaware that the prototype is held together randomly, unaware that in the
rush to get it working, the overall software quality is not considered or
long-term maintainability.
 As a software engineer, you often make implementation compromises
in order to get a prototype working quickly.
 An inappropriate operating system or programming language may be used
simply because it is available and known; an inefficient algorithm may be
implemented simply to demonstrate capability.
❑Although problems can occur, prototyping can be an effective paradigm for
engineering.
 Evolutionary models-The Spiral Model

 Originally proposed by Barry Boehm,

 the spiral model is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and systematic aspects of
the waterfall model.
 It provides the potential for rapid development of increasingly more complete
versions of the software.
 Boehm describes the model in the following manner:
 The spiral development model is a risk-driven process model generator that is used
to guide multi-stakeholder concurrent engineering of software intensive systems.
 It has two main distinguishing features.
 One is a cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
 The other is a set of anchor point milestones for ensuring stakeholder commitment to
feasible and mutually satisfactory system solutions.
 Evolutionary models-The Spiral Model

• The spiral model is a realistic approach to the development of large-scale systems

and software.
• It maintains the systematic stepwise approach suggested by the classic life cycle
but incorporates it into an iterative framework that more realistically reflects the
real world.
 Concurrent Models

Fig : One element of the concurrent process model

 Concurrent Models
 The concurrent development model, sometimes called concurrent engineering,
allows a software team to represent iterative and concurrent elements of any of
the process models described.
 All Software Engineering activities exist concurrently but reside in different
states. Ex: Early in a project the communication activity has completed its 1st
iteration and exists in the awaiting changes state.
 The modelling activity (which existed in inactive state) while initial
communication was completed now make a transition into the under-
development state.
 If, however, the customer indicates that changes in requirement must be made,
the modelling activity moves from under-development state to awaiting
changes state.
 Concurrent modelling defines a series of events that will trigger transitions
from state to state for each of the software engineering activities, actions or
tasks.
 Concurrent modelling is applicable for all types of software development and
provides an accurate picture of the current state of the project.
 Specialized process Models
Component-Based Development
 The component-based development model incorporates many of the
characteristics of the spiral model. It is evolutionary in nature,
demanding an iterative approach to the creation of software.
 The component-based development model incorporates the following steps
 Available component-based products are researched and evaluated for the
application domain in question.
 Component integration issues are considered.
 A software architecture is designed to accommodate the components.
 Components are integrated into the architecture.
 Comprehensive testing is conducted to ensure proper functionality.
 The component-based development model leads to software reuse, and
reusability provides software engineers with a number of measurable
benefits.
 Specialized process Models
The Formal Methods Model
 The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software.
 Formal methods enable us to specify, develop, and verify a computer-based system
by applying a rigorous, mathematical notation. A variation on this approach, called
clean room software engineering.
 When formal methods are used during development, they provide a mechanism for
eliminating many of the problems that are difficult to overcome using other
software engineering paradigms.
 When formal methods are used during design, they serve as a basis for program
verification which discover and correct errors that might otherwise go undetected.
 The formal methods model offers the promise of defect-free software.
 Draw Backs:
 The development of formal models is currently quite time consuming and expensive.
 Because few software developers have the necessary background to apply formal
methods, extensive training is required.
 It is difficult to use the models as a communication mechanism for Technically
unsophisticated customers.
 Specialized process Models

Aspect-Oriented Software Development (AOSD)

 In AOSD, aspects represent customer concerns that cut across multiple system
functions, features, and information.
 Such concerns are called crosscutting concerns, and aspectual requirements
define their impact on the software architecture.
 AOSD, often referred to as aspect-oriented programming (AOP), is a relatively
new software engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing aspects.”
 Grundy provides further discussion of aspects in the context of what he calls
aspect- oriented component engineering (AOCE):
 AOCE uses a concept of horizontal slices through vertically-decomposed software
components, called “aspects,” to characterize cross-cutting functional and non-
functional properties of components.
 * Additional information
Aspect-Oriented
Component-Based Formal Methods
Feature / Model Software Development
Development (CBD) Model
(AOSD)

Build by assembling Use mathematical Separate cross-cutting

Main Idea
reusable components specification & proof concerns as “aspects”

Focus Reuse & integration Correctness & rigor Separation of concerns

Clean, maintainable,
Strength Faster, cheaper, modular Very reliable, precise
modular code

Costly, complex, Tool support &

Limitation Compatibility issues
requires expertise debugging complexity

Enterprise/business Systems with security,

Best Use Case Safety-critical systems
applications logging, or auditing
 * Additional information
Component-Based Development (CBD)
A software process model where applications are built by assembling pre-
existing, reusable software components, focusing on modularity, faster
development, and cost reduction.

Formal Methods Model

A process model that uses mathematical specifications and proofs to ensure
software correctness, reliability, and absence of ambiguity, mainly applied in
safety-critical systems.

Aspect-Oriented Software Development (AOSD)

A process model that modularizes cross-cutting concerns (like logging, security,
error handling) into separate “aspects,” improving separation of concerns and
maintainability.
 The Unified Process

 Unified Process is an attempt to draw on the best features and

characteristics of traditional software process models, but characterize them
in a way that implements many of the best principles of agile software
development.
 The Unified Process recognizes the importance of customer
communication and streamlined methods for describing the customer’s view
of a system.
 It emphasizes the important role of software architecture and “helps the
architect focus on the right goals, such as understandability, reliance to future
changes, and reuse.
 It suggests a process flow that is iterative and incremental, providing the
evolutionary feel that is essential in modern software development.
 The Unified Process
A Brief History
 During the early 1990s James Rumbaugh, Grady Booch and Ivar Jacobson began
working on a “unified method” that would combine the best features of each of their
individual object-oriented analysis and design methods and adopt additional features
proposed by other experts in object- oriented modeling.
 The result was UML—a unified modeling language that contains a robust notation
for the modeling and development of object-oriented systems.
 By 1997,UML became a de facto industry standard for object-oriented software
development.
 UML provided the necessary technology to support object-oriented software
engineering practice, but it did not provide the process framework to guide project
teams in their application of the technology.
 Over the next few years, Jacobson, Rumbaugh, and Booch developed the Unified
Process, a framework for object-oriented software engineering using UML.
 Today, the Unified Process (UP) and UML are widely used on object-oriented
projects of all kinds. The iterative, incremental model proposed by the UP can and
should be adapted to meet specific project needs.
 The Unified Process
Phases of the Unified Process
 The Unified Process(UP) is no exception.
 Figure below depicts the “phases” of the UP and relates them to the generic
activities
 The Unified Process

Inception phase :
 The Inception phase of the UP encompasses both customer communication and
planning activities. By collaborating with stakeholders, business requirements for
the software are identified; a rough architecture for the system is proposed; and a
plan for the iterative, incremental nature of the ensuing project is developed.
 Fundamental business requirements are described through a set of preliminary use
cases that describe which features and functions each major class of user's desires.
 Architecture at this point is nothing more than a tentative outline of major
subsystems and the function and features that populate them.
 Later, the architecture will be refined and expanded into a set of models that will
represent different views of the system.
 Planning identifies resources, assesses major risks, defines a schedule, and
establishes a basis for the phases that are to be applied as the software increment is
developed.
 The Unified Process

Elaboration phase:

 The elaboration phase encompasses the communication/planning and

modeling activities of the generic process model.
 Elaboration refines and expands the preliminary use cases that were
developed as part of the inception phase and expands the architectural
representation to include five different views of the software: the use case
model, the requirements model, the design model, the implementation
model, and the deployment model.
 In some cases, elaboration creates an “executable architectural baseline”
that represents a “first cut” executable system.
 The Unified Process
Construction Phase:
 The construction phase of the UP is identical to the construction activity
defined for the generic software process.
 Using the architectural model as input, the construction phase develops or
acquires the software components that will make each use case operational for
end users.
 Requirements and design models that were started during the elaboration phase
are completed to reflect the final version of the software increment.
 All necessary and required features and functions for the software increment
(i.e., the release) are then implemented in source code.
 As components are being implemented, unit tests are designed and executed for
each.
 In addition, integration activities (component assembly and integration testing)
are conducted. Use cases are used to derive a suite of acceptance tests that are
executed prior to the initiation of the next UP phase.
 The Unified Process
Transition phase :
 The transition phase of the UP encompasses the latter stages of the
generic construction activity and the first part of the generic
deployment (delivery and feedback) activity.
 Software is given to end users for beta testing and user feedback reports
both defects and necessary changes.
 In addition, the software team creates the necessary support information
(e.g., user manuals, troubleshooting guides, installation procedures) that is
required for the release.
 At the conclusion of the transition phase, the software increment
becomes a usable software release.
 The Unified Process
Production phase :
 The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and requests for
changes are submitted and evaluated.
 At the same time the construction, transition, and production phases are being
conducted, work may have already begun on the next software increment.
 A software engineering workflow is distributed across all UP phases.
 A workflow identifies the tasks required to accomplish an important software engineering
action and the work products that are produced as a consequence of successfully
completing the tasks.
 It should be noted that not every task identified for a UP workflow is conducted for every
software project. The team adapts the process(actions, tasks, subtasks, and work products)
to meet its needs.
 * Additional information

1. Inception: Define project scope, business case, and feasibility.

2. Elaboration: Refine requirements, identify risks, and establish
architecture.
3. Construction: Implement and test the system in iterative builds.
4. Transition: Deploy software, provide training, and fix post-release
issues.
5. Production: Maintain, support, and enhance the system after release.
THANK YOU