1

PIT – II YEAR CSE

CS8494- SOFTWARE ENGINEERING

SYLLABUS
UNIT I SOFTWARE PROCESS AND AGILE DEVELOPMENT
Introduction to Software Engineering, Software Process, Perspective and Specialized Process
Models-Introduction to Agility – Agile process – Extreme programming – XP Process.

UNIT II REQUIREMENTS ANALYSIS AND SPECIFICATION

Software Requirements: Functional and Non-Functional, 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

Design process – Design Concepts-Design Model– Design Heuristic – Architectural Design –
Architectural styles, Architectural Design, 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 MAINTENANCE

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 – Maintenance and Reengineering
– BPR model – Reengineering process model – Reverse and Forward Engineering.

UNIT V PROJECT MANAGEMENT

Software Project Management: Estimation – LOC, FP Based Estimation, Make/Buy Decision,
COCOMO I & II Model – Project Scheduling – Scheduling, Earned Value Analysis, Planning
– Project Plan, Planning Process, RFP Risk Management –Identification, Projection, Risk
Management – Risk Identification –RMMM Plan – CASE TOOLS.
 2

UNIT I SOFTWARE PROCESS AND AGILE DEVELOPMENT

Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models-Introduction
to Agility – Agile process – Extreme programming – XP Process.

1. INTRODUCTION TO SOFTWARE ENGINEERING

Software:
 Software is a set of instructions (computer programs) that when executed provide desired features,
function, and performance.
 Simply, It is a program and other operating information used by a computer to perform some
task. Example: Picasa, Windows media player.
 Software is more than just a program code. Software is considered to be collection of executable
programming code, associated libraries and documentations.
Characteristics of Software:
A software product can be judged by what it offers and how well it can be used.
Well-engineered and crafted software is expected to have the following characteristics:
Operational: Transitional Maintenance
This tells us how well This aspect is important when the This aspect briefs about how well a
software works in software is moved from one software has the capabilities to maintain
operations. platform to another: itself in the ever-changing environment
It can be measured on: It can be measured on: It can be measured on:
 Usability Portability  Modularity
 Efficiency Interoperability  Maintainability
 Correctness Reusability  Flexibility
 Functionality Adaptability  Scalability
 Dependability
 Security
 Safety

Software has characteristics that are considerably different than those of hardware:
Software is developed or engineered; it is not manufactured in the classical sense.
o Software is developed. But hardware is engineered. They both are fundamentally different.
o In both hardware and software,high quality is achieved through good design.
o Both activities are dependent on people, but the relationship between people applied and work
accomplished is entirely different.
o Both activities require the construction of a ―product,‖ but the approaches are different.
o Changes can be made easily in software compared to hardware.
Software doesn’t “wear out.”
o Hardware exhibits relatively high failure rates early in its life. (these failures are often attributable
to design or manufacturing defects);
o Though defects can be corrected and rectified,. as time passes the failure rate rises again as
hardware components suffer from the cumulative effects of dust, vibration, abuse, temperature
extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out.
 3

o But software does not wear out. But ,deteriorate!. The performance of the software will become
less efficient as time passes.
Although the industry is moving toward component-based construction, most software continues to be
custom built.
o In the hardware world, component reuse is a natural part of the engineering process. But, not in
case of software.
o A software component should be designed and implemented so that it can be reused in many
different programs.
Software Products:
They are two types
1. Generic products
2. Customized products
Generic Product Customized Product
They are developed by an organization and sold They are developed by an organization for specific
to a open market(public). customer.
Ex: Whatsapp, Windows movie maker. Ex: Library management system for specific college
Software Application Domains:
System software:
A software collection of programs written to service other programs. E.g., compilers, editors, and file
management.
Application software:
Stand-alone programs that solve a specific business need.
E.g., point-of-sale transaction processing, real-time manufacturing process control.
Scientific software :
Software—has been characterized by ―number crunching‖ algorithms. Applications range from
astronomy to volcanology, from automotive stress analysis to space shuttle orbital dynamics, and from
molecular biology to automated manufacturing.
Engineering software: E.g, Computer-aided design, system simulation,etc..
Embedded software:
Resides within a product or system. Embedded software can perform limited functions.
E.g., digital functions in an automobile such as fuel control, dashboard displays, braking systems, toys,
security alarm, televisions etc.
Product-line software:
Designed to provide a specific capability for use by many different customers.
(E.g., word processing, spreadsheets, computer graphics, multimedia, entertainment, database
management, and personal and business financial applications).
Web applications:
Called ―WebApps,‖ this network-centric software category spans a wide variety of applications. It is
also are integrated with corporate databases and business applications. E.g, asp.net,
php.net,cloud9,firebase etc..
Artificial intelligence software:
Makes use of non numerical algorithms to solve complex problems. Applications within this area
include robotics, expert systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing.
 4

Software Engineering:
The term is made of two words, software and engineering.
 Software is more than just a program code. Software is considered to be collection of executable
programming code, associated libraries and documentations. Software, when made for a specific
requirement is called software product.
 Engineering on the other hand, is all about developing products, using well-defined, scientific
principles and methods.
 Software engineering is a branch that is associated with collection of methods (practice),
procedures, concepts, techniques and tools that allow professionals to build high quality computer
software.
 IEEE States, Software engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software.

Simply, Software engineering is a science and art of building a significant software system that are
 On time & On budget
 With acceptable performance
 With correct operation.
Software engineering is a layered technology.

A Quality Focus:
Any engineering approach (including software engineering) must rest on an organizational commitment that
focus on quality of the product.
Process:
The foundation for software engineering is the process layer.(Technology layer).
A process is a collection of activities, actions or task that performed when some work product is to be
created.
Methods:
Methods includes a broad set of tasks such as communication, requirements analysis, design modelling,
program construction, testing, and support.
Tools:
Software engineering tools provide automated or semi automated support for the process and the methods.

2. SOFTWARE PROCESS:
Process:
A process is a collection of activities, actions or task that are performed when some work product is to be
created.
Software process is characterized by i) Process Framework Activities
ii) Task sets
iii)Umbrella Activities
 5

(i) Generic Process Framework Activities: ( Software Development Lifecycle phases) :

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
Communication (Requirement gathering)
 Business requirements are gathered in this phase.
 Meetings with managers, developer and users are held in order to determine the requirements like;
 who is going to use the system? How will they use the system?
 What data should be input into the system? What data should be output by the system?
 After requirement gathering these requirements are analyzed for their validity
 Finally, a Requirement Specification document is created which serves the purpose of guideline for the
