Software Engineering Course Instructor: Aisha Azeem Types of Software Applications  System software: such management utilities as compilers, editors, file  Application software: stand-alone programs for specific needs.  Engineering/scientific software: Characterized.

Download Report

Transcript Software Engineering Course Instructor: Aisha Azeem Types of Software Applications  System software: such management utilities as compilers, editors, file  Application software: stand-alone programs for specific needs.  Engineering/scientific software: Characterized.

Software Engineering
Course Instructor: Aisha Azeem
Types of Software
Applications
 System software: such
management utilities
as
compilers,
editors,
file
 Application software: stand-alone programs for specific
needs.
 Engineering/scientific software: Characterized by “number
crunching ” algorithms. such as automotive stress analysis,
molecular biology, orbital dynamics etc
 Embedded software resides within a product or system. (key
pad control of a microwave oven, digital function of
dashboard display in a car)
Types of Software
Applications
 Product-line software focus on a limited marketplace to
address mass consumer market. (word processing, graphics,
database management)
 WebApps (Web applications) network centric software. As
web 2.0 emerges, more sophisticated computing
environments is supported integrated with remote database
and business applications.
 AI software uses non-numerical algorithm to solve complex
problem. Robotics, expert system, pattern recognition game
playing
FAQ about software
engineering
Question
Answer
What is software?
Computer programs, data structures and associated
documentation. Software products may be
developed for a particular customer or may be
developed for a general market.
What are
software?
the
attributes
of
What is software engineering?
good Good software should deliver the required
functionality and performance to the user and
should be maintainable, dependable and usable.
Software engineering is an engineering discipline
that is concerned with all aspects of software
production.
What is the difference between Computer science focuses on theory and
software engineering and computer fundamentals; software engineering is concerned
science?
with the practicalities of developing and delivering
useful software.
What is the difference between System engineering is concerned with all aspects of
software engineering and system computer-based systems development including
engineering?
hardware, software and process engineering.
Software engineering is part of this more general
process.
Essential attributes of good
software
Product characteristic
Description
Maintainability
Software should be written in such a way so that it can
evolve to meet the changing needs of customers. This is a
critical attribute because software change is an inevitable
requirement of a changing business environment.
Dependability and
security
Software dependability includes a range of characteristics
including reliability, security and safety. Dependable
software should not cause physical or economic damage in
the event of system failure. Malicious users should not be
able to access or damage the system.
Efficiency
Software should not make wasteful use of system resources
such as memory and processor cycles. Efficiency therefore
includes responsiveness, processing time, memory utilisation,
etc.
Acceptability
Software must be acceptable to the type of users for which
it is designed. This means that it must be understandable,
usable and compatible with other systems that they use.
Software Engineering
 In order to build software that meets challenges of 21st
century, following must be recognized:
 Understand the problem before you build a solution
 Design is a pivotal software engineering activity
 Both quality and maintainability are an outgrowth of
good design
How do we define software
engineering?
 Software engineering is a layered technology:
A Layered Technology
 A quality Process
 Any engineering approach must rest on an quality.
 The "Bed Rock" that supports software Engineering is Quality
focus
 Process
 Foundation for SE is the Process Layer
 SE process is the GLUE that holds all the technology layers
together and enables the timely development of computer
software.
 It forms the base for management control of software project
in which:
 technical methods are applied, work products(models,
documents, data , reports, forms etc)are produced,
milestones, quality is ensured & change is properly
managed.
A Layered Technology
 Methods
 SE methods provide the "Technical Questions" for
building Software.
 Methods contain a broad array of tasks that include
communication, requirement analysis, design, modeling,
program construction, testing and support.
 Tools
 SE tools provide automated or semi-automated support
for the "Process" and the "Methods".
 Tools are integrated so that information created by one
tool can be used by another.
Elements of Software
Process
 Process is a collection of:
 Activities
 Strives to achieve a broad objectives e.g.
 communication with stakeholders regardless of
project size, application domain, complexity of effort
Elements of Software
Process
 Actions
 Consists of set of tasks that produces a major work
product i.e.
 Architectural design model
 Task
 Focuses on small , but well defined objectives e.g.
 Conducting an unit test to produce tangible
outcomes
The Software Process
 In software engineering, a process is not a rigid prescription
for how to build computer software
 Rather, it is adaptable approach that enables
people(software teams) to pick and choose appropriate
work actions & tasks
 The intent is to deliver the software in time and with quality
to satisfy those who sponsored its creation and those who
will use it(customers).
Software process framework
activities
 Five generic process framework activities are:
 Communication
 communicate with customer to understand objectives and gather
requirements
 Planning
 creates a “map” defines the work by describing the tasks, risks and
resources, work products and work schedule.
 Modeling
 Create a “sketch”, what it looks like architecturally, how the
constituent parts fit together and other characteristics.
 Construction
 code generation and the testing
 Deployment
 Delivered to the customer who evaluates the products and
provides feedback based on the evaluation.
Cont . . .
 These five framework activities can be used to all software
development regardless of the application domain, size of
the project, complexity of the efforts etc, though the details
will be different in each case.
 For many software projects, these framework activities are
applied iteratively as a project progresses.
 Each iteration produces a software increment that provides
