Module I: Introduction to Software Engineering

Basics terms of Software Engineering: Evolving role of software, changing nature of Software, Software
Myths.
A Generic View of Process:-Software engineering-A layered technology, A Process Frame Work, The
Capability Maturity Model Integration (CMMI)
Process Models: The water fall model, Incremental process models, evolutionary process models, and
the unified process.
-----------------------------------------------------------------------------------------------------------------------------------------
Introduction to Software Engineering
The term software engineering is the product of two words, software, and engineering.
Software:
Software is a collection of executable integrated programs
Basically software can be 2 types
1.System software: A collection of programs written to service other programs.
(e.g., compilers, editors, and file management utilities)
2. Application software: Stand-alone programs that solve a specific business need.

Engineering: application of science, tools& methods to find cost effective solution to problems

Software Engineering: It is defined as systematic, disciplined and quantifiable approach for the
development, operation and maintenance of software.

Characteristics of a software
• Software should achieve a good quality in design and meet all the specifications of the customer.
• Software does not wear out i.e. it does not lose the material.
• Software should be inherently complex.
• Software must be efficient i.e. the ability of the software to use system resources in an effective and
efficient manner.
• Software must be integral i.e. it must prevent from unauthorized access to the software or data.
 Basics terms of Software Engineering:
Evolving role of software
Software takes on a dual role.
1. It is a product, and
2. The vehicle for delivering a product.
As a product, (produces, manages and displays the information)
1) It delivers the computing potential embodied by computer hardware or more broadly
Eg: A network of computers that are accessible by local hardware. whether it resides in a mobile
phone or in a mainframe computer.
2) Software is information transformer— producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as a single bit or as complex as a multimedia
presentation derived from data acquired from dozens of independent sources.
As the vehicle used to deliver the product(process), Software delivers most important product of our
life time - information
1) Software acts as the basis for the control of the computer (Eg:operating systems)
2) The communication of information (eg: internet )and
3) The creation and control of other programs (software tools and environments).

The role of computer software has undergone significant change over a time span of little more than 50
years.
Dramatic improvements in hardware performance, profound changes in computing architectures, vast
increases in memory and storage capacity, and a wide variety of exotic input and output options have all
precipitated more sophisticated and complex computer-based systems.
Sophistication and complexity can produce super results when a system succeeds, but they can also
show huge problems for those who must build complex systems.

• Before 1970s
- Single processors: mainframes
- Designed in one of two ways
• as a transformation: input was converted to output
• as a transaction: input determined which function should be performed
• After 1970s
- Run on multiple systems
- Perform multi-functions
• During the later 1990s,
The role of computers were demonized by some of the famous authors too emphasizing the legitimate
concerns and ignoring the benefits

•The prospects of software professionals were reevaluated in late 90s and that time was called as rise of
American programmers.
•In 2000 the whole software focus shifted to Y2K virus.
• In early 2000s there was a major impact of 9/11 on IT industry and community.
• Then the time came for various software simulations
• Then was the era of semantic web i.e the various software which were helping to interact with each other in
social media.
• A paradigm shift in software engineering process and SDLC cycle as the team has replaced the lone person in
software team.

The lone programmer of an earlier era has been replaced by a team of software specialists, each focusing on one
part of the technology required to deliver a complex application.
And yet, the same questions asked of the lone programmer are being asked when modern computer-based
systems are built:
1) Why does it take so long to get software finished?
2) Why are development costs so high?
3) Why can't we find all the errors before we give the software to customers?
4) Why do we continue to have difficulty in measuring progress as software is being developed?
Changing nature of Software
There are seven broad categories of computer software having different forms, uses and challenges to
software engineers.

System software- System software is a collection of programs written to service other programs. System
software: such as compilers, editors, file management utilities.

Application software: stand-alone programs for specific needs. This software are used to controls business
needs. Ex: Transaction processing.

Embedded software – This software resides within a system or product and it is used to implement and control
features and functions from end user and system itself. This software performs limited function like keypad
control for microwave oven.

Artificial intelligence software- Artificial intelligence (AI) software makes use of nonnumeric algorithms to solve
complex problems. Applications within this area include robotics, pattern recognition, and game playing.

Engineering and scientific software- This software are specially used for drawing, modeling, drafting, load
calculations and analysis of engineering and statistical data for interpretation and decision making.
For example, CAD (Computer Aided Design), CAM (Computer Aided Manufacturing), and CAE (Computer
Aided Engineering).

Product-line software focus on a limited marketplace to address mass consumer market. (word processing,
graphics, database management) .

