1
LECTURE NOTES
ON
SOFTWARE ENGINEERING
B.Tech IV Semester
Ms. B DHANALAXMI
Assistant Professor
Mr. A.PRAVEEN
Assistant Professor
INFORMATION TECHNOLOGY
INSTITUTE OF AERONAUTICAL ENGINEERING
(Autonomous)
DUNDIGAL, HYDERABAD - 500 043
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Lecture Notes on Software Engineering, Lecture notes of Software Engineering
Lecture notes on software engineering for B.Tech IV semester students. The course covers software process and project management, requirements analysis and specification, software design, testing and implementation, and project management. The objective of the course is to enable students to learn how to elicitate requirements and develop software life cycles, understand the design considerations for enterprise integration and deployment, analyze quality assurance techniques and testing methodologies, and prepare a project plan for a software project. The document also includes the syllabus and features of software.
Typology: Lecture notes
2021/2022
1 / 142
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Lecture Notes on Software Engineering and more Lecture notes Software Engineering in PDF only on Docsity!
LECTURE NOTES
ON
SOFTWARE ENGINEERING
B.Tech IV Semester
Ms. B DHANALAXMI
Assistant Professor
Mr. A.PRAVEEN
Assistant Professor
INFORMATION TECHNOLOGY
INSTITUTE OF AERONAUTICAL ENGINEERING
(Autonomous)
DUNDIGAL, HYDERABAD - 500 043
SYLLUBUS
IV Semester: IT | V Semester: CSE
Course Code Category (^) Hours / Week Credits Maximum Marks
ACS008 Core
L T P C CIA SEE Total 3 1 - 4 30 70 100 Contact Classes: 45 Tutorial Classes: 15 Practical Classes: Nil Total Classes: 60
OBJECTIVES: The course should enable the students to: I. Learn how to elicitate requirements and develop software life cycles. II. Understand the design considerations for enterprise integration and deployment. III. Analyze quality assurance techniques and testing methodologies. IV. Prepare a project plan for a software project that includes estimates of size and effort, a schedule, resource allocation, configuration control, and project risk.
UNIT-I SOFTWARE PROCESS AND PROJECT MANAGEMENT Classes: 08
Introduction to software engineering, software process, perspective and specialized process models; Software project management: Estimation: LOC and FP based estimation, COCOMO model; Project scheduling: Scheduling, earned value analysis, risk management.
UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION Classes: 09
Software requirements: Functional and nonfunctional, user requirements, system requirements, software requirements document; Requirement engineering process: Feasibility studies, requirements elicitation and analysis, requirements validation, requirements management; Classical analysis: Structured system analysis, petri nets, data dictionary.
UNIT-III SOFTWARE DESIGN Classes: 09
Design process: Design concepts, design model, design heuristic, architectural design architectural styles, architectural design, and architectural mapping using data flow.
User interface design: Interface analysis, interface design; Component level design: Designing class based components, traditional components.
UNIT-IV TESTING AND IMPLEMENTATION Classes: 10
Software testing fundamentals: Internal and external views of testing, white box testing, basis path testing, control structure testing, black box testing, regression testing, unit testing, integration testing, validation testing, system testing and debugging; Software implementation techniques: Coding practices, refactoring.
UNIT-V PROJECT MANAGEMENT Classes: 09
Estimation: FP based, LOC based, make/buy decision; COCOMO II: Planning, project plan, planning process, RFP risk management, identification, projection; RMMM: Scheduling and tracking, relationship between people and effort, task set and network, scheduling; EVA: Process and project metrics.
UNIT- I: Software process and project management: Introduction to software engineering, software process, perspective and specialized process models; Software project management: Estimation: LOC and FP based estimation, COCOMO model; Project scheduling: Scheduling, earned value analysis, risk management.
Introduction to software engineering
What is Software?
The product that software professionals build and then support over the long term.
Software encompasses:
I. Instructions (computer programs) that when executed provide desired features, function, and performance; II. Data structures that enable the programs to adequately store and manipulate information and III. Documentation that describes the operation and use of the programs.
Software products
Generic products Stand-alone systems that are marketed and sold to any customer
Who wishes to buy them? Examples – PC software such as editing, graphics programs, project management tools; CAD software; software for specific markets such as appointments systems for dentists. Customized products Software that is commissioned by a specific customer to meet their own needs. Examples – embedded control systems, air traffic control software, traffic monitoring systems.
Why Software is Important?
The economies of ALL developed nations are dependent on software. More and more systems are software controlled (transportation, medical, telecommunications, military, industrial, entertainment, etc…) Software engineering is concerned with theories, methods and tools for professional software development. Expenditure on software represents a significant fraction of Gross national product (GNP) in all developed countries.
Features of Software
Its characteristics that make it different from other things human being build. Features of such logical system: Software is developed or engineered; it is not manufactured in the classical sense which has quality problem. Software doesn't "wear out.‖ but it deteriorates (due to change). Hardware has bathtub curve of failure rate ( high failure rate in the beginning, then drop to steady state, then cumulative effects of dust, vibration, abuse occurs). Although the industry is moving toward component-based construction (e.g. standard screws and off-the-shelf integrated circuits), most software continues to be custom-built. Modern reusable components encapsulate data and processing into software parts to be reused by different programs. E.g. graphical user interface, window, pull-down menus in library etc.
Software Applications
I. System software: such as compilers, editors, file management utilities II. Application software: stand-alone programs for specific needs. III. Engineering/scientific software: Characterized by ―number crunching‖ algorithms. such as automotive stress analysis, molecular biology, orbital dynamics etc IV. Embedded software resides within a product or system. (key pad control of a microwave oven, digital function of dashboard display in a car) V. Product-line software focus on a limited marketplace to address mass consumer market. (word processing, graphics, database management) VI. WebApps (Web applications) network centric software. As web 2.0 emerges, more sophisticated computing environments is supported integrated with remote database and business applications. VII. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert system, pattern recognition game playing
Software Engineering Definition
The seminal definition:
[Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.
The IEEE definition:
Software Engineering:
(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
(2) The study of approaches as in (1).
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.
Umbrella Activities
Complement the five process framework activities and help team manage and control progress, quality, change, and risk.
- Software project tracking and control: assess progress against the plan and take actions to maintain the schedule.
- Risk management: assesses risks that may affect the outcome and quality.
- Software quality assurance: defines and conduct activities to ensure quality.
- Technical reviews: assesses work products to uncover and remove errors before going to the next activity.
- Measurement: define and collects process, project, and product measures to ensure stakeholder‘s needs are met.
- Software configuration management: manage the effects of change throughout the software process.
- Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components.
- Work product preparation and production: create work products such as models, documents, logs, forms and lists.
Adapting a Process Model
The process should be agile and adaptable to problems. Process adopted for one project might be significantly different than a process adopted from another project. (to the problem, the project, the team, organizational culture). Among the differences are:
- the overall flow of activities, actions, and tasks and the interdependencies among them
- the degree to which actions and tasks are defined within each framework activity
- the degree to which work products are identified and required
- the manner which quality assurance activities are applied
- the manner in which project tracking and control activities are applied
- the overall degree of detail and rigor with which the process is described
- the degree to which the customer and other stakeholders are involved with the project
- the level of autonomy given to the software team
- the degree to which team organization and roles are prescribed
Software Process: A Generic Process Model
- A framework for the activities, actions, and tasks that are required to build high-quality software.
- SP defines the approach that is taken as software is engineered.
- Is not equal to software engineering, which also encompasses technologies that populate the process – technical methods and automated tools.
- A Generic process model
A generic process framework for software engineering defines five framework activities- communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities- project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others are applied throughout the process. Next question is: how the framework activities and the actions and tasks that occur within each activity are organized with respect to sequence and time? See the process flow for answer.
Process Flow
- Linear process flow executes each of the five activities in sequence.
- An iterative process flow repeats one or more of the activities before proceeding to the next.
Process Pattern Types
- Stage patterns — defines a problem associated with a framework activity for the process. It includes multiple task patterns as well. For example, Establishing Communication would incorporate the task pattern Requirements Gathering and others.
- Task patterns — defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice
- Phase patterns — define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature. Example includes Sprial Model or Prototyping.
An Example of Process Pattern
- Describes an approach that may be applicable when stakeholders have a general idea of what must be done but are unsure of specific software requirements.
- Pattern name. Requirement Unclear
- Intent. This pattern describes an approach for building a model that can be assessed iteratively by stakeholders in an effort to identify or solidify software requirements.
- Type. Phase pattern
- Initial context. Conditions must be met (1) stakeholders have been identified; (2) a mode of communication between stakeholders and the software team has been established; (3) the overriding software problem to be solved has been identified by stakeholders ; (4) an initial understanding of project scope, basic business requirements and project constraints has been developed.
- Problem. Requirements are hazy or nonexistent. Stakeholders are unsure of what they want.
- Solution. A description of the prototyping process would be presented here.
- Resulting context. A software prototype that identifies basic requirements. (modes of interaction, computational features, processing functions) is approved by stakeholders. Following this, 1. This prototype may evolve through a series of increments to become the production software or 2. the prototype may be discarded.
- Related patterns. Customer Communication, Iterative Design, Iterative Development, Customer Assessment, Requirement Extraction.
Process Assessment and Improvement
- The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer‘s needs, or that it will exhibit the technical characteristics that will lead to long-term quality characteristics.
- A number of different approaches to software process assessment and improvement have been proposed over the past few decades:
- Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five-step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis for assessment [SEI00].
- CMM-Based Appraisal for Internal Process Improvement (CBA IPI) — provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment [Dun01].
- SPICE (ISO/IEC15504) — a standard that defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process [ISO08].
- ISO 9001:2000 for Software — a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies [Ant06].
Prescriptive Process Models
- Classic Process Models
- Waterfall Model (Linear Sequential Model)
- Incremental Process Models
- Incremental Model
- Evolutionary Software Process Models
- Prototyping
- Spiral Model
- Concurrent Development Model
- Classic Process Models - Waterfall Model (Linear Sequential Model)
- The waterfall model, sometimes called the classic life cycle.
- It is the oldest paradigm for Software Engineering. When requirements are well defined and reasonably stable, it leads to a linear fashion
- The waterfall model, sometimes called the classic life cycle, suggests a systematic,
- sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software.
A variation of waterfall model depicts the relationship of quality assurance actions to the actions associated with communication, modeling and early code construction activates.
provide capability that serves the user and also provide a platform for evaluation by the user.
- Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project
- Evolutionary Software Process Models
- Prototyping
- Spiral Model
- Concurrent Development Model
- Software system evolves over time as requirements often change as development proceeds. Thus, a straight line to a complete end product is not possible. However, a limited version must be delivered to meet competitive pressure.
- Usually a set of core product or system requirements is well understood, but the details and extension have yet to be defined.
- You need a process model that has been explicitly designed to accommodate a product that evolved over time.
- It is iterative that enables you to develop increasingly more complete version of the software.
- Two types are introduced, namely Prototyping and Spiral models.
Evolutionary Models: Prototyping
- When to use: Customer defines a set of general objectives but does not identify detailed requirements for functions and features. or Developer may be unsure of the efficiency of an algorithm, the form that human computer interaction should take.
- What step: Begins with communication by meeting with stakeholders to define the objective, identify whatever requirements are known, outline areas where further definition is mandatory. A quick plan for prototyping and modeling (quick design) occur. Quick design focuses on a representation of those aspects the software that will be visible to end users. (interface and output). Design leads to the construction of a prototype which will be deployed and evaluated. Stakeholder‘s comments will be used to refine requirements.
- Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately. However, engineers may make compromises in order to get a prototype working quickly. The less- than-ideal choice may be adopted forever after you get used to it.
Prototyping can be problematic for the following reasons:
- Stakeholders see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you hasn‘t considered overall software quality or long-term maintainability.
- As a software engineer, you often make implementation compromises in order to get a prototype working quickly.
- An inappropriate operating system or programming language may be used simply because it is available and known;
- An inefficient algorithm may be implemented simply to demonstrate capability. After a time, you may become comfortable with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system
Evolutionary Models: The Spiral
- It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model and is a risk-driven process model generator that is used to guide multi- stakeholder concurrent engineering of software intensive systems.
- Two main distinguishing features: one is cyclic approach for incrementally growing a system‘s degree of definition and implementation while decreasing its degree of risk. The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
- A series of evolutionary releases are delivered. During the early iterations, the release might be a model or prototype. During later iterations, increasingly more complete version of the engineered system are produced.
- The first circuit in the clockwise direction might result in the product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software.
Specialized Process Models
Specialized process models take on many of the characteristics of one or more of the traditional models. However, these models tend to be applied when a specialized or narrowly defined software engineering approach is chosen.
- Component-Based Development
- The Formal Methods Model
- Aspect-Oriented Software Development
- Component-Based Development:
Commercial off-the-shelf (COTS) software components, developed by vendors who offer them as products, provide targeted functionality with well-defined interfaces that enable the component to be integrated into the software that is to be built.
These components can be as either conventional software modules or object-oriented packages or packages of classes
Steps involved in CBS are
- Available component-based products are researched and evaluated for the application domain in question.
- Component Integration issues are considered.
- A software architecture is designed to accommodate the components
- Components are integrated into the architecture
- Comprehensive testing is conducted to ensure proper functionality
- Component-based development model leads to software reuse and reusability helps software engineers with a number of measurable benefits
- Component-based development leads to a 70 percent reduction in development cycle time, 84 percent reduction in project cost and productivity index of 26.2 compared to an industry norm of 16.
- Formal Methods Model
- Formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software
- They enable software engineers to specify, develop and verify a computer-based system by applying a rigorous mathematical notation
- Development of formal models is quite time consuming and expensive
- Extensive training is needed in applying formal methods
- Difficult to use the model as a communication mechanism for technically unsophisticated customers
- Aspect-oriented Software Development
- The aspect-oriented approach is based on the principle of identifying common program code within certain aspects and placing the common procedures outside the main business logic
- The process of aspect orientation and software development may include modeling, design, programming, reverse-engineering and re-engineering;
- The domain of AOSD includes applications, components and databases;
- Interaction with and integration into other paradigms is carried out with the help of frameworks, generators, program languages and architecture-description languages (ADL).
The Unified process, personal and team process models
- The Unified Process is an iterative and incremental development process. Unified Process divides the project into four phases 1. Inception 2. Elaboration 3. Construction 4. Transition
- The Inception, Elaboration, Construction and Transition phases are divided into a series of time boxed iterations. (The Inception phase may also be divided into iterations for a large project.)
- Each iteration results in an increment , which is a release of the system that contains added or improved functionality compared with the previous release.
- Although most iterations will include work in most of the process disciplines ( e.g. Requirements, Design, Implementation, Testing) the relative effort and emphasis will change over the course of the project.
- Risk Focused
- The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first. Risk Focused
- Inception Phase
- Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it is usually an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process.
- The following are typical goals for the Inception phase.
- Establish a justification or business case for the project
- Establish the project scope and boundary conditions
- Outline the use cases and key requirements that will drive the design tradeoffs
- Outline one or more candidate architectures
- Identify risks
- Prepare a preliminary project schedule and cost estimate
- The Lifecycle Objective Milestone marks the end of the Inception phase.
- Elaboration Phase
- During the Elaboration phase the project team is expected to capture a majority of the system requirements. The primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture.
- Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams).
- Integration throughout the process of software development, in theory sounds a good thing. But on particularly big projects with multiple development streams it will only add to the confusion and cause more issues during the stages of testing
Personal and Team process models
- The best software process is one that is close to the people who will be doing the work. The PSP model defines five framework activities.
- Personal Software Process (PSP)
Planning. This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created.
High-level design. External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.
High-level design review. Formal verification methods (Chapter 21) are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.
Development. The component-level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.
Postmortem. Using the measures and metrics collected, the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
- Team Software Process (TSP): The goal of TSP is to build a ―self directed‖ project team that organizes itself to produce high-quality software. TSP objectives are,
- Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20 engineers.
- Show managers how to coach and motivate their teams and how to help them sustain peak performance.
- Accelerate software process improvement by making CMM23 Level 5 behavior normal and expected.
- Provide improvement guidance to high-maturity organizations.
- Facilitate university teaching of industrial-grade team skills.
Software project management: Estimation
Estimation is attempt to determine how much money, effort, resources & time it will take to build a specific software based system or project. Estimation involves answering the following questions:
- How much effort is required to complete each activity?
- How much calendar time is needed to complete each activity?
- What is the total cost of each activity?
Project cost estimation and project scheduling are normally carried out together. The costs of development are primarily the costs of the effort involved, so the effort computation is used in both the cost and the schedule estimate.
Do some cost estimation before detailed schedules are drawn up. These initial estimates may be used to establish a budget for the project or to set a price for the software for a customer.
There are three parameters involved in computing the total cost of a software development project:
- Hardware and software costs including maintenance
- Travel and training costs
- Effort costs (the costs of paying software engineers).
The following costs are all part of the total effort cost:
- Costs of providing, heating and lighting office space
- Costs of support staff such as accountants, administrators, system managers, cleaners and technicians
- Costs of networking and communications
- Costs of central facilities such as a library or recreational facilities
- Costs of Social Security and employee benefits such as pensions and health insurance.
Factors affecting software pricing