All about the Software Engineering

Software Testing

What are the main objectives of Software Testing?

  • Finding Errors / Bugs in Software
  • Requirement Verification
  • Performance
  • An Indication of quality

Functional Points Calculation 1

Given the following values, compute F.P when all complexity adjustment factors and weighting factors are average.

  • User I/P = 50
  • User O/P = 40
  • User Inquires = 35
  • User Files = 6
  • External Interfaces = 4
Functional UnitWighting Factors
LowAverageHigh
External Inputs (EI)346
External Outputs (EO)457
External Enquired (EQ)346
Internal Logic Files (ILF) 71015
External Interface Files (EIF)5710
COCOMO MODEL

Solution:

Here, we are given functional units as:

  • User I/P = 50
  • User O/P = 40
  • User Inquires = 35
  • User Files = 6
  • External Interfaces = 4

Also, we are given,

Complexity Adjustment Factors are average.

0 – No Influences

1 – Incidental

2 – Moderate

3 – Average

4 – Significant

5 – Essential

And Weighting Factors are also average.

AVERAGE complexity weights = {4, 5, 4, 10, 7} for the 5 complexities respectively.

Now,

We know that,

Final F.P = UFP X CAF

Where UFP (Unadjusted Functional Points)

Unadjusted Functional Points

And CAF (Complexity Adjustment Factor)

Complexity Adjustment Factor
UFP Calculation
Unadjusted Function Points

UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7

UFP = 200 + 200 + 140 + 60 + 28

UFP = 628

CAF = 0.65 + 0.01 (14 x 3)

CAF = 1.07

F.P = UFP x CAF

F.P = 628 x 1.07

F.P = 671.96

Therefore Function Points = 671.96

Advantages of Functional Points (F.P)

  1. Size of software delivered is measured independently of Language, technology, and tools.
  2. Functional Points F.P are directly estimated from requirements, before design and coding
  3. We get an estimate of SW size even before major design or coding happens (early phases)
  4. Any change in requirements can be easily reflected in the Functional Points FP count.
  5. Useful even for those users without technical expertise.
  6. F.P. is biased on the external structure of the software to develop.

Function Point

As a Software Engineer, one of the major difficult questions faced by the client or management is What is the cost and time for the software development? It’s difficult to weigh the real value or worth of software. One of the best ways to estimate the software development cost and time is based on previous software development experience.

To measure the standard worth of the software, as a unit of software worth, Function Point was developed. Functional Point was first defined by Allan Albrecht of IBM in 1977.

Function Point

  1. It measures functionality from the user’s point of view.
  2. What the user receives from Software and what the user requests from Software.
  3. Focuses on what functionality is being delivered.

A Functional Point is a unit of measurement to express the amount of business functionality an information system provides to a user. – Source: Wikipedia

Functional Point
Functional Point

GA

5 Types of Functional Units

  1. Internal Logic Files (ILF) – The control info or logically related data that is present within the system.
  2. External Interface Files (EIF) – The control data or other logical data i.e. referenced by the system but present in another system.
  3. External Inputs (EI) – Data/control info that comes from outside our system
  4. External Outputs (EO) – data that goes out of the system after generation
  5. External Enquired (EQ) – Combination of i/o – o/p resulting in data retrieval

How to Calculate Functional Points?

Final F.P = UFP X CAF
UFP = Unadjusted Function Point
CAF = Complexity Adjustment Factor

GA

Step 1: Each Function point is ranked according to complexity. There exist per-defined weights for each F.P in each category.

Step 2: Calculate the Unadjusted Function Point by multiplying each F.P. by its corresponding weight factor.

UFP = Sum of all the Complexities of all the EI’s, EO’s EQ’s, ILF’s and EIF’s

Step 3: Calculate Final Function Points

Final F.P = UFP X CAF

“Total Degree of Influence of the 14 General System Characteristics”

Complexity Adjustment Factor is calculated using 14 aspects of processing complexity. 14 questions answered on a scale of 0 – 5

0 – No Influences

1 – Incidental

2 – Moderate

3 – Average

4 – Significant

5 – Essential

Functional UnitWighting Factors
LowAverageHigh
External Inputs (EI)346
External Outputs (EO)457
External Enquired (EQ)346
Internal Logic Files (ILF) 71015
External Interface Files (EIF)5710

14 aspects of processing complexity questions are as follows:

  1. Data Communication
  2. Distributed Data Processing
  3. Performance
  4. Heavily Used Configuration
  5. Transaction Role
  6. Online Data Entry
  7. End-User Efficiency
  8. Online Update
  9. Complex Processing
  10. Reusability
  11. Installation Ease
  12. Operational Ease
  13. Multiple Sites
  14. Facilitate Change