WebApps (Web applications) A web application is software that runs in your web browser. Businesses
have to exchange information and deliver services remotely.
Software Myths
Myth: Wrong belief (or) misinformation (or) misleading attitudes that caused serious problems.
Software myth: Software myths are beliefs about software and the process used to build it.
Software myths are 3 Types:
1) Management Myths
2) Customer Myths
3) Developer (or) Practitioner’s Myths
1) Management Myths:
Managers are often under pressure for software development under a tight budget, improved
quality, and a packed schedule, often believing in some software myths. Following are some
management myths.

 Myth: We already have a book that’s full of standards and procedures for building
software. They are sufficient for developers
Reality: The book of standards may very well exist but, is it used? Are software practitioners
aware of its existence? Does it reflect modern software engineering practice?

 Myth: We can add workers when we get behind the schedule.

Reality: Software development is not a mechanistic process like manufacturing. As new people are
added, people who were working must spend time educating the new comers, thereby reducing
the amount of time spend on productive development effort. People can be added but only in a
planned and well coordinated manner.

 Myth: If I decide to outsource the software project to a third party, I can just relax and let
that firm built it.
Reality: If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsources software projects.

 Myth: They think they have latest computers

 Myth: A good manager can manage any project

2) Customer Myths:
Customer Myths are generally due to false expectations by customers, and these myths end
up leaving customers with dissatisfaction with the software developers. Following are some
customer myths.

 Myth: A general statement of objectives is sufficient to begin writing program

Reality: Although a comprehensive and stable statement of requirements is not always possible, an
ambiguous statement of objectives is recipe for disaster.

 Myth: Change requests is easy because s/w is flexible

Reality: Longer the time for which software has proceeded for development, it becomes more and
more difficult to accommodate any changes. Any change causes an increase in additional costs
because incorporating changes at later stages needs redesigning and extra resources.

 Myth: Customer always thinks that the s/w development is an easy process.
 3) Developer (or) Practitioner’s Myths:
Myths that are still believed by software practitioners: during the early days of software,
programming was viewed as an art from old ways and attitudes die hard

 Myth: if I miss something now, I can fix it later

 Myth: Once we write the program and get it to work, our job is done.
Reality: Practically 60% – 80% of the efforts are expended on the software when the software is
delivered to the customer for the first time.
When the software is delivered to the customer for the first time. When a customer starts using
the software they figure out the improvements that can be made to enhance the quality of the
software.

 Myth: software engineering will make us create large and unnecessary documentation and
will invariably slows down.
Reality: software engineering is not about creating documents. It is about creating quality. Better
quality leads to reduced rework. And reduced rework results in faster delivery times

 Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software configuration that includes many
elements. Documentation provides guidance for software support.

 Myth: Until I get the program “running” I have no way of assessing its quality.

A Generic View of Process:-

Process: A set of activities, methods, practices, and transformations that people use to develop and
maintain software and the associated products
(e.g., project plans, design documents, code, test cases, and user manuals)

Software engineering-A layered technology

Software Engineering:

• Software Engineering is the application of a systematic, disciplined, quantifiable approach to

the development, operation, and maintenance of software; that is, the application of
engineering to software.
Software engineering - Layered technology
• Software engineering is a fully layered technology.
• To develop software, we need to go from one layer to another.
• All these layers are related to each other and each layer demands the fulfillment of the previous layer.
 The layered technology consists of:
1. Quality focus
The characteristics of good quality software are:
• Correctness of the functions required to be performed by the software.
• Maintainability of the software
• Integrity i.e. providing security so that the unauthorized user cannot access information or data.
• Usability i.e. the efforts required to use or operate the software.

2. Process
• It is the base layer or foundation layer for the software engineering.
• The software process is the key to keep all levels together.
• It defines a framework that includes different activities and tasks.
• In short, it covers all activities, actions and tasks required to be carried out for software development.

3. Methods
• The method provides the answers of all 'how-to' that are asked during the process.
• It provides the technical way to implement the software.
• It includes collection of tasks starting from communication, requirement analysis, analysis and design
modelling, program construction, testing and support.

4. Tools
• The software engineering tool is an automated support for the software development.
• The tools are integrated i.e the information created by one tool can be used by the other tool.
• For example: The Microsoft publisher can be used as a web designing tool.

A Process Frame Work

