SE-Unit-1-V-1

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

Unit - 1

Software is defined as: Instructions + Data Structures + Documents.


(1) instructions (computer programs) that when executed provide desired function and performance.
(2) A Data structure that enable the programs to adequately manipulate information.
(3) Documents that describe the operation and use of the programs.
Engineering is the process of designing and building something that serves a particular purpose.
Software Engineering is the application of engineering principles and techniques to design, develop, test,
deploy and maintain software systems. It involves a systematic approach to building software that meets
requirements, is reliable, efficient, and easy to maintain.

Software Characteristics:
To gain an understanding of software (and ultimately an understanding of software engineering), it is
important to examine the characteristics of software that make it different from other things that human
beings build. When hardware is built, the human creative process (analysis, design, construction, testing)
is ultimately translated into a physical form. If we build a new computer, our initial sketches, formal
design drawings, and breadboarded prototype evolve into a physical product (chips, circuit boards,
power supplies, etc.).

Software is a logical rather than a physical system element. Therefore, software has characteristics that
are considerably different than those of hardware:

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


Although some similarities exist between software development and hardware manufacture,
the two activities are fundamentally different.
=> In both activities, high quality is achieved through good design,
=> But the manufacturing phase for hardware can introduce quality problems that are non-existent (or
easily corrected) for software.

2. Software doesn't "wear out."


=> The Hardware exhibits relatively high failure rates early in its life, these failures are caused due to
design or manufacturing defects.
=> defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some
period of time.
=> Hardware components suffer from the cumulative effects (like Dust, vibration, abuse, temperature
extremes and other environmental issues).
=> The failure rate raises again, stated simply the hardware begins to “Wear Out”.
=> This is shown below using “Bath Tub Curve”.
Bath Tub Curve for Hardware Failure

Idealized Curve for Software Failure


Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory,
therefore, the failure rate curve for software should take the form of the “idealized curve” shown in
Figure 1.2. Undiscovered defects will cause high failure rates early in the life of a program. However,
these are corrected (ideally, without introducing other errors) and the curve flattens as shown.
3. Although the industry is moving toward component-based assembly, most software continues to
be custom built.
Consider the manner in which the control hardware for a computer-based product is designed and
built. The design engineer draws a simple schematic of the digital circuitry, does some fundamental
analysis to assure that proper function will be achieved, and then goes to the shelf where catalogs of
digital components exist. Each integrated circuit (called an IC or a chip) has a part number, a defined
and validated function, a well-defined interface, and a standard set of integration guidelines. After
each component is selected, it can be ordered off the shelf.
Changing Nature of Software:
Information content and determinacy are important factors in determining the nature of a software
application. Content refers to the meaning and form of incoming and outgoing information.
1) System software: System software is a collection of programs written to service other programs.
Some system software process complex, but determinate, information structures.
Ex: compilers, editors, and file management utilities.
Other system application processes largely indeterminate data. Sometimes when, the system software
area is characterized by the heavy interaction with computer hardware that requires scheduling,
resource sharing, and sophisticated process management.
Ex: operating system components, drivers, telecommunications.
Note=> It is a interaction between Hardware and Application software
Ex: Windows, Linux, Android, macOS

2) Application Software: Application software is defined as programs that solve a specific business
need. Application in this area processes business or technical data in a way that facilitates business
operation or management technical decision-making. In addition to conventional data processing
applications, application software is used to control business functions in real-time.

Ex: Word, Excel, PPT, Calculator, browsers like Firefox, Chrome, Social media apps, Gaming apps,
Banking apps, Shopping aps, Booking apps.

3) Engineering and Scientific Software: This software is used to facilitate the engineering function
and task. however modern applications within the engineering and scientific area are moving away
from conventional numerical algorithms. Computer-aided design, system simulation, and other
interactive applications have begun to take a real-time and even system software characteristic.

Ex: Weather prediction apps, Stock market apps, Stress analysis, Body measurement apps, CAD,
Scientific Calculator, MATLAB

4) Embedded Software: Embedded software resides within the system or product and is used to
implement and control features and functions for the end-user and for the system itself. Embedded
software can perform limited and esoteric functions or provide significant function and control
capability.

Ex: Microwave ovens, Washing machines, ATMs, Card swipe machines, Smart watch, Fitness tracker

5) Product-line Software: Designed to provide a specific capability for use by many customers,
product-line software can focus on the limited and esoteric marketplace or address the mass consumer
market.

