Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

S E-1

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 46

Software and Software Engineering

2.1 The Nature of Software


2.2 Defining Software
2.3 Software Application Domains
2.4 Legacy Software
2.5 Software Engineering, Software Engineering Practice
2.6 The Software Process
2.7 The Essence of Practice
2.8 General Principles, Software Myths
What is software ?
Set of programs clubbed together to achieve particular goal
or objective
Write a
program/set Execute/deploy
of programs code
Location based searching

Output for the code .


Code to accomplish a task
Software in execution
Guess the difference between hardware and software
Nature of software/ Characteristics of software
 Software is not manufactured in traditional sense but they
are developed or engineered
 Software doesn’t get old or it does not ware out.
- After some period hardware use its components or
parts may suffer because of effects of extreme temperature,
dust and other types of environmental related problems
- Environmental conditions can not cause problem
to software
-During the lifecycle of software ,it has to undergo the
change. As the changes are made to the software ,there are
chances of errors getting introduced in it.
Software Application Domains
1) System software : operating systems, device drivers etc.

2)Application software : Google map, ERP


3)Engineering/Scientific software :MATLAB, AUTOCAD
4)Embedded software :keypad of microwave, washing machine
5)Web applications : e-commerce websites
6) Artificial intelligence software : Alexa
Legacy Software
 Some software's are old or even older. Ex. Software's
delivered to government, Industry or individuals.
 Theses older programs are known as Legacy Software.
 Legacy software systems are old software systems ,developed decades ago
and are continuously modified to meet changing computing platforms
and business requirement
 Organizations can face problems like costly maintenance and risk to get
evolved
 Most of the legacy software found supporting and useful for core business
functions they are indispensable to the business
Reasons legacy software's should get evolved over the period of time

 Need to be modified to cater the new requirements of user and


technology or computing environments
 Software need to be enhanced to implement new or future business
requirements
 To get join with the modern systems and database software should
be extended
 The software should be re-architecture or re-build to make viable or
workable within a network environment
What was the Software Crisis?
 It was in the late 1960s when many software projects failed.
 Many software became over budget. Output was an unreliable
 software which is expensive to maintain.
 Larger software was difficult and quite expensive to maintain.
 Lots of software not able to satisfy the growing requirements of the
customer.
 Complexities of software projects increased whenever its hardware
capability increased.
Why software Engineering
 To manage Large software
 For more Scalability
 Cost Management
 To manage the dynamic nature of software
 For better quality Management
Software Engineering

The application of a systematic ,disciplined, quantifiable approach to the


development ,operation and maintenance of software, in order to obtain
economically software that is reliable and works efficiently on real machines
Importance of Software Engineering
Software Process : Can be defined as collection of activities ,actions and task that are executed
While creating workproduct
Communication
 Before technical work begins, it is necessary to communicate and
Collaborate with the customers and other stakeholders too
 Intention behind communication is to know and understand exact
Objectives of stakeholders and to collect requirements that assist in
Defining software functions and features
Planning
 Software project plan defines the software engineering work that
Includes description of technical tasks to be conducted, the risks
involved ,required recourses ,the work product that needs to be
Created
Modeling
 During the modeling phase, the actual conceptualizing of the
solution is created, that is the detailed software architecture meeting
specific project requirements is created.
 During this phase, the whole structure of the project is built with
the final prototype
Construction
 This activity is a combination of code generation and the testing.
Code generation could be automated or manual.
 Coding is a programming activity that actually converts design of the
Software into executable programs or software. Testing is needed to
remove errors form the code
Deployment
 Deployment is delivering software completely or partially to the
customer.
 Customer uses ,evaluates the product and gives feedback based on
evaluation done
Umbrellas activities
 Umbrella activities are applicable throughout a project and it is a
