UNIT 1

Syllabus
• [Link]
Contents:
Introduction to Software Engineering, Software engineering principles,
Software Myths, Software Engineering - a Layered Technology,
Software Process Framework, , Requirement Engineering Process,
Eliciting Requirement: Software Requirements Specification. Software
Process Models: Waterfall Model, Incremental Process Models,
Evolutionary Process Models, Specialized Process Models.
Introduction to Software Engineering.
• Software Engineering is the process of designing, developing,
testing, and maintaining software. It is a systematic and disciplined
approach to software development that aims to create high-quality,
reliable, and maintainable software. Software engineering includes a
variety of techniques, tools, and methodologies, including
requirements analysis, design, testing, and maintenance.
Key principals of software Engineering
• Modularity: Breaking the software into smaller, reusable components
that can be developed and tested independently.
• Abstraction: Hiding the implementation details of a component and
exposing only the necessary functionality to other parts of the
software.
• Encapsulation: Wrapping up the data and functions of an object into a
single unit, and protecting the internal state of an object from external
modifications.
• Reusability: Creating components that can be used in multiple
projects, which can save time and resources.
Continued…
• Maintenance: Regularly updating and improving the software to fix bugs,
add new features, and address security vulnerabilities.
• Testing: Verifying that the software meets its requirements and is free of
bugs.
• Design Patterns: Solving recurring problems in software design by
providing templates for solving them.
• Agile methodologies: Using iterative and incremental development
processes that focus on customer satisfaction, rapid delivery, and flexibility.
• Continuous Integration & Deployment: Continuously integrating the code
changes and deploying them into the production environment.
Continued…
• Maintainability: It should be feasible for the software to evolve to
meet changing requirements.
• Efficiency: The software should not make wasteful use of computing
devices such as memory, processor cycles, etc.
• Correctness: A software product is correct if the different requirements
specified in the software development specification (SRS) Document
have been correctly implemented.
• Reusability: A software product has good reusability if the different
modules of the product can easily be reused to develop new products.
Continued…
• Testability: Here software facilitates both the establishment of test criteria
and the evaluation of the software with respect to those criteria.
• Reliability: It is an attribute of software quality. The extent to which a
program can be expected to perform its desired function, over an arbitrary
time period.
• Portability: In this case, the software can be transferred from one computer
system or environment to another.
• Adaptability: In this case, the software allows differing system constraints
and the user needs to be satisfied by making changes to the software.
• Interoperability: Capability of 2 or more functional units to process data
cooperatively.
Program vs Software Product
• Program • Software Product
1. A program is a set of 1. Software is when a program is
instructions that are given to a made available for commercial
computer in order to achieve a business and is properly
specific task. documented along with its
licensing.
Software Product = Program +
Documentation + Licensing.
Continued…
2. Program is one of the stages 2. Software Development usually
involved in the development of the follows a life cycle, which
software. involves the feasibility study of
the project, requirement gathering,
development of a prototype,
system design, coding, and testing.
Advantages of Software Engineering
There are several advantages to using a systematic and disciplined
approach to software development, such as:
• Improved Quality: By following established software engineering
principles and techniques, the software can be developed with fewer
bugs and higher reliability.
• Increased Productivity: Using modern tools and methodologies can
streamline the development process, allowing developers to be more
productive and complete projects faster.
• Better Maintainability: Software that is designed and developed using
sound software engineering practices is easier to maintain and update
over time.
Continued…
• Reduced Costs: By identifying and addressing potential problems early in
the development process, software engineering can help to reduce the cost
of fixing bugs and adding new features later on.
• Increased Customer Satisfaction: By involving customers in the
development process and developing software that meets their needs,
software engineering can help to increase customer satisfaction.
• Better Team Collaboration: By using Agile methodologies and continuous
integration, software engineering allows for better collaboration among
development teams.
• Better Scalability: By designing software with scalability in mind, software
engineering can help to ensure that software can handle an increasing
number of users and transactions.
Continued…
• Better Security: By following the Software Development Life Cycle
(SDLC) and performing security testing, software engineering can
help to prevent security breaches and protect sensitive data.
Software Myths
• Most, experienced experts have seen myths or superstitions (false
beliefs or interpretations) or misleading attitudes, which creates major
problems for management and technical people. The types of
software-related myths are listed below.
Continued…
(i) Management Myths:
Myth 1:
We have all the standards and procedures available for software
development.
Fact:
• Software experts do not know all the requirements for the software
development.
• And all existing processes are incomplete as new software
development is based on new and different problem.
Continued…
Myth 2:
• The addition of the latest hardware programs will improve the
software development.
Fact:
• The role of the latest hardware is not very high on standard software
development; instead computer aided software engineering (CASE)
tools help the computer, they are more important than hardware to
produce quality and productivity.
• Hence, the hardware resources are misused.
Continued…
Myth 3:
• With the addition of more people and program planners to Software
development can help meet project deadlines (If lagging behind).
Fact:
If software is late, adding more people will merely make the problem
worse. This is because the people already working on the project now
need to spend time educating the newcomers, and are thus taken away
from their work. The newcomers are also far less productive than the
existing software engineers, and so the work put into training them to
work on the software does not immediately meet with an appropriate
reduction in work.
Continued…
(ii)Customer Myths:
The customer can be the direct users of the software, the technical team,
marketing / sales department, or other company. Customer has myths
leading to false expectations (customer) & that’s why you create
dissatisfaction with the developer
Myth 1:
A general statement of intent is enough to start writing plans (software
development) and details of objectives can be done over time.
Continued…
Fact:
• Official and detailed description of the database function, ethical
performance, communication, structural issues and the verification
process are important.
• Unambiguous requirements (usually derived iteratively) are developed
only through effective and continuous communication between
customer and developer.
Continued…
Myth 2:
• Software requirements continually change, but change can be easily
accommodated because software is flexible.
Fact:
• It is true that software requirements change, but the impact of change varies
with the time at which it is introduced. When requirements changes are
requested early (before design or code has been started), the cost impact is
relatively small. However, as time passes, the 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.
Continued…
(iii)Practitioner’s Myths:
Myths 1:
They believe that their work has been completed with the writing of the
plan.
Fact:
It is true that every 60-80% effort goes into the maintenance phase (as
of the latter software release). Efforts are required, where the product is
available first delivered to customers.
Continued…
Myths 2:
• There is no other way to achieve system quality, until it is “running”.
Fact:
• Systematic review of project technology is the quality of effective
software verification method. These updates are quality filters and
more accessible than test.
Continued…
Myth 3:
• An operating system is the only product that can be successfully
exported project.
Fact:
• A working system is not enough, the right document brochures and
booklets are also required to provide guidance & software support.
Continued…
Myth 4:
• Engineering software will enable us to build powerful and unnecessary
document & always delay us.
Fact:
• Software engineering is not about creating documents. It is about
creating a quality product. Better quality leads to reduced rework. And
reduced rework results in faster delivery times
Software Engineering – A layered technology
• Software engineering is a layered technology because it uses
engineering principles to design, develop, test, deploy, and manage
systems. The layers are connected, and each layer requires the
previous layer to be fulfilled.
Fig. The diagram shows the layers of a
software development
Continued…
Layered technology is divided into four parts:
1. A quality focus: It defines the continuous process improvement
principles of software. It provides integrity that means providing security
to the software so that data can be accessed by only an authorized person,
no outsider can access the data. It also focuses on maintainability and
usability.
2. Process: It is the foundation or base layer of software engineering. It is
key that binds all the layers together which enables the development of
software before the deadline or on time. Process defines a framework that
must be established for the effective delivery of software engineering
technology. The software process covers all the activities, actions, and
tasks required to be carried out for software development.
Continued…

