SE-Unit-1-V-1
SE-Unit-1-V-1
SE-Unit-1-V-1
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:
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..
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
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
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.