1.1 Software Engineering Approach

UNIT 1

Introduction & Software Processes

Software engineering works with a variety of software production methods. It accompanies software product development using well-defined scientific principles, methods and processes. The result of software engineering is an efficient and reliable software product.

The term software engineering is coined with the addition of 'software + Engineering'.

Software is more than just program code. The program is a usable code, which serves a specific calculation purpose. Software is considered a collection of effective editing code, compatible libraries and texts. Software, when required for a specific purpose, is called product software.

Engineering, on the other hand, is about making products, using well-defined scientific principles and methods.

There are some definitions of software engineering provided by some famous authors:

(1) The use of a systematic, directed, unparalleled approach to software development, operation and maintenance; that is, the use of engineering in software. [By IEEE]

(2) German computer scientist Fritz Bauer described software engineering as: “Software engineering is the development and application of sound engineering principles to provide reliable and efficient software for real machines”

1.2 Software Process, Product and Program

The term software specifies to the set of computer programs, procedures and associated documents (Flowcharts, manuals, etc.) that describe the program and how they are to be used.

A software process is the set of activities and associated outcome that produce a software product. Software engineers mostly carry out these activities. These are four key process activities, which are common to all software processes. These activities are:

Software specifications: The functionality of the software and constraints on its operation must be defined.

Software development: The software to meet the requirement must be produced.

Software validation: The software must be validated to ensure that it does what the customer wants.

Software evolution: The software must evolve to meet changing client needs.

A software process model is a specified definition of a software process, which is presented from a particular perspective. Models, by their nature, are a simplification, so a software process model is an abstraction of the actual process, which is being described. Process models may contain activities, which are part of the software process, software product, and the roles of people involved in software engineering. Some examples of the types of software process models that may be produced are:

A workflow model: This shows the series of activities in the process along with their inputs, outputs and dependencies. The activities in this model perform human actions.

A dataflow or activity model: This represents the process as a set of activities, each of which carries out some data transformations. It shows how the input to the process, such as a specification is converted to an output such as a design. The activities here may be at a lower level than activities in a workflow model. They may perform transformations carried out by people or by computers.

A role/action model: This means the roles of the people involved in the software process and the activities for which they are responsible

Software Evolution is a term which refers to the process of developing software initially, 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 an 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.

Laws used for Software Evolution:

Law of continuing change:
This law states that any software system that represents some real-world reality undergoes continuous change or become progressively less useful in that environment.

Law of increasing complexity:
As an evolving program changes, its structure becomes more complex unless effective efforts are made to avoid this phenomenon.

Law of conservation of organization stability:
Over the lifetime of a program, the rate of development of that program is approximately constant and independent of the resource devoted to system development.

Law of conservation of familiarity:
This law states that during the active lifetime of the program, changes made in the successive release are almost constant.

1.3 Characteristics of Software process

Software is treated as a good software by the means of different factors. A software product is concluded as a good software by what it offers and how well it can be used. The factors that decide the software properties are divided into three categories: Operational, Transitional, and Maintenance. These are explained as following below.

1. Operational:
In operational categories, the factors that decide the software performance in operations. It can be measured on:

Budget

Functionality

Usability

Dependability

Efficiency

Security

Correctness

Safety

2. Transitional:

When the software is moved from one platform to another, the factors deciding the software quality:

Portability

Interoperability

Reusability

Adaptability

3. Maintenance:

In this categories all factors are included that describes about how well a software has the capabilities to maintain itself in the ever changing environment:

Modularity

Maintainability

Flexibility

Scalability

1.4 Software Development Process

A software life cycle model (also termed process model) is a pictorial and diagrammatic representation of the software life cycle. A life cycle model represents all the methods required to make a software product transit through its life cycle stages. It also captures the structure in which these methods are to be undertaken.

SDLC Cycle:

Requirements design

implementation

testing

implementation

testing

deployment

operations

maintenance

Software Development Process

Some of the Software development processes are discussed below:

The Code-and-Fix model

Code and fix model are another level ahead of the Big-Bang model. Identifies the product to be tested before release.

The testing team detects bugs and sends software to fix it. Bringing in the repair editors complete the installation of certain codes and send the software again for testing. This process is repeated until bugs are found in it, at an acceptable level.

The Waterfall model,

Winston Royce introduced the Waterfall Model in 1970. This model has five phases: needs analysis and specification, construction, implementation, and evaluation of units, integration and system evaluation, and implementation and maintenance. The steps always follow this way and are not consistent. The developer must complete all stages before the start of the next phase. This model is called the "Waterfall Model", because its graphic representation is similar to the fall of a waterfall.