6) Web Application: It is a client-server computer program that the client runs on the web browser. In
their simplest form, Web apps can be little more than a set of linked hypertext files that present
information using text and limited graphics. However, as e-commerce and B2B applications grow in
importance. Web apps are evolving into a sophisticated computing environment that not only provides
a standalone feature, computing function, and content to the end user.
Ex: All websites i.e Google, Gmail, Google Drive, Google Docs, YouTube, Facebook, Instagram..

7) Artificial Intelligence Software: Artificial intelligence software makes use of a nonnumerical


algorithm to solve a complex problem that is not amenable to computation or straightforward analysis.
Applications within this area include robotics, expert systems, pattern recognition, artificial neural
networks, theorem proving, and game playing.

Ex: Chatbots, ChatGPT, Google Assistant, Alexa, Google-Gemini, etc…

Software engineering layers:


Software Engineering: The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to software.
In software engineering, 'Layered Technology' is a fundamental system design principle. This approach
segments a software system into distinct layers, each with its dedicated responsibility.

1. 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. The bedrock that supports software
engineering is a quality focus.

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. Such as
Communication, Planning, Designing, Development, Testing, Deployment, Maintenance.

3. Methods: During the process of software development the answers to all “how-to-do” questions are given by
method. Methods encompass a broad array of tasks that includes communication, requirements analysis, design
modelling, program construction, testing, and support. Software engineering methods rely on a set of basic
principles that govern each area of the technology and include modelling 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.
The Software Process Frame Work:

A Software Process Framework is a structured approach that defines the steps, tasks, and activities
involved in software development. This framework serves as a foundation for software engineering,
guiding the development team through various stages to ensure a systematic and efficient process. A
Software Process Framework helps in project planning, risk management, and quality assurance by
detailing the chronological order of actions.

Every process needs a particular order or sequence that must be followed to keep things right. This
system of following a particular sequence is a software engineering framework. It illustrates a detailed
guide within a framework on how to go about the application. The software engineer frameworks
include process activity, umbrella activity, and task sets.

It includes task sets, umbrella activities, and process framework activities, all essential for a successful
software development lifecycle. Utilizing a well-defined Software Process Framework enhances
productivity, consistency, and the overall quality of the software product

• Task: This is a specified goal that has been elaborated.


• Action: This section discusses what must be done to achieve the elaborated task.
• Activities: Within this section, all the minor or related procedures are illustrated to achieve the
action and the task.
Process Framework Activities
A process framework is a basic structure where all the activities are described in detail to achieve the
task. This is further divided into five generic software engineering framework activities for a better
approach and to ensure that no detail is missed.
1. Communication
2. Planning
3. Modelling
4. Construction
5. Deployment

1. Communication
Communication is the most basic yet important step in the software engineering framework. Here,
the software engineer and the user or the client discuss the functioning of the application. It is important
to note down all the details. Even if a small detail is missed or ignored, it may cause a problem in the
later steps.
 The software development starts with the communication between Client and Developer.
 Developer gather the requirements of the project with Client.
 Communication with consumers and stakeholders to determine the systems objectives,
software requirements and features.

2. Planning
Planning is a more technical part of the software engineering frameworks. It requires the engineer to
formulate a work plan that shall be successful and fool proof. It also contains a list of all the
requirements and risks. Further, it has a detailed timetable on how work shall be scheduled ahead.
=> It consists of complete estimation, scheduling, for project development and tracking.
=> Discuss work plan, technical risk, list of resource requirements, work schedule and work produced.

3. Modelling
A model is designed with the help of analysing the data collected and the rough plan for the
framework software engineering. This helps get a rough idea of how the application would function. It
also helps significantly identify any loopholes or problems the application may have.
=> Develop a practical model to get a better understanding of the project.
=> It consists of complete requirement analysis and design of the project in Algorithm and Flowchart.
=> The algorithm is the step-by-step solution of the problem.
Ex: Login Module -> 1) Enter User Name 2) Enter Password 3) Click on Login Button
=> The Flow chart shows a complete flow diagram of a program
Ex: After clicking on Login Button which page will be open.
=> If changes are required, we implement them in this step.

