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.
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.
Fritz Bauer, a German computer scientist, defines software engineering as:
Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and work efficiently on real machines.

Characteristics of good software

A software product can be judged by what it offers and how well it can be used. This software
must satisfy on the following grounds:

 Operational
 Transitional
 Maintenance
Well-engineered and crafted software is expected to have the following characteristics:

Operational
This tells us how well software works in operations. It can be measured on:

 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety
Transitional
This aspect is important when the software is moved from one platform to another:

 Portability
 Interoperability
 Reusability
 Adaptability
Maintenance
This aspect briefs about how well a software has the capabilities to maintain itself in the ever-
changing environment:
  Modularity
 Maintainability
 Flexibility
 Scalability

Software Development Life Cycle(SDLC)

The systems development life cycle is also known as the application development life-cycle. It is
a method which is used in systems engineering, information systems, and software engineering
to define a procedure for analyzing, developing, testing and deploying a software project. There
are six stages in this cycle: Planning and analysis, Defining Requirements, Implementation,
Developing, Testing, Deployment, and Maintenance.

The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

It is the first phase in SDLC. It is performed by the seniors of the team. They work on the inputs
from the customers, market surveys of the industry. After that, this information is used to plan
the project approach. Then senior members conduct the feasibility study in the economical,
operational and technical areas.

The outcome of the feasibility study is to define the approaches which can be followed to
implement the project successfully.

Stage2: Defining Requirements

When the requirement analysis is complete, the next phase is defining requirements. In this
phase, the team clearly explain and document the project requirements and get them approved
from the customer and market surveys. The whole process finished through SRS( Software
Requirement Specification).

Stage3: Designing the Architect

The next phase is about to bring down all the knowledge of requirements, analysis and design of
the software project. This phase is the product of the last two phases like inputs from the
customer and requirement gathering.

Stage4: Developing the project

The actual development starts in this phase of SDLC. The implementation of design begins
concerning writing code. High-level languages such a C, C++, Pascal, Java and PHP used for
coding. The programming language selection depends on the type of software which is going to
developed.

Stage5: Testing

This one is the last phase of SDLC before the software is handover to the customers. The testers
purpose to search defects within the system as well as verifying whether the application performs
as expected and according to what documented in the requirements analysis phase.

This cycle repeated until all the requirements tested and all the defects have fixed, and the
software is ready to be shipped.

Stage6: Deployment and Maintenance

When the software tested, and no issues or error remain in the software, it is time to deploy to
production where the customer can use the software.

When a version of the software is free to production, there is usually a maintenance team that
looks after any post-production problems.

Requirement Engineering

The process to collect the software requirements from customers, analyze and document them is
referred to as requirement engineering.

The primary purpose of requirement engineering is to develop and maintain the delicate and
descriptive 'System Requirements Specification' document.

Requirement Engineering Process:

It is a four-step process, which includes -

1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing the software that
is acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:
 1. Technical Feasibility - Technical feasibility evaluates the current technologies, which
are needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the required
software performs a series of levels to solve business problems and customer
requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can
generate financial profits for an organization.

2. Requirement Gathering:

After the feasibility study, the report of the feasibility study is positive towards the project then,
next phase starts with collect requirements from the customers. In this phase, the analyst and
engineer interact with a client and end-users to know their demands on what the project should
provide and what features they want the software to include.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software analyst

after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Prerequisite of Software requirements:

Collection of software requirements is the basis of the entire software development project.
Hence they should be clear, correct and well-defined.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
 o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized into two categories:

1. Functional Requirements:Functional requirements define a function that a system or

system element must be qualified to perform and must be documented in different forms.
The functional requirements are describing the behaviour of the system as it correlates to
the system's functionality.
2. Non-functional Requirements:This can be the necessities that specify the criteria that
can be used to decide the operation instead of specific behaviours of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run time.
o Evolution qualities like testability, maintainability, extensibility, and scalability
that embodied in the static structure of the software system.
Inputs for writing Experiment 1: FORWARD ENGINEERING

Scope and Objectives of Project

Understand the project objectives

In order to define the scope of a project, it is necessary to first establish the project objectives.
The objective of a project may be to produce a new product, create a new service to provide
within the organisation, or develop a new bit of software. There are any number of objectives
that could be central to a given project - and it is the role of the project manager to see that their
team or contractors deliver a result that meets the specified functions and features.
How do you define the project scope?

The work and resources that go into the creation of the product or service are essentially the
things that frame the scope of the project. The scope of the project outlines the objectives of the
project and the goals that need to be met to achieve a satisfactory result. Every project manager
should understand how to define the project scope and there are some steps that can be followed
when doing this.
Steps for defining the scope of a project