Why are Project Late?

The project can be late due to different factors. Some of the main reasons for late project are as follows:

  • An unrealistic deadline was established by someone outside the software development group.
  • Changing customer requirements that are not reflected in schedule changes.
  • An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job.
  • Predictable and/or unpredictable risks that were not considered when the project commenced.
  • Technical difficulties that could not have been foreseen in advance.
  • Human difficulties that could not have been foreseen in advance.
  • Miscommunication among project staff results in delays.
  • A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem.
Late Project
Late Project

Project scheduling is key to a projects success!

Gantt Chart

After the methodology has been selected, planning should be done very carefully. Planning software development as per the chosen methodology can be reflected in the graphical form which is known as the Gantt Chart. Gantt Chart is nothing more than a pictorial representation of planning where it shows tasks to do against time table. It is a very important tool for the project manager or software engineer to assign the job to the employee, trace the target and deadline, track the project progress, and decide to take action in case there is a risk of the project being behind or failing.

In the Gantt Chart, the list of tasks to do is listed horizontally whereas a suitable time frame is scaled vertically. Each activity is represented by a bar; the position and length of the bar reflect the start date, duration, and end date of the activity.

Gantt Chart
Gantt Chart

Gantt chart can simply be defined as a horizontal bar chart, which contains a set of tasks with a proper schedule. It was first developed by Henry L. Gantt in 1917 as a production control tool. It helps to manage which activity should we do at the beginning and when to end it, how many activities overlap, what activity should be done at last, and when the project should end.

Gantt chart will reflect on the methodology that you choose for the software development. For example, if you are developing the software using Water Fall Methodology, as we know the phases of the waterfall methodology are

  1. Requirement Analysis
  2. System Design
  3. Implementation
  4. System Testing
  5. System Deployment
  6. System Maintenance

In waterfall, these phases are executed one after another so we plan phase-wise. So the Gantt chart will look like the ladder.

Gantt Chart most reflects the RUP Methodology if you are going to develop the software using RUP.

In RUP, it’s not going to execute phase-wise. There will be more overlap in the planning because more than one task will be in operation simultaneously. In a team, some will be working on designing where developers are also developing the system. Of course, we know that we can’t go development without system design but in this methodology, we will not wait for the whole system design and finalize, as one module system design is finalized, the developer starts working where are designer starts to design for the next module. So that there will be more overlap in the execution. In the waterfall, we start development only after finalizing the whole system design.

Rational Unified Process (RUP)

Working as a software engineer is one of the most challenging jobs in the world. A software engineer has to work very hard and carefully to manage the project, resources, and clients correctly so that he/she can track the project, execute as per plan, and lead to success. Software engineers always focus on how to reduce the risk of project failure.

RUP Phases
RUP Phases

The topic that we are going to cover:

  1. What is a Rational Unified Process (RUP)?
  2. Phases of the RUP methodology and its sub-tasks.
  3. How does the RUP methodology work?
  4. Advantages and Disadvantages of RUP methodology

Software Engineering is an organized approach to the design, development, operation, and maintenance of the software system. The objectives of Software Engineering are Maintainability, Correctness, Reusability, Testability, Reliability, Portability, and Adaptability.

GA

As a software engineer, establishing a good and efficient system needs more practice and more effort into it. Always keep in mind that until and unless, there is no proper process in the system, there is always a risk of project failure, and there will always temporary solutions. So the first job of the software engineer is to make a good system. To make a good and efficient system, software development methodology should be chosen based on the client’s requirement and the Client’s nature. There are different kinds of software development methodologies.

Among this list of methodologies, RUP is one of the most popular and effective methodologies for software development.

What is RUP?

Rational Unified Process (RUP) is a software development process from the Rational division of IBM. It can be defined as

A processed product – the development team for RUP is working closely with customers, partners, groups organizations to ensure that the process is constantly updated

The RUP leverages team productivity – it allows the team to have free access to a knowledge base with all the guidelines and tool mentors that help them overcome critical issues. This helps the entire team share the same language when developing software

The RUP creates and maintains models – instead of producing a large amount of paperwork, this method creates models – semantically rich representations of the software system your team is developing

The RUP is a guide on how to use Unified Modelling Language (UML)  – UML allows your team to communicate their requirements, architecture, and design of the project.

The RUP is a configurable process – it is a simple and clear process that can fit both small development teams as well as large organizations.

Rational Unified Process (RUP) divides the development process into four distinct phases that each involve business modeling, analysis and design, implementation, testing, and deployment. The four phases are as follows:

RUP Phases
RUP Phases

1. Inception: It is the initial phase of the developing process. Essentially, in this phase, your team determines the structure and the basic idea of the project. Also, the team will decide the purpose of the project, success criteria, estimated cost, risk assessment, scheduled time, and resources required to complete it, etc. It is just like an evaluation of the project.

The conclusions of the inception phase are:

  • It provides a general vision project initiative document with multiple parameters.
  • We get the project scope with the initial project model.
  • An initial business suite with financial analysis.
  • A project plan with different phases with a business model.
  • Requirement understanding.
  • Actual expenditures versus planned expenditures.

The major tasks involved in the Inception are as follows:

  1. Scheduling Resources
  2. Cost and Time Estimation
  3. Planning
  4. Risk Management
  5. Prototypes Development

2. Elaboration: This is the second phase of the development process. The project’s architecture and required resources are further evaluated. This phase aims to analyze the requirements and the architecture of the system, develop the project plan, and eliminate the highest risk elements of the project. It’s undoubtedly the most critical of all stages as it signifies the transition from low-risk to high-risk. It’s also the point when your team has to decide whether to start construction (development and coding) or not.

The conclusions of the Elaboration phase are:

  • It provides a full model of the project with functional and non-functional requirements.
  • It provides a full Software Architecture Description.
  • It provides the stability of the project, like the vision of the product & architecture of the product stable or not?
  • Similarly, the project plan be approved or not?
  • Is the actual resource cost versus planned resource cost acceptable or not?

The major tasks involved in the Elaboration are as follows:

  1. Analysis of the problem domain
  2. Use Case Diagram Development
  3. System Architecture Development

3. Construction: This is the third phase of the development process. At this stage, your team is finally ready to develop all components and features and integrate them into the product. It’s a manufacturing process where your team focuses on managing resources to optimize costs, schedules, and quality. The software is designed, written, and tested successfully.

The conclusions of the Construction phase are:

  • The software product is integrated into different modules.
  • It provides a user manual.
  • Is the product release stable or not?
  • Does it meet client requirements or not?
  • Is the actual resource cost versus planned resource cost acceptable or not?

The major tasks involved in the Construction are as follows:

  1. System Build
  2. System Operational Manual
  3. User Manual
  4. Test Cases

4. Transition: This is the last phase of the development process. The transition phase is the moment when the product is finally finished, released, and delivered to customers. However, once the product is given to the user, several issues can arise. This requires the team to handle all the bug fixes and correct problems or to finish some features that were postponed. It is the process of deployment.

The conclusions of the Transition phase are:

  • It is one type of beta testing to validate the product as per user expectations.
  • It allows the end-user to be satisfied or not.
  • All types of training manuals for the user.

The major tasks involved in the Transition Phase are as follow:

  1. Training
  2. Beta Testing
  3. Analysis of User Review
  4. Supporting & maintaining product

The benefits of RUP:

  • It allows you to deal with changing requirements regardless of whether they are coming from the customer or from the project itself
  • It emphasizes the need for accurate documentation.
  • It forces integration to happen throughout the software development, more specifically in the construction phase.
  • It allows us to deal with changing requirements within the development life cycle of the project as per the client or customer needs i.e. it welcomes change.
  • It supports incremental build of the software product.
  • It provides proper documentation of the software product.
  • It helps to use the resources efficiently.
  • It helps to identify issues early in the process life cycle.
  • It improves process control and risk management.
  • It enhances team productivity. It allows you to deal with changing requirements regardless of whether they are coming from the customer or from the project itself.
  • It emphasizes the need for accurate documentation.
  • It forces integration to happen throughout the software development, more specifically in the construction phase.
  • It helps reduce unexpected development costs.

The disadvantages of RUP:

  • It mostly relies on the ability of experts and professionals to assign the activities to individuals who should then produce pre-planned results in the form of artifacts.
  • The integration in the development process can also have an adverse impact on some more fundamental activities during the stages of testing
  • Although RUP has delivered excellent results, especially in software development, it is a rather complex method which makes its implementation challenging, particularly for smaller businesses, teams, or projects.
  • It is a complex model to implement as it has multiple stages of the workflow.
  • It is challenging for organizations to implement which has, a small team size or projects.
  • It should be highly result-oriented for individuals or teams.
  • It emphasizes the integration of modules throughout the development process of software, so this creates trouble during the testing phase.

Agile Software Development

What is Agile ?

Agile is a set of values and principles.

What is Not Agile?

Agile is not a Methodology.

Agile is not a specific way of developing software.

Agile is not a framework or process.