next phase of the model.
Planning (Cost Estimating, Scheduling)
 Estimation of cost or project budget is done here
 Scheduling the time duration of a project is done in this stage
 Project budget and delivery date are finalized and documented
Modeling (Analysis, Design)
 Models are created to better understand software requirements and the design that will achieve those
requirements.
 In this phase, the system and software design is prepared from the requirement specifications which
were studied in the first phase.
 System Design helps in specifying hardware and system requirements and also helps in defining overall
system architecture. It is actually a blueprint for implementation.
 The system design specifications serve as input for the next phase of the model.
Construction (Coding, Testing)
 On receiving system design documents, the work is divided in modules/units and actual coding is
started.
Coding: It is an important phase where design is translated into machine readable form. Simply,
Programs are created in this phase.
 This is the longest phase of the software development life cycle.
Testing: After the code is developed it is tested against the requirements to make sure that the product is
actually solving the needs addressed and gathered during the requirements phase.
 The purpose of testing is to uncover errors, fix the bugs and meet customer requirements.
 During this phase unit testing, integration testing, system testing, acceptance testing are done.
 Testing ensures the execution of all the paths and functio nal behaviours.
Deployment (delivery, maintenance)
 After successful testing, the product is delivered / deployed to the customer for their use.
 Once when the customers starts using the developed system then the actual problems comes up and
needs to be solved from time to time.
 This process where the care is taken for the developed product is known as maintenance.
 6

(ii) Taskset: It defines the actual work done in order to achieve the software objectives.
(iii) Umbrella Activities:
 Software engineering process framework activities are complemented by a number of umbrella
activities.
 In general, umbrella activities are applied throughout a software project and help a software team
manage and control progress, quality, change, and risk.

Fig, A software Process framework

 7

Typical umbrella activities include:

 Software project tracking and control—allows the software team to assess progress against the
project plan and take any necessary action to maintain the schedule.
 Risk management—assesses risks that may affect the outcome of the project or the quality of the
product.
 Software quality assurance—defines and conducts the activities required to ensure software quality
 Technical reviews—assesses software engineering work products in an effort to uncover and remove
errors before they are propagated to the next activity.
 Measure ment—defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders‘ needs; can be used in conjunction with all other framework
and umbrella activities.
 Software configuration management—manages the effects of change throughout the software process.
 Reusability management—defines criteria for work product reuse (including software components)
and establishes mechanisms to achieve reusable components.
 Work product preparation and production—encompasses the activities required to create work
products such as models, documents, logs, forms, and lists.

3. PERSPECTIVE PROCESS MODELS:

1. The waterfall model
2. V-model
3. Incremental process model / RAD model
4. Evolutionary process model / Prototyping model
5. The spiral model
6. Concurrent Development model
3.1 The Waterfall Model
The Waterfall Model is also referred to as a linear-sequential model or classic life cycle model.
It is a sequential approach to software development that begins with customer specificatio n of requirements and
progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the
completed software .

Fig, Waterfall Model

Features of waterfall model:
 It is very simple to understand and use.
 In a waterfall model, each phase must be completed fully before the next phase can begin.
 This type of model is basically used for the for the project which is small and there are no uncertain
requirements.
 At the end of each phase, a review takes place to determine if the project is on the right path and whether
or not to continue or discard the project.
 Testing phase starts only after the development is complete.
 8

 In waterfall model phases do not overlap.

 Documentation is produced in each and every step.
Advantages of waterfall model:
 This model is simple and easy to understand and use.
 In this model phases are processed and completed one at a time. Phases do not overlap.
 Easy to manage because there is no parallel processing.
 Waterfall model works well for smaller projects where requirements are very well understood.
 Documentation helps for future reference.
Disadvantages of waterfall model:
 Requirement analysis is done initially, sometime its nit possible to state all requirements initially.
 Once an application is in the testing stage, it is very difficult to go back and change something.
 Customer can see the model only at the end.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and complex projects.
 No customer interaction.
When to use the waterfall model:
 This model is used only when the requirements are very well known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 The project is short.
3.2 V-model
 V- Model means Verification and Validation model. A variation in the representation of the waterfall
model is called the V-model.
 Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes.
 Each phase must be completed before the next phase begins.
 Testing of the product is planned in parallel with a corresponding phase of development.
Phases of V-Model:
Requirements:
 Requirements like BRS and SRS begin the life cycle model just like the waterfall model.
 But, in this model before development is started, a system test plan is created.
 The test plan focuses on meeting the functionality specified in the requirements gathering.
The high-level design (HLD):
 This phase focuses on system architecture and design.
 It provides overview of solution, platform, system, product and service/process.
 An integration test plan is created in this phase as well in order to test the pieces of the software systems
ability to work together.
The low-level design (LLD):
 This phase is where the actual software components are designed.
 It defines the actual logic for each and every component of the system.
 Class diagram with all the methods and relation between classes comes under LLD.
 Component tests are created in this phase as well.
 9

Implementation
 In this phase , all coding takes place.
 Once coding is complete, the path of execution continues up the right side of the V where the test plans
developed earlier are now put to use.
Coding:
 This is at the bottom of the V-Shape model.
 Module design is converted into code by developers.
Advantages of V-model:
 Simple and easy to use.
 Testing activities like planning, test designing happens well before coding. This saves a lot of time.
Hence higher chance of success over the waterfall model.
 Proactive defect tracking – that is defects are found at early stage.
 Avoids the downward flow of the defects.
 Works well for small projects where requirements are easily understood.
Disadvantages of V-model:
 Very rigid and least flexible.
 Software is developed during the implementation phase, so no early prototypes of the software are
produced.
 If any changes happen in midway, then the test documents along with requirement documents
has to be updated.
Diagram of V-model:

When to use the V-model:

 The V-shaped model should be used for small to medium sized projects where requirements are clearly
defined and fixed.
 The V-Shaped model should be chosen when ample technical resources are available with needed
technical expertise.
 High confidence of customer is required for choosing the V-Shaped model approach. Since, no
prototypes are produced, there is a very high risk involved in meeting customer expectations.
 10

3.3 Incremental Model:

 In incremental model the whole requirement is divided into various builds.
 Incremental model delivers series of releases to the customer. These releases are called
increments. More and more functionality is associated with each increment.
 First increment is called core product. Basic requirements are included in this increment. Then, new