To define a project scope, first identify the following things:

 Project objectives
 Goals
 Sub-phases
 Tasks
 Resources
 Budget
 Schedule

Once you've established these things, you'll then need to clarify the limitations or parameters of
the project and clearly identify any aspects that are not to be included. In specifying what will
and will not be included, the project scope must make clear to the stakeholders, senior
management and team members involved, what product or service will be delivered. Alongside
of this, the project scope should have a tangible objective for the organisation that is undertaking
the project. Understanding the scope provides you with the foundations for managing project
change and risk management. It enables goal setting and a timeline to work towards, as well as
key points for reporting on the progress of the project to senior management and other
stakeholders.

Module Specfication

A module is logically separable part of a program. It is a program unit, identifiable with respect
to compiling and loading .A module can be a function, process or packages.
To produce modular design, some criteria must be followed to select modules so that they
support well defined abstractions .

Coupling and cohesion are two modularizing techniques.

Coupling: Coupling attempts to capture “how strongly” different modules are interconnected.

Cohesion: They are involved in determining how closely the elements in a module are related to
each other.

Data Dictionary

The Data Dictionary provides a detailed accounting of all tables found within the user/designer-
created database. The data dictionary contains all the attribute names and characteristics for each
table in the system. It contains meta data –data about data. It is sometimes described as “the
database designer’s database “because it records the design decisions about tables and their
structures.
It is a collection of descriptions of the data objects or items in a data model for the benefit of
programmers and others who need to refer to them. A first step in analyzing a system of objects
with which users interact is to identify each object and its relationship to other objects. This
process is called data modeling and results in a picture of object relationships. After each data
object or item is given a descriptive name, its relationship is described (or it becomes part of
some structure that implicitly describes relationship), the type of data (such as text or image or
binary value) is described, possible predefined values are listed, and a brief textual description is
provided. This collection can be organized for reference into a book called a data dictionary.
When developing programs that use the data model, a data dictionary can be consulted to
understand where a data item fits in the structure, what values it may contain, and basically what
the data item means in real-world terms.
Modeling using Unified Modeling Language

1. Model

 A model is a simplification of reality.

 A model provides the blueprints of a system.

 A model may be structural, emphasizing the organization of the system,

or it may be behavioral, emphasizing the dynamics of the system.

 We build models so that we can better understand the system we are

developing.

 We build models of complex systems because we cannot comprehend

such a system in its entirety.

Through modeling, we achieve four aims.

 Models help us to visualize a system as it is or as we want it to be.

 Models permit us to specify the structure or behavior of a system.

 Models give us a template that guides us in constructing as system.

 Models document the decisions we have made

2. Principles of Modeling

 The choice of what models to create has a profound influence on how

a problem is attacked and how a solution is shaped

 Every model may be expressed at different levels of precision

 The best models are connected to reality

  No single model is sufficient. Every nontrivial system is best
approached through a small set of nearly independent models

3. Unified Modeling Language (UML)

The UML is a language for

 Visualizing

 Specifying

 Constructing

 Documenting

The UML is a Language

A modeling language is a language whose vocabulary and rules focus on the conceptual and
physical representation of a system

The UML is a Language for Visualizing

 Some programmers think of an implementation and then

code it. Some programmers think mentally i.e. they even sketch out a few ideas on a
paper. That means some things are best modeled textually, others are best modeled
graphically. The UML is such a graphical language.

The UML is a Language for Specifying

 Specifying means building models. It specifies of all the important analysis,

design, and implementation decisions that must be made in developing a software
project.

The UML is a Language for constructing

 The UML is not a visual programming language, but its

models can be directly connected to a variety of a programming language. This
means that it is possible to map from a model in the UML to a programming
language such as Java, C++.

The UML is a Language for Documenting

A Healthy software organization produces all sorts of artifacts in addition to raw executable
code. These artifacts include
1. Requirements
2. Architecture
 3. Design
4. Source code
5. Project plans
6. Tests
7. Releases

4. Architectural views of UML

The UML addresses the documentation of a system’s architecture and all of its detail.

The Use Case view

- Use Case Diagram – It shows a set of use cases and actors and their relationships.

The Design view

- Class Diagram – it shows a set of classes, interfaces and collaborations and their
relationships.

- Object Diagram – it shows a set of objects and their relationships.

The Interaction view

- Sequence Diagram – it is an Interaction diagram that emphasizes the time ordering

of messages.

- Collaboration diagram – it is an Interaction diagram that emphasizes the structural

organization of the objects that send and receive messages.

- State Diagram – it shows a state machine, consisting of states, transitions, events and
activities. It illustrates the dynamic view of a system.

-Activity Diagram – it shows the flow from step to step within a computation. It
illustrates the dynamic view of a system.

