Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Software Engineering: Maintenance, Reengineering, and Project Management, Study notes of Software Engineering

Lecture notes for software maintenance

Typology: Study notes

2017/2018

Uploaded on 04/18/2018

pawan-kumar-shah
pawan-kumar-shah 🇮🇳

4.4

(5)

2 documents

1 / 13

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
ASSIGNMENT-02
Unit-5
SOFTWARE MAINTENANCE
NAME: PAWAN KUMAR SHAH
ENROLL NO: 0822IT151041
SOFTWARE MAINTENANCE
Definition:
o Software maintenance is a part of Software Development Life Cycle. Its main
purpose is to modify and update software application after delivery to correct faults
and to improve performance. Software is a model of the real world. When the real-
world changes, the software requires alteration wherever possible.
There are four categories of software change:
I. Corrective
II. Adaptive
III. Perfective
IV. Preventive
I. Corrective Change
Corrective change, most commonly referred to as “bugs,” is the most typical change
associated with maintenance work. Corrective changes address errors and faults in
your software that could affect various areas of your software; design, logic or code.
Most commonly, these changes are sprung by bug reports created by users. It is
important to note that sometimes problem reports submitted by users are actually
enhancements of the system not bugs.
II. Adaptive Changes
Adaptive change is triggered by changes in the environment your software lives in.
An adaptive change can be triggered by changes to the operating system, hardware,
software dependencies and even organizational business rules and policies. For
example, updating the server, compilers, etc or modifications to shipping carriers and
payment processors can affect functionality in your software.
III. Perfective Changes
Perfective changes refer to the evolution of requirements and features in your
existing system. As your software gets exposed to users they will think of different
ways to expand the system or suggest new features that they would like to see as part
of the software, which in turn can become future enhancements to the system.
Surprisingly, 50-55% of most maintenance work is attributed to perfective changes.
pf3
pf4
pf5
pf8
pf9
pfa
pfd

Partial preview of the text

Download Software Engineering: Maintenance, Reengineering, and Project Management and more Study notes Software Engineering in PDF only on Docsity!

ASSIGNMENT- 02

Unit- 5

SOFTWARE MAINTENANCE

NAME: PAWAN KUMAR SHAH

ENROLL NO: 0822IT

SOFTWARE MAINTENANCE

  • Definition: o Software maintenance is a part of Software Development Life Cycle. Its main purpose is to modify and update software application after delivery to correct faults and to improve performance. Software is a model of the real world. When the real- world changes, the software requires alteration wherever possible. There are four categories of software change: I. Corrective II. Adaptive III. Perfective IV. Preventive I. Corrective Change Corrective change, most commonly referred to as “bugs,” is the most typical change associated with maintenance work. Corrective changes address errors and faults in your software that could affect various areas of your software; design, logic or code. Most commonly, these changes are sprung by bug reports created by users. It is important to note that sometimes problem reports submitted by users are actually enhancements of the system not bugs. II. Adaptive Changes Adaptive change is triggered by changes in the environment your software lives in. An adaptive change can be triggered by changes to the operating system, hardware, software dependencies and even organizational business rules and policies. For example, updating the server, compilers, etc or modifications to shipping carriers and payment processors can affect functionality in your software. III. Perfective Changes Perfective changes refer to the evolution of requirements and features in your existing system. As your software gets exposed to users they will think of different ways to expand the system or suggest new features that they would like to see as part of the software, which in turn can become future enhancements to the system. Surprisingly, 50-55% of most maintenance work is attributed to perfective changes.

IV. Preventive Changes Preventive changes refer to changes made to increase the understanding and maintainability of your software in the long run. Restructuring, optimizing code and updating documentation are common preventive changes. Executing preventive changes reduces the amount of unpredictable effects a software can have in the long term and helps it become scalable, stable, understandable and maintainable. RE-ENGINEERING

  • Software re-engineering means re-structuring or re-writing part or all of the software engineering system. It is needed for the application which requires frequent maintenance.
  • Software re-engineering is a process of software development which is done to improve the maintainability of a software system.
  • Re-engineering a software system has two key advantages: Reduced risk: As the software already exists, the risk is less as compared to developing new software. Reduced cost: The cost of re-engineering is significantly less than the costs of developing new software.
  • Re-engineering process activities:
    • Source code translation: In this phase code is converted into new language.
    • Reverse Engineering: Under this activity the program is analysed and understood thoroughly.
    • Program structure improvement : Restructure automatically for understandability.
    • Program modularization: The program structure is reorganized. Data re-engineering: Finally, clean-up and restructure system data. Figure 1 Types of Maintenance

Advantages

  • BPR directly addresses non-value adding activities in the form of administrative overheads.
  • BPR directly addresses business processes which are customer centric and non- function centric
  • BPR offers four R’s to the organization, namely: o Revitalize o Restructure o Reposition o Renew Development Methodology for BPR
  1. Develop vision and objectives
  2. Identify process for redesign
  3. Understand and measure existing process
  4. Identify IT levels
  5. Pilot\ trial new process
  6. Develop supply solution
  7. Make new process operational
  8. Ongoing continuous improvement REVERSE ENGINEERING: Reverse engineering is the process of design recovery. In reverse engineering the data, architectural and procedural information is extracted from a source code. The reverse engineering is required because using this technique the dirty, ambiguous code can be converted to clear and unambiguous specification. This specification helps in understanding the source code. There are 3 important issues in reverse engineering: i. Abstraction Level: This level helps in obtaining the design information from the source code. It is expected that abstraction level should be high in reverse engineering. ii. Completeness Level: The completeness means detailing of abstract level. The completeness decreases as abstraction level increases. iii. Directionality Level: Directionality means extracting the information from source code and gives it to software engineer. The directionality can be one way or two ways. The one-way directionality means extracting all the information from source code and gives it to software engineer. The two-way directionality means the information taken from source code is fed to re-engineering tool that attempts to restructure or regenerate old programs.

