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