The Implementation view

- Component Diagram – it shows the internal parts, connectors and ports that implement a
component.

The Deployment view

Deployment Diagram – It captures the configuration of the runtime elements of the

application .
UML Diagrams

UML is made up of nine diagrams that can be used to model a system at different points of time
in the software life cycle of a system. The nine UML diagrams are:

 Use case diagram: The use case diagram is used to identify the primary elements and
processes that form the system. The primary elements are termed as "actors" and the
processes are called "use cases." The use case diagram shows which actors interact with
each use case.
 Class diagram: The class diagram is used to refine the use case diagram and define a
detailed design of the system. The class diagram classifies the actors defined in the use
case diagram into a set of interrelated classes. The relationship or association between the
classes can be either an "is-a" or "has-a" relationship. Each class in the class diagram may
be capable of providing certain functionalities. These functionalities provided by the class
are termed "methods" of the class. Apart from this, each class may have certain
"attributes" that uniquely identify the class.
 Object diagram: The object diagram is a special kind of class diagram. An object is an
instance of a class. This essentially means that an object represents the state of a class at a
given point of time while the system is running. The object diagram captures the state of
different classes in the system and their relationships or associations at a given point of
time.
 State diagram: A state diagram, as the name suggests, represents the different states that
objects in the system undergo during their life cycle. Objects in the system change states
in response to events. In addition to this, a state diagram also captures the transition of the
object's state from an initial state to a final state in response to events affecting the
system.
 Activity diagram: The process flows in the system are captured in the activity diagram.
Similar to a state diagram, an activity diagram also consists of activities, actions,
transitions, initial and final states, and guard conditions.
 Sequence diagram: A sequence diagram represents the interaction between different
objects in the system. The important aspect of a sequence diagram is that it is time-
ordered. This means that the exact sequence of the interactions between the objects is
represented step by step. Different objects in the sequence diagram interact with each
other by passing "messages".
 Collaboration diagram: A collaboration diagram groups together the interactions
between different objects. The interactions are listed as numbered interactions that help to
trace the sequence of the interactions. The collaboration diagram helps to identify all the
possible interactions that each object has with other objects.
 Component diagram: The component diagram represents the high-level parts that make
up the system. This diagram depicts, at a high level, what components form part of the
system and how they are interrelated. A component diagram depicts the components
culled after the system has undergone the development or construction phase.
 Deployment diagram: The deployment diagram captures the configuration of the
runtime elements of the application. This diagram is by far most useful when a system is
built and ready to be deployed.
UML Diagram Classification—Static, Dynamic, and Implementation

A software system can be said to have two distinct characteristics: a structural, "static" part and a
behavioral, "dynamic" part. In addition to these two characteristics, an additional characteristic
that a software system possesses is related to implementation.

 Static: The static characteristic of a system is essentially the structural aspect of the
system. The static characteristics define what parts the system is made up of.
 Dynamic: The behavioral features of a system; for example, the ways a system behaves
in response to certain events or actions are the dynamic characteristics of a system.
 Implementation: The implementation characteristic of a system is an entirely new
feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

 Static
o Use case diagram
o Class diagram
 Dynamic
o Object diagram
o State diagram
o Activity diagram
o Sequence diagram
o Collaboration diagram
 Implementation
o Component diagram
o Deployment diagram

Representations

Types of Things

Name Symbol Description Variations/

other related
elements

Description of a set of - actors

objects that share the
Class same: attributes, - signals
operations, - utilitie
relationships and
semantics.

Interface A collection of
operations that specify
a service of a class or
component.
Collaborat An interaction and a
ion society or roles and
other elements that
work together to
provide some
cooperative behavior
that is bigger than the
sum of all the elements.
Represent
implementation of
patterns that make up
the system.

Actor The outside entity that

communicates with a
system, typically a
person playing a role or
an external device

Use Case A description of set of

sequence of actions that
a system performs that
produces an observable
result of value to a
particular actor. Used
to structure behavioural
things in the model.

Active A class whose objects

class own a process or
execution thread and
therefore can initiate a
control activity on their
own
Componen A component is a
t physical and replicable
part that conforms to
and provides the
realization of a set of
interfaces.

Node A physical resource

that exists in run time
and represents a
computational
resource.

Interactio Set of messages

n exchanged among a set
of objects within a
particular context to
accomplish a specific
purpose.

State A behavior that

machine specifies the sequences
of states an object or an
interaction goes
through during its
lifetime in response to
events, together with its
responses to those
events.

Packages General purpose

mechanism of
organizing elements
into groups.
 Note A symbol for rendering
notes and constraints
attached to an element
or a collection of
elements.

Relationships are used to connect things into well defined models (UML diagrams).