4. Construction
Construction is the step where the application is generated with the help of a code. The application is
also tested, and all the identified bugs or glitches are fixed. This is also known as software design
mapping.
=> Construction consists of code generation and the testing part.
=> Coding part implements the design using an appropriate programming language.
=> Testing is to check whether the flow of coding is correct or not.
=> Testing also check that the program provides desired output.
5. Deployment
=> Deployment step consists of delivering the product to the client and take feedback from the client.
=> If the client wants some corrections or demands for the additional capabilities, then the change is
required for improvement in the quality of the software.

Umbrella Activities
While developing software, it is important to write the correct code. It is equally important to take
measurements to track the development of the application and make the necessary changes for any
improvement that might be needed. These framework activities in software engineering fall under the
category of umbrella activities.
1) Software Project Tracking and Control
2) Risk Management
3) Software Quality Assurance
4) Formal Technical Reviews
5) Software Configuration Management
6) Measurement

1) Software Project Tracking and Control


The framework of the project is well planned, keeping in mind the time frame and deadlines.
However, the deadlines are also committed to the client or the user.
Therefore, it is equally important to stand by this timing. Software project tracking is a measure taken
by software engineers to track and control the timing and schedule of the project.
=> Project Manager will check that whether project is running as per the deadline or not.
2) Risk Management
Risk management, as the name suggests, involves analysing the potential risks of the application in
terms of quality or outcome. These risks may create a drastic impact on the outcome and the
functionality of the application.
The main goal of risk management is to predict possible risks and find solutions to deal with them
successfully

3) Software Quality Assurance


Testing the quality of the software is necessary. It helps to determine how the application will do
when used or launched in the market. On quality testing, the client is assured that everything in the
application went as planned. This is known as the software quality framework in software engineering.
4) Formal Technical Reviews
Evaluation of errors is done at every step of the generic process framework for software engineering.
This helps to eliminate a major blunder at the end of the process.
The software engineers check their work for technical and quality issues and find technical bugs or
glitches. Step-wise error analyses help in the smooth functioning of software development.
5) Software Configuration Management
The software configuration process helps in managing the application when changes are necessary.
6) Measurement
The software engineers collect relevant data that is analysed to measure the quality and
development of the application.

Software Myths:
Software Myths are false beliefs that do not have any pure evidence. Software myths may lead to many
misunderstandings, unrealistic expectations, and poor decision-making in software development
projects. Some common software myths include

1) Management Myths
2) Customer / Client Myths
3) Developer / Practitioner Myths

Management Myths: Managers with software responsibility, like managers in most disciplines, are
often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a
drowning person who grasps at a straw, a software manager often grasps at belief in a software
myth, if that belief will lessen the pressure (even temporarily)
Myth-1: We already have a book that's full of standards and procedures for building software, won't that
provide my people with everything they need to know? (Available Standards and Procedures are
enough)
Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its
existence? Does it reflect modern software engineering practice? Is it complete? Is it streamlined to
improve time to delivery while still maintaining a focus on quality? In many cases, the answer to all of
these questions is "no."
Myth-2: If I decide to outsource the software project to a third party, I can just relax and let that firm
build it.
Reality: If an organization does not understand how to manage and control software projects internally,
it will invariably struggle when it outsources software projects.
Myth-3: We can add workers when we get behind the schedule.
Reality: 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.

Customer myths. A customer who requests computer software may be a person at the next desk, a
technical group down the hall, the marketing/sales department, or an outside company that has requested
software under contract. In many cases, the customer believes myths about software because software
managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the
customer) and ultimately, dissatisfaction with the developer.
Myth1: A general statement of objectives is sufficient to begin writing programs we can fill in the details
later.
Reality: A poor up-front definition is the major cause of failed software efforts. A formal and detailed
description of the information domain, function, behaviour, performance, interfaces, design constraints,
and validation criteria is essential.
Myth2: Project requirements continually change, so change can be easily accommodated because
software is flexible.
Reality: 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.
Developer Myths. Myths that are still believed by software practitioners have been fostered by 50 years
of programming culture. During the early days of software, programming was viewed as an art form. Old
ways and attitudes die hard.
Myth1: Once we write the program and get it to work, our job is done.
Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll take you to get done."
Industry data ([LIE80], [JON91], [PUT97]) indicate that between 60 and 80 percent of all effort expended
on software will be expended after it is delivered to the customer for the first time.
Myth2: Until I get the program "running" I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied from the
inception of a project—the formal technical review. Software reviews are a "quality filter" that have been
found to be more effective than testing for finding certain classes of software defects.

You might also like