0% found this document useful (0 votes)
34 views14 pages

SE 1-1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
34 views14 pages

SE 1-1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

SOFTWARE ENGINEERING

Q. What are the characteristics of Software?


Software
Software is a collection of instructions, data, or computer programs that are used to run machines and
carry out particular activities.
Software takes Dual role of Software. It is a Product and at the same time a Vehicle for delivering a
product.
Defining Software
Software is defined as:--
1. Instructions: Programs that when executed provide desired function, features, and performance
2. Data structures: Enable the programs to adequately manipulate information
3. Documents: Descriptive information in both hard copy and virtual forms that describes the operation
and use of the programs.
Characteristics of software
Software has characteristics that are considerably different than those of hardware:
1) Software is developed or engineered, it is not manufactured in the Classical Sense.
Although some similarities exist between software development and hardware manufacture, the two
activities are fundamentally different. In both the activities, high quality is achieved through good
design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent
or easily corrected for software. Both the activities are dependent on people, but the relationship
between people is totally varying. These two activities require the construction of a "product" but the
approaches are different. Software costs are concentrated in engineering which means that software
projects cannot be managed as if they were manufacturing.
2) Software doesn't "Wear Out"
The following figure shows the relationship between failure rate and time. Consider the failure rate as a
function of time for hardware. The relationship is called the bathtub curve, indicates that hardware
exhibits relatively high failure rates early in its life, defects are corrected and the failure rate drops to a
steady-state level for some period of time. As time passes, however, the failure rate rises again as
hardware components suffer from the cumulative effects of dust, vibration, abuse, temperature
extremes, and many other environmental maladies. So,stated simply, the hardware begins to wear out.
Software is not susceptible to the environmental maladies that cause hardware to wear out.
3) Although the industry is moving toward component-based construction, most software continues
to be custom built
A software component should be designed and implemented so that it can be reused in many different
programs. Modern reusable components encapsulate both data and the processing that is applied to the
data, enabling the software engineer to create new applications from reusable parts

Q. What are Software Myths? Explain.


Software Myths--Most, experienced experts have seen myths or superstitions (false beliefs or
interpretations) or misleading attitudes (naked users) which creates major problems for management
and technical people. The types of software-related myths are listed below.

Types Of
myths

Management Customer Practitioner's


Myths Myths Myths