Fig. Process activities

Continued…
Process activities are listed below:
• Communication: It is the first and foremost thing for the development of
software. Communication is necessary to know the actual demand of the
client.
• Planning: It basically means drawing a map for reduced the complication
of development.
• Modeling: In this process, a model is created according to the client for
better understanding.
• Construction: It includes the coding and testing of the problem.
• Deployment: It includes the delivery of software to the client for evaluation
and feedback.
Continued…
3. Method:
• During the process of software development the answers to all “how-to-do”
questions are given by method.
• It has the information of all the tasks which includes communication,
requirement analysis, design modeling, program construction, testing, and
support.
4. Tools:
• Software engineering tools provide a self-operating system for processes
and methods.
• Tools are integrated which means information created by one tool can be
used by another.
Software Process Framework
• Software Process Framework is an abstraction of the software
development process. It details the steps and chronological order of a
process.
• Since it serves as a foundation for them, it is utilized in most
applications. Task sets, umbrella activities, and process framework
activities all define the characteristics of the software development
process.
Continued…
Software process includes:
• Tasks – focus on a small, specific objective.
• Action – set of tasks that produce a major work product.
• Activities – group of related tasks and actions for a major objective.
Fig. Software Process Framework
Continued…
Process Framework Activities:
• The process framework is required for representing common process
activities.
• Five framework activities are described in a process framework for
software engineering.
• Communication, planning, modeling, construction, and deployment
are all examples of framework activities.
• Each engineering action defined by a framework activity comprises a
list of needed work outputs, project milestones, and software quality
assurance (SQA) points.
Continued…
➢Communication: By communication, customer requirement gathering is
done. Communication with consumers and stakeholders to determine the
system’s objectives and the software’s requirements.
➢Planning: Establish engineering work plan, describes technical risk, lists
resources requirements, work produced and defines work schedule.
➢Modeling: Architectural models and design to better understand the
problem and for work towards the best solution. The software model is
prepared by:
❖ Analysis of requirements
❖ Design
Continued…
• Construction: Creating code, testing the system, fixing bugs, and
confirming that all criteria are met. The software design is mapped
into a code by:
❖ Code generation
❖ Testing
• Deployment: In this activity, a complete or non-complete product or
software is represented to the customers to evaluate and give feedback.
On the basis of their feedback, we modify the product for the supply
of better products.
Continued…
• Umbrella activities:
Umbrella Activities are that take place during a software development
process for improved project management and tracking.
1. Software project tracking and control: This is an activity in which
the team can assess progress and take corrective action to maintain
the schedule. Take action to keep the project on time by comparing
the project’s progress against the plan.
2. Risk management: The risks that may affect project outcomes or
quality can be analyzed. Analyze potential risks that may have an
impact on the software product’s quality and outcome.
Continued…
3. Software quality assurance: These are activities required to maintain
software quality. Perform actions to ensure the product’s quality.
4. Formal technical reviews: It is required to assess engineering work
products to uncover and remove errors before they propagate to the next
activity. At each level of the process, errors are evaluated and fixed.
5. Software configuration management: Managing of configuration
process when any change in the software occurs.
6. Work product preparation and production: The activities to create
models, documents, logs, forms, and lists are carried out.
Continued…
7. Reusability management: It defines criteria for work product reuse.
Reusable work items should be backed up, and reusable software
components should be achieved.
8. Measurement: In this activity, the process can be defined and
collected. Also, project and product measures are used to assist the
software team in delivering the required software.
Software Requirement Task
• Requirements engineering is a broad domain that focuses on being the
connector between modeling, analysis, design, and construction.
• It is the process that defines, identifies, manages, and develops
requirements in a software engineering design process.
• This process uses tools, methods, and principles to describe the
system’s behavior and the constraints that come along with it.
• Requirements engineering is the most important part every business
must follow, in order to build and release a project successfully, as it is
the foundation to key planning and implementation.
Continued…
Requirements Engineering Tasks: The software requirements
engineering process includes the following steps of activities:
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management
Continued…
1. Inception:
• This is the first phase of the requirements analysis process. This phase
gives an outline of how to get started on a project. In the inception
phase, all the basic questions are asked on how to go about a task or
the steps required to accomplish a task.
• A basic understanding of the problem is gained and the nature of the
solution is addressed. Effective communication is very important in
this stage, as this phase is the foundation as to what has to be done
further. Overall in the inception phase, the following criteria have to
be addressed by the software engineers:
Continued…
• Understanding of the problem.
• The people who want a solution.
• Nature of the solution.
• Communication and collaboration between the customer and
developer.
Continued…
2. Elicitation:
• This is the second phase of the requirements analysis process.
• This phase focuses on gathering the requirements from the stakeholders.
• One should be careful in this phase, as the requirements are what
establishes the key purpose of a project.
• Understanding the kind of requirements needed from the customer is very
crucial for a developer.
• In this process, mistakes can happen in regard to, not implementing the
right requirements or forgetting a part.
• The right people must be involved in this phase. The following problems
can occur in the elicitation phase:
Continued…
✓Problem of Scope: The requirements given are of unnecessary detail,
ill-defined, or not possible to implement.
✓Problem of Understanding: Not having a clear-cut understanding
between the developer and customer when putting out the
requirements needed. Sometimes the customer might not know what
they want or the developer might misunderstand one requirement for
another.
✓Problem of Volatility: Requirements changing over time can cause
difficulty in leading a project. It can lead to loss and wastage of
resources and time.
Continued…
3. Elaboration:
• This is the third phase of the requirements analysis process.
• This phase is the result of the inception and elicitation phase.
• In the elaboration process, it takes the requirements that have been
stated and gathered in the first two phases and refines them.
• Expansion and looking into it further are done as well.
• The main task in this phase is to indulge in modeling activities and
develop a prototype that elaborates on the features and constraints
using the necessary tools and functions
Continued…
4. Negotiation:
• This is the fourth phase of the requirements analysis process.
• This phase emphasizes discussion and exchanging conversation on what is
needed and what is to be eliminated.
• In the negotiation phase, negotiation is between the developer and the customer
The following are discussed in the negotiation phase:
o Availability of Resources.
o Delivery Time.
o Scope of requirements.
o Project Cost.
o Estimations on development.
Continued…
5. Specification:
• This is the fifth phase of the requirements analysis process. This phase
specifies the following:
▪ Written document.
▪ A set of models.
▪ A collection of use cases.
▪ A prototype.
Continued…
6. Validation:
This is the sixth phase of the requirements analysis process. This phase
focuses on checking for errors and debugging. In the validation phase,
the developer scans the specification document and checks for the
following:
• All the requirements have been stated and met correctly.
• Errors have been debugged and corrected.
• Work product is built according to the standards.
Continued…
7. Requirements Management:
• This is the last phase of the requirements analysis process.
Requirements management is a set of activities where the entire team
takes part in identifying, controlling, tracking, and establishing the
requirements for the successful and smooth implementation of the
project.
• In this phase, the team is responsible for managing any changes that
may occur during the project.
Requirement Engineering Process
• Requirements engineering is the process of identifying, eliciting,
analyzing, specifying, validating, and managing the needs and
expectations of stakeholders for a software system.
• The requirements engineering process is an iterative process that
involves several steps, including:
Requirements Elicitation:
▪ This is the process of gathering information about the needs and
expectations of stakeholders for the software system.
▪ This step involves interviews, surveys, focus groups, and other
techniques to gather information from stakeholders.
Continued…
Requirements Analysis:
▪ This step involves analyzing the information gathered in the
requirements elicitation step to identify the high-level goals and
objectives of the software system.
▪ It also involves identifying any constraints or limitations that may
affect the development of the software system.
Continued…
Requirements Specification:
▪ This step involves documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous manner.
▪ This step also involves prioritizing and grouping the requirements into
manageable chunks.
Requirements Validation:
▪ This step involves checking that the requirements are complete,
consistent, and accurate.
▪ It also involves checking that the requirements are testable and that
they meet the needs and expectations of stakeholders.
Continued…
Requirements Management:
▪ This step involves managing the requirements throughout the software
development life cycle, including tracking and controlling changes,
and ensuring that the requirements are still valid and relevant.
The Requirements Engineering process is a critical step in the software
development life cycle as it helps to ensure that the software system
being developed meets the needs and expectations of stakeholders, and
that it is developed on time, within budget, and to the required quality.
Continued…
• Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining
service provided by the system.
• It is the disciplined application of proven principle , methods ,tools
and notations to describe a proposed system’s intended behavior and
its associated constraints.
Continued…
• Tools involved in requirement engineering:
➢Observation report
➢Questionnaire ( survey, poll )
➢Use cases
➢User stories
➢Requirement workshop
➢Mind mapping
➢Prototyping
Waterfall Model
• The Waterfall Model was the first Process Model to be introduced. It is
also referred to as a linear-sequential life cycle model.
• It is very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and there is
no overlapping in the phases.
• The Waterfall model is the earliest SDLC approach that was used for
software development.
• The waterfall Model illustrates the software development process in a
linear sequential flow. This means that any phase in the development
process begins only if the previous phase is complete. In this waterfall
model, the phases do not overlap.
Continued…
Waterfall Model – Design
• Waterfall approach was first SDLC Model to be used widely in
Software Engineering to ensure success of the project.
• In "The Waterfall" approach, the whole process of software
development is divided into separate phases.
• In this Waterfall model, typically, the outcome of one phase acts as the
input for the next phase sequentially.
Fig. Waterfall Model
Continued…
Requirement Analysis:
• All possible requirements of the system to be developed are captured
in this phase and documented in a requirement specification document.
• Remove Requirement Problems such as
- Inconsistencies: One part of the requirement contradicts with some of
the other part of the requirement.
- Anomalies: anomalies are ambiguity (state of being unclear or
confusing), sore requirements are anomalous or not clear.
- Incompleteness: Some information are missed.
Continued…
• After eliminating the problems the information needs to be
documented or organize into a Software Requirement Specifications
(SRS) document.
• Gathering the relevant data:
- Usually collected from the end users through interviews and
discussions.
- Example: For a business accounting software
- Interview all the accountants of the organization to find out there
requirements.
Continued…
• System Design − The requirement specifications from first phase are
studied in this phase and the system design is prepared. This system
design helps in specifying hardware and system requirements and
helps in defining the overall system architecture.
• The design activity typically uses the requirement specification
document, the designers consult the SRS document and then come up
with the design which will be easily implemented in some
programming language.
Continued…
• Two commonly used design approaches:
- Traditional Approach
- It consist of two activities:
- Structured Analysis (Typically carried out by using DFD (Data flow
diagram))
- Once the Data flow digram is completed done then it is translated to a
structured design.
- Structured Design

