UNIT I SOFTWARE PROCESS

Basics − S/W engineering paradigm − Life cycle models (Water fall, Incremental, Spiral,
WINWIN, Spiral, Evolutionary, Prototyping, Object Oriented) − System engineering −
Computer based system −Verification − Validation − Life cycle process – Development
process − System engineering hierarchy
------------------------------------------------------------------------------------------------------------------------
1.1 Basics:
 Software is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be collection of executable
programming code, data structures and documentations. Software, when made for a specific
requirement is called 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.
Definitions

IEEE defines software engineering as:

(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software; that is, the application of
engineering to software.
(2) The study of approaches as in the above statement.

Characteristics of the software

 Software is engineered or developed, not manufactured.
 Software does not wear out.
 Most software is custom built rather than being assembled from components.

Need of Software Engineering

The need of software engineering arises because of higher rate of change in user requirements and
environment on which the software is working.
 Large software - It is easier to build a wall than to a house or building, likewise, as the size
of software become large engineering has to step to give it a scientific process.
 Scalability- If the software process were not based on scientific and engineering concepts, it
would be easier to re-create new software than to scale an existing one.
 Cost- As hardware industry has shown its skills and huge manufacturing has lower down he
price of computer and electronic hardware. But the cost of software remains high if proper
process is not adapted.
 Dynamic Nature- The always growing and adapting nature of software hugely depends
upon the environment in which user works. If the nature of software is always changing,
new enhancements need to be done in the existing one. This is where software engineering
plays a good role.
 Quality Management- Better process of software development provides better and quality
software product.
Software engineering Layers
Software engineering is a fully layered technology, to develop software we need to go from one
layer to another. All the layers are connected and each layer demands the fulfilment of the previous
layer.
Software engineering is the establishment and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently in real machines.

1. Quality focus : Any engineering approach (including software engineering) must rest on an
organizational commitment to quality. Total quality management, Six Sigma, and similar
philosophies foster a continuous process improvement culture, and it is this culture that ultimately
leads to the development of increasingly more effective approaches to software engineering. The
bedrock that supports software engineering is a quality focus.
2. Process: 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. The software process forms the basis for
management control of software projects and establishes the context in which technical methods are
applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are
established, quality is ensured, and change is properly managed.
3. Methods: 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 methods rely on
a set of basic principles that govern each area of the technology and include modeling activities and
other descriptive techniques.
4. Tools: Software engineering tools provide automated or semi automated support for the process
and the methods. When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided software
engineering, is established.

Software Evolution
The process of developing a software product using software engineering principles and methods is
referred to as software evolution. This includes the initial development of software and its
maintenance and updates, till desired software product is developed, which satisfies the expected
requirements.
Evolution starts from the requirement gathering process. After which developers create a prototype
of the intended software and show it to the users to get their feedback at the early stage of software
product development. The users suggest changes, on which several consecutive updates and
maintenance keep on changing too. This process changes to the original software, till the desired
software is accomplished.
Even after the user has desired software in hand, the advancing technology and the changing
requirements force the software product to change accordingly. Re-creating software from scratch
and to go one-on-one with requirement is not feasible. The only feasible and economical solution is
to update the existing software so that it matches the latest requirements.
Software Evolution Laws
Lehman has given laws for software evolution. He divided the software into three different
categories:
 S-type (static-type) - This is a software, which works strictly according to
defined specifications and solutions. The solution and the method to achieve it, both are
immediately understood before coding. The s-type software is least subjected to changes
hence this is the simplest of all. For example, calculator program for mathematical
computation.
 P-type (practical-type) - This is a software with a collection of procedures. This is defined
by exactly what procedures can do. In this software, the specifications can be described but
the solution is not obvious instantly. For example, gaming software.
 E-type (embedded-type) - This software works closely as the requirement of real-
world environment. This software has a high degree of evolution as there are various
changes in laws, taxes etc. in the real world situations. For example, Online trading software.
1.2 Software Paradigms
 Software paradigm refers to method and steps, which are taken while designing the
software.
 Programming paradigm is a subset of software design paradigm which is future for other a
subset of software development paradigm.
 Software is considered to be a collection of executable programming code, associated
libraries, and documentation.
 Software development paradigm is also known as software engineering, all the
engineering concepts pertaining to developments software applied.
 It consists of the following parts as Requirement Gathering, Software design,
Programming, etc. The software design paradigm is a part of software development. It
includes design, maintenance, programming.
 These can be combined into various categories, though each of them is contained in one another:
[Link] Development Paradigm
This Paradigm is known as software engineering paradigms where all the engineering concepts
pertaining to the development of software are applied. It includes various researches and
requirement gathering which helps the software product to build. It consists of –
 Requirement gathering
 Software design
 Programming
[Link] Design Paradigm
This paradigm is a part of Software Development and includes –
 Design
 Maintenance
 Programming
3. Programming Paradigm
is a subset of Software design paradigm which is further a subset of Software development
paradigm.
This paradigm is related closely to programming aspect of software development. This includes
 Coding
 Testing
 Integration

Advantages of using a software paradigm:

 Provide a consistent structure for developing software systems.
 Help developers understand the problem they are trying to solve.
 Help developers design and implement solutions more effectively.
 Help developers organize and reuse code more efficiently.
 Help developers create more reliable and maintainable software.

Disadvantages of using a software paradigm:

 Can be difficult to learn and understand for new developers.
 Can be limiting if a problem does not fit well into a specific paradigm.
 Can make it difficult to integrate systems developed using different paradigms.
 Can make it difficult to adapt to new technologies or changing requirements.
1.3SOFTWARE PROCESS
 A software process is a collection of activities, actions, and tasks that are required to build
high-quality software.
 A process defines who is doing what when and how to reach a certain goal.
 The aim of software process is effective on-time delivery of software with quality.
Elements of a software Process
[Link]: An activity helps to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size, complexity and degree of
rigor with which software engineering is to be applied.
2Action: Actions consist of the set of tasks that is used to produce the product.

[Link]: A task focuses on a small, but well-defined objective that produces a tangible outcome.

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.
Process framework activities:
[Link]
 Before starting any technical work, it is important to communicate and collaborate with the
customer and other stakeholders.
 The main objective is to understand stakeholders’ objectives for the project and to gather
requirements that helps to define software features and functions.
[Link]
 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.
[Link]
 Model helps to better understand software requirements and the design that will achieve
those requirements.
[Link]
 This activity combines code generation and the testing that is required to uncover the
errors in the code.
[Link]
 The software is delivered to the customer, who evaluates the product and provides
feedback based on the evaluation.
 Generally, the framework activities are applied iteratively as a project progresses.
 Each project iteration produces a software increment that provides stakeholders with a
subset of overall software features and functionality.
 As each increment is produced, the software becomes more and more complete.
 The Process framework activities are complemented by a number of umbrella activities
which helps to manage and control progress, quality, change, and risk.
Umbrella activities:
1. Software project tracking and control- helps to assess progress against the project plan
 and take any necessary action to maintain the schedule.
2. Risk management- assesses risks that may affect the outcome and quality of the
[Link] quality assurance defines the activities required to ensure software
quality.
3. Technical reviews- assess the products to uncover and remove errors before they are
propagated to the next activity.
4. Measurement- defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs.
5. Software configuration managemen- manages the effects of change throughout the
software process.
6. Reusability management- defines criteria for work product reuse and establishes
mechanisms to achieve reusable components.
7. Work product preparation and production encompasses the activities required to
create work products such as models, documents, and lists.
So a process adopted for one project might be significantly different than a process adopted
for another project.

PROCESS MODEL

Fig: 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. The software process is represented schematically in
above figure.
 As shown in figure 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.
 The important aspect of the software process called process flow describes how the
framework activities and the actions and tasks that occur within each framework
activity are organized with respect to sequence and time.
1. linear process flow: A linear process flow executes each of the five framework
activities in sequence, beginning with communication and culminating with
deployment
2. iterative process flow: An iterative process flow repeats one or more of the
activities before proceeding to the next.

3. evolutionary process flow: An evolutionary process flow executes the activities in

a “circular” manner. Each circuit through the five activities leads to a more
complete version of the software.

4. Parallel process flow: A parallel process flow executes one or more activities in
parallel with other activities

Defining a Framework Activity:

 Defining refers to specifying what actions are appropriate for a framework

activity, given the nature of the problem to be solved, the characteristics of the
people doing the work, and the stakeholders.
 For a small software project, the communication activity includes contacting
the stakeholder, discuss the requirements, generate a brief statement of the
requirement and get the review and approval of it from the stakeholder.
 For complex Projects, the communication activity might have six distinct
actions: inception, elicitation, elaboration, negotiation, specification, and
validation.
Identifying a Task Set
 A task set defines the actual work to be done to accomplish the objectives of a
software engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied
 Eg: For a small project, the task set may include:
 Make a list of stakeholders for the project.
 Informal meeting with stake holders to identify the functions required
 Discuss requirements and build a final list.
 Prioritize requirements.
 Choose the task sets that achieve the goal and still maintain quality and agility.

Process Patterns
 A process pattern provides a template for describing problem solutions that is encountered
during software engineering work
 The template for describing a process pattern:
Pattern Name. - a meaningful name describing the pattern within the context (e.g., Technical
Reviews).
Forces - The environment where the pattern is encountered.
Type - The pattern type is specified. They are three types of patterns:
[Link] patterns define a problem associated with a framework activity for the process.
A stage pattern has multiple related task patterns. Eg: Establishing Communication
includes the task pattern Requirements Gathering and others.
[Link] patterns define a problem associated with a software engineering action or work
task and relevant to successful software engineering practice.
3. Phase patterns define the sequence of framework activities that occur with the
process. Eg: Sprial Model or Prototyping
Initial context - This describes the conditions under which the pattern applies.
Problem - The specific problem to be solved by the pattern.
Solution - Describes how to implement the pattern successfully and how the
initial state of the process is modified as a consequence of the initiation of the
pattern.
Resulting Context - Describes the conditions that will result once the pattern has been
successfully implemented.
Related Patterns - Provide a list of all process patterns that are directly related to this
one. Eg: the stage pattern Communication encompasses the task patterns: Project Team,
Collaborative Guidelines, Scope Isolation, Requirements Gathering, Constraint
Description, and Scenario Creation.
Known Uses and Examples - Indicate the specific instances in which the pattern is
 applicable.
 Process patterns provide an effective mechanism for addressing problems associated
with any software process.
 After developed the process patterns can be reused for the definition of process
variants.

1.4Software development life cycle (SDLC):

SDLC is the acronym for software development life cycle. It is also called the software
development process. All the tasks required for developing and maintaining software. It consists
of a plan describing how to develop, maintain, replace and alter the specific software. It is a
process for planning, creating, testing, and information system. It is a framework of describes the
activity performed at each stage of software development. It is a process used by a system analyst
to develop an information system including requirements, validation, training, and ownership.
Stages of SDLC model:
Brief overview of SDLC stages are as follows.
Stage-1: Requirement gathering: The feasibility report is positive towards the project and next
phase start with gathering requirement from the user. Engineer communicates with the client and
end-users to know their Idea and which features they want to software to include.
Stage-2: Software design: It is a process to transform user requirements into a suitable form. It
helps programmers in software coding. There is a need for more specific and detailed
requirements in software. The output of the process can directly be used in implementation in a
programming language. There are three design levels as follows.
1. Architectural design – It is the highest abstract version of the system. In a software system,
many components interact with each other.
2. High-level design – It focuses on how the system along with all its components and its can be
implemented in form of modules.
3. Detailed design – It defines the logical structure of each module and its interface to
communicate with each module.
Stage-3: Developing Product – In this phase of SDLC, you will see how the product will be
developed. It is one of the crucial parts of SDLC, It is also called the Implementation phase.
Stage-4: Product Testing and Integration – In this phase, we will integrate the modules and
will test the overall product by using different testing techniques.
Stage-5: Deployment and maintenance – In this phase, the actual deployment of the product, or
you can say the final product will be deployed, and also we will do maintenance of product for
any future update and release of new features.

Advantages of SDLC:
 Provides a structured approach to software development, which helps to ensure that important
steps are not overlooked.
 Helps to identify and manage risks early in the development process.
 Helps to deliver software on time and within budget.
 Helps to ensure that software meets the needs of the customer or end-user.
 Helps to improve communication and collaboration among team members.
 Better Resource Management: The SDLC helps to ensure that resources, such as personnel,
equipment, and materials, are allocated effectively throughout the development process. This
helps to ensure that the project stays on schedule and within budget.
 Quality Assurance: The SDLC includes multiple stages of quality assurance, including
testing, validation, and verification. This helps to ensure that the final product is free of bugs
and errors and meets quality standards.
 Flexibility: The SDLC can be adapted to suit the needs of different types of projects and
organizations. This flexibility allows organizations to choose the SDLC methodology that
works best for them.
 Improved Documentation: The SDLC requires documentation at every stage of the
development process. This helps to ensure that important information is captured and can be
referred to later if needed.
 Continuous Improvement: The SDLC encourages continuous improvement by providing
opportunities for feedback and evaluation throughout the development process. This helps to
ensure that the final product meets the changing needs of the customer or end-user.
 Compliance: The SDLC can help organizations to comply with regulatory requirements and
industry standards by ensuring that software is developed in a controlled and structured
manner.

Disadvantages of SDLC:
 Can be inflexible, making it difficult to accommodate changes or unexpected events.
 Can be time-consuming and costly, particularly in the early stages of development.
 Can lead to delays or increased costs if requirements change during development.
 Can lead to a focus on documentation rather than working software.
 Can lead to a lack of customer involvement during development, which can result in a product
that does not meet the customer’s needs.
 Limited scope for creativity: The SDLC is a structured approach to software development
that can be quite rigid in its processes and procedures. This can limit the ability of developers
to be creative and come up with innovative solutions.
 Overemphasis on planning: The SDLC places a great deal of emphasis on planning and
documentation, which can sometimes result in too much time and resources being spent on
these activities at the expense of actually developing the software.
 Difficulty in handling complex or large projects: The SDLC can be difficult to manage for
complex or large projects, as it involves a lot of coordination and communication among team
members and stakeholders.
 Risk of waterfall model: The SDLC follows a sequential process, often referred to as the
waterfall model. This means that each stage of the development process must be completed
before moving on to the next stage. This can result in delays and increased costs if problems
are encountered later in the development process.
 Can be too rigid for agile projects: The SDLC is not well suited for agile development
methodologies, which require a more flexible and iterative approach to software development.
 May not be suitable for all types of software: The SDLC may not be suitable for all types
of software, particularly those that require a rapid development cycle or frequent updates.

1.5 LIFE CYCLE MODELS/ PROCESS MODELS/ PRESCRIPTIVE PROCESS MODELS

 Prescriptive process models stress detailed definition, identification, and application of
process activities and tasks.
 Their intent is to improve system quality, make projects more manageable, make
delivery dates and costs more predictable, and guide teams of software engineers as
they perform the work required to build a system.
 1. Waterfall Model:
 The waterfall model is the oldest paradigm for software engineering.
 The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification of
requirements and progresses through planning, modelling, construction, and deployment,
culminating in ongoing support of the completed software
 This model is used for developing projects where the requirements are well defined and
reasonably stable, it leads to a linear fashion.

Phases:
1. Communication: Customer specification of requirements
2. Planning - identifying the work task, analysing the risk involved, scheduling the project and
estimating the effort and time needed to complete the project etc
3. Modelling which involves translating the requirements gathered into a design
4. Construction – converting the design into the executable code and testing to uncover the
errors.
5. Deployment includes delivery of the product and evaluation of the software.

Problems/Drawbacks of waterfall model

1. Real projects rarely follow the sequential flow that the model proposes. Although the
linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds
2. It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty accommodating the natural uncertainty that exists at
the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the working
program is reviewed, can be disastrous.
 The linear nature of the classic life cycle leads to “blocking states” in which some
project team members must wait for other members of the team to complete dependent
tasks. The time spent waiting can exceed the time spent on productive work. The
 blocking states tend to be more prevalent at the beginning and end of a linear sequential
process.
 It can serve as a useful process model in situations where requirements are fixed and
work is to proceed to completion in a linear manner.

V-model
 A variation in the representation of the waterfall model is called the V-model which
includes the quality assurance actions associated with communication, modeling and
early code construction activities.
 Team first moves down the left side of the V to refine the problem requirements.
 Once code is generated, the team moves up the right side of the V, performing a series
of tests that validate each of the models created.
 The V-model provides a way of visualizing how verification and validation actions
are applied at the different stages of development.

[Link] Models
 The incremental model delivers a series of releases, called increments, that provide
progressively more functionality for the customer as each increment is delivered
 Incremental models construct a partial implementation of a total system and then
slowly add increased functionality
 The incremental model prioritizes requirements of the system and then implements them
in groups.
 Incremental Model, also known as the successive version model, is a widely adopted
model of software development process
 Here the software requirements are divided or broken down into multiple stand-alone
modules/increments in the SDLC (Software Development Life Cycle).
 Each increment is treated as a sub-project and goes through all phases of the SDLC
incremental model.
 This sounds similar to an iterative model. However, this model is an enhancement to the
iterative model and due to this, the incremental model is also called the Iterative
Enhancement Model.
  Each iteration passes through the requirements, design, coding and testing phases. And
each subsequent release of the system adds function to the previous release until all
designed functionality has been implemented.

 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.
When to use Incremental models?
 Requirements of the system are clearly understood
 When demand for an early release of a product arises
 When software engineering team are not very well skilled or trained
 When high-risk features and goals are involved
 Such methodology is more in use for web application and product based companies

Types of Incremental Model

Staged Delivery Model: This type of incremental model involves only one part of the project
being built at a time. In the staged-delivery model, you do not deliver the software all at once, but
rather in successive stages throughout the project as shown below.

Parallel Development Model: This incremental model involves the simultaneous development
of different sub-systems as shown below. As long as sufficient resources are available, it can
decrease the amount of time needed for the development process, i.e., TTM (Time to Market).
Advantages of incremental model
 The software will be generated quickly during the software life cycle
 It is flexible and less expensive to change requirements and scope
 Throughout the development stages changes can be done
 This model is less costly compared to others
 A customer can respond to each building
 Errors are easy to be identified

Disadvantages of incremental model

 It requires a good planning designing
 Problems might cause due to system architecture as such not all requirements collected up
front for the entire software lifecycle
 Each iteration phase is rigid and does not overlap each other
 Rectifying a problem in one unit requires correction in all the units and consumes a lot of
time

[Link] (Rapid Application Development) Model

 The RAD model is a type of incremental process model in which there is extremely
short development cycle.
 When the requirements are fully understood and the component-based construction
approach is adopted then the RAD model is used.
 Various phases in RAD are Requirements Gathering, Analysis and Planning, Design,
Build or Construction, and finally Deployment.
 A software project can be implemented using this model if the project can be broken
down into small modules wherein each module can be assigned independently to
separate teams. These modules can finally be combined to form the final product.
 Development of each module involves the various basic steps as in the waterfall model
i.e. analyzing, designing, coding, and then testing, etc. as shown in the figure.
 Another striking feature of this model is a short time span i.e. the time frame for
delivery(time-box) is generally 60-90 days.
This model consists of 4 basic phases:
1. Requirements Planning – It involves the use of various techniques used in requirements
elicitation like brainstorming, task analysis, form analysis, user scenarios, FAST
(Facilitated Application Development Technique), etc. It also consists of the entire
structured plan describing the critical data, methods to obtain it, and then processing it to
form a final refined model.
2. User Description – This phase consists of taking user feedback and building the
prototype using developer tools. In other words, it includes re-examination and validation
 of the data collected in the first phase. The dataset attributes are also identified and
elucidated in this phase.

3. Construction – In this phase, refinement of the prototype and delivery takes place. It
includes the actual use of powerful automated tools to transform processes and data
models into the final working product. All the required modifications and enhancements
are too done in this phase.
4. Cutover – All the interfaces between the independent modules developed by separate
teams have to be tested properly. The use of powerfully automated tools and subparts
makes testing easier. This is followed by acceptance testing by the user.
The process involves building a rapid prototype, delivering it to the customer, and taking
feedback. After validation by the customer, the SRS document is developed and the design is
finalized.
Advantages
 Use of reusable components helps to reduce the cycle time of the project.
 Encourages user involvement
 Reduced cost.
 Flexible and adaptable to changes

Disadvantages
 For large scalable projects, RAD requires sufficient human resources to create the right
number of RAD teams.
 If developers and customers are not committed to the rapid-fire activities, then project will
fail.
 If a system cannot properly be modularized, building the components necessary for RAD
will be problematic.
 The use of powerful and efficient tools requires highly skilled professionals.
 Customer involvement is required throughout the life cycle.
Evolutionary Process Models
 Evolutionary process models are iterative models that produce an increasingly more
complete version of the software with each iteration.
 Two types of evolutionary approaches are there namely
i. Prototyping and
ii. Spiral models.
i). Prototyping Model:
 Prototyping Model is a software development model in which prototype is built,
