Download software engineering notes and more Study notes Software Engineering in PDF only on Docsity!
UNIT I
SOFTWARE PRODUCT AND PROCESS
1.0 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
1.1 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).
"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
1.2 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
The V & V process
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.
1.3 Life Cycle models
o The waterfall model Separate and distinct phases of specification and development.
o Evolutionary development Specification, development and validation are interleaved.
o Component-based software engineering The system is assembled from existing components.
o There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design. Waterfall model phases
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase. Waterfall model
Waterfall model problems
o Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. o Therefore, this model is only appropriate when the requirements are well- understood and changes will be fairly limited during the design process. o Few business systems have stable requirements. o The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. Evolutionary development
o Exploratory development
o Applicability For small or medium-size interactive systems; For parts of large systems (e.g. the user interface); For short-lifetime systems. Incremental development
Incremental development advantages
Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing.
Spiral development
Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process.
Spiral model of the software process
RAD MODEL:
1.4 BUSINESS PROCESS ENGINEERING
o Concerned with re-designing business processes to make them more responsive and more efficient o Often reliant on the introduction of new computer systems to support the revised processes o May force software re-engineering as the legacy systems are designed to support existing processes
LISTEN TOWARDS THE CUSTOMER
REUSE / REBUILD MOCK-UP
CUSTOMER TEST DRIVES MOCK - UP
The re-engineering process
Re-engineering approaches
1.5 SYSTEM ENGINEERING
What is a system?
o A purposeful collection of inter-related components working together towards some common objective.
The systems engineering process
1.6 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 system makes 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 of
data, 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 the procedural 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.
1.7 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) o Identify and design key features o Select 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
UNIT II
SOFTWARE REQUIREMENTS
2.1Requirement Engineering Process
Software Requirements Specification(SRS):
The s/w requirement and specification focuses on what the system will do, not how the system will be implemented. It is produced as the culmination of the s/w requirements analysis task in the lifecycle model. You must analyze the information domain, the function, performance and behavior and interface requirement of the system. Software requirements can be specified in the following ways.
representation format and content should be relevant to the problem information contain within the specification should be nested. Representations should be revisable. s/w requirements specification produced at the culmination of the analysis task. This also states the goal and objectives of the s/w. information description provides a detailed description of the problem that the s/w must solve. Functional description is a description of each function required to the solve the problem. Behavioral description section of the specification examines the operation of the s/w as a consequence of external events and internally generated control characteristics. Validation criteria is the most important and ironically the most often neglected section of requirements specification. Functional vs. non functional requirements (i) functional requirements: statements of services the systems should provide, how the system should react to particular inputs and how the systems should behave in particular situations. (ii) Non functional requirements: constraints on the services or functions offered by the system such as timing constraints, constrains on the development process, standards etc., 2.1.1Requirement engineering process:
Requirement engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need accessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification and managing the requirements as they are transformed into an operational system. The requirement engineering process can be described in five distinct steps.
requirement elicitation requirement analysis and negotiation requirement specification system modeling requirement validation requirement management
2.2 software prototyping:
A model of s/w to be built is called a prototype. A prototype is constructed for customer and developer assessment.
(i) selecting a prototyping approach:
the prototyping paradigm can be either close ended or open ended
the close ended approach also called throw away prototyping. Using this a prototype serves as a rough demonstration of requirements.
an open ended approach, called evolution of the prototyping uses the prototype as the first part of an analysis activity that will be continued into design and construction.
Before a close ended or open ended approach can be chosen, it is necessary to determine whether the system to be built is amenable to prototyping.
Prototyping factors are application area, application complexity, customer characteristics and project characteristics.
(ii) prototyping s/w process:
in common with other types of s/w development, the prototyping process follows a define s/w process model.
This model indicated the processes and tasks, which have to be performed during development of the prototype.
Process model device for this particular approach comprise the following stages.
- analysis requirements: This involved the developer understanding the content and nature of the customer’s initial requirements.