Great help to the software team in managing and controlling risks,
change and quality
Umbrella Activities in software engineering
1.Software Project Tracking and Control
2.Formal Technical Reviews
3.Software Quality Assurance
4.Software Configuration Management
5.Document Preparation and Production
6.Re-usability Management
7.Measurement and Metrics
8.Risk Management
1. Software Project Tracking and Control
Before the actual development begins, a schedule for developing the software is created. Based
on that schedule the development will be done. However, after a certain period of time it is
required to review the progress of the development to find out actions which are in need to be
taken to complete the development, testing etc. in time. The outcome of the review might
require the development to be rescheduled.

2. Formal Technical Reviews


Software engineering is done in clusters or modules, after completing each module, it is good
practice to review the completed module to find out and remove errors so their propagation to
the next module can be prevented.
3. Software Quality Assurance
The quality of the software such as user experience, performance, load handling
capacity etc. should be tested and confirmed after reaching predefined milestones.
This reduces the task at the end of the development process. It should be
conducted by dedicated teams so that the development can keep going on.

4. Software Configuration Management


Software configuration management (SCM) is a set of activities designed to control
changes by identifying the work products that are likely to change, establishing
relationships among them, defining mechanisms for managing different versions of
these work products.
Document preparation and production
 All the project planning and other activities should be hardly copied and the production get
started here.
 Work products can be lists, log forms, models, documents etc

Re-usability Management
This includes the backing up of each part of the software project they can be corrected or any
kind of support can be given to them later to update or upgrade the software at user/time
demand.

Measurement & Metrics


This will include all the measurement of every aspects including project , process measures
that help software team in delivering software that help software team in delivering software
that satisfies stakeholders requirements
Measurement activity can be combined with other umbrella activities
Risk Management
Risk management is the series of steps that help a software team to understand
and manage uncertainty. It’s a really good idea to identify it, assess its probability
of occurrence, estimate its impact, and establish a contingency plan that─ ‘should
the problem actually occur’.
Risk Management
Risk management is the series of steps that help a software team to understand
and manage uncertainty. It’s a really good idea to identify it, assess its probability
of occurrence, estimate its impact, and establish a contingency plan that─ ‘should
the problem actually occur’.
The essence of practice
Following is an outline of problem solving
1) Understand the problem
 Understanding problems is most of the time difficult
 It may look simple to understand but practically overall
understanding of the problem is needed
 Following is the list of questions worth pondering
1) who are the stakeholders?
2)What functions, features and data will be needed to
solve the problem?
3) Can we divide problem in small parts ?
The essence of practice….
Following is an outline of problem solving
2) Plan the solution
 In this step it might assumed that we understood the problem
 Below questions can help to do better planning
1) Have you gone through same kind of a problem before this
project? Is there any existing software that includes functions,
feature and data that is required in the current Project
2) Can we find sub problems? Is yes, are the solutions to sub
problems clear?
3) can we represent a solution in a manner that leads to
effective implementation ?Can a design model be created?
The essence of practice….
Following is an outline of problem solving
3) Carry out the plan

 In previous step we made a kind of a road map to the system


that we want to build
 Below questions can help to do carry out the plan
1)Does plan will take us to a solution? Is source code as
per design model
2)Is every component part of the solution is correct? are
design and code reviewed
The essence of practice….
Following is an outline of problem solving
4) Examine the result
 We cannot claim that our solution is perfect. We could be
sure about the number of tests that we have designed to find
number of possible errors
 Following is the list questions that could be asked
1) Can we check and test every component of the solution ?
Have we implemented reasonable testing strategy?
2)Can solution produce outcome that will match the expected
data, functions and features? Is software validated against
requirements of all stakeholders?
General Principals
 Software Engineering core principle are vital for successful
software engineering process
 David Hooker has proposed seven core principles help us to
establish a mind-set of solid software engineering practice
Core principles that guide a software process
1) The reason at all exists

 The software can be called as complete software if it satisfies


all the requirements of customer.
 Hence before beginning a software project, be sure that the
software has a business purpose
Core principles that guide a software process
2) Keep it simple but perfect
 The design of software should be as simple as possible
 If there are too many interfaces in the system , its difficult to