tested, and reworked until an acceptable prototype is achieved.
 It also creates base to produce the final system or software.
 It works best in scenarios where the project’s requirements are not known in detail. It
is an iterative, trial and error method which takes place between developer and client.
 Phases:
 Begins with communication by meeting with stakeholders to define the objective,
identify whatever requirements are known, outline areas where further definition is
necessary.
 A quick plan for prototyping and modeling is determined.
 Quick design focuses on a representation of those aspects the software that will be
visible to end users.
 Design leads to the construction of a prototype which will be deployed and
evaluated. Stakeholder’s comments will be used to refine requirements.

Advantages of Prototype Model

 The customer gets to see partial products early in the lifecycle, hence ensuring customer
satisfaction.
 The developed prototype can be reused for bigger projects in the future.
 There is scope to accommodate new requirements.
 Errors and missing functionalities can be identified much early in the lifecycle because
the users are actively involved.
 User feedback is accommodated quickly.
 The model is very straightforward and does not require skilled experts to implement.

Disadvantages of Prototype Model

 Prototyping is a slow and time taking process.
 Documentation is poor as the requirements change frequently.
  When the customer evaluates the prototype, there may be much too many variances in
software needs.
 There is a risk of inadequate requirement analysis owing to too much dependency on the
prototype.

Example for Understanding