Requirements analysis and specification phase: The aim of this phase is to understand the exact requirements of the customer and to document them properly. It describes the "what" of the system to be produced and not "how. “In this phase, a large document called Software Requirement Specification (SRS) document is created which contained a detailed description of what the system will do in the common language.

Design Phase: This phase aims to transform the requirements gathered in the SRS into a suitable form which permits further coding in a programming language. It defines the overall software architecture together with high level and detailed design. All this work is documented as a Software Design Document (SDD).

Implementation and unit testing: During this phase, design is implemented. If the SDD is complete, the implementation or coding phase proceeds smoothly, because all the information needed by software developers is contained in the SDD.

Integration and System Testing: This phase is highly crucial as the quality of the end product is determined by the effectiveness of the testing carried out. However, in this phase, the modules are tested for their interactions with each other and with the system.

Operation and maintenance phase: Maintenance is the task performed by every user once the software has been delivered to the customer, installed, and operational.

The Incremental Implementation

An Incremental model is a software development process where the requirements are divided into multiple independent software cycle modules. In this model, each module goes through the stages of need, construction, implementation and testing. All subsequent release of the module can add function to the previous release. The process continues until a complete plan is found.

The various phases of incremental model are as follows:

Requirement analysis: In the first phase of the incremental model, the product analysis expertise identifies the requirements. And the system functional requirements are understood by the requirement analysis team. To develop the software under the incremental model, this phase performs a crucial role.

Design & Development: In this phase of the Incremental model of SDLC, the design of the system functionality and the development method are finished with success. When software develops new practicality, the incremental model uses style and development phase

Testing: In the incremental model, the testing phase checks the performance of each existing function as well as additional functionality. In the testing phase, the various methods are used to test the behaviour of each task.

Implementation: Implementation phase enables the coding phase of the development system. It involves the final coding that design in the designing and development phase and tests the functionality in the testing phase. After completion of this phase, the number of the product working is enhanced and upgraded up to the final system product.

Prototype Model

The model of software development where after each iteration prototype is shown to the customer for evaluation.

Steps of Prototype Model

Requirement Gathering and Analyst

Quick Decision

Build a Prototype

User Evaluation

Prototype Refinement

Engineer Product

The Evolutionary Model

Evolutionary process model resembles the iterative enhancement model. The same phases are defined for the waterfall model occurs here in a cyclical fashion. This model differs from the iterative enhancement model in the sense that this does not require a useful product at the end of each cycle. In evolutionary development, requirements are implemented by category rather than by priority.

Spiral Model

The spiral model, initially proposed by Boehm, is an evolutionary software process model that couples the iterative feature of prototyping with the controlled and systematic aspects of the linear sequential model. It implements the potential for rapid development of new versions of the software. Using the spiral model, the software is developed in a series of incremental releases. During the early iterations, the additional release may be a paper model or prototype. During later iterations, more and more complete versions of the engineered system are produced.

Spiral Model

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the various alternatives that are possible for achieving the targets, and the constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these various alternatives based on the goals and constraints. The focus of evaluation in this stage is located on the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve uncertainties and risks. This process may include activities such as benchmarking, simulation, and prototyping.

Planning: Final, step is planned. The project is reviewed, and a choice made whether to continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-interface risks are treated more essential than the program development risks, the next phase may be an evolutionary development that includes developing a more detailed prototype for solving the risks.

Software Reuse

Software reuse is creating new system by combining existing components that have been used in other systems. Software engineering always emphasized on original development but now recognised to achieve better software, quickly at lower cost, with the help of systematic software reuse.

Benefits of software reuse

Improving productivity, raising quality and reducing delivery time-scales.

Increased dependability

Reused software

Reduced process risk

Critical Comparisons of SDLC models

1.4.3 An Introduction to Non-Traditional Software Development Process: Rational Unified Process, Rapid Application Development, Agile Development Process.

Rapid Application

RAD is a linear sequential software development process model that emphasizes a concise development cycle using an element based construction approach. If the requirements are well understood and described, and the project scope is a constraint, the RAD process enables a development team to create a fully functional system within a concise time period.

RAD (Rapid Application Development) is a concept that products can be developed faster and of higher quality through:

Gathering requirements using workshops or focus groups

Prototyping and early, reiterative user testing of designs

