Software Evolution is a term which refers to the process of developing software initially, CMMI It is not a software process model.
ess model. It is a framework that is used to analyze the
then timely updating it for various reasons, i.e., to add new features or to remove obsolete
functionalities etc. The evolution process includes fundamental activities of change
analysis, release planning, system implementation and releasing a system to customers.
The cost and impact of these changes are accessed to see how much system is affected by
the change and how much it might cost to implement the change. If the proposed changes
are accepted, a new release of the software system is planned. During release planning, all
the proposed changes (fault repair, adaptation, and new functionality) are considered.
A design is then made on which changes to implement in the next version of the system.
The process of change implementation is an iteration of the development process where
the revisions to the system are designed, implemented and tested. >> The necessity of
Software evolution: Software evaluation is necessary just because of the
following reasons:
a) Change in requirement with time: With the passes of time, the organization’s needs and
modus Operandi of working could substantially be changed so in this frequently changing
time the tools(software) that they are using need to change for maximizing the
performance.b) Environment change: As the working environment changes the
things(tools) that enable us to work in that environment also changes proportionally same
happens in the software world as the working environment changes then, the
organizations need reintroduction of old software with updated features and functionality
to adapt the new environment.c) Errors and bugs: As the age of the deployed software
within an organization increases their preciseness or impeccability decrease and the
efficiency to bear the increasing complexity workload also continually degrades. So, in that
case, it becomes necessary to avoid use of obsolete and aged software. All such obsolete
Softwares need to undergo the evolution process in order to become robust as per the
workload complexity of the current environment. d) Security risks: Using outdated
software within an organization may lead you to at the verge of various software-based
cyberattacks and could expose your confidential data illegally associated with the software
that is in use. So, it becomes necessary to avoid such security breaches through regular
assessment of the security patches/modules are used within the software. If the software
isn’t robust enough to bear the current occurring Cyber attacks so it must be changed
(updated).e) For having new functionality and features: In order to increase the
performance and fast data processing and other functionalities, an organization need to
continuously evolute the software throughout its life cycle so that stakeholders & clients of
the product could work efficiently.
CHARS It is intangible, meaning it cannot be seen or touched.>>It is non-perishable,
meaning it does not degrade over time.
>>It is easy to replicate, meaning it can be copied and distributed easily.
>>It can be complex, meaning it can have many interrelated parts and features.
>>It can be difficult to understand and modify, especially for large and complex systems.
>>It can be affected by changing requirements, meaning it may need to be updated or
modified as the needs of users change.>>It can be affected by bugs and other issues,
meaning it may need to be tested and debugged to ensure it works as intended.
SRS The production of the requirements stage of the software development process is
Software Requirements Specifications (SRS) (also called a requirements document). This
report lays a foundation for software engineering activities and is constructing when entire
requirements are elicited and analyzed. SRS is a formal report, which acts as a
representation of software that enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user requirements for a system as well
as detailed specifications of the system requirements.
The SRS is a specification for a specific software product, program, or set of applications
that perform particular functions in a specific environment. It serves several goals
depending on who is writing it. First, the SRS could be written by the client of a system.
Second, the SRS could be written by a developer of the system. The two methods create
entirely various situations and establish different purposes for the document altogether.
The first case, SRS, is used to define the needs and expectation of the users. The second
case, SRS, is written for various purposes and serves as a contract document between
customer and developer.
CHARS>> Correctness: User review is used to provide the accuracy of requirements stated
in the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from
the system. 2 Completeness: The SRS is complete if, and only if, it includes the following
elements:(1). All essential requirements, whether relating to functionality, performance,
design, constraints, attributes, or external interfaces.(2). Definition of their responses of
the software to all realizable classes of input data in all available categories of situations. 3.
Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict.4Unambiguousness: SRS is unambiguous when every fixed
requirement has only one interpretation. This suggests that each element is uniquely
interpreted. In case there is a method used with multiple definitions, the requirements
report should determine the implications in the SRS so that it is clear and simple to
understand. 5 Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the significance or
stability of that particular requirement.6Modifiability: SRS should be made as modifiable as
likely and should be capable of quickly obtain changes to the system to some extent.
Modifications should be perfectly indexed and cross-referenced. 7 Verifiability: SRS is
correct when the specified requirements can be verified with a cost-effective system to
check whether the final software meets those requirements. The requirements are verified
with the help of reviews. 8 Traceability: The SRS is traceable if the origin of each of the
requirements is clear and if it facilitates the referencing of each condition in future
development or enhancement documentation.9Design Independence: There should be an
option to select from multiple design alternatives for the final system. More specifically,
the SRS should not contain any implementation details. 10Testability: An SRS should be
written in such a method that it is simple to generate test cases and test plans from the
report. 11Understandable by the customer: An end user may be an expert in his/her
explicit domain but might not be trained in computer science.12 The right level of
abstraction: If the SRS is written for the requirements stage, the details should be
explained explicitly.
approach and techniques followed by any organization to develop software products. It
also provides guidelines to further enhance the maturity of the process used to develop
those software products. It is based on profound feedback and development practices
adopted by the most successful organizations worldwide. This model describes a strategy
for software process improvement that should be followed by moving through 5 different
levels. Each level of maturity shows a process capability level. All the levels except level 1
are further described by Key Process Areas (KPA).
Principles of Capability Maturity Model (CMM) People’s capability is a competitive issue.
Competition arises when different organizations are performing the same task (such as
software development). In such a case, the people of an organization are sources of
strategy and skills, which in turn results in better performance of the organization.>> The
people’s capability should be defined in relation to the business objectives of the
organization>>>An organization should invest in improving the capabilities and skills of the
people as they are important for its success.>> The management should be responsible for
enhancing the capability of the people in the organization. >>The improvement in the
capability of people should be done as a process. This process should incorporate
appropriate practices and procedures.>> The organization should be responsible for
providing improvement opportunities so that people in the organization can take
advantage of them. >>Since new technologies and organizational practices emerge rapidly,
organizations should continually improve their practices and develop the abilities of
people. 5 LEVLS Level 1: Initial At the first level, the software development process is ad
hoc and occasionally chaotic. Success depends on individual effort, as few processes are
clearly defined. The success of the development process depends on the managers, who
are often able to withstand the pressure to speed up the process 2 Repeatable At the
repeatable level, project management processes include cost, schedule, and functionality
tracking. For projects with similar applications, the procedure is already in place to build on
prior successes. 3 Defined At the defined level, the software development process is
standardized, integrated into all organizational processes, and managed by management
and software engineering teams. Each project follows an approved version of the
organization’s standard software development and maintenance process. 4 Managed At
the managed level, software development is checked and controlled in great detail to
ensure high-quality products. the managed level refers to a process capability where an
organization can predict how its quality will change and take appropriate action when
necessary. Optimizing At the optimizing level, the quantitative feedback from the process
and experimenting with innovative ideas and technologies help continuous improvement.
WATERFALL MODEL It is the first approach and the basic model used in software
development. It is a simple model that is easy to use as well as understand. The execution
happens in the sequence order, which means that the outcome of the one-stage is equal to
the input of another stage. That's why it is also known as the Linear-sequential life cycle
model.//To avoid the overlapping issues of the multiple phases, every stage should be
completed before moving to the next stage. Each stage of the waterfall model involves the
deliverable of the previous stage, like requirements, are transferred to the design phase,
design moved to development, and so on. When we have the Life critical (hospital
application) and Machine critical (Military project), we will widely use the waterfall model.
// The waterfall model is a linear, sequential approach to the software development
lifecycle (SDLC) that is popular in software engineering and product development.
The waterfall model uses a logical progression of SDLC steps for a project, similar to the
direction water flows over the edge of a cliff. It sets distinct endpoints or goals for each
phase of development. Those endpoints or goals can't be revisited after their completion.
Dr. Winston W. Royce at the Lockheed Software Technology Center introduced the concept
in a paper published in 1970 on his experience developing software for satellites. However,
Royce didn't use the term waterfall; instead, he referred to the downstream value of
documentation. // This methodology is good for teams and projects that want to
develop a project according to fixed or unchanging requirements set forth at the
beginning of the project. Waterfall projects have a high degree of process definition
with little or no output variability. Waterfall is also a good choice if the project is
constrained by cost or time.
The waterfall model continues to be used in industrial design applications. It's often cited
as the first software development methodology. The model is also used more generally as
a high-level project management methodology for complicated, multifaceted projects.
The waterfall model is divided into various stages, which are as follows:1 Requirement
collection2Feasibility study3Design4Coding5TESTING6Installation
7Maintenance
UMBRELLA ACTIVITIES Software engineering is a collection of interconnected phases. These
steps are expressed or available in different ways in different software process models.
Umbrella activities are a series of steps or procedures followed by a software development
team to maintain the progress, quality, changes, and risks of complete development tasks.
These steps of umbrella activities will evolve through the phases of the generic view of
software development.
i. Software Project tracking and control: It allows the software team to assess progress
against the project plan and take necessary action to maintain the schedule.
ii. Formal Technical Reviews: It assesses software engineering work products to uncover
and remove errors before they are propagated to the next action or activity.
iii. Software Quality Assurance: It defines and conducts the activities required to ensure
software quality. It is a methodology of checking the software development process with a
predefined set of standards.
iv. Software Configure Management: It is the task of tracking and controlling changes in the
software development part. It manages the effects of change throughout the software
process.v. Documentation: At first, all the project planning and other activities should be
hard-copy documents and then the production gets started here.
vi. Re-usability Management: It defines criteria for work product reuse and establishes
mechanisms to achieve reusable components.
vii. Measurement: It defines process, project and product measures that assist the team in
delivering software that meets customer’s needs, it can be used in conjunction with all
other frameworks.