Scribd
Upload
68 views

UNIT-I: Software Engineering & Process Models: Dual Role of Software

Software can serve as both a product and a vehicle to deliver other products. It provides computing functions and controls other programs. Software engineering involves developing instructions and data structures to manipulate information as described in documentation. Unlike hardware, software is developed rather than manufactured and does not wear out over time. The nature of software is constantly changing with new types of applications emerging. Legacy software tends to have poor quality due to issues like convoluted code and documentation. Software engineering uses processes, methods, tools, and a quality focus to effectively develop software.

Uploaded by

Ansh Goel
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
68 views

UNIT-I: Software Engineering & Process Models: Dual Role of Software

Software can serve as both a product and a vehicle to deliver other products. It provides computing functions and controls other programs. Software engineering involves developing instructions and data structures to manipulate information as described in documentation. Unlike hardware, software is developed rather than manufactured and does not wear out over time. The nature of software is constantly changing with new types of applications emerging. Legacy software tends to have poor quality due to issues like convoluted code and documentation. Software engineering uses processes, methods, tools, and a quality focus to effectively develop software.

Uploaded by

Ansh Goel
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

UNIT-I: Software Engineering & Process Models

Dual Role of Software


• Both a product and a vehicle for delivering a product
– Product
• Delivers computing potential
• Produces, manages, acquires, modifies, display, or transmits information
– Vehicle
• Supports or directly provides system functionality
• Controls other programs (e.g., operating systems)
• Effects communications (e.g., networking software)
Helps build other software (e.g., software tools)
A Definition of Software
• Instructions (computer programs) that when executed provide desired features, function,
and performance
• Data structures that enable the programs to adequately manipulate information
• Documents that describe the operation and use of the programs
Differences between Software and Hardware
• Software is developed or engineered; it is not manufactured in the classical sense
– Impacts the management of software projects
• Software doesn't wear out
– Hardware bathtub curve compared to the software ascending spiked curve
• Industry is moving toward component-based construction, most software continues to be
custom built
– it is still complex to build
– Reusable components are created so that engineers can concentrate on innovative
elements of a design
– User interfaces are built with reusable components
– The data structures and processing details are kept in a library for interface
construction
Hardware Failure Curve
Software Failure Curve

Changing Nature of Software


• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software (e.g., inventory control, word processing, multimedia)
• Web applications
• Artificial intelligence software
• Ubiquitous computing (small, wireless devices)
• Netsourcing (net-wide computing)
• Open source (operating systems, databases, development environments)
• The ".com" marketing applications
Legacy Software – Characteristics
• Support core business functions
• Have longevity and business criticality
• Exhibit poor quality
– Convoluted code, poor documentation, poor testing, poor change management
Reasons for Evolving the Legacy Software
• (Adaptive) Must be adapted to meet the needs of new computing environments or more
modern systems, databases, or networks
• (Perfective) Must be enhanced to implement new business requirements
• (Corrective) Must be changed because of errors found in the specification, design, or
implementation
Software Myths – Management
• "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?"
– Not used, not up to date, not complete, not focused on quality, time, and money
• "If we get behind, we can add more programmers and catch up"
– Adding people to a late software project makes it later
– Training time, increased communication lines
• "If I decide to outsource the software project to a third party, I can just relax and let that
firm build it"
– Software projects need to be controlled and managed
Software Myths – customer
• "A general statement of objectives is sufficient to begin writing programs – we can fill in the
details later"
– Ambiguous statement of objectives spells disaster
• "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)
Software Myths - Practitioner
• "Once we write the program and get it to work, our job is done"
– 60% to 80% of all effort expended on software occurs after it is delivered
• "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)
• "The only deliverable work product for a successful project is the working program"
– Software, documentation, test drivers, test results
• "Software engineering will make us create voluminous and unnecessary documentation and
will invariably slow us down"
– Creates quality, not documents; quality reduces rework and provides software on
time and within the budget
Software Engineering is a Layered Technology

• A Quality Focus
– Engineering approach must rely on quality
– Total Quality Management (TQM), six sigma leads to continuous improvement in
culture.
– This culture ultimately helps to develop more effective approaches to SE.
• Process
– Provides the glue that holds the layers together;
– enables balanced and timely development;
– provides a framework for effective delivery of technology;
– forms the basis for management; provides the context for technical methods, work
products, milestones, quality measures, and change management
• Methods
– Provide the technical "how to" for building software;
– rely on a set of basic principles;
– encompass a broad array of tasks; include modeling activities
• Tools
– Provide automated or semi-automated support for the process and methods (i.e.,
CASE tools)
Generic Process Framework
• Communication
– Involves communication among the customer and other stake holders; encompasses
requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better understand the requirements and the
design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback

You might also like