Let us understand evolutionary prototyping with the example of a simple database
application. In this application, one cycle may implement the graphical user interface (GUI),
another file manipulation, another query, and yet another update. Before a workable product is
available, all four cycles must be completed. The graphical user interface (GUI) lets users engage
with the system; file manipulation allows data to be saved and retrieved; inquiries allow users to
exit the system, and updates allow users to put data into the system.

Types of Prototyping Models

There are four types of Prototyping Models, which are described below.
 Rapid Throwaway Prototyping- This technique offers a useful method of exploring ideas
and getting customer feedback for each of them. In this method, a developed prototype need
not necessarily be a part of the ultimately accepted prototype. Customer feedback helps in
preventing unnecessary design faults and hence, the final prototype developed is of better
quality.
 Evolutionary Prototyping- In this method, the prototype developed initially is incrementally
refined on the basis of customer feedback till it finally gets accepted. In comparison to Rapid
Throwaway Prototyping, it offers a better approach that saves time as well as effort. This is
because developing a prototype from scratch for every iteration of the process can sometimes
be very frustrating for the developers.
 Incremental Prototyping- In this type of incremental Prototyping, the final expected product
is broken into different small pieces of prototypes and developed individually. In the end,
when all individual pieces are properly developed, then the different prototypes are
collectively merged into a single final product in their predefined order. It’s a very efficient
approach that reduces the complexity of the development process, where the goal is divided
into sub-parts and each sub-part is developed individually. The time interval between the
project’s beginning and final delivery is substantially reduced because all parts of the system
are prototyped and tested simultaneously. Of course, there might be the possibility that the
pieces just do not fit together due to some lack of ness in the development phase – this can
only be fixed by careful and complete plotting of the entire system before prototyping starts.
 Extreme Prototyping- This method is mainly used for web development. It consists of three