requirements are added in further increments. The process continues till the complete system is
achieved.
 Multiple development cycles take place here, making the life cycle a multi-waterfall cycle. Cycles
are divided up into smaller, more easily managed modules.
 Each module passes through the requirements, design, implementation and testing phases.

For example:

Diagram of Incremental model:

Example: Word processing package

The word processing software package can be considered as an example of incremental model.
In the 1st increment only document processing facilities are available.
In 2nd increment, more sophisticated document processing facilities, file management functionalities are given.
In the next increment spelling and grammar checking facilities can be given and so on.
Example: Banking Software:
In the first increment, Personal banking system is delivered. In the second increment, insurance service to
customers can be added. In the third increment home loans and other additional features can be added.
Example: Operating system software:
Providing basic operating system functionalities is the first increment. Then, security features can be given in
second increment. In the third increment, updating on various versions can be added and so on.
Advantages of Incremental model:
 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built. 
 Easier to manage risk because risky pieces are identified and handled during it‘d iteration.
 11

Disadvantages of Incremental model:

 Needs good planning and design.
 Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.
 Total cost is higher than waterfall.
When to use the Incremental model:
 This model can be used when the requirements of the complete system are clearly defined and
understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early. 
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals. 

RAD Model/(RAPID APPLICATION DEVELOPMENT MODEL):

 RAD model is a type of incremental process model in which there is extremely short development cycle.
 It is a type of incremental model.
 In RAD model the components or functions are developed in parallel as if they were mini projects.
 The developments are time boxed, delivered and then assembled into a working prototype.
 This can quickly give the customer something to see and use and to provide feedback regarding the
delivery and their requirements.

Fig, RAD Model

Features of RAD model:
- Using a RAD Model, a software product can be developed within 60 to 90 days of time.
- Various phases of RAD model are
 Requirement gathering,
 Planning,
 Analysis,
 Design and
 Deployment
 12

Advantages of the RAD model:

 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD Model:
 Requires highly skilled developers/designers.
 Requires multiple teams and large number of people to work on a project.
 Need Heavy resources
 If there is no proper modularization, then RAD project would fail.
 Adopting new technologies is difficult.
When to use RAD model:
 When there is a need to create a system 2-3 months of time.
 Only when the resources with high business knowledge are available

3.4 The Evolutionary Process Model / Prototyping Model:

 It is difficult to do modifications in earlier development phases of linear model. In such cases Iterative
approach is adopted.
 The evolutionary process model is iterative model.

Fig, Prototype Model

Features:
 The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a
throwaway prototype is built to understand the requirements.
 This prototype is developed based on the currently known requirements.
 By using this prototype, the client can get an actual feel of the system, since the interactions with
prototype can enable the client to better understand the requirements of the desired system.
 Prototyping is an attractive idea for complicated and large systems for which there is no manual process
or existing system to help determining the requirements.
 The prototype is usually not complete systems and many of the details are not built in the prototype.
The goal is to provide a system with overall functionality.
 13

Advantages of Prototype model:

 Since, in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
 Users are actively involved in the development
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified
Disadvantages of Prototype model:
 Leads to implementing and then repairing way of building systems.
 Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.
 Incomplete application may cause application not to be used as the full system was designed.
 Incomplete or inadequate problem analysis.
When to use Prototype model:
Prototype model should be used when the desired system needs to have a lot of interaction with the end users.
 Typically, online systems, web interfaces have a very high amount of interaction with end users, are best
suited for Prototype model.
 It might take a while for a system to be built that allows ease of use and needs minimal training for the
end user.
 Prototyping ensures that the end users constantly work with the system and provide a feedback which is
incorporated in the prototype to result in a useable system.
 They are excellent for designing good human computer interface systems.

3.5 The Spiral Model:

Diagram of Spiral model:

 Spiral model is iterative in nature.

 The spiral model is similar to the incremental model, with more emphasis placed on risk analysis.
 The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.
 A software project repeatedly passes through these phases in iterations (called Spirals in this model).
 The baseline spiral, starting in the planning phase, requirements is gathered and risk is assessed.
 Each subsequent spiral builds on the baseline spiral.
 14

Planning Phase:
 Requirements are gathered during the planning phase.
 Requirements like ‛BRS‘ that is ‛Business Requirement Specifications’ and SRS‘ that is
‗System Requirement specifications’.
Risk Analysis:
 In the risk analysis phase, a process is undertaken to identify risk and alternate solutions.
 A prototype is produced at the end of the risk analysis phase.
 If any risk is found during the risk analysis then alternate solutions are suggested and
implemented.
Engineering Phase:
 In this phase software is developed, along with testing at the end of the phase.
 Hence in this phase the development and testing is done.
Evaluation phase:
 This phase allows the customer to evaluate the output of the project to date before the project
continues to the next spiral.
Advantages of Spiral model:
 High amount of risk analysis hence, Hence Risk vcan be identified and rectified before they get
problematic.
 Requirement changes can be made easily at every stage.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Disadvantages of Spiral model:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project‘s success is highly dependent on the risk analysis phase.
 Doesn‘t work well for smaller projects.
When to use Spiral model:
 When costs and risk evaluation is important
 When project is not expected within a specific limited time span
 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex.
 Significant changes are expected (research and exploration)

3.6 The Concurrent Process Model:

 The concurrent development model, sometimes called concurrent engineering.
 Any process model can be represented in concurrent methodology.
 It has following states
1. Inactive 4. Base lined
2. Under development 5. Done
3. Under review 6. Awaiting changes
7. Under revision
 15

Working Principle:
 For example, early in a project the communication activity (not shown in the figure) has completed its