• The process of framework defines a small set of activities that are applicable to all types of projects.
• The software process framework is a collection of task sets.
• Task sets consist of a collection of small work tasks, project milestones, work productivity and software
quality assurance points.
Framework Activities
• Communication: By communication, customer requirement gathering is done. Communication
with consumers and stakeholders to determine/gathering the system’s objectives and the
software’s requirements.
• Planning: Establish engineering work plan, describes technical risk, lists resources requirements,
work produced and defines work schedule.
• Modeling: Architectural models and design to better understand the problem and for work
towards the best solution. The software model is prepared by:
o Analysis of requirements
o Design
• Construction: Creating code, testing the system, fixing bugs, and confirming that all criteria are
met. The software design is mapped into a code by:
o Code generation
o Testing
• Deployment: In this activity, a complete or non-complete product or software is represented to
the customers to evaluate and give feedback. On the basis of their feedback, we modify the
product for the supply of better products.
Umbrella activities
Typical umbrella activities are:
1. Software project tracking and control
• In this activity, the developing team accesses project plan and compares it with the predefined
schedule.
• If these project plans do not match with the predefined schedule, then the required actions are
taken to maintain the schedule.
2. Risk management
• Risk is an event that may or may not occur.
• If the event occurs, then it causes some unwanted outcome. Hence, proper risk management is
required.
3. Software Quality Assurance (SQA)
• SQA is the planned and systematic pattern of activities which are required to give a guarantee of
software quality.
For example, during the software development meetings are conducted at every stage of
development to find out the defects and suggest improvements to produce good quality software.
4. Formal Technical Reviews (FTR)
• FTR is a meeting conducted by the technical staff.
• The motive of the meeting is to detect quality problems and suggest improvements.
• The technical person focuses on the quality of the software from the customer point of view.
5. Measurement
• Measurement consists of the effort required to measure the software.
• The software cannot be measured directly. It is measured by direct and indirect measures.
• Direct measures like cost, lines of code, size of software etc.
• Indirect measures such as quality of software which is measured by some other factor. Hence, it is
an indirect measure of software.
6. Software Configuration Management (SCM)
• It manages the effect of change throughout the software process.
7. Reusability management
• It defines the criteria for reuse the product.
• The quality of software is good when the components of the software are developed for certain
application and are useful for developing other applications.
8. Work product preparation and production
• It consists of the activities that are needed to create the documents, forms, lists, logs and user
manuals for developing a software.
The Capability Maturity Model Integration (CMMI)
The Capability Maturity Model Integration (CMMI) is a process model that guides organizations to
improve processes, boosts productivity and efficient behaviors during a project, product or service
development which results in risk reduction.
CMMI Goals
The objective of CMMI is to enhance the quality of the product/service by following a standard model
which fulfils customer expectations as well as increases the value of the organization in market.
CMMI Representation
There are two types of CMMI representation that allows an organization to follow a different set of
improvement goals.
1. Staged representation, which uses a pre-set process to create an improvement path.
Improvement path is find out by maturity levels.
2. Continuous representation focuses on specific process area.
It uses capability levels to assess and improve the development of a particular process area.
CMMI – Maturity Levels
According to the CMMI model organizational process maturity is divided into 5 levels. Once businesses
reach the maturity level they must focus on maintenance and regular progresses.
Maturity levels of CMMI are:

✓ Maturity Level 1: Initial

Processes are being conceptualized at this stage.
✓ Maturity Level 2: Managed
Projects are planned, implemented, measured and monitored at this level.
✓ Maturity Level 3: Defined
The main focus of this level is defining standard of the project.
✓ Maturity Level 4: Quantitatively managed
At this level project is in controlled position, processes offer high quality results with minimum
risk involved.
✓ Maturity Level 5: Optimizing:
Processes are safe and flexible at this level. Organizations optimize resources at this stage for
continuous improvement.
CMMI – Capability Levels
Apart from maturity levels, The CMMI has capability levels that are utilized to evaluate an organization’s
performance and process development related to a specific process area.

The capability levels are mentioned as below:

➢ Capability Level 0: Incomplete

Process is incomplete, goals are not set and standards are not met at this capability level.
➢ Capability Level 1: Initial
At this level performance issues regarding a particular process area are addressed.
➢ Capability Level 2: Managed
During this level, improvements in the process area become more visible.
➢ Capability Level 3: Defined
At this level organizational standards are followed and process standardization is prioritized.
➢ Capability Level 4: Quantitatively Managed
Process is being monitored using statistics and quantitative techniques.
➢ Capability Level 5: Optimizing
At this level, organization focus on continuous improvement of the process.