sequential independent phases:
1. In this phase, a basic prototype with all the existing static pages is presented in HTML
format.
2. In the 2nd phase, Functional screens are made with a simulated data process using a
prototype services layer.
3. This is the final step where all the services are implemented and associated with the final
prototype.
 Extreme Prototyping method makes the project cycling and delivery robust and fast and keeps
the entire developer team focused and centralized on product deliveries rather than
discovering all possible needs and specifications and adding un-necessitated features.

(ii) Spiral Model:

 Originally proposed by Barry Boehm [Boe88], 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
  Spiral model couples the iterative nature of prototyping with the systematic aspects of the
waterfall model
 It is a risk-driven process model generator that is used to guide multi-stakeholder
concurrent engineering of software intensive systems.
 Two main distinguishing features:
(i) Cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
(ii) Set of anchor point milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
 A series of evolutionary releases are delivered.
 During the early iterations, the release might be a model or prototype. During later
iterations, increasingly more complete version of the engineered system are produced.
 The first circuit in the clockwise direction might result in the product specification;
subsequent passes around the spiral might be used to develop a prototype and then
progressively more sophisticated versions of the software.
 After each iteration, the project plan has to be refined. Cost and schedule are adjusted
based on feedback. Also, the number of iterations will be adjusted by project manager.

 The Spiral Model is a risk-driven model, meaning that the focus is on managing risk
