SPPM Notes 1
SPPM Notes 1
SPPM Notes 1
Department of CSE
UNIT I
SOFTWARE PROJECT AND PROCESS MANAGEMENT
INTRODUCTION
SOFTWARE:
Software is a set of instruction used to perform a specific task.
ENGINEERING:
It comprises analysis,design,construction,verification and management of technical
entities.
SOFTWARE ENGINEERING:
IEEE: International Electrical and Electronic Engineer
It is a systematic,disciplined,quantifiable approach for the development,operation,maintenance of
software.
SOFTWARE ENGINEERING PARADIGM:
A combination of software engineering layers and generic view of software engineering is
called Software Engineering Paradigm.
SOFTWARE ENGINEERING LAYERS:
Tools
Methods
Process
Quality
SOFTWARE VIEW OF SOFTWARE ENGINEERING:
1.Analysis
2.Design
3.Implementation
4.Testing
5.Maintenance
SOFTWARE PROCESS MODELS:
Waterfall life cycle model
RAD model
Prototype model
Spiral model
Incremental model
Object oriented model
Winwin spiral model
S/W Engineering Paradigm
The term "software engineering" was coined in about 1969 to mean "the establishment and
use of sound engineering principles in order to economically obtain software that is reliable and works
efficiently on real machines".
This view opposed uniqueness and "magic" of programming in an effort to move the
development of software from "magic" (which only a select few can do) to "art" (which the
talented can do) to "science" (which supposedly anyone can do!). There have been numerous
definitions given for software engineering (including that above and below).
Software Engineering is not a discipline; it is an aspiration, as yet unachieved. Many
approaches have been proposed including reusable components, formal methods, structured methods
and architectural studies. These approaches chiefly emphasize the engineering product; the solution
rather than the problem it solves.
Software Development current situation:
People developing systems were consistently wrong in their estimates of time, effort, and costs
Reliability and maintainability were difficult to achieve
Delivered systems frequently did not work
1979 study of a small number of government projects showed that:
2% worked
3% could work after some corrections
45% delivered but never successfully used
20% used but extensively reworked or abandoned
30% paid and undelivered
Fixing bugs in delivered software produced more bugs
Increase in size of software systems
NASA
StarWars Defense Initiative
Social Security Administration
financial transaction systems
Changes in the ratio of hardware to software costs
early 60's - 80% hardware costs
middle 60's - 40-50% software costs
today - less than 20% hardware costs
Increasingly important role of maintenance
Fixing errors, modification, adding options
Cost is often twice that of developing the software
Advances in hardware (lower costs)
Advances in software techniques (e.g., users interaction)
Increased demands for software
Medicine, Manufacturing, Entertainment, Publishing
Demand for larger and more complex software systems
Airplanes (crashes), NASA (aborted space shuttle launches),
"ghost" trains, runaway missiles,
ATM machines (have you had your card "swallowed"?), life-support systems, car
systems, etc.
US National security and day-to-day operations are highly dependent on computerized
systems.
Manufacturing software can be characterized by a series of steps ranging from concept exploration to
final retirement; this series of steps is generally referred to as a software lifecycle.
Steps or phases in a software lifecycle fall generally into these categories:
Requirements (Relative Cost 2%)
Specification (analysis) (Relative Cost 5%)
Design (Relative Cost 6%)
Implementation (Relative Cost 5%)
Testing (Relative Cost 7%)
Integration (Relative Cost 8%)
Maintenance (Relative Cost 67%)
Retirement
Software engineering employs a variety of methods, tools, and paradigms.
Paradigms refer to particular approaches or philosophies for designing, building and maintaining
software. Different paradigms each have their own advantages and disadvantages which make one
more appropriate in a given situation than perhaps another (!).
A method (also referred to as a technique) is heavily depended on a selected paradigm and may be
seen as a procedure for producing some result. Methods generally involve some formal notation and
process(es).
Tools are automated systems implementing a particular method.
Thus, the following phases are heavily affected by selected software paradigms
Design
Implementation
Integration
Maintenance
The software development cycle involves the activities in the production of a software system.
Generally the software development cycle can be divided into the following phases:
Requirements analysis and specification
Design
Preliminary design
Detailed design
Implementation
Component Implementation
Component Integration
System Documenting
Testing
Unit testing
Integration testing
System testing
Installation and Acceptance Testing
Maintenance
Bug Reporting and Fixing
Change requirements and software upgrading
Software lifecycles that will be briefly reviewed include:
Build and Fix model
Waterfall and Modified Waterfall models
Rapid Prototyping
Boehm's spiral model
VERIFICATION VS VALIDATION
Verification:
"Are we building the product right"
The software should conform to its specification
Validation:
"Are we building the right product"
The software should do what the user really requires
Is a whole life-cycle process - V & V must be
applied at each stage in the software process.
Has two principal objectives
o The discovery of defects in a system
o The assessment of whether or not the system is usable in an
operational situation.
Static and dynamic verification
Software inspections Concerned with analysis of
the static system representation to discover problems (static verification)
o May be supplement by tool-based document and code analysis
Software testing Concerned with exercising and
observing product behaviour (dynamic verification)
o The system is executed with test data and its operational behaviour is observed
V& V goals
Verification and validation should establish confidence that the software is fit for purpose
This does NOT mean completely free of defects
Rather, it must be good enough for its intended use and the type of use will determine the
degree of confidence that is needed
V & V planning
Careful planning is required to get the most out of testing and inspection processes
Planning should start early in the development process
The plan should identify the balance between static verification and testing
Test planning is about defining standards for the testing process rather than describing
product tests
The V-model of development
Software validation
o Verification and validation (V & V) is intended to show that a system conforms to its
specification and meets the requirements of the system customer.
o Involves checking and review processes and system testing.
o System testing involves executing the system with test cases that are derived from the
specification of the real data to be processed by the system.
Life Cycle models
o The waterfall model
Little scope for iteration between phases because hardware changes are very
expensive. Software may have to compensate for hardware problems
o Inevitably involves engineers from different disciplines who must work together
Much scope for misunderstanding here. Different disciplines use a
different vocabulary and much negotiation is required. Engineers may
have personal agendas to fulfil.
The systems engineering process
COMPUTER-BASED SYSTEMS
Definition
A set or arrangement of elements that are organized to accomplish some predefined goal by
processing information.
The goal may be to support some business function or to develop a product that can be sold
to generate business revenue. To accomplish the goal, a computer-based systemmakes use of a
variety of system elements:
Software. Computer programs, data structures, and related documentation that serve to effect
the logical method, procedure, or control that is required.
Hardware. Electronic devices that provide computing capability, the interconnectivity
devices (e.g., network switches, telecommunications devices) that enable the flow ofdata,
and electromechanical devices (e.g., sensors, motors, pumps) that provide external world
function.
People.Users and operators of hardware and software.
Database.A large, organized collection of information that is accessed via
software.Documentation.Descriptive information (e.g., hardcopy manuals, on-line help files,
Web sites) that portrays the use and/or operation of the system.
Procedures.The steps that define the specific use of each system element or theprocedural
context in which the system resides.
The elements combine in a variety of ways to transform information. For example, a marketing
department transforms raw sales data into a profile of the typical purchaser of a product; a robot
transforms a command file containing specific instructions into a set of control signals that cause some
specific physical action. Creating an information system to assist the marketing department and control
software to support the robot both require system engineering.
Product Engineering Overview
Product Engineering
Product engineering is a crucial term in the sphere of software development. It is through product
engineering that the future of a product is decided. The purpose of software Product Engineering is to
consistently and innovatively perform a well-defined engineering process that integrates all software
engineering activities to effectively and efficiently develop correct, consistent software products.
Software Engineering tasks include analyzing the system requirements allocated to software, developing
software architecture, designing the software, implementing the software in the code, integrating
software components, and testing the software to verify whether it specifies specific requirements.
Product Conceptualization Engineering
o Write product marketing/business requirements specifications (MRS, BRS, PRD),
system requirements specifications and functional specifications (SRS, FS)
oIdentify and design key
featuresoSelect architecture and
design o Provide UI prototypes
Product Architecture Consulting
o Construct the technology foundations needed to build robust products
o Consult on Enterprise Application Integration, Distributed Computing, Transaction
Management
o Select architectural styles and patterns
Product Design and Implementation