first iteration and exists in the awaiting changes state.
 The modeling activity (which existed in the inactive state while initial communication was completed,
now makes a transition into the under development state.
 If, however, the customer indicates that changes in requirements must be made, the modeling activity
moves from the under development state into the awaiting changes state.
 Concurrent modeling defines a series of events that will trigger transitions from state to state for each
of the software engineering activities, actions, or tasks.

Fig, Concurrent development model

Advantages:
 It is applicable for all type of software projects
 It gives accurate state of current project.
 It requires less time compare to other models.
Disadvantages:
 Need to keep track of all states simultaneously
 Costly model
 Need more man power
 Because all of the stages are working simultaneously, any changes to user requirements halts the work
on any component dependent on the component being changed.
 This model requires excellent and current communication between all teams, which is sometimes not
easily feasible.
When to use:
 When time duration of the project is less
 When we want to utilize all resources
 16

4. SPECIALIZED PROCESS MODELS:

These specialized process models will take many characteristics of one or more perspective process model.
Types:
1. Component Based Development
2. The Formal Methods Model
3. Aspect-Oriented Software Development
4.1 Component Based Development Model:
 Prepackaged components , Commercial off-the-shelf (COTS) Software components that are developed
by different vendors, can be used to build the software product.
 These components provide targeted functionality with well-defined interfaces . It enable the
component to be integrated into the Software.
 This model construct the applications from prepackages software model.
 The component based development model makes use of various spiral model.
 This model is evolutionary in model.(i.e.) necessary changes can be made in the software during each
iteration of software development cycle.
Steps involved in developing the component-based development model :
1. Available component-based products are researched and evaluated for the
application.
2. Component integration issues are considered.
3. Software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Integration testing is conducted to ensure proper functionality.
Advantages:
 Component reusability
 SDLC time will be reduced.
 Reduction in projects cost if component is already available.
4.2 The Formal Methods Model
 The Formal Methods Model encompasses a set of activities that leads to formal mathematical
specifications of Software.
 Formal methods enable a Software engineer to specify, develop, and verify a computer-based system
by applying a rigorous, mathematical notation.
 In this method all specifications and designs are converted into mathematical notations.
 All mathematical notations are validated against mathematical proofs.
 So this method assures us to produce error free software.
 Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily through the
application of mathematical analysis.
 When formal methods are used during design, they serve as a basis for program verification and
therefore enable.
 A variation of this approach, called clean-room Software engineering is currently applied by some
software development organizations.
Advantages:
 100% error free software.
 Ambiguity and complex functionality are removed
 Fault tolerance.
 17

Disadvantages:
 The development of formal models is currently quite time consuming and expensive.
 Extensive training and deep mathematical knowledge is required.
 It is difficult to communicate with technically unsophisticated customers.
 It is difficult to convert all specifications into mathematical notations.
4.3 Aspect-Oriented Software Development (AOSD):
 The builders of complex software invariably implement a set of localized features, functions, and
information content.
 These localized software characteristics are modeled as components and then constructed within the
context of system architecture.
Terminilogies used in AOSD:
 Concern
Anything any stakeholder wants the system to do.
Anything, any stakeholder
 Cross-cutting Concern
Far-reaching concern
Applies to many subsections of the system
The reason for Aspect Oriented to exist
 Separation of Concerns
Removal of sections in a module that deals with other concerns
 AOSD allows multiple concerns to be expressed separately and automatically unified into
working systems.
 As modern computer-based systems become more sophisticated (and complex), certain concerns,
customer required properties or areas of technical interest span the entire architecture.
 When concerns cut across multiple system functions, features, and information, they are often referred
to as crosscutting concerns.
 Viewpoints - represent the requirements of related groups of stakeholders.
 Cross-cutting concerns - are concerns that are identified by all viewpoints.

Vi e wpoi n ts C once rn s

Equip ment

Users

M anagers T HE SYST EM

Organis ation

Society

Regul ation Security Dependability

Fig, Viewpoints and Concerns
Aspect-oriented software development focuses on the identification, specification and representation
of cross-cutting concerns and their modularization into separate functional units as well as their automated
composition into a working system.
 18

 Aspect-oriented software development (AOSD), often referred to as aspect-oriented

programming (AOP).
Aspect-oriented design:
o The process of designing a system that makes use of aspects to implement the cross-cutting
concerns and extensions that are identified during the requirements engineering process.
Aspect-oriented programming
o The implementation of an aspect-oriented design using an aspect-oriented programming
language such as AspectJ.
 The implementation of a concern is scattered if its code is spread out over multiple modules. The
concern affects the implementation of multiple modules. Its implementation is not modular.
 The implementation of a concern is tangled if its code is intermixed with code that implements other
concerns. The module in which tangling occurs is not cohesive.
 Scattering and tangling often go together, even though they are different concepts

An AOSD Process:

5 Agile Process model:

 Agile processes can deliver successful systems quickly.
 It stresses on continuous communication and collaboration among developers and customers.
 Iterative development with frequent delivery to the customer is a core practice in agile software
development.
 Agile software engineering guidelines stress on-time delivery of an operational software increment over
analysis and design.
Agile process:
Are based on three key assumptions
1. It is difficult to predict in advance which requirements or customer priorities will change and which
will not.
2. For many types of software design and construction activities are interleaved (construction is used to
prove the design).
3. Analysis, design, and testing are not as predictable as we think
Following diagram shows change costs with respect to time and development of agile software process and
traditional software process.
 19

Princilpes of Agile Process Model:

The Agile Alliance (see [Agi03], [Fow01]) defines 12 agility principles for those who want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer‘s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self– organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behaviour accordingly.

Human factors:
Traits that need to exist in members of agile development teams:
o Competence
o Common focus
o Collaboration
o Decision- making ability
o Fuzzy-problem solving ability
o Mutual trust and respect
o Self-organization
Note:
We need not choose between agility and software engineering. Rather, define a software engineering approach
that is agile.
 20

6 Capability Maturity Model(CMM):

• Capability Maturity Model is a bench-mark for measuring the maturity of an organization‘s software
process. It is a methodology used to develop and refine an organization‘s software development process.
• CMM can be used to assess an organization against a scale of five process maturity levels based on certain
Key Process Areas (KPA). It describes the maturity of the company based upon the project the company is
dealing with and the clients.
• Each level ranks the organization according to its standardization of processes in the subject area being
assessed.

Level One :Initial

• The software process is characterized as inconsistent, and occasionally even chaotic.
• Defined processes and standard practices that exist are abandoned during a crisis. Success of the
organization majorly depends on an individual effort, talent, and heroics.
• The heroes eventually move on to other organizations taking their wealth of knowledge or lessons
learnt with them.
Level Two: Repeatable
• This level of Software Development Organization has a basic and consistent project management
processes to track cost, schedule, and functionality.
• The process is in place to repeat the earlier successes on projects with similar applications.
• Program management is a key characteristic of a level two organization.
Level Three: Defined
• The software process for both management and engineering activities are documented, standardized,
and integrated into a standard software process for the entire orga nization and all projects across the
organization use an approved, tailored version of the organization's standard software process for
developing, testing and maintaining the application.
Level Four: Managed
• Management can effectively control the software development effort using precise measurements.
• At this level, organization set a quantitative quality goal for both software process and software
maintenance. At this maturity level, the performance of processes is controlled using statistical and
other quantitative techniques, and is quantitatively predictable.
Level Five: Optimizing
• The Key characteristic of this level is focusing on continually improving process performance through
both incremental and innovative technological improvements.
 21

• At this level, changes to the process are to improve the process performance and at the same time
maintaining statistical probability to achieve the established quantitative process- improvement
objectives.
Advantage:
 Cost saving in terms of lesser effort due to less defects and less rework
 This also results in increased Productivity
 On-Time Deliveries
 Increased Customer Satisfaction
 Overall increased Return on Investment
 Decreased Costs
 Improved Productivity
Disadvantage:
 It may not be suitable for every organization.
 It may add overhead in terms of documentation.
 May require a considerable amount of time and effort for implementation.
 Require a major shift in organizational culture and attitude.

Agile :
The word ‗agile‘ means −
 Able to move your body quickly and easily.
 Able to think quickly and clearly.

Characteristics of Agility:

 Agility in Agile Software Development focuses on the culture of the whole team with multi-discipline, cross-
functional teams that are empowered and self organizing.
 It fosters shared responsibility and accountability.
 Facilitates effective communication and continuous collaboration.
 The whole-team approach avoids delays and waits times.
 Frequent and continuous deliveries ensure quick feedback that in in turn enable the team align to the
requirements.
 Collaboration facilitates combining different perspectives timely in implementation, defect fixes and
accommodating changes.
 Progress is constant, sustainable, and predictable emphasizing transparency.

Extreme Programming:
Definition:
Extreme Programming (XP) is an agile software development framework that aims to produce higher quality
software, and higher quality of life for the development team. XP is the most specific of the agile frameworks
regarding appropriate engineering practices for software development.
Advantages:

 Slipped schedules − and achievable development cycles ensure timely deliveries.

 Cancelled projects − Focus on continuous customer involvement ensures transparency with the customer
and immediate resolution of any issues.
 Costs incurred in changes − Extensive and ongoing testing makes sure the changes do not break the
existing functionality. A running working system always ensures sufficient time for accommodating changes
such that the current operations are not affected.
 Production and post-delivery defects: Emphasis is on − the unit tests to detect and fix the defects early.
 22

 Misunderstanding the business and/or domain − Making the customer a part of the team ensures constant
communication and clarifications.
 Business changes − Changes are considered to be inevitable and are accommodated at any point of time.
 Staff turnover − Intensive team collaboration ensures enthusiasm and good will. Cohesion of multi-
disciplines fosters the team spirit.

Extreme Programming Values

Extreme Programming (XP) is based on the five values −

 Communication
 Simplicity
 Feedback
 Courage
 Respect

Communication

Communication plays a major role in the success of a project. Problems with projects often arise due to lack of
communication. Many circumstances may lead to the breakdown in communication. Some of the common problems
are −

 A developer may not tell someone else about a critical change in the design.
 A developer may not ask the customer the right questions, and so a critical domain decision is blown.
 A manager may not ask a developer the right question, and project progress is misreported.
 A developer may ignore something important conveyed by the customer.

Extreme Programming emphasizes continuous and constant communication among the team members, managers
and the customer. The Extreme Programming practices, such as unit testing, pair programming, simple designs,
common metaphors, collective ownership and customer feedback focus on the value of communication.

XP employs a coach whose job is to notice when the people are not communicating and reintroduce them. Face-to-
Face communication is preferred and is achieved with pair programming and a customer representative is always
onsite.

Simplicity

Extreme Programming believes in ‗it is better to do a simple thing today and pay a little more tomorrow to change
it‘ than ‗to do a more complicated thing today that may never be used anyway‘.

 Do what is needed and asked for, but no more.

o Do what is needed and asked for, but no more.
o ''Do the simplest thing that could possibly work'' The DTSTTCPW principle.
o Implement a new capability in the simplest possible way. Also known as the KISS principle ‗Keep It
Simple, Stupid!‘.
o A coach may say DTSTTCPW when he sees an Extreme Programming developer doing something
needlessly complicated.
o Refactor the system to be the simplest possible code with the current feature set. This will maximize
the value created for the investment made till date.
 Take small simple steps to your goal and mitigate failures as they happen.
 Create something that you are proud of and maintain it for a long term for reasonable costs.
 Never implement a feature you do not need now i.e. the ‗You Aren‘t Going to Need It‘ (YAGNI) principle.
 23

Feedback
Every iteration commitment is taken seriously by delivering working software. The software is delivered early to the
customer and a feedback is taken so that necessary changes can be made if needed. Concrete feedback about the
current state of the system is priceless. The value of the feedback is a continuously running system that delivers
information about itself in a reliable way.

In Extreme Programming, feedback is ensured at all levels at different time scales −

 Customers tell the developers what features they are interested in so that the developers can focus only on
those features.
 Unit tests tell the developers the status of the system.
 The system and the code provides feedback on the state of development to the managers, stakeholders and
the customers.
 Frequent releases enable the customer to perform acceptance tests and provide feedback and developers to
work based on that feedback.
 When the customers write new features/user stories, the developers estimate the time required to deliver the
changes, to set the expectations with the customer and managers.

Thus, in Extreme Programming the feedback −

 Works as a catalyst for change

 Indicates progress
 Gives confidence to the developers that they are on the right track

Courage

Extreme Programming provides courage to the developers in the following way −

 To focus on only what is required

 To communicate and accept feedback
 To tell the truth about progress and estimates
 To refactor the code
 To adapt to changes whenever they happen
 To throw the code away (prototypes)

This is possible as no one is working alone and the coach guides the team continuously.

Respect

Respect is a deep value, one that lies below the surface of the other four values. In Extreme Programming,

 Everyone respects each other as a valued team member.

 Everyone contributes value such as enthusiasm.
 Developers respect the expertise of the customers and vice versa.
 Management respects the right of the developers to accept the responsibility and receive authority over their own work.

Combined with communication, simplicity, and concrete feedback, courage becomes extremely valuable.

 Communication supports courage because it opens the possibility for more high-risk, high- reward
experiments.
 Simplicity supports courage because you can afford to be much more courageous with a simple system. You
are much less likely to break it unknowingly.
 Courage supports simplicity because as soon as you see the possibility of simplifying the system you try it.
 24

Extreme Programming Principles

The fundamental principles of Extreme Programming are −

 Rapid feedback
 Assume simplicity
 Incremental change
 Embracing change
 Quality work

Rapid Feedback

Rapid feedback is to get the feedback, understand it, and put the learning back into the system as quickly as possible.

 The developers design, implement and test the system, and use that feedback in seconds or minutes instead
of days, weeks, or months.
 The customers review the system to check how best it can contribute, and give feedback in days or weeks
instead of months or years.

Assume Simplicity

To assume simplicity is to treat every problem as if it can be solved with simplicity.Traditionally, you are told to
plan for the future, to design for reuse. The result of this approach may turn into ‗what is required today by the
customer is not met and what is ultimately delivered may be obsolete and difficult to change.‘

‗Assume Simplicity‘ means ‗do a good job of solving today's job today and trust your ability to add complexity in
the future where you need it.‘ In Extreme Programming, you are told to do a good job (tests, refactoring, and
communication) focusing on what is important today.

 With good unit tests, you can easily refactor your code to do additional tests.
 Follow YAGNI (You Ain‘t Gonna Need It).
 Follow the DRY(Don‘t Repeat Yourself) principle. For example,
o Do not have multiple copies of identical (or very similar) code.
o Do not have redundant copies of information.
o No wastage of time and resources on what may not be necessary.

Incremental Change

In any situation, big changes made all at once just do not work. Any problem is solved with a series of the smallest
change that makes a difference.

In Extreme Programming, Incremental Change is applied in many ways.

 The design changes a little at a time.

 The plan changes a little at a time.
 The team changes a little at a time.

Even the adoption of Extreme Programming must be taken in little steps.

Embracing Change

The best strategy is the one that preserves the most options while actually solving your most pressing problem.
 25

Quality Work

Everyone likes doing a good job. They try to produce the quality that they are proud of. The team

 Works well
 Enjoys the work
 Feels good in producing a product of value

Activities in Extreme Programming:

There are four basic activities in Extreme Programming. They are −

 Coding
 Testing
 Listening
 Designing

Kent Beck, the author of ‗Extreme Programming Explained‘ defined 12 Extreme Programming practices as follows

 The Planning Game

 Short Releases
 Metaphor
 Simple Design
 Testing
 Refactoring
 Pair Programming
 Collective Ownership
 Continuous Integration
 40 hour Week
 On-site Customer
 Coding Standards

Extreme Programming Practices The following diagram shows how Extreme Programming is
woven around the Extreme Programming practices −
 26

The Planning Game

The main planning process within extreme programming is called the Planning Game. The game is a meeting that
occurs once per iteration, typically once a week. The Planning Game is toqQuickly determine the scope of the next
release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
Advantages
The Planning Game has the following advantages −
 Reduction in time, wasted on useless features
 Greater customer appreciation of the cost of a feature
 Less guesswork in planning
Disadvantages
The disadvantages of the Planning Game are that you cannot possibly start development with only a rough plan and
you cannot constantly update the plan as it would take too long and upset the customers.

Short Releases
You should put a simple system into production quickly, and then release new versions in very short cycles. Every
release should be as small as possible, so that it is −
 Achievable in a short cycle
 Contains the most valuable and immediate business requirements
 A working system
The duration of the short cycle may vary with the software that needs to be built. However, it needs to be ensured
that the minimum possible duration is chosen.
Advantages
The advantages of Short Releases are −
 Frequent feedback
 Tracking
 Reduce chance of overall project slippage
Disadvantages

You cannot possibly go into production after a few months. You certainly cannot make new releases of the system
on cycles ranging from daily to every couple of months. This is because you take time to absorb new requirements,
changes into the current code.

Metaphor
According to Cambridge online dictionary- A Metaphor is an expression, often found in literature that describes a
person or object by referring to something that is considered to have similar characteristics to that person or object.
For example, ‗The mind is an ocean‘ and ‗the city is a jungle‘ are both Metaphors.
Advantages
 Encourages a common set of terms for the system
 Reduction of buzz words and jargon
 A quick and easy way to explain the system
 27

Simple Design
The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as
it is discovered. The right design for the software at any given time is the one that −
 Runs all the tests
 Has no duplicated logic like parallel class hierarchies
 States every intention important to the developers
 Has the fewest possible classes and methods
Advantages
 Time is not wasted adding superfluous functionality
 Easier to understand what is going on
 Refactoring and collective ownership is made possible
 Helps keep the programmers on track
Disadvantages
You cannot possibly have just enough design for today's code and your design may not continue to evolve the
system.

Testing
The developers continually write unit tests, which need to pass for the development to continue. The customers write
tests to verify that the features are implemented. The tests are automated so that they become a part of the system
and can be continuously run to ensure the working of the system. The result is a system that is capable of accepting
change.
Advantages
 Unit testing promotes testing completeness
 Test-first gives developers a goal
 Automation gives a suite of regression tests
Disadvantages
 You cannot possibly write all those tests.
 It can take too much time to write the tests.
 Developers will not write the tests.
Refactoring
When implementing a feature, the developers always ask if there is a way of changing the existing code to make
adding the feature simple. After they have added a feature, the developers ask if they now can see how to make the
code simpler, while still running all of the tests. They restructure the system without changing its behavior to remove
duplication, improve communication, simplify, or add flexibility. This is called Refactoring.
 28

Advantages
 Prompts the developers to proactively improve the product as a whole
 Increases the developer knowledge of the system
Disadvantages
You cannot possibly refactor the design of the system all the time. It would −
 Take too long.
 Be too hard to control, and
 Most likely break the system.

Pair Programming
In Pair programing, the entire code is written with two developers at one machine, with one keyboard and one
mouse.
There are two roles in each pair −
 The first developer (the one with the keyboard and the mouse) thinks about the best way to implement this
method right here.
 The other developer is thinks more strategically
o Is this whole approach going to work?
o What are some other test cases that might not work yet?
o Is there some way to simplify the whole system so the current problem just disappears?
The pairing is dynamic. It means that the two Roles A and B may exchange their places, or they may pair up with
other team members. More often, anyone on the team will do as a partner. For example, if you have a responsibility
for a task in an area that is unfamiliar to you, you might ask someone with recent experience to pair with you.
Advantages
The advantages of Pair Programming are −
 Two heads are better than one
 Focus
 Two people are more likely to answer the following questions −
o Is this whole approach going to work?
o What are some test cases that may not work yet?
o Is there a way to simplify this?
Disadvantages:
 You cannot possibly write all the code in pairs. It will be too slow. It makes the situation difficult if two
people do not get along well.
 29

Collective Ownership
In Extreme Programming, the entire team takes responsibility for the whole of the system. Not everyone knows
every part equally well, although everyone knows something about every part.
If a pair is working and they see an opportunity to improve the code, they go ahead and improve it.
Advantages
 Helps mitigate the loss of a team member who is leaving.
 Promotes the developers to take responsibility for the system as a whole rather than parts of the system.
Continuous Integration
Code is integrated and tested many times a day, one set of changes at a time. A simple way to do this is to have a
machine dedicated to integration. A pair with code ready to integrate −
 Sits when the machine is free.
 Loads the current release.
 Loads their changes (checking for and resolving any collisions).
 Runs the tests until they pass (100% correct).
Advantages
The advantages of Continuous Integration are −
 Reduces the duration, which is otherwise lengthy.
 Enables the short releases practice as the time required before release is minimal.
Disadvantages
You cannot possibly integrate after only a few hours of work, as integration takes long and there are too many
conflicts and chances to accidentally break something.
40-Hour Week
Extreme Programming emphasizes on the limited number of hours of work per week for every team members, based
on their sustainability, to a maximum of 45 hours a week. If someone works for more time than that, it is considered
as overtime. Overtime is allowed for at most one week. This practice is to ensure that every team member be fresh,
creative, careful and confident.
Advantages
The advantages of 40-hour week are −
 Most developers lose effectiveness past 40 hours.
 Value is placed on the developers‘ well-being.
 Management is forced to find real solutions.
Disadvantages
You cannot possibly work 40-hour weeks. You cannot create enough business value in 40 hours.
 30

On-Site Customer
Include a real, live user on the team, available full-time to answer the questions, resolve disputes and set small-scale
priorities. This user may not have to spend 40 hours on this role only and can focus on other work too.
Advantages
The advantages of having an onsite customer are −
 Can give quick and knowledgeable answers to the real development questions.
 Makes sure that what is developed is what is needed.
 Functionality is prioritized correctly.
Disadvantages
You cannot possibly have a real customer full- time on the team, not producing any value. They can produce far
more value for the business elsewhere.

Coding Standards
Developers write all code in accordance with the rules emphasizing-
 Communication through the code.
 The least amount of work possible.
 Consistent with the ―once and only once‖ rule (no duplicate code).
 Voluntary adoption by the whole team.
Advantages
The advantages of Coding Standards are −
 Reduces the amount of time developers spend reformatting other peoples‘ code.
 Reduces the need for internal commenting.
 Calls for clear, unambiguous code.
Disadvantages
You cannot possibly ask the team to code to a common standard as developers are usually individualistic.

Extreme Programming Process Cycle

Extreme Programming is iterative and incremental and is driven by Time-Boxed Cycles. Therefore, the rhythm of
the Extreme Programming process is crucial.
Extreme Programming has the following activity levels −
 Product Life Cycles
 Releases
 Iterations
 Tasks
 Development
 Feedback
 31

Each of the activity levels provides the minimal inputs required for the next level. They are −
 Product life cycle activities provide inputs for release cycles.
 Release planning sessions provide inputs for iteration cycles.
 Iteration planning sessions provide inputs for task cycles.
 Task development provides inputs for development episodes.
 Development produces the product.
Feedback is a continuous activity throughout the project and across all the above activity levels.
Product Life Cycles
This is also referred to as the Exploration phase. It involves feature set definition and planning. The customer arrives
at high value requirements and the requirements are given as user stories.Stories are the primary deliverable of this
level activity.
Releases
This is also referred to as the Commitment phase. In this activity −
 The whole team gathers so that −
o Progress is reviewed.
o New requirements can be added and/or existing requirements can be changed or removed.
o Customer presents stories.
o Stories are discussed.
 The developers determine the technical approach and risk. They provide first-level estimates and options.
 The customer prioritizes the stories and chooses target release time box.
 The customer and developers commit themselves to the functionality that are to be included and the date of
the next release.
 The developers −
o Arrange stories into probable iterations.
o Include defect fixes from acceptance testing of the previous release.
o Begin the iterations.
Release plan is the primary deliverable of this level activity.
Iterations
This is also referred to as the Steering phase. The whole team gathers so that the progress is reviewed and the plan
can be adjusted. The customer presents stories for the iteration and the stories are discussed in greater detail.
The iteration Plan is the primary deliverable of this activity.
The developers −
 Determine detailed technical approach.
 Create task list for each story.
 Begin the development.
 Deploy the system
 32

Tasks
The developers Sign- up for the tasks and begin development episodes to implement the stories. They ensure the
tasks for the iteration are complete. The developers also ensure that the stories for the iteration are complete with
acceptance tests.
Development
The developers form pairs, which can be a continuous and dynamic activity.
Each Pair −
 Verifies their understanding of the story.
 Determines detailed implementation approach, ensuring simple design.
 Begins test-driven development, i.e., write unit test, implement code to pass the unit test, refactor to make the code
simple.
 Integrates their code to the system code base at appropriate intervals.
 Reviews the progress frequently.
Feedback
Pairs constantly communicate within themselves and outward to the team as well. On-line customer is also involved
in the communication on a continuous basis. Certain teams resort to daily stand-up meetings to discuss the overall
team status quickly and the possible re-synchronization and micro-planning if necessary.
The iteration and release reviews provide overall status and points for process adjustment and improvement.
 Development episodes may cause rethinking of tasks.
 Task development may cause rethinking of stories.
 Story re-estimation may cause iteration changes or recovery.
 Iteration results may cause changes to release plan.
The Extreme Programming process cycle is illustrated below.
 33

XP – Activities
In Extreme Programming, the four basic activities are −
 Coding
 Testing
 Listening
 Designing
Coding
In pair programming, coding is considered the heart of development. You code because if you do not code, at the
end of the day you have not done anything.
Testing
In pair programming, testing needs to be done to ensure that the coding is done. If you do not test, you do not know
when you have finished coding.
Listening
In pair programming, you listen to know what to code or what to test. If you do not listen, you do not know what to
code or what to test.
Designing
In pair programming, you design so that you can keep coding and testing and listening indefinitely, as good design
allows extension of the system, with changes in only one place.
These activities are performed during −
 Release Planning
 Iteration Planning
 Implementation
PART A
1. What is Software Engineering?[NOV / DEC 2013]
Software engineering is an engineering discipline that is concerned with all aspects of software production.

2. ‗Software doesn’t wear out’. Justify[NOV / DEC 2013]

Software failure is distinct from hardware failure in that software does not wear out. Failures are often
transient. The system carries on working after an incorrect result has been produced.

3. What is software process? List its activities. [MAY / JUNE 2013]

A software process model is an abstract representation of a process. It presents a description of a process f
from some particular perspective
Specification – defining what the system should do;
Design and implementation – defining the organization of the system and implementing the system.
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer needs.
 34

4. How a software process can be characterized? [NOV / DEC 2012]

Modularity, Iterative, Time-Bound
5. Give two reasons why system engineering must understand environment of a system. [MAY / JUNE
2012]
The system engineering process begins with a world view; the busi- ness or product domain is examined to
ensure that the proper busi- ness or technology context can be established.The world view is refined to
focus on a specific domain of interest.Within a specific domain, the need for targeted system elements is
analyzed.Finally, the analysis, design, and construction of a targeted system element are initiated

6. What are two type of software product? [MAY / JUNE 2012]

Generic products
Customized products
7. What are the different types of architecture in software engineering? [NOV / DEC 2010]
Business Architecture
Technical Architecture
Solutions Architecture
Enterprise Architecture
Product Line Architecture
8. What is software engineering? [APR MAY 2010]
Software engineering is a discipline in which theories, methods and tools are applied to develop Professional
software.
9. What is Software? [NOV/DEC 2010, APR/MAY 2018]
Software is nothing but a collection of computer programs that are related documents that are indented to
provide desired features, functionalities and better performance.
10.What are the characteristics of the software? [APR/MAY 2013, APR/MAY 2018]
 Software is engineered, not manufactured.
 Software does not wear out.
 Most software is custom built rather than being assembled from components

11.What are the various categories of software? [[NOV/DEC 2014]

 System software
 Application software
 Engineering/Scientific software
 Embedded software
 Web Applications
 Artificial Intelligence software

12. What are the challenges in software?

 Copying with legacy systems.
 Heterogeneity challenge
 Delivery times challenge
13.Define software process.
Software process is defined as the structured set of activities that are required to develop the software system.

14.What are the fundamental activities of a software process?

 Specification
 Design and implementation
 Validation
 Evolution
 35

15.What are the umbrella activities of a software process? [APR/MAY 2012]

 Software project tracking and control
 Risk management.
 Software Quality Assurance.
 Formal Technical Reviews.
 Software Configuration Management.
 Work product preparation and production.
 Reusability management.
 Measurement.

16. What are the merits of incremental model?

i. The incremental model can be adopted when there are less number of people involved in the project.
ii. Technical risks can be managed with each increment.
iii. For a very small time span, at least core product can be delivered to the customer.

17. List the task regions in the Spiral model.[APR/MAY 2015]

 Customer communication – In this region it is suggested to establish customer communication.
 Planning – All planning activities are carried out in order to define resources timeline and other project
related activities.
 Risk analysis – The tasks required to calculate technical and management risks.
 Engineering – In this the task region, tasks required to build one or more representations of applications are
carried out.
 Construct and release – All the necessary tasks required to construct, test, install the applications are
conducted. ¾_Customer evaluation – Customer‟ s feedback is obtained and based on the customer
evaluation required tasks are performed and implemented at installation stage.

18. What are the drawbacks of spiral model? [[NOV/DEC 2014]

i. It is based on customer communication. If the communication is not proper then the software product that gets
developed will not be the up to the mark.
ii. It demands considerable risk assessment. If the risk assessment is done properly then only the successful product
can be obtained.

19. What is System Engineering?

System Engineering means designing, implementing, deploying and operating systems which include hardware,
software and people

20. List the process maturity levels in SEIs CMM.

Level 1:Initial – Few processes are defined and individual efforts are taken.
Level 2:Repeatable – To track cost schedule and functionality basic project management processes are established.
Level 3:Defined – The process is standardized, documented and followed.
Level 4:Managed – Both the software process and product are quantitatively understood and controlled using
detailed measures.
Level 5:Optimizing – Establish mechanisms to plan and implement change.

21. What is the use of CMM?

Capability Maturity Model is used in assessing how well an organization‘s processes allow to complete and manage
new software projects.

22. Name the Evolutionary process Models.

i. Incremental model ii. Spiral model
iii. WIN-WIN spiral model iv. Concurrent Development.
 36

23. List two deficiencies in waterfall model. Which process model do you suggest to overcome each
deficiency? [APR / MAY 2017]
1. The major drawback of waterfall model is we move to the next stage only when the previous one is finis hed
and there was no chance to go back if something is Software Engineering Tutorial13found wrong in later
stages. V -Model provides means of testing of software at each stage in reverse manner.
2. High amounts of risk and uncertainty in waterfall model. Spiral model produced High amount of risk
analysis hence, avoidance of Risk is enhanced.

24. If you have to develop a word processing software product, what process model will you choose? Justify
[APR / MAY 2018]
Incremental model is used to develop word processing software because we get software release in series of
increments.

PART B
1. Explain iterative waterfall and spiral model for software life cycle and various activities in each
phase.[APR/MAY 2012] .[APR/MAY 2015] [U]
2. Explain in detail about incremental and Rapid application development Model (RAD) and mention its
advantages and disadvantages. [APR/MAY 2012] [U]
3. Explain about the incremental model. [NOV/DEC 2014] [R]
4. Explain in detail about the software process. [NOV/DEC 2014] [R]
5. Explain in detail about the life cycle process. [APR/MAY 2012] [R]
6. Explain in detail about project scheduling & EVA? [APR/MAY 2015] [R]
7. Compare the following life cycle models based on their distinguishing factors, Strengths and weaknesses,
– Waterfall Model, R Model, Spiral Model and Formal Methods Model. (Present in the form of table
only – use diagrams wherever necessary) [NOV / DEC 2013] [An]
8. What is the process model? Describe the process model that you would choose to manufacture a car. Explain
giving suitable reasons. [APR / MAY 2017] [U]
9. How function point analysis methodology is applied in estimation of software size? Explain. Why FPA
methodology is better than LOC methodology? [APR / MAY 2017] [U]
10. Explain how work break down structure is used in software engineering. Discuss how software project
scheduling helps in timely release of a product.[APR / MAY 2018] [U]

11. Which software process model is good for risk management? Explain the model. Describe how the model is
used to layout the objectives, risks and plans for quality improvement. .[APR / MAY 2018] [U]