through multiple iterations of the software development process
 The Radius of the spiral at any point represents the expenses(cost) of the project so
far, and the angular dimension represents the progress made so far in the current
phase.
 The arrows pointing inward along the axis separating the deployment region from the
communication region indicate a potential for local iteration along the same spiral path.
Win-Win Spiral Model
The spiral model suggests a framework activity that addresses customer communication. The
objective of this activity is to elicit project requirements from the customer. In an ideal context, the
developer simply asks the customer what is required and the customer provides sufficient detail to
proceed. Unfortunately, this rarely happens. In reality, the customer and the developer enter into a
process of negotiation, where the customer may be asked to balance functionality, performance, and
other product or system characteristics against cost and time to market.
“The original spiral model uses a cyclic approach to develop increasingly detailed
elaborations of a software system’s definition, culminating in incremental releases of the system’s
operational capability.
The win-win spiral process explicitly emphasizes continuous collaborative involvement of a
software product’s stakeholder in it’s early definition and development stages.
 Example: For obtaining the project requirements, customer communication is very important
and essential in the spiral model, the WIN-WIN model also suggests and supports well and
proper communication with the customer. In actual practice, the process of negotiation which
simply means to compromise has to be faced by the customers and developers. When both
sides agree, only then successful negotiation occurs. This is called the WIN-WIN situation.
The best negotiations strive for a “win-win” result. That is,
 Customer’s win means –
Obtaining the system that fulfill most of the requirements of customers.
 Developer’s win means –