construct and implement such type of system
 But it does not mean to skip the requirements
 Advantage of simple is system can maintained easily.
Core principles that guide a software process
3) Maintain the vision
 There should be integrity in thoughts of the people who work
on it towards the vision of project.
 A good architect can hold the vision and confirms very
successful software project
Core principles that guide a software process
4) What you produce ,others will consume it
 This principle states about the transparency of the software
project designing ,planning and development. There are
different teams which work on the same project but
participating in different activities
 In short members in the team may use the software, which is
analysed, designed and constructed by other persons in a
team
 Maintain the software or to extend it system must be
transparent enough
Core principles that guide a software process
5) Be open to the future
 The system with the long lifetime is always better and ,more
preferable
 While designing the software solution there should be a
question what if this question tries to find all the possibilities
which may occur in that context
 In short solution to every problem must be generalized and
not specific, so that it can be reused for other applications
Core principles that guide a software process
6) Plan ahead for reuse
 One of the good quality of software is reusability. The
reusable software can be used in the development of other
applications
 If reusable modules are available ,then system can be
developed very fast
 Due to reusability the time and efforts can be reduced
effectively
 There should be a plan that is ready for code and design
reusability
Core principles that guide a software process
7) Think
 The seventh principle is think, which is mostly ignored
 If we are having solution and we think for better solution the
better idea will come out. This can improve the quality of
system
 A complete thought before execution an action always
produce good results
Software Myths
Software myths are nothing but erroneous belief about
software.

A) Managers myths
1) Myth : there is already a book of standards and that will help
employees to do everything to accomplish the project
Reality : Book of standards is available but
 book may not contain complete content
 Contents of book may not adaptable
 May not facilitate approach which can ensure the delivery
within time with focus on quality
 May not explain modern software engineering approach
2 )Myth : If the project is behind the schedule more
programmers can be added
Reality :
 Software development is not manufacturing and it is not
mechanical process
 When people added at the later stage will make the project
later
 It takes time to train and educate new people ever, as new
people are added, people who were working must spend
time educating newcomers.
 We can add new people but after planning and coordination
3 )Myth : Manager feels that it the work is outsourced to third
party ,then he can be relaxed and the third party will build the
software
Reality :
 Understanding of managing and controlling project is
required, If organization do not understand this, it will always
struggle even if work is auto sourced
Software Myths
Software myths are nothing but erroneous belief about
software.

B ) Customer myths
1) Myth : To begin with the program, general statement of
objectives is enough to start. The details can be filled later on
Reality :
 If statement of objectives is ambiguous then it is recipe of
disaster
 Statements of objectives can be only formed through
iteration and with efficient and continuous communication
between developer and customer
2 ) Myth : Software requirements can be changed
continuously .But changes can be easily absorbed or
accommodate as software is flexible
Reality :
 Software requirement can change is the truth. But changes
made certain impact . Impact may vary depending on the
time when they are added to the software
 When changes are made or requested before design or code
the cost is small . But as time passes the cost gets increases
and projects becomes complicated
Software Myths
Software myths are nothing but erroneous belief about
software.

C) Practitioners Myths
1) Myth : Once the programme is done work is done
Reality : Industry statistics indicates that 60 to 8o of total
efforts are spent after product is delivered to the customer for
the first time
2) Myth : For the assessing the quality of the program it should
be in running state
Reality :
 Software quality assurance is a kind of mechanism that can
be used since project beginning till the end of the project
 Technical reviews helps at every stage of project
 Software reviews are kind of quality filter that needs to be
used
3) Myth : Working programme is only deliverable product
Reality :
 In practicality a working program is just one of the parts of
the software configuration
 A variety of work products provide a foundation for
successful engineering and more important guidance foe
software support
4) Myth : Creation of voluminous and unnecessary
documentation will be compelled by software engineers and
that will reduce the working speed
Reality :
 Creation documents is not a major part of software
engineering documentation is used to increase the quality
and reduce rework that will ensure delivery of the software
well within time

You might also like