Process Models:
Software process is a collection of various activities.
There are five generic process framework activities:
1. Communication:
The software development starts with the communication between customer and developer.

2. Planning:
It consists of complete estimation, scheduling for project development and tracking.

3. Modeling:
• Modeling consists of complete requirement analysis and the design of the project like algorithm,
flowchart etc.
• The algorithm is the step-by-step solution of the problem and the flow chart shows a complete
flow diagram of a program.
 4. Construction:
• Construction consists of code generation and the testing part.
• Coding part implements the design details using an appropriate programming language.
• Testing is to check whether the flow of coding is correct or not.
• Testing also check that the program provides desired output.
5. Deployment:
• Deployment step consists of delivering the product to the customer and take feedback from them.
• If the customer wants some corrections or demands for the additional capabilities, then the
change is required for improvement in the quality of the software.
Prescriptive Process Models
The following framework activities are carried out irrespective of the process model chosen by the
organization.
1. Communication 4. Construction
2. Planning 5. Deployment
3. Modeling

The name 'prescriptive' is given because the model prescribes a set of activities, actions, tasks, quality
assurance and change the mechanism for every project.
There are three types of prescriptive process models. They are:
1. The Waterfall Model
2. Incremental Process model
3. RAD model
1. The Waterfall Model
• The waterfall model is also called as 'Linear sequential model' or 'Classic life cycle model'.
• In this model, each phase is fully completed before the beginning of the next phase.
• This model is used for the small projects.
• In this model, feedback is taken after each phase to ensure that the project is on the right path.
• Testing part starts only after the development is complete.

NOTE: The description of the phases of the waterfall model is same as that of the process model.
 An alternative design for 'linear sequential model' is as follows:

Advantages of waterfall model

• The waterfall model is simple and easy to understand, implement, and use.
• All the requirements are known at the beginning of the project, hence it is easy to manage.
• It avoids overlapping of phases because each phase is completed at once.
• This model works for small projects because the requirements are understood very well.
• This model is preferred for those projects where the quality is more important as compared to the cost
of the project.
Disadvantages of the waterfall model
• This model is not good for complex and object oriented projects.
• It is a poor model for long projects.
• The problems with this model are uncovered, until the software testing.
• The amount of risk is high.
2. Incremental Process model
• The incremental model combines the elements of waterfall model and they are applied in an iterative
fashion.
• The first increment in this model is generally a core product.
• Each increment builds the product and submits it to the customer for any suggested modifications.
• The next increment implements on the customer's suggestions and add additional requirements in the
previous increment.
• This process is repeated until the product is finished.
For example, the word-processing software is developed using the incremental model.
 Advantages of incremental model
• This model is flexible because the cost of development is low and initial product delivery is faster.
• It is easier to test and debug during the smaller iteration.
• The working software generates quickly and early during the software life cycle.
• The customers can respond to its functionalities after every increment.

Disadvantages of the incremental model

• The cost of the final product may cross the cost estimated initially.
• This model requires a very clear and complete planning.
• The planning of design is required before the whole system is broken into small increments.
• The demands of customer for the additional functionalities after every increment causes problem
during the system architecture.
3. RAD model
• RAD is a Rapid Application Development model.
• Using the RAD model, software product is developed in a short period of time (60-90 days).
• It requires heavy resources.
• It require multiple teams on scalable project.
• The initial activity starts with the communication between customer and developer.
• Planning depends upon the initial requirements and then the requirements are divided into groups.
• Planning is more important to work together on different modules.
The RAD model consist of following phases:
1. Business Modeling
• Business modeling consist of the flow of information between various functions in the project.
For example what type of information is produced by every function and which are the functions to
handle that information.
• A complete business analysis should be performed to get the essential business information.
2. Data modeling
• The information in the business modeling phase is refined into the set of objects and it is essential for
the business.
• The attributes of each object are identified and define the relationship between objects.
3. Process modeling
• The data objects defined in the data modeling phase are changed to fulfil the information flow to
implement the business model.
• The process description is created for adding, modifying, deleting or retrieving a data object.
4. Application generation
• In the application generation phase, the actual system is built.
• To construct the software the automated tools are used.
 5. Testing and turnover
• The prototypes are independently tested after each iteration so that the overall testing time is
reduced.
• The data flow and the interfaces between all the components are are fully tested. Hence, most of the
programming components are already tested.

Evolutionary Process Models

• Evolutionary models are iterative type models.
• They allow to develop more complete versions of the software.
Following are the evolutionary process models.

1. The prototyping model