PROGRAM RECONSTRUCTING

It is a process to re-structure and re-construct the existing software. It is all about re- arranging the source code, either in same programming language or from one programming language to a different one. Restructuring can have either source code-restructuring and data-restructuring or both. Re-structuring does not impact the functionality of the software but enhance reliability and maintainability. Program components, which cause errors very frequently can be changed, or updated with re-structuring. The dependability of software on obsolete hardware platform can be removed via re- structuring. FORWARD ENGINEERING Forward engineering is a process of obtaining desired software from the specifications in hand which were brought down by means of reverse engineering. It assumes that there was some software engineering already done in the past. Forward engineering is same as software engineering process with only one difference – it is carried out always after reverse engineering. Figure 3 Reverse Engineering Process Figure 4 Forward Engineering

PROJECT SCHEDULING AND TRACKING PLAN

Project Scheduling: Project Scheduling in a project refers to roadmap of all activities to be done with specified order and within time slot allotted to each activity. Project managers tend to define various tasks and project milestones and then arrange them keeping various factors in mind. They look for tasks like in critical path in the schedule, which are necessary to complete in specific manner (because of task interdependency) and strictly within the time allocated. During the project scheduling the total work is separated into various small activities. For scheduling a project, it is necessary to:

  • Break down the project tasks into smaller, manageable form
  • Find out various tasks and correlate them
  • Estimate time frame required for each task
  • Divide time into work-units
  • Assign adequate number of work-units for each task
  • Calculate total time required for the project from start to finish Tracking the schedule means determine the tasks and milestone in the project as it proceeds. Following are the various ways by which tracking of the project can be achieved:
  • Conduct periodic meetings.
  • Evaluate results of all the project reviews.
  • Compare actual start date and scheduled start date of each of the project task.
  • Determine if milestones of the project are achieved on scheduled date or not.
  • Meet informally to the software practitioners.
  • Assess the progress of the project quantitatively.    PROJECT MANAGEMENT CONCEPTS: Software project management is an activity of organizing, planning and scheduling the software projects. The goal of software project management is to deliver the software product in given time and within the budget. It is also necessary that the software project should be developed in accordance with the requirements of the organization. The project management is the application of knowledge, skill, tools and techniques to project activities to meet the project requirements. Figure 5 Project Scheduling Process

Objectives of project management: o The objective of the project planning and management is to provide a framework for the project. o Using the project framework, the project manager decides the estimates for the schedule, cost and resources. o Another objective of the project planning and management is that- it should be possible to get the best case and worst-case outcomes of the project. o There should be sufficient information discovery through the project so that reasonable project estimate can be made. SOFTWARE QUALITY ASSURANCE (SQA): Software Quality : In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance). Quality Control: Quality control (QC) is a procedure or set of procedures intended to ensure that a manufactured product or performed service adheres to a defined set of quality criteria or meets the requirements of the client or customer. Quality Assurance: It is planned and systematic pattern of activities necessary to provide a high degree of confidence in the quality of a product. It provides quality assessment of the quality control activities and determines the validity of the data or procedures for determining quality. SQA Activities to Assure the Software Quality The Software Quality Assurance of the software is analysed and ensured by performing a series of activities. The activities are performed as step by step process and the result analysis is reported for the final evaluation process. The activities are performed as step by step process and the result analysis is reported for the final evaluation process.

  • A Quality Management Plan is prepared
  • Application of Technical Methods (Employing proper methods and tools for developing software)
  • Conduct of Formal Technical Review (FTR)
  • Testing of Software
  • Enforcement of Standards (Customer imposed standards or management-imposed standards)
  • Control of Change (Assess the need for change, document the change)
  • Measurement (Software Metrics to measure the quality, quantifiable)
  • Records Keeping and Recording (Documentation, reviewed, change control etc. i.e. benefits of docs).

CMM (CAPABILITY MATURITY MODEL)

What is capability maturity model? The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an increasing series of levels of a software development organization. The higher the level, the better the software development process, hence reaching each level is an expensive and time- consuming process. Levels of CMM

  • 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 Figure 6 : SCM Process

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 organization 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. 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. Figure 7 Levels of CMM

What Is A Component-Based System?

  • A component-based system has the following divide-and-conquer feature. o A component-based system is a system in which a major relationship between the components is tree-shaped or reducible.
  • Consequence: the entire system can be reduced to one abstract node o at least along the structuring relationship
  • Systems with layered relations (dag-like relations) are not necessarily component- based. o Because they cannot be reduced What Is A Component-Based System?
  • Because of the divide-and-conquer property, component-based development is attractive.
  • However, we have to choose the structuring relation
  • And, we have to choose the composition model
  • Mainly, 2 types of models are known o Modular decomposition (black box) o Separation of concerns (grey box)