Getting the work done by fulfilling the realistic requirements of customers in a given
deadline and achievable budgets.
Features of win-win spiral process model
 It provides an explicit set of goals for collaborative software definition and
development.
 It embeds collaborative activities explicitly within a robust life-cycle model the spiral
model.
The resulting process uses the “Theory W” of win-win model approach to converge on a system’s
next level objectives, constraints, and alternatives.
Boehm’s WINWIN spiral model defines a set of negotiation activities at the beginning of each pass
around the spiral.

There are following seven steps in a win-win spiral model.

Step 1. Identifying the next-level stakeholders.
 In this step you identify the next level stakeholders.
 These are the peoples who you need to make happy after the current phase of
development.
Step 2. Identify stakeholder’s win conditions
Step 3. Reconcile win conditions. Establish next level objectives, constraints, alternatives.
Step 4. Evaluate product and process alternatives, resolves the risks.
 In this step, the current project is examined carefully to consider alternatives and to
resolves any risks that may have been found.
 If they have not been found but later cause problems, blame someone no longer on the
project.
Step 5. Defining next level of product and process, Including partitions
 At this step, the next level is further defined and may partition the system into
subsystem that can be developed in parallel cycles.
 This is particularly useful if a system can be broken into easy part and hard part because
you can delegate the hard part of someone else.
Step 6. Validate Product and Process Definition
Step 7. Review Commitment
In addition to the emphasis placed on early negotiation, the WINWIN spiral model introduces three
process milestones, called anchor points [BOE96], that help establish the completion of one cycle
around the spiral and provide decision milestones before the software project proceeds.
In essence, the anchor points represent three different views of progress as the project traverses the
spiral.
 The first anchor point, life cycle objectives (LCO), defines a set of objectives for each
major software engineering activity. For example, as part of LCO, a set of objectives
establishes the definition of top-level system/product requirements.
 The second anchor point, life cycle architecture (LCA), establishes objectives that must be
met as the system and software architecture is defined. For example, as part of LCA, the
software project team must demonstrate that it has evaluated the applicability of off-the-shelf
and reusable software components and considered their impact on architectural decisions.
 Initial operational capability (IOC) is the third anchor point and represents a set of
objectives associated with the preparation of the software for installation/distribution, site
preparation prior to installation, and assistance required by all parties that will use or support
the software.

Object-Oriented Life Cycle Model/Component based model

 The object-oriented life cycle model considers 'objects' as the basis of the software
engineering process.
 The development team starts by observing and analyzing the system they intend to develop
before defining the requirements.
 Once the process is over, they focus on identifying the objects of the system. Now, an object
could be anything; it can have a physical existence like a customer, car, etc. An object also
constitutes intangible elements like a process or a project.
 Facilitates component based development that incorporates all the characteristics of the spiral
model
 It is evolutionary in nature which demands iterative approach to the creation of software
 This model composes final application from pre-packaged software components
Advantages of Object-Oriented Life Cycle Model
 Since it is data-focused and easy to work with problem domains.
 It uses encapsulation and data hiding process that allows a developer to build tamper-proof
systems.
 It enables software modularity, making it easier to manage and maintain complex software.
 It allows developers to create new modules using existing models, saving time and
development cost of organizations.

The primary objectives of the Object-Oriented Model

 Object-oriented Analysis
 Object-oriented Design
 Object-oriented Implementation
Object-Oriented Analysis (OOA)
 The object-oriented analysis consists of the process where a development team evaluates the
system and organizes the requirements as objects. Contrary to traditional structural analysis,
the OOA heavily depends on advanced data like Use Cases and Object Models.
 Use case- Use Cases are written descriptions about how users will behave when they enter
your website or application. It comprises the goals of each user from the point of their entry
to exit.
 Object Model- An object model allows the development team to create an architectural
software or system model before implementing or programming. It helps in defining a
software/system in objects and classes. It informs the developers about
 Interaction between different models
 Inheritance
 Encapsulation
 Other types of object-oriented interfaces
The OOA starts with analyzing the problem domain and produce a conceptual model by thoroughly
evaluating the information in the given area. There is an abundance of data available from various
sources like Formal document, Requirement statements and Primary data collected through
stakeholders

Once the analysis is complete, the development team prepares a conceptual model describing the
system's functionalities and requirements.

Object-oriented Design(OOD)
 It is the next development stage of the object-oriented life cycle model where the analysts
design the desired system's overall architecture.
 The system is divided into a set of interacting subsystems.
 The analyst considers the specifications from the system analysis. Its all about evaluating
what the end-users expect from the new system.
 As per the object-oriented design, the system is considered a collection of objects, with each
object handling a specific state data.
 For example, in banking software, each account may feature some exclusive objects with
separate data and functions.
 The philosophy behind an object-oriented design is to create a set of interacting objects as
seen in the real world.
 Instead of process-based structural programming, developers create objects through data
structures.
 Useful definitions for Object-oriented design

Class
 A class refers to a collection of similar objects. It is created as a blueprint to define variables
and methods that share certain similarities with objects. As stated above, an object-oriented
design bears resemblances with the real world.
 Let's say you have purchased a smartphone. Now, your smartphone is just one of the several
'smartphones' available in the world. We can consider 'smartphones' as a class of objects, and
your smartphone object is an instance of a class of objects. Smartphones feature many states
(operating System, RAM, and motherboard) and behavior (play music, call, messaging) in
common. However, the state of each smartphone is independent and can be different from
other smartphones.
 While manufacturing smartphones, manufacturers can use the exact blueprint to build many