2. The spiral model
3. Concurrent development model
1. The Prototyping model
• Prototype is defined as first or preliminary form using which other forms are copied or derived.
• Prototype model is a set of general objectives for software.
• It does not identify the requirements like detailed input, output.
• It is software working model of limited functionality.
• In this model, working programs are quickly produced.
The different phases of Prototyping model are:
1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the software.
2. Quick design
• Quick design is implemented when requirements are known.
• It includes only the important aspects like input and output format of the software.
• It focuses on those aspects which are visible to the user rather than the detailed plan.
• It helps to construct a prototype.
3. Modeling quick design
• This phase gives the clear idea about the development of software because the software is now
built.
• It allows the developer to better understand the exact requirements.
4. Construction of prototype
The prototype is evaluated by the customer itself.
5. Deployment, delivery, feedback
• If the user is not satisfied with current prototype then it refines according to the requirements
of the user.
• The process of refining the prototype is repeated until all the requirements of users are met.
• When the users are satisfied with the developed prototype then the system is developed on the
basis of final prototype.

Advantages of Prototyping Model

• Prototype model need not know the detailed input, output, processes, adaptability of operating
system and full machine interaction.
• In the development process of this model users are actively involved.
• The development process is the best platform to understand the system by the user.
• Errors are detected much earlier.
• Gives quick user feedback for better solutions.
• It identifies the missing functionality easily. It also identifies the confusing or difficult functions.

Disadvantages of Prototyping Model:

• The client involvement is more and it is not always considered by the developer.
• It is a slow process because it takes more time for development.
• Many changes can disturb the rhythm of the development team.
• It is a thrown away prototype when the users are confused with it.

2. The Spiral model

✓ Spiral model is a risk driven process model.
✓ It is used for generating the software projects.
✓ In spiral model, an alternate solution is provided if the risk is found in the risk analysis, then
alternate solutions are suggested and implemented.
✓ It is a combination of prototype and sequential model or waterfall model.
✓ In one iteration all activities are done, for large project's the output is small.
 The framework activities of the spiral model are as shown in the following figure.

NOTE: The description of the phases of the spiral model is same as that of the process model.
Advantages of Spiral Model
• It reduces high amount of risk.
• It is good for large and critical projects.
• It gives strong approval and documentation control.
• In spiral model, the software is produced early in the life cycle process.
Disadvantages of Spiral Model
• It can be costly to develop a software model.
• It is not used for small projects.
3. The concurrent development model
• The concurrent development model is called as concurrent model.
• The communication activity has completed in the first iteration and exits in the awaiting changes state.
• The modeling activity completed its initial communication and then go to the underdevelopment state.
• If the customer specifies the change in the requirement, then the modeling activity moves from the
under development state into the awaiting change state.
• The concurrent process model activities moving from one state to another state.
Advantages of the concurrent development model
• This model is applicable to all types of software development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
• It needs better communication between the team members. This may not be achieved all the time.
• It requires to remember the status of the different activities.
Unified process (UP)
The Unified Process (UP) is a software development framework used for object-oriented modeling.
It is also known as Rational Unified Process (RUP) and
The Open Unified Process (Open UP).
Some of the key features of this process include:
• It defines the order of phases.
• It is component-based, meaning a software system is built as a set of software components.
There must be well-defined interfaces between the components for smooth communication.
• It follows an architecture centric, use case driven, iterative and incremental development
process.

Phases
We can represent a unified process model as a series of cycles.
Each cycle ends with the release of a new system version for the customers.
We have four phases in every cycle:
• Inception
• Elaboration
• Construction
• Transition
Inception
The main goal of this phase involves delimiting the project scope. This is where we define why we are
making this product in the first place. It should have the following:
• What are the key features?
• How does this benefit the customers?
• Which methodology will we follow?
• What are the risks involved in executing the project?
• Schedule and cost estimates.

Elaboration
We build the system given the requirements, cost, and time constraints and all the risks involved. It
should include the following:
• Develop with the majority of the functional requirements implemented.
• Finalize the methodology to be used.
• Deal with the significant risks involved.

Construction
This phase is where the development, integration, and testing take place. We build the complete
architecture in this phase and hand the final documentation to the client.

Transition
This phase involves the deployment, multiple iterations, beta releases, and improvements of the
software. The users will test the software, which may raise potential issues. The development team will
then fix those errors.

Conclusion
This method allows us to deal with the changing requirements throughout the development period. The
unified process model has various applications which also makes it complex in nature. Therefore, it's
most suitable for smaller projects and should be implemented by a team of professionals.