- Object Oriented Approach

Continued…
Structured Design
• The end of the structured design will have a high level design decomposes
in the module structure.
• High Level design:
- Represents the invocation relationship
Amongst the modules.
• Detailed Design:
- Different modules designed in a
Greater detail, data structure and
Algorithms for each module are designed.
Continued…
Object Oriented Design:
- First identify various objects (Real world entities) occurring in the
problem.
- Identify the relationships among the object.
- For example, the object in a payroll software may be:
• Employees,
• Managers,
• Pay-roll register
• Departments, etc
Continued…
• Object Oriented design has several advantages:
- Lower development efforts
- Lower Development Time
- Better maintenability
Continued…
Coding:
- Each module of the is coded.
- Each module is unit tested.
That is tested independently as a stand alone unit and debugged.
- Once it is passed the unit testing the modules are documented.
Continued…
• Testing
Integration and system testing is carried out:
- During integration testing the different modules are integrated in a
planned manner, i.e. there are number of steps through which the
modules are integrated.
- To integrate this module the main idea is that, we check
Weather they are interacting properly.
- The interface box are the main focus in the integration
testing. During Unit testing box in the different modules are identified.
Continued…
• And in the next step more modules may be identified and again the
interfacing between them is checked.
• System is integrated over a number of steps.
• Once all the modules have been integrated
then the system testing is carried out.
Continued…
• Goals of the system testing:
Ensures that the development system functions according to its
requirements specified in the SRS document.
Continued…
Maintenance
- Once the testing is done the software is delivered to the customer and
then the starting of the maintenance phase takes place where if there is
is any issue reported by the customer then this needs to be fixed,
enhancements and so on.
- Maintenance work continues for quite long time.
- Maintenance of any software require much more efforts than to effort
to develop the product itself.
- Development effort to maintenance effort is typically 40-60.
Continued…
• Types of Maintenance:
1. Corrective Maintenance:
- Correct errors which were not discovered during the product
development phase.
- Example: Bugs may be reported that needs to be corrected.
2. Perfective maintenance:
-It may be necessary to enhance the functionality, which were not
visualized earlier
-or improve the implementation in some way, for example may be the
response time is not satisfactory, the try to improve the response time.
Continued…
3. Adaptive Maintenance:
- In adaptive maintenance the software may be required to work with a
new hardware.
- Example: The company procured the new server and it has to be
installed on that needs to work on this.
- Or may be there is new operating system on the new computer and it
needs to work with new operating system and therefore the program
may have to change little bit .
- So these kind of maintenance is adaptive maintenance.
Continued…
Iterative waterfall model
- Classical waterfall model is idealistic.
- Assume that no defect is introduced during any development activity.
- In practice- defects do get introduced in almost every phase of the life
cycle.
- Defects usually get detected much later in the life cycle:
- For example, a design defects might go unnoticed till the coding or
testing phase.
Continued…
• The ‘later the phase I which the defects gets detected, the more
expensive is its removal – why?
• Because we have to rework the results of many phases.
• If we detect the requirement problem during testing then we not only
have to take up the requirements documents and change all the
requirements that are in problem but need to redesign, need to change
the code and again need to test.
• If we discover the problem during the design phase we might have just
change the requirements and some part of the design.
Continued…
• Once the defect is detected, the phase in which it occur needs to be
reworked.
• Redo some of the work done during that and all subsequent phases.
• Therefor need feedback paths in the classical waterfall model.
Continued…
• Defect of one phase may get detected any of the later phase and as it is
detected we need to rework the results produced at that phase and
therefore we need feedback paths, so that should be able to revisit that
phase and that’s basically the representation of iterative waterfall
model where we have added feedback paths to the classical
waterfall model.
Continued…
Phase Containment of Errors:
The principal of detecting errors as close to its point of introduction as
possible is known as Phase Containment of Errors.
• Errors should be detected in the same phase in which they are introduced.
• But the principal that the later the defect is detected the more expensive it is
that gives us an idea is that if we detect the defect in the same phase itself
then it will cost the least.
• Example: if the design problem is detected in the design phase then we can
just correct it there itself, but if we detect it during coding and unit testing
not only we need to change the design part but also the change the code.
Continued…
• Iterative waterfall model is by far the most widely used model. Almost
every other model is derived from the waterfall model.
Continued…
Waterfall Strengths:
• Easy to understand, easy to use.
• Provides a reference to inexperienced staff.
• Milestones are well understood by team.
• Provides requirements stability.
• Facilitates strong management control.
Continued…
Waterfall Deficiencies
• All the requirements must be known upfront.
• Deliverables created for each phase are considered frozen – inhebits
flexibity.
• Can give a false impression of progress.
• Integration is one big bang at the end.
• Little opportunity for the customer to preview the system.
Continued…
When to use waterfall model:
• Requirements are well known and stable.
• Technology is understood.
• Experienced development team.
Incremental Process Models
• Incremental Model is a process of software development where
requirements divided into multiple standalone modules of the software
development cycle. In this model, each module goes through the
requirements, design, implementation and testing phases. Every
subsequent release of the module adds function to the previous
release. The process continues until the complete system achieved.
Continued…
• The basic idea…take advantage of what was being learned during the
development of earlier, incremental, deliverable, versions of the
system.
• Learning comes from both the development and use of the system.
• Starts with a simple implementation of a subset of a software
requirements and iteratively enhance the evolving sequence of
versions. At each version design modifications are made along with
adding new functional capabilities. – Vector Basili
Continued…
Key Characteristics of the Iterative Development
- Builds system incrementally.
- Consists of a planned number of iterations.
- Each iteration produces a working program.
Benefits
- Facilitates and manages changes.
Continued…
Customers Perspective
• If we look at the customers perspective the incremental development,
initially we develop the core part of the software, later on customer
gives the feedback and gets slightly larger software and so on until you
get the full software.
• But as far the designers are concerned the developers the model they
follow as:
Continued…
• That they get the requirements (Initial requirements) and they split it
into deliverable features, and they do a overall design, and they keep
on developing the increment, validate the increment, integrate with
the previous system, validate the system and keep on doing this
until all the features are accommodated. And finally they deliver
the system.
Continued…
• Incremental Model Requirements:
Continued…
• If we compare the incremental model with the waterfall model.
• Waterfall model has a single release.
• Iterative model has many releases (increments)
• First increment is core functionality.
• Successive increments: add fix functionality
• Final increment: the complete product.