smartphones as they share common characteristics. This allows manufacturers to create new
blueprints more efficiently.
 Likewise, in object-oriented programming, developers can use many similar objects to create
blueprints. This is called a class.
Abstraction
 Abstraction is the essence used by developers to build classes. Developers observe a set of
similar objects and characteristics of importance to define classes.
 The abstraction of objects varies as per the application. For example, while defining a
smartphone class of users, developers might set attributes like color, features, price, etc.
However, for manufacturing firms, developers may set attributes containing such as the
manufacturing costs per smartphone, quality control, turnaround, etc.
Inheritance
 The concept of inheritance in object-oriented design defines the process of reusing 'objects.'
Developers can define a new class type using a similar existing class.
Object-oriented Implementation

 In this phase, developers translate the class objects and the interrelationships of classes and
code them using a programming language. This is the phase to create databases and establish
functionalities for the system.
 The object-oriented methodology focuses on identifying objects in the system. Developers
closely observe each object to identify characteristics and behavioral patterns. The
developers ensure that the object recognizes and responds perfectly to an event.
 Let's consider a smartphone screen as an object and the touch on a specific icon as an event.
Now, when the user touches an icon, the screen opens up an application. This means the
smartphone screen (object) responds to the event (touch) by opening an application.

Types of Models:

The object-oriented implementation methodology supports three basic models

1. Class Model:

 The class model shows all the classes present in the system. The class model shows the
attributes and the behavior associated with the objects.
 The class diagram is used to show the class model.
  The class diagram shows the class name followed by the attributes followed by the
functions or the methods that are associated with the object of the class.
 Goal in constructing class model is to capture those concepts from the real world that are
important to an application.

2. State Model:

 State model describes those aspects of objects concerned with time and the sequencing of
operations – events that mark changes, states that define the context for events, and the
organization of events and states.
 Actions and events in a state diagram become operations on objects in the class model.
 State diagram describes the state model.

[Link] Model:

 Interaction model is used to show the various interactions between objects, how the
objects collaborate to achieve the behavior of the system as a whole.
 The following diagrams are used to show the interaction model:
1. Use Case Diagram
2. Sequence Diagram
3. Activity Diagram

The object model describes the essential elements of a system. When all the models are combined, it
represents the complete function of the system.

Example:

Class diagram State transition diagram

Sequence diagram

1.6System Engineering
Computer Based Ssytem:
Is defined as set of arrangement of elements which are combined to perform a specific task ie.
Predefined goal. This predefined goal is achieved by processing information(when input is
given it is processed and output is produced).
The goal may be to support some business function or to develop a product that can be sold to
generate business revenues. To accomplish the goal, a computer based system makes use of
variety of system elements as follows.
1. Software
2. Hardware
3. People
4. Database
5. Documentation
6. Procedures
1. Software: Software is a computer program or set of instructions, data structures and
related documentation that serve to effect logical method, procedure or control that is
required.
2. Hardware: It is
Electronic device that provide computing capability,
The interconnectivity devices that enable the flow of data(ex:network switch,
telecommunication device),
Electromechanical devices(Sensors, motors , pumps) that provides external world
function.(Ex. Fire alarm system)
3. People: Users or operators of hardware and software.
4. Database: Large , organised collection of information that is accessed via software.
5. Documentation: Descriptive information that portrays the use and/or operation of
system. It is a hard copy or manual or report.(Ex: when u purchase anything manual is
associated with it)
6. Procedure: The steps that define the specific use of each of system element or the
procedure context in which the system resides.

These elements(software, hardware, people, database, documentation, procedure)

 combine in variety of ways to transform information

Example:
You are having a Robot. This robot is going to transform each and every command into
set of signals and these control signals cause some set of action.
Example:
Consider a factory automation system where multiple products or software is being
developed in bulk. It is going to have different levels of hierarchy.
At the lowest level of hierarchy, you are going to have control machines , the robots or
any data entry devices. Each of them is a component based system because it is going to
take input and produce output.
Within the control machines u r going to have any electromechanical hardware or
electronic staff will be there. Here the
Hardware- can be processor, memory, sensors
Software- Communication, machine control
Database- program
Documentation- manual, reports
Procedures- actions->task.
At the next level of hierarchy, we can have a manufacturing cell. Within this also it has
different computer based systems which has different elements of its own. Ex:
Computers, mechanical fixers, how to integrate the different elements with the software.

1.7 System Engineering Hierarchy

 It encompasses a collection of top down and bottom up method to navigate the hierarchy.
 System engineer narrows the focus of work as it moves downward in the hierarchy
 The system engineering process usually begins with a “world view.” That is, the entire
business or product domain is examined to ensure that the proper business or technology
context can be established.
 The world view is refined to focus more fully on specific domain of interest.
 Within a specific domain, the need for targeted system elements (e.g., data, software,
hardware, people) is analyzed.
 Finally, the analysis,design, and construction of a targeted system element is initiated.
 At the top of the hierarchy, a very broad context is established and, at the bottom, detailed
technical activities, performed by the relevant engineering discipline (e.g., hardware or
software engineering), are conducted.
1. World view:
 The system engineering process usually begins with a "world view," That is, the entire
business or product domain is examined to ensure that the proper business or technology
context can be established.
 Stated in a slightly more formal manner, the world view (WV) is composed of a set of
domains (Di), which can each be a system or system of systems in its own right.
WV = {D1, D2, D3, . . . , Dn}