The re-use of software components

A rigidly paced schedule that refers design improvements to the next product version

Less formality in reviews and other team communication

The various phases of RAD are as follows:

1. Business Modelling

2. Data Modelling

3. Process Modelling

4. Application Generation

5. Testing & Turnover

Agile Development Process

The meaning of Agile is swift or versatile. "Agile process model" refers to a software development approach based on iterative development. Agile methods break tasks into smaller iterations, or parts do not directly involve long term planning. The project scope and requirements are laid down at the beginning of the development process. Plans regarding the number of iterations, the duration and the scope of each iteration are clearly defined in advance.

1.5 Project management Process

Project management is one of the critical processes of any project. This is due to the fact that project management is the core process that connects all other project activities and processes together. When it comes to the activities of project management, there are plenty. However, these plenty of project management activities can be categorized into five main processes.

Five main project management processes in detail are:

1 - Project Initiation

Project initiation is the starting point of any project. In this process, all the activities related to winning a project takes place. Usually, the main activity of this phase is the pre-sale.

During the pre-sale period, the service provider proves the eligibility and ability of completing the project to the client and eventually wins the business. Then, it is the detailed requirements gathering which comes next.

During the requirements gathering activity, all the client requirements are gathered and analysed for implementation. In this activity, negotiations may take place to change certain requirements or remove certain requirements altogether.

Usually, project initiation process ends with requirements sign-off.

2 - Project Planning

Project planning is one of the main project management processes. If the project management team gets this step wrong, there could be heavy negative consequences during the next phases of the project.Therefore, the project management team will have to pay detailed attention to this process of the project.

In this process, the project plan is derived in order to address the project requirements such as, requirements scope, budget and timelines. Once the project plan is derived, then the project schedule is developed.

Depending on the budget and the schedule, the resources are then allocated to the project. This phase is the most important phase when it comes to project cost and effort.

3 - Project Execution

After all paperwork is done, in this phase, the project management executes the project in order to achieve project objectives.When it comes to execution, each member of the team carries out their own assignments within the given deadline for each activity. The detailed project schedule will be used for tracking the project progress.

During the project execution, there are many reporting activities to be done. The senior management of the company will require daily or weekly status updates on the project progress.

In addition to that, the client may also want to track the progress of the project. During the project execution, it is a must to track the effort and cost of the project in order to determine whether the project is progressing in the right direction or not.

In addition to reporting, there are multiple deliveries to be made during the project execution. Usually, project deliveries are not onetime deliveries made at the end of the project. Instead, the deliveries are scattered through out the project execution period and delivered upon agreed timelines.

4 - Control and Validation

During the project life cycle, the project activities should be thoroughly controlled and validated. The controlling can be mainly done by adhering to the initial protocols such as project plan, quality assurance test plan and communication plan for the project. Sometimes, there can be instances that are not covered by such protocols. In such cases, the project manager should use adequate and necessary measurements in order to control such situations.

Validation is a supporting activity that runs from first day to the last day of a project. Each and every activity and delivery should have its own validation criteria in order to verify the successful outcome or the successful completion.When it comes to project deliveries and requirements, a separate team called 'quality assurance team' will assist the project team for validation and verification functions.

5 - Closeout and Evaluation

Once all the project requirements are achieved, it is time to hand over the implemented system and closeout the project. If the project deliveries are in par with the acceptance criteria defined by the client, the project will be duly accepted and paid by the customer.

Once the project closeout takes place, it is time to evaluate the entire project. In this evaluation, the mistakes made by the project team will be identified and will take necessary steps to avoid them in the future projects.During the project evaluation process, the service provider may notice that they haven't gained the expected margins for the project and may have exceeded the timelines planned at the beginning.In such cases, the project is not a 100% success to the service provider. Therefore, such instances should be studied carefully and should take necessary actions to avoid in the future.

Project management is a responsible process. The project management process connects all other project activities together and creates the harmony in the project.Therefore, the project management team should have a detailed understanding on all the project management processes and the tools that they can make use for each project management process.

1.6 Project configuration management

Project configuration management is managing the configuration of all of the project’s key products and assets. This includes any end products that will be delivered to the customer, as well as all management products, such as the project management plan and performance management baseline. Implementation of configuration management and project change management need to occur hand-in-hand. Any change must be monitored and assessed to determine its impact on project configuration. The two processes are so interrelated that project configuration management has been said to be “kind of like change management on steroids.”

There are five key steps to project configuration management:

Planning. A configuration management plan details how you will record, track, control, and audit configuration. This document is often part of the project quality management plan.

Identification. All configuration requirements on a project should be identified and recorded. That includes functionality requirements, design requirements, and any other specifications. The completion of this process results in the configuration baseline for the project.

Control: As the project scope is altered, the impact to the configuration must be assessed, approved, and documented. This is normally done within the project change control process.

Status accounting: Track your project’s configuration at all times. You should be able to tell what version your configuration is on, and have a historical record of the old versions. It’s crucial to have an account of all versions so you can trace changes throughout the project.

Audit: This includes any tests to prove that the product conforms with the configuration requirements. Let’s say you built a report that must run within 10 seconds. The audit tests to see if the finished report actually runs that fast. Often, audits and checks will be built in at the completion of major project phases. This is so you can identify issues early.

The key difference to configuration management for Agile projects is in the identification step. Using Agile, the initial identification of specifications will be very general. It will be modified and updated frequently as the project progresses

1.7 Software Configuration Management in Project Management

A configuration is the set of characteristics that define a final product or deliverable. This includes all functional and physical specifications. Physical specifications may include the colour, size, weight, shape, and materials. Functional specifications dictate the ability for the product to achieve a certain outcome. Take a car for example. Physical specs may call for a red, 4-door vehicle. Functional specs could include the ability to reach 60 mph in 10 seconds and meet emissions standards.

Need Configuration management

The primary reasons for Implementing Technical Software Configuration Management System are:

There are multiple people working on software which is continually updating

It may be a case where multiple version, branches, authors are involved in a software config project, and the team is geographically distributed and works concurrently

Changes in user requirement, policy, budget, and schedule need to be accommodated.

Software should able to run on various machines and Operating Systems

Helps to develop coordination among stakeholders

SCM process is also beneficial to control the costs involved in making changes to a system

Any change in the software configuration Items will affect the final product. Therefore, changes to configuration items need to be controlled and managed.

Tasks in SCM process

Configuration Identification

Baselines

Change Control

Configuration Status Accounting

Configuration Audits and Reviews

Status Reporting

Identification

Basic Object

Unit of Text created by a software engineer during analysis, design, code, or test.

Aggregate Object

A collection of essential objects and other aggregate objects. Design Specification is an aggregate object.

Each object has a set of distinct characteristics that identify it uniquely: a name, a description, a list of resources, and a "realization."

The interrelationships between configuration objects can be described with a Module Interconnection Language (MIL).

Version Control

Version Control combines procedures and tools to handle different version of configuration objects that are generated during the software process.

Clemm defines version control in the context of SCM

Configuration management allows a user to specify the alternative configuration of the software system through the selection of appropriate versions. This is supported by associating attributes with each software version, and then allowing a configuration to be specified [and constructed] by describing the set of desired attributes.

Change Control

James Bach describes change control in the context of SCM is: Change Control is Vital. But the forces that make it essential also make it annoying.

We worry about change because a small confusion in the code can create a big failure in the product. But it can also fix a significant failure or enable incredible new capabilities.

We worry about change because a single rogue developer could sink the project, yet brilliant ideas originate in the mind of those rogues, and

A burdensome change control process could effectively discourage them from doing creative work.

A change request is submitted and calculated to assess technical merit; potential side effects, the overall impact on other configuration objects and system functions, and projected cost of the change.

The results of the evaluations are presented as a change report, which is used by a change control authority (CCA) - a person or a group who makes a final decision on the status and priority of the change.

The "check-in" and "check-out" process implements two necessary elements of change control-access control and synchronization control.

Access Control governs which software engineers have the authority to access and modify a particular configuration object.

Synchronization Control helps to ensure that parallel changes, performed by two different people, don't overwrite one another.

Configuration Audit

SCM audits to verify that the software product satisfies the baselines requirements and ensures that what is built and what is delivered.

SCM audits also ensure that traceability is maintained between all CIs and that all work requests are associated with one or more CI modification.

SCM audits are the "watchdogs" that ensures that the integrity of the project's scope is preserved.

Status Reporting

Configuration Status reporting (sometimes also called status accounting) providing accurate status and current configuration data to developers, testers, end users, customers and stakeholders through admin guides, user guides, FAQs, Release Notes, Installation Guide, Configuration Guide, etc.

Sign Up

Index

Notes

Highlighted

Underlined

Browse by Topics

Notes

Highlighted

Underlined