`Types of Software Myths

(i) Management Myths:


Myth 1:
We have all the standards and procedures available for software development.
Fact:
 Software experts do not know all the requirements for the software development.
 And all existing processes are incomplete as new software development is based on new and
different problem.
Myth 2:
The addition of the latest hardware programs will improve the software development.
Fact:
 The role of the latest hardware is not very high on standard software development; instead (CASE)
Engineering tools help the computer, they are more important than hardware to produce quality
and productivity.
Myth 3:
 With the addition of more people and program planners to Software development can help meet
project deadlines (If lagging behind).
Fact:
 If software is late, adding more people will merely make the problem worse. This is because the
people already working on the project now need to spend time educating the newcomers, and are
thus taken away from their work. The newcomers are also far less productive than the existing
software engineers, and so the work put into training them to work on the software does not
immediately meet with an appropriate reduction in work.
(ii)Customer Myths:
The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customer has myths leading to false expectations (customer) & that’s
why you create dissatisfaction with the developer.
Myth 1:
A general statement of intent is enough to start writing plans (software development) and details of
objectives can be done over time.
Fact:
 Official and detailed description of the database function, ethical performance, communication,
structural issues and the verification process are important.
Software requirements continually change, but change can be easily accommodated because software
is flexible
Fact:
 It is true that software requirements change, but the impact of change varies with the time at
which it is introduced. When requirements changes are requested early the cost impact is
relatively small.

(iii)Practitioner’s Myths:
Myths 1:
They believe that their work has been completed with the writing of the plan.
Fact:
 It is true that every 60-80% effort goes into the maintenance phase (as of the latter software
release). Efforts are required, where the product is available first delivered to customers.
Myths 2:
There is no other way to achieve system quality, until it is “running”.
Fact:
 Systematic review of project technology is the quality of effective software verification
method. These updates are quality filters and more accessible than test.
Myth 3:
An operating system is the only product that can be successfully exported project.
Fact:
 A working system is not enough, the right document brochures and booklets are also required to
provide guidance & software support.
Myth 4:
Engineering software will enable us to build powerful and unnecessary document & always delay us.
Fact:
 Software engineering is not about creating documents. It is about creating a quality product.
Better quality leads to reduced rework. And reduced rework results in faster delivery times

Q. Explain Waterfall Process Model & Incremental Process Model.


Waterfall Process Model
The classical waterfall model is the basic software development life cycle model. It is very simple but
idealistic. Earlier this model was very popular but nowadays it is not used. However, it is very
important because all the other software development life cycle models are based on the classical
waterfall model.
The waterfall model is a software development model used in the context of large, complex projects,
typically in the field of information technology. It is characterized by a structured, sequential
approach to project management and software development.
Importance of Waterfall Model
1. Clarity and Simplicity: The linear form of the Waterfall Model offers a simple and unambiguous
foundation for project development.
2. Clearly Defined Phases: The Waterfall Model’s phases each have unique inputs and outputs,
guaranteeing a planned development with obvious checkpoints.
3. Documentation: A focus on thorough documentation helps with software comprehension,
upkeep, and future growth.
4. Stability in Requirements: Suitable for projects when the requirements are clear and steady,
reducing modifications as the project progresses.
5. Resource Optimization: It encourages effective task-focused work without continuously changing
contexts by allocating resources according to project phases.
6. Relevance for Small Projects: Economical for modest projects with simple specifications and
minimal complexity.
Phases of Waterfall Model – Design
The Waterfall Model has six phases which are:
Requirements analysis

Software Design

Development

Testing

Deployment

Maintenance

1. Requirements Analysis: The first phase involves gathering requirements from stakeholders and
analyzing them to understand the scope and objectives of the project.
2. Software Design: Once the requirements are understood, the design phase begins. This involves
creating a detailed design document that outlines the software architecture, user interface, and
system components.
3. Development: The Development phase include implementation involves coding the software based
on the design specifications. This phase also includes unit testing to ensure that each component of
the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the
requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the production
environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance, which involves fixing any
issues that arise after the software has been deployed and ensuring that it continues to meet the
requirements over time.

Advantages of Waterfall model


 This model is simple to implement also the number of resources that are required for it is
minimal.
 The requirements are simple and explicitly declared; they remain unchanged during the entire
project development.
 The start and end points for each phase is fixed, which makes it easy to cover progress.
 The release date for the complete product, as well as its final cost, can be determined before
development.
 It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model


 In this model, the risk factor is higher, so this model is not suitable for more significant and
complex projects.
 This model cannot accept the changes in requirements during development.
 It becomes tough to go back to the phase. For example, if the application has now shifted to
the coding phase, and there is a change in requirement, It becomes tough to go back and
change it.
 Since the testing done at a later stage, it does not allow identifying the challenges and risks in
the earlier phase, so the risk reduction strategy is difficult to prepare.

Incremental Process Model


Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle. In this model, each module goes through the
requirements, design, implementation and testing phases. Every subsequent release of the module
adds function to the previous release. The process continues until the complete system achieved.

Incremental software development, which is a fundamental part of agile approaches is better than a
waterfall approach for must business, e-commerce, and personal systems.

Incremental development is based on the idea of developing an initial implementations, exposing this
to user comment and evolving it through several versions until an adequate system has been
developed.

1. Communication
2. Planning
3. Modeling(analysis,design)
4. Construction(code,text)
Software functionality and features

5. Deployment(delivery,feedback)

Increment # n
Increment #2 delivery of nth increment

Increment #1 delivery of 2nd increment

delivery of 1st increment

Project Calender Time

Phases of incremental model


Requirements of Software are first broken down into several modules that can be incrementally
constructed and delivered

1. Requirement analysis: In Requirement Analysis At any time, the plan is made just for the next
increment and not for any kind of long-term plan. Therefore, it is easier to modify the version
as per the needs of the customer.
2. Design & Development: At any time, the plan is made just for the next increment and not for
any kind of long-term plan. Therefore, it is easier to modify the version as per the needs of the
customer. The Development Team first undertakes to develop core features (these do not
need services from other features) of the system. Once the core features are fully developed,
then these are refined to increase levels of capabilities by adding new functions in Successive
versions. Each incremental version is usually developed using an iterative waterfall model of
development.
3. Testing and Deployment: After Requirements gathering and specification, requirements are
then split into several different versions starting with version 1, in each successive increment,
the next version is constructed and then deployed at the customer site. in development and
Testing the product is checked and tested for the actual process of the model.
4. Implementation: In implementation After the last version (version n), it is now deployed at
the client site.
Characteristics of Incremental Process Model
1. System development is divided into several smaller projects.
2. To create a final complete system, partial systems are constructed one after the other.
3. Priority requirements are addressed first.
4. The requirements for that increment are frozen once they are created.
Advantages of the Incremental Process Model
1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Provides risk handling support, because of its iterations.
5. Adjusting the criteria and scope is flexible and less costly.
6. Comparing this model to others, it is less expensive.
7. The identification of errors is simple.
Disadvantages of the Incremental Process Model
1. A good team and proper planned execution are required.
2. Because of its continuous iterations the cost increases.
3. Issues may arise from the system design if all needs are not gathered upfront throughout the
program lifecycle.
4. Every iteration step is distinct and does not flow into the next.
5. It takes a lot of time and effort to fix an issue in one unit if it needs to be corrected in all the units.

Q. Explain Unified Process Model. Explain about Scrum in software


development?

Unified Process Model


The Unified Process (UP) is a software development methodology that emphasizes iterative
development, collaboration, and flexibility. It is based on the Unified Modeling Language (UML) and is
characterized by its use of use cases to drive development, its focus on architecture-centric
development, and its emphasis on risk management and incremental delivery. UP is a flexible and
adaptable process that can be tailored to meet the specific needs of a project or organization, making
it a popular choice for many software development teams.
Deployment Communication

Transition Inception

Construction Planning

Elaboration
Construction
Modelling

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 iterative, incremental, architecture-centric, and use-case driven approach

Let's have a look at these approaches in detail.

The case-driven approach

Use a case-driven approach that follows a set of actions performed by one or more entities. A use case
refers to the process of the team performing the development work from the functional requirements.
The functional requirements are made from the list of requirements that were specified by the client.
For example, an online learning management system can be specified in terms of use cases such as "add
a course," "delete a course," "pay fees," and so on.

The architecture-centric approach

The architecture-centric approach defines the form of the system and how it should be structured to
provide a specific functionality whereas the use case defines the functionality.

The iterative and incremental approach

An iterative and incremental approach means that the product will be developed in multiple phases.
During these phases, the developers evaluate and test.
Phases

Inception
Defines objetive Elaboration
of project
Planning the Construction
project Transition
Initial operationa
capability Final Release of
the product

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.

Advantages

Flexibility: UP can adapt to changing needs from customers or the project itself.

Documentation: UP emphasizes the importance of thorough documentation.

Integration: UP requires integration throughout the software development process.

Quality: UP is well suited for building and maintaining high-quality complex products.

Collaboration: UP can improve collaboration between teams and with clients.

Budget: UP can help ensure effective use of a budget.

Disadvantages

Complexity: UP is a complex process that can be difficult to learn and apply correctly.

Cost and time: The documentation required for UP can be time-consuming and expensive.

Expert reliance: UP relies on experts to assign activities and produce results.

SCRUM :

Scrum is a management framework that teams use to self-organize and work towards a common goal. It
describes a set of meetings, tools, and roles for efficient project delivery. Much like a sports team
practicing for a big match, Scrum practices allow teams to self-manage, learn from experience, and
adapt to change. Software teams use Scrum to solve complex problems cost effectively and sustainably.

Scrum is a framework that's part of the larger Agile project management philosophy. Agile is a set of
principles and values that help teams adapt to change, while Scrum is a specific methodology that helps
teams structure their work.

While Scrum is an Agile methodology, not all Agile projects use Scrum. There are many different
methodologies that use an Agile approach to project management
Scrum artifacts

Scrum Teams use tools called Scrum artifacts to solve problems and manage projects. Scrum artifacts
provide critical planning and task information to team members and stakeholders. There are three
primary artifacts:

1. Product Backlog

The Product Backlog is a dynamic list of features, requirements, enhancements, and fixes that must be
completed for project success. It is essentially the team’s to-do list, which is constantly revisited and
reprioritized to adapt to market changes. The product owner maintains and updates the list, removing
irrelevant items or adding new requests from customers.

2. Sprint Backlog

The Sprint Backlog is the list of items to be completed by the development team in the current Sprint
cycle. Before each Sprint, the team chooses which items it will work on from the Product Backlog. A
Sprint Backlog is flexible and can evolve during a Sprint.

3. Increment

The Increment is a step towards a goal or vision. It is the usable end product from a Sprint. Teams can
adopt different methods to define and demonstrate their Sprint Goals. Despite the flexibility, the
fundamental Sprint Goal—what the team wants to achieve from the current Sprint—can’t be
compromised.

For example, some teams choose to release something to their customers at the end of the Sprint, so
their Sprint Goal would be completed once the software change is released. Other teams might work on
completing a set of features that will be released together. In this case, the Sprint Goal would be
completed when a feature is tested successfully.

Scrum roles

A Scrum Team needs three specific roles: a Product Owner, Scrum leader, and development team.

Product Owner

The Product Owner focuses on ensuring the development team delivers the most value to the business.
They understand and prioritize the changing needs of end users and customers. Effective product
owners do the following:

 Give the team clear guidance on which features to deliver next.

 Bridge the gap between what the business wants and what the team understands.

 Decide when and how frequently releases should happen.

Scrum leader

Scrum leaders are the champions for Scrum within their teams. They are accountable for the Scrum
Team’s effectiveness. They coach teams, Product Owners, and the business to improve its Scrum
processes and optimize delivery. Scrum leaders are also responsible for doing the following:

 Schedule the resources needed for each Sprint.

 Facilitate other Sprint events and team meetings.


 Lead digital transformation within the team.

 Facilitate any team training when adopting new technologies.

 Communicate with external groups to solve any challenges the team might be facing as a whole.

Scrum development team

The Scrum Team consists of testers, designers, UX specialists, Ops engineers, and developers. Team
members have different skill sets and cross-train each other, so no one person becomes a bottleneck in
delivering work.
Jeff Bezos, the founder of Amazon, recommends the two-pizza rule when deciding team size:A team
should be small enough to share two pizzas.

Scrum development teams do the following:

 Work collaboratively to ensure a successful Sprint completion.

 Champion sustainable development practices.


 Self-organize and approach their projects with an evident we attitude.

 Drive the planning and estimating for how much work they can complete for each Sprint.
Advantage of Scrum framework

 Scrum framework is fast moving and money efficient.

 Scrum framework works by dividing the large product into small sub-products. It’s like a divide
and conquer strategy

 In Scrum customer satisfaction is very important.


 Scrum is adaptive in nature because it have short sprint.

 As Scrum framework rely on constant feedback therefore the quality of product increases in less
amount of time
Disadvantage of Scrum framework

 Scrum framework do not allow changes into their sprint.

 Scrum framework is not fully described model. If you wanna adopt it you need to fill in the
framework with your own details like Extreme Programming(XP), Kanban, Dynamic Systems
Development Method (DSDM).

 It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear
definition.

 The daily Scrum meetings and frequent reviews require substantial resources.

You might also like