- Each iteration is a short mini project with a separate life cycle. Example
waterfall.
Continued…
Incremental Delivery
Continued…
• Here the entire increment is split into increments and the first
increment design, build, install, and customer feedback.
• And once the first increment customer feedback is obtained the second
instant increment is started, and then the third increment is started and
so on.
• And this time to develop on increment is typically called as a time
box.
Continued…
Which Increment first?
- Requirement are identified, split into several increments, there may be
n number of increments lets us say 10 increments are there but which
increment will be done first? How does the developer decide which
increment to be taken off first.
- One thing is that some increments have to be done because the other
one is depend on that, we have to do that first because the others might
have the dependency on that.
- But if some requirements are can be done on any order then we can
compute a value to cost ratio.
Continued…
V/C
where,
- V is the value to the customer. We can ask the customer to give a value
1 to 10.
- And the cost C is a cost of development can give a value 1 to 10
Continued…
V/C ratios: An example
Continued…
• Here in this example we have features (steps), values that the
customer specify that how valuable are the features.
• And we have the cost of development, the development team gives a
cost and then the ration is worked out.
• Here 9 is the largest ratio and this will be the first increment.
Evolutionary Process Models
• In any real project the requirements change during the development,
there are many reasons why the requirements change.
• One of the reason may be the customer is not able to view the software
in entirely before the software is built and therefore many
requirements are missed many requirements are given ambiguously,
there inconsistency.
• Cappers jones an established researcher he studied 8000 projects and
found that 40% of the requirements change during the development.
• This is a very significant issue because neither waterfall model not the
incremental model handle this satisfactory.
Continued…
• Waterfall model has no provision for requirement change during the
development.
• In Incremental model, identifies all the requirements upfront and then
slicing the requirements into incremental features to be deployed at the
customer side.
• While a features being installed the customer feedback is obtained
which may necessitate additional requirements or change of
requirements.
• Still the fact remains that the incremental model requires all the
requirements to be identified upfront as far as possible.
Continued…
• Evolutionary Model tries to overcome necessity of having to identify
all the requirements upfront.
• There are some similarities between the evolutionary model and the
incremental model in the sense that increments are deployed at the
client side but here in the evolutionary model no upfront requirement
specification is required.
• Initially some features are implemented which have been identified
and then as the customer experiments is those more and more features
get developed and deployed so the software actually evolves starting
with something very simple.
Continued…
• But the main difference with and the incremental model and purely
evolutionary model is that with respect to upfront identification of the
requirements.
• Promotes early risk mitigation:
- Breaks down the system into mini projects and focus on the riskier
issue first.
- “Plan a little, design a little, and code a little”
• Because each time only few features are identified plan for those features
design, develop, deployed at the customer site.
• Encourage all development participants to be involved earlier on unlike the
waterfall model.
- End users, Testers, integrators, and technical writer.
Continued…
• Evolutionary model with iterations:
A complex system is will be most successful if implemented in a small
steps. “Retreat” to a previous successful step on failure. Opportunity to
receive some feedback from the real world before throwing in all the
resources, and you can correct possible errors. – Tom glib in software
metrics.
• Identified the big advantage of evolutionary model that the client
feedback is obtained and the features are determined as the client
keeps on using the system evolves, and if some features the customer
does not like then that feature is simply discarded and new features
replacing that are built.
Continued…
• Evolutionary iterative development implies that the requirements,
plan, estimates and solution evolve or are refined over the course of
the iterations, rather than fully defined and frozen in a major upfront
specification effort before the development iterations begin.
Evolutionary methods are consistent with the pattern of unpredictable
discovery and change in new product development. ---Craig Larman
Continued…
What is involved in the evolutionary model?
• First develop the core modules of the software.
• The initial skeletal software is refined into increasing levels of
capability: (Iterations)
- Each iterations adds new functionalities in successive versions.
Continued..
Activities in an iteration
• Software developed over several “Mini Waterfalls”.
• The result of a single iteration:
- Ends with delivery of some tangible code.
- An incremental improvement to the software, leads to evolutionary
development.
- After a single iteration some code is deployed and the client expresses
what is required next and this leads to the evolutionary development.
Continued…
Evolutionary Model with iteration
• Outcome of each iteration: tested, integrated, executable system.
• Does not “Freeze” requirements and then conservatively design to
accommodate any feature changes.
• Iteration length is short and fixed.
- usually between 2 to 6 weeks.
- Development takes many iterations (10 – 15)
Continued…
• Successive Versions: Functioning systems capable of performing some
useful work. The customer can make use of them in real work.
Continued…
Evolutionary Model:
Evolves an initial implementation with user feedback:
- multiple versions until the final version.
Continued…
Advantages of Evolutionary Model
• Users get a chance to experiment with a partially developed system:
much before the full working version is released.
• Helps find exact user requirements: Software more likely to meet
exact user requirements.
• Core module get tested thoroughly: Reduces chances of errors in final
delivered software.
• Better management of complexity by developing one increment at a
time.
• Better management of changing requirements.
Continued…
• Can get customer feedback and incorporate them much more
efficiently.
• Training can start on an earlier release: Customer feedback taken into
account.
• Frequent releases allow developers to fix unanticipated problems
quicker.
Continued…
Evolutionary Model Problems:
• The process is intangible, no regular well defined deliverables.
• The process is unpredictable: hard to manage, e.g. scheduling etc.
• Systems are rather poorly structured: Continual, unpredictable changes
tend to degrade the software structure.
• Systems may not even converge to final versions.
Specialized Process Models
• Specialized process models take on many of the characteristics of one
or more of the traditional models. However, these models tend to be
applied when a specialized or narrowly defined software engineering
approach is chosen.
• It is important to note, however, that being the first to reach a market
is no guarantee of success. In fact, many very successful software
products have been second or even third to reach the market (learning
from the mistakes of their predecessors).
• In this context software quality is defined quite broadly to encompass
not only customer satisfaction, but also a variety of technical criteria
discussed.
Continued…
• In some cases, these specialized process models might better be
characterized as a collection of techniques or a "methodology for
accomplishing a specific software development goals However, they
do imply a process.
• In this specialized process model we have to study three different
models, such as:
1. Component – Based Development.
2. The formal methods model.
3. Aspect Oriented software development.
1. Component-Based Development
• Commercial off-the-shelf (COTS) software components, developed by
vendors who offer them as products, provide targeted functionality
with well-defined interfaces that enable the component to be
integrated into the software that is to be built.
• It is evolutionary in nature demanding an iterative approach to the
creation of software.
• However, the component- based development model comprises
applications from prepackaged software components.
Continued…
• Regardless of the technology that is used to create the components, the
component-based development model incorporates the following steps
(implemented using an evolutionary approach):
1. Available component-based products are researched and evaluated
for the application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the
components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
Continued…
• The component-based development model leads to software reuse, and
re- usability provides software engineers with a number of measurable
benefits including a reduction in development cycle time and a
reduction in project cost if component reuse becomes part of your
organization's culture.
2. 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 you to specify, develop, and verify a
computer-based system by applying a rigorous, mathematical notation.
• A variation on this approach, called cleanroom software engineering,
is currently applied by some software development organizations.
• In clean room software engineering, an efficient and good quality
software product is delivered to the client as QA (Quality Assurance)
is performed each and every phase of software development.
Continued…
• When formal methods are used during development, they provide a
mechanism for eliminating many of the problems that are difficult to
over come using other software engineering paradigms Ambiguity,
incompleteness, and inconsistency can be discovered and corrected
more easily not through ad hoc review, but through the application of
mathematical analysis.
• When formal methods are used during design, they serve as a basis for
program verification and therefore enable you to discover and correct
errors that might otherwise go undetected.
Continued…
• Although not a mainstream approach, the formal methods model offers
the promise of defect-free software.
• Yet, concern about its applicability in a business environment has been
voiced:
➢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 techni cally
unsophisticated customers
Continued…
• These concerns notwithstanding, the formal methods approach has
gained adherents among software developers who must build safety-
critical software (e.g., developers of aircraft avionics and medical
devices)
3. Aspect-Oriented Software Development
• Aspect-Oriented Software Development Regardless of the software
process that is chosen, the builders of complex software invariably
implement a set of localized features, functions, and information
content.
• These localized software characteristics are modeled as components
(e.g., object-oriented classes) and then constructed within the context
of a system architecture.
• As modern computer-based systems become more sophisticated (and
complex), certain concerns-customer required properties or areas of
technical interest-span the entire architecture.
Continued…
• Some concerns are high-level properties of a system (e.g., security,
fault tolerance). Other concerns affect functions (eg, the application of
business rules), while others are systemic (e.g.. task synchronization or
memory management).
• When concerns cut across multiple system functions, features, and
information, they are often referred to as crosscutting concerns.
Aspectual requirements define those crosscutting concerns that have
an impact across the software architecture.
Continued…
• Aspect-oriented software development (AOSD), often referred to as
aspect-oriented programming (AOP) or aspect-oriented component
engineering (AOCE) IGru021, is a relatively new software
engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and Constructing
aspects.
• Example:
To provide a security to the three application layer UI layer, Business
Layer and Data access layer we can use the common snippet of code
such as (security, transaction management) hence there code are written
in a classes and these classes are called as aspects.
End of the Unit 1