2. Domain View
Each domain is composed of specific elements (Ej) each of which serves some role in
accomplishing the objective and goals of the domain or component:
Di = {E1, E2, E3, . . . , Em}

[Link] View
Finally, each element is implemented by specifying the technical components (Ck) that achieve the
necessary function for an element:
Ej = {C1, C2, C3, . . . , Ck}

[Link] View
In the software context, a component could be a computer program, a reusable program
component, a module, a class or object, or even a programming language statement. It is
important to note that the system engineer narrows the focus of work as he or she moves
downward in the hierarchy just described.

Example: Product Engineering System Hierarchy

System Modelling
System engineering is a modeling process. Whether the focus is on the world view or the detailed view,
the engineer creates models that
• Define the processes that serve the needs of the view under consideration.
• Represent the behavior of the processes and the assumptions on which the behavior is based.
• Explicitly define both exogenous and endogenous input3 to the model.
• Represent all linkages (including output) that will enable the engineer to better understand the view.

To construct a system model, the engineer should consider a number of restraining

factors
1. Assumptions
2. Simplification
3. Limitation
4. Constraints
5. Preferences
1. Assumptions:
 It reduce the number of possible permutations and variations, thus enabling a model to reflect
the problem in a reasonable manner.
 Example: consider a three-dimensional rendering product used by the entertainment industry to
create realistic animation. One domain of the product enables the representation of 3D human
forms. Input to this domain encompasses the ability to specify movement from a live human
actor, from video, or by the creation of graphical models. The system engineer makes certain
assumptions about the range of allowable human movement (e.g., legs cannot be wrapped
around the torso) so that the range of inputs and processing can be limited.
[Link]:
 It enable the model to be created in a timely manner.
  Example: consider an office products company that sells and services a broad range of copiers,
faxes, and related equipment. The system engineer is modeling the needs of the service
organization and is working to understand the flow of information that spawns a service order.
Although a service order can be derived from many origins, the engineer categorizes only two
sources: internal demand and external request. This enables a simplified partitioning of input
that is required to generate the service order.
[Link]:
 It help to bound the system.
 Example: an aircraft avionics system is being modeled for a next generation aircraft. Since the
aircraft will be a two-engine design, the monitoring domain for propulsion will be modeled to
accommodate a maximum of two engines and associated redundant systems.
[Link]:
 It will guide the manner in which the model is created and the approach taken when the model is
implemented.
 Example: the technology infrastructure for the three-dimensional rendering system described
previously is a single G4-based processor. The computational complexity of
problems must be constrained to fit within the processing bounds imposed by the processor.
[Link]:
 This indicates the preferred architecture for all data, functions, and technology.
 The preferred solution sometimes comes into conflict with other restraining factors.
 Yet, customer satisfaction is often predicated on the degree to which the preferred approach is
realized.
The resultant system model (at any view) may call for a completely automated solution, a semi-
automated solution, or a nonautomated approach. In fact, it is often possible to characterize models of
each type that serve as alternative solutions to the problem at hand. In essence, the system engineer
simply modifies the relative influence of different system elements (people, hardware, software) to
derive models of each type.

System Simulation
 In the late 1960s, R. M. Graham [GRA69] made a distressing comment about the way we build
computer-based systems: "We build systems like the Wright brothers built airplanes— build the
whole thing, push it off a cliff, let it crash, and start over again."
 Many computer-based systems interact with the real world in a reactive fashion.
 That is, real-world events are monitored by the hardware and software that form the computer-
based system, and based on these events, the system imposes control on the machines,
processes, and even people who cause the events to occur.
 Real-time and embedded systems often fall into the reactive systems category.
Problems/Complications in reactive systems
 The developers of reactive systems sometimes struggle to make them perform properly.
 It is difficult to predict the performance, efficiency, and behavior of such systems prior to
building them.
 If the system crashed due to incorrect function, inappropriate behavior, or
poor performance, we picked up the pieces and started over again.
 Many systems in the reactive category control machines and/or processes (e.g., commercial
aircraft or petroleum refineries) that must operate with an extremely high degree of reliability. If
the system fails, significant economic or human loss could occur. For this reason, the approach
described by Graham is both painful and dangerous.

Today, software tools for system modeling and simulation are being used to help to eliminate
surprises when reactive, computer-based systems are built. These tools are applied during the
system engineering process, while the role of hardware and software, databases and people is being
specified. Modeling and simulation tools enable a system engineer to "test drive" a specification of
the system.
1.8Verification and Validation
Verification and Validation is the process of investigating whether a software system
satisfies specifications and standards and fulfills the required purpose. Barry Boehm described
verification and validation as the following:
Verification: Are we building the product right?
Validation: Are we building the right product?
Verification
 Verification is the process of checking that software achieves its goal without any bugs.
 It is the process to ensure whether the product that is developed is right or not.
 It verifies whether the developed product fulfills the requirements that we have.
 Verification is simply known as Static Testing.
 Here are some of the activities that are involved in verification.
 Inspections
 Reviews
 Walkthroughs
 Desk-checking
Validation
 It is the process of checking the validation of the product i.e. it checks what we are
developing is the right product. it is a validation of actual and expected products.
 Validation Testing is known as Dynamic Testing in which we examine whether we have
developed the product right or not and also about the business needs of the client. Here are
some of the activities that are involved in Validation.
 Black Box Testing
 White Box Testing
 Unit Testing
 Integration Testing
 Verification is followed by Validation.

------------------------------------------------------------------------------------------------------