Agile Software Development
Agile Software Development

The Manifesto for Agile Software Development

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

List of 12 Agility Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity the art of maximizing the amount of work not done is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Activity Diagram

The Activity Diagram is another important diagram in UML to describe the dynamic aspects of the system. The Activity Diagram is a flowchart to represent the flow from one activity to another activity. The activity can be described as an operation of the system. The control flow is drawn from one operation to another. This flow can be sequential, branched, or concurrent. Activity diagrams deal with all types of flow control by using different elements such as fork, join, etc.

Activity Diagram
Activity Diagram

Purpose of Activity Diagrams

The basic purposes of activity diagrams are similar to the other four diagrams. It captures the dynamic behavior of the system. The other four diagrams are used to show the message flow from one object to another but the activity diagram is used to show the message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not only used for visualizing the dynamic nature of a system, but they are also used to construct the executable system by using forward and reverse engineering techniques. The only missing thing in the activity diagram is the message part.

It does not show any message flow from one activity to another. The Activity Diagram is sometimes considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows different flows such as parallel, branched, concurrent, and single.
The purpose of an activity diagram can be described as
Draw the activity flow of a system.
Describe the sequence from one activity to another.
Describe the parallel, branched, and concurrent flow of the system.

How to Draw an Activity Diagram?

Activity diagrams are mainly used as a flowchart that consists of activities performed by the system. Activity diagrams are not exactly flowcharts as they have some additional capabilities. These additional capabilities include branching, parallel flow, swim lane, etc.

Before drawing an activity diagram, we must have a clear understanding of the elements used in the activity diagram. The main element of an activity diagram is the activity itself. An activity is a function performed by the system. After identifying the activities, we need to understand how they are associated with constraints and conditions.
Before drawing an activity diagram, we should identify the following elements
Activities
Association
Conditions
Constraints

Once the above-mentioned parameters are identified, we need to make a mental layout of the entire flow. This mental layout is then transformed into an activity diagram.

Following is an example of an activity diagram for the order management system. In the diagram, four activities are identified which are associated with conditions. One important point should be clearly understood an activity diagram cannot be exactly matched with the code. The activity diagram is made to understand the flow of activities and is mainly used by business users
The following diagram is drawn with the four main activities
Send order by the customer
Receipt of the order
Confirm the order
Dispatch the order
After receiving the order request, condition checks are performed to check if it is a normal or special order. After the type of order is identified, dispatch activity is performed and that is marked as the termination of the process.

Where to Use Activity Diagrams?

The basic usage of the activity diagram is similar to the other four UML diagrams. The specific usage is to model the control flow from one activity to another. This control flow does not include messages.

The Activity Diagram is suitable for modeling the activity flow of the system. An application can have multiple systems. The Activity Diagram also captures these systems and describes the flow from one system to another. This specific usage is not available in other diagrams. These systems can be databases, external queues, or any other system.

We will now look into the practical applications of the activity diagram. From the above discussion, it is clear that an activity diagram is drawn from a very high level. So it gives a high-level view of a system. This high-level view is mainly for business users or any other person who is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. The diagram has more impact on business understanding rather than on implementation details.
Activity diagram can be used for
Modeling workflow by using activities.
Modeling business requirements.
High-level understanding of the system’s functionalities.
Investigating business requirements at a later stage.

Communication – Diagram

What is a Communication Diagram?

First of all, I would like to make clear that it is also known as a Collaboration Diagram. So these two diagram communication and collaboration diagrams are the same. Communication Diagram is used to show how objects interact to perform the behavior of a particular use case or a part of a use case.

After the expanded use case description of the major use cases, we start the communication diagram. So that you should know what is and how to write an expanded use case description. An expanded use case description is a two-way interaction step written between the actor and the system about how that particular use case will execute. It’s like the script of the movie which is written, with step-by-step execution.

Communication Diagarm

As we are drawing the design in an object-oriented way, a collaboration diagram describes a pattern of interaction among objects. It shows the objects participating in the interaction by their links to each other and the messages that they send to each other.

Collaboration diagrams are used by designers to define and clarify the roles of the objects that perform a particular flow of events of use cases. They are the primary source of information used for determining class responsibilities and interfaces.

After the collaboration diagram, we will also get the numbers of classes and their names which need to be defined in the application and its respective objects as well. Not only that but also we will know how these objects of different classes will interact and flow messages with each other stepwise. All showing this kind of information in the diagram is the Collaboration diagram. Its main purpose is to visualize the interactive behavior of the system.

We all know that objects of the classes communicate by sending and receiving messages.

Use Case Diagram
Use Case Diagram