a subset of overall software features and functionality.
Software Myths
 Describes a number of common beliefs or myths that
software managers, customers, and developers believe
falsely
 Misleading attitudes that have caused serious problems for
managers and practitioners
Management Myths
 Managers with software responsibility, like management in
most disciplines, are often under pressure to maintain:
 Budgets
 Keep schedules
 Improve quality
 To lessen the pressure the software mangers often grasp at
beliefs in software myths.
Management’s Myths
 Myth: "We already have a book that is full of standards and
procedures for building software. Won't that provide my
people with everything they need to know?"
 Reality: the book standards may exist,




but is it used?
Are the practitioners aware of its existence?
Is it up to date and complete?
Is it streamlined to deliver on time and still maintain quality?
 Not used, not up to date, not complete, not focused on
quality, time, and money
Cont . . .
 Myth: "If we get behind, we can add more programmers
and catch up"
 Reality: software development is not a mechanistic process
like manufacturing.
 Adding people to a late software project makes it later
 Training time to newcomers, reduced productive
development effort.
 Myth:"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 that how to
manage and control s/w projects internally.
 It will always struggle when it outsource software
projects.
Customer’s Myths
 A customer who requests computer software




May be a person at the next desk
A technical group
Marketing /sales department
Or outside company
 Customers believes myths about software because S/w managers and
practitioners do little to correct misinformation.
 Myths lead to false expectation and ultimately dissatisfaction with the
developer.
Customer’s Myths
g432222432
 Myth:"A general statement of objectives is sufficient to begin
writing programs – we can fill in the details later“
 Reality: although a comprehensive and stable statement
of requirement is not always possible
 Ambiguous statement of objectives spells disaster
 Unambiguous requirement are developed via effective and
continuous communication between the customer and developer.
 Myth:"Project requirements continually change, but change
can be easily accommodated because software is flexible"
 Impact of change depends on where and when it
occurs in the software life cycle (requirements analysis,
design, code, test)
Practitioner's myths
 Myths that are still believed by software practitioners have
been forwarded by over 50 years culture.
 Early days programming was viewed as an art form.
 Old ways and attitude die hard
Practitioner’s Myth
 Myth:"Once we write the program and get it to work, our job is
done"
 60% to 80% of all effort spent on software occurs after it is delivered to
customer.
 Myth:"Until I get the program running, I have no way of assessing its
quality
 Formal technical reviews of requirements analysis documents, design
documents, and source code (more effective than actual testing)
 Myth:"The only deliverable work product for a successful project is
the working program"
 Software, documentation, test drivers, test results
 Myth:"Software engineering will make us create voluminous and
unnecessary documentation and will invariably slow us down"
 Creates quality, quality reduces rework and provides software on time
and within the budget
Phases in Software
Development
 When ever we develop a program or build something,
there are some activities we perform.
 Requirement Analysis
 Design
 Coding
 Testing
Software Engineering
 For large software's where the problem solving activities
may last for many years and where many people are
involved in development, performing theses activities
without proper documentation will not work.
 In most commercial software developments there are some
activities performed before the analysis requirement takes
place called feasibility analysis phase in order to calculate
cost and profit.
Software Engineering
Requirement Analysis
 Requirement analysis is done in order to understand the
problem which the software system is to solve.
 The problem could be automating an existing manual system
or developing a new system
 For large system where there are a lot of features,
understanding the requirement is a major problem.
Software Engineering
 In this phase the emphasis is given on identifying what is
needed from the system and not how the system will
achieve the goals
 Two parties are involved in this process
 A client ………… A developer
Software Engineering
 There are two major activities in this phase
 Problem understanding or analysis and requirement
specification (software Requirement specification)
 This phase ends with the validation of the requirements
specified in the document.
Software Engineering
 Software Design
 The purpose of the design phase is to plan a solution of
the problem specified by the requirement document.
 Design stage takes us towards how to satisfy the needs.
 Most important part of the software
 Blue print of the software
Software Engineering
 The design activity is often divided into two parts
 System design
 Detailed design
 This phase produces a design document
 Partitioning and Abstraction
 Validation
Software Engineering
 Coding
 The goal of this phase is to translate the design into a
code in a given Language
 The coding phase affects both the testing and maintenance
phase.
 Single entry------Single exit construct
Software Engineering
 Testing
 Testing is the major control measure employed during
software development
 Its basic purpose is to detect errors in the software.
 Unit testing
 Integration testing
 System Testing
Software Engineering
 For testing to be successful, proper selection of test cases
are essential.
 Test Plan:
 It identifies all the testing activities that must be
performed and specifies the schedule, cost, resources,
different units to be tested and the manner in which all
the modules will be integrated, different test cases etc.
Software Engineering
 Maintenance
 It is not a part of software development but extremely
important activity in software product.
 It always start after the software is delivered to the customer
 Two major forms of maintenance are
 Adaptive maintenance
 Corrective maintenance
Cont . . .
 Adaptive maintenance:
 Over time the original environment e.g OS, CPU or other
business rules for which the software was developed is
likely to change.
 So adaptive maintenance results in modification of s/w
to accommodate such changes to its external
environment.
 Corrective maintenance
 When the customer is using the software he is likely to
uncover defects and the correction of such changes will
come under corrective maintenance.