All about the Software Engineering

Requirements Engineering

Requirements engineering is the cornerstone of any successful project. It involves defining what a system should do and ensuring it meets stakeholders’ needs. A clear understanding of requirements leads to better outcomes, fewer changes, and smoother project execution.

Why Requirements Engineering Matters

Effective requirements engineering helps bridge the gap between stakeholders and developers. It ensures that everyone involved has a shared vision of what the system should achieve. By identifying and documenting needs early, teams can avoid costly mistakes and rework.

Key Phases of Requirements Engineering

Elicitation: Gathering requirements from stakeholders through interviews, surveys, and observations. This phase focuses on understanding what users need and expect from the system.

Analysis: Reviewing and refining requirements to ensure they are clear, complete, and feasible. This phase helps in prioritizing requirements and resolving conflicts.

Specification: Documenting requirements in a detailed and understandable manner. Clear documentation serves as a reference for the development and testing phases.

Validation: Ensuring that the documented requirements accurately reflect stakeholder needs and are feasible within project constraints. This phase involves reviewing requirements with stakeholders to confirm accuracy.

Management: Handling changes to requirements as the project evolves. Effective management ensures that changes are tracked and communicated, preventing scope creep.

Best Practices for Effective Requirements Engineering

Engage Stakeholders Early: Involve stakeholders from the start to gather comprehensive and accurate requirements.

Use Clear and Simple Language: Avoid jargon and complex terms to ensure everyone understands the requirements.

Prioritize Requirements: Focus on the most critical needs to deliver the most value.

Validate Regularly: Continuously review and validate requirements to adapt to any changes or new insights.

Common Challenges and Solutions

Ambiguous Requirements: Use specific language and examples to clarify ambiguous requirements.

Changing Requirements: Implement a change management process to handle evolving needs systematically.

Communication Gaps: Foster open communication between stakeholders and developers to address misunderstandings quickly.

Conclusion

Requirements engineering is not just a step in the development process; it’s a continuous effort that shapes the project’s success. By adopting best practices and staying engaged with stakeholders, teams can deliver systems that truly meet user needs and expectations. Embrace requirements engineering as a vital part of your project strategy, and watch your projects thrive.

Fagan Inspection Methodology

The Fagan Inspection Methodology is a structured approach used in software engineering for peer review of software artifacts, primarily focusing on code inspection. It was developed by Michael Fagan in the late 1970s and has been widely adopted in various software development methodologies.

The Fagan Inspection Methodology involves a systematic and rigorous examination of software code or documents by a team of peers to identify defects, errors, and areas for improvement. The key components of the Fagan Inspection Methodology include:

Fagan Inspection Methodology

Fagan

Preparation: This stage involves preparing the software artifact (such as code or documentation) for inspection. The author of the artifact typically provides the necessary materials to reviewers, including relevant documentation and guidelines for the inspection process.

Overview Meeting: Before the inspection begins, an overview meeting is held to familiarize the inspection team with the artifact under review, its purpose, and the inspection process. The meeting aims to ensure that all team members understand the objectives and scope of the inspection.

Fagan Overview Meeting

Fagan Overview

Inspection Meeting: During this phase, the inspection team thoroughly examines the software artifact to identify defects and errors. Each reviewer systematically inspects the artifact, looking for issues such as coding errors, design flaws, and deviations from coding standards.

Fagan Inspection Meeting

Fagan Inspection

Rework: After the inspection meeting, the author addresses the identified issues and makes necessary corrections to the software artifact. This stage may involve reworking the code or documentation to fix defects and improve quality.

Fagan Rework

Fagan Rework

Follow-Up Meeting: Once the rework is completed, a follow-up meeting may be held to verify that all identified issues have been addressed satisfactorily. This meeting ensures that the software artifact meets the required quality standards before proceeding further in the development process.

Fagan Follow-Up Meeting

Fagan Follow Up Meeting

The Fagan Inspection Methodology emphasizes the importance of collaboration, thoroughness, and objectivity in the peer review process. By involving multiple team members in the inspection, it helps to identify defects early in the development lifecycle, leading to improved software quality and reduced rework costs. Additionally, the structured nature of the methodology helps to ensure consistency and repeatability in the inspection process, making it an effective quality assurance technique in software development projects.

Benefits of software inspections

Software inspections, including methods like the Fagan Inspection Methodology, offer numerous benefits to software development projects. Here are some of the key advantages:

Early Defect Detection: Inspections facilitate the early detection of defects and errors in software artifacts such as code, designs, and documentation. Finding and fixing defects early in the development process reduces the cost and effort of addressing them later.

Improved Software Quality: By identifying and correcting defects before they propagate further into the development process, inspections contribute to overall software quality improvement. This leads to a more reliable, robust, and maintainable software product.

Knowledge Sharing and Learning: Inspections provide an opportunity for team members to share knowledge and learn from each other’s expertise. Reviewers gain insights into different aspects of the software and can improve their own skills through exposure to various coding styles, design patterns, and best practices.

Reduced Rework and Maintenance Costs: Detecting and fixing defects during inspections helps prevent the accumulation of technical debt and reduces the need for extensive rework or costly maintenance activities later in the software lifecycle. This leads to significant cost savings over the long term.

Enhanced Communication and Collaboration: Inspections promote communication and collaboration among team members, as they work together to review and improve software artifacts. This fosters a culture of teamwork and accountability within the development team. Compliance and Standards Adherence: Inspections help ensure that software artifacts adhere to organizational standards, coding guidelines, and industry best practices. This is particularly important in regulated industries where compliance with standards and regulations is mandatory. Customer Satisfaction:

Question-Related to COCOMO model – 4

Using the Basic COCOMO 81 model ‘see the tables and example below’, calculate the effort required – ‘in person-months’, the overall development time, and the number of personnel required for the project described below.

  1. Effort = a (KLOC)b. person month
  2. Development Time = c (Effort)d months
  3. Number of People = Effort / Development Time   persons
Software Product Typeabcd
Organic2.41.052.50.38

Assume that the size of an organic-type software product has been estimated to be 32,000 lines of source code. Determine the effort required to develop the software Product, its duration, and the number of personnel.

Solution:

We know that

Effort = a (KLOC)b. person month

Development Time = c (Effort)d months

Number of People = Effort / Development Time   persons

Given that, estimated Lines of Code = 32,000 = 32 KLOC

Software Product Type / Modes of Development: Organic

Effort = a (KLOC)b person month

2.5 (32) 1.05 person month

95.13 person month

= 95 person month

Development Time = c (Effort) d Months

2.5 (95) 0.38 Months

14.1 Months

= 14 Months

Number of People = Effort / Development Time   persons

95 / 14 persons

11.65 persons

= 6.78 persons

= 7 persons

Question-Related to COCOMO model – 3

A company needs to develop a strategy for software product development for which it has a choice of two programming languages L1 and L2. The number of lines of code (LOC) developed using L2 is estimated to be twice the LOC developed with L1. The product will have to be maintained for five years. Various parameters for the company are given in the table below.

ParameterLanguage L1Language L2
Man years needed for developmentLOC / 10000LOC / 10000
Development Cost per yearRs. 10,00,0007,50,000
Maintenance Time5 Years5 Years
Cost of maintenance per yearRs. 1,00,000Rs. 50,000

The total cost of the project includes the cost of development and maintenance. What is the LOC for L1 for which the cost of the project using L1 is equal to the cost of the project using L2?

COCOMO MODEL

Solution:

Let’s Suppose LOC for the L1 = X

Given that: The number of lines of code (LOC) developed using L2 is estimated to be twice the LOC developed with L1.

Then LOC for the L2 = 2X

We know that:

The total cost of the project includes the cost of development and maintenance. And the LOC for L1 for which the cost of the project using L1 is equal to the cost of the project using L2.

Development cost of L1 + Maintenance cost of L1  =  Development cost for L2 + Maintenance cost of L2

Development cost of L1 = (X / 10,000) * 1,00,0000

Maintenance cost of L1 = 5 * 1,00,000

Development cost of L2 = (2X / 10,000) * 7,00,000

Maintenance cost of L2 = 5 * 50,000

{(X / 10,000) * 10,00,000 + 5 * 1,00,000 }  =  { (2X / 10,000) * 7,50,000 + 5 * 50,000}

5X  =  2,50,000

X = 5,000

The LOC for L1 for which the cost of the project using L1 is equal to the cost of the project using L2 = 5,000.

Question-Related to COCOMO model – 2

Using the Basic COCOMO 81 model (see the tables and formulae below), calculate the effort required (in person-months), the overall development time, and the number of personnel required for each product described below.

BASIC MODEL EQUATIONS

  1. Effort = a (KLOC)b. person month
  2. Development Time = c (Effort)d months
  3. Number of People = Effort / Development Time   persons
Software Product Typeabcd
Organic2.41.052.50.38
Semi-detached3.01.122.50.35
Embedded3.61.202.50.32

Product 1: A semi-detached mode product delivering 75,000 lines of code.
Product 2: An embedded mode product delivering 75,000 lines of code.
Product 3: An organic mode product delivering 75,000 lines of code.

Briefly comment on your estimations for the above products.

COCOMO MODEL

Solution:

We know that

Effort = a (KLOC)b. person month

Development Time = c (Effort)d months

Number of People = Effort / Development Time   persons

Given that, estimated Lines of Code = 75,000 = 75 KLOC

Product 1: Semi-detached Mode of Development

Effort = a (KLOC)b person month

3 (75) 1.12 person month

377.73 person month

378 person month

Development Time = c (Effort) d Months

2.5 (378) 0.35 Months

19.9 Months

20 Months

Number of People = Effort / Development Time   persons

378 / 20 persons

18.9 persons

19 persons

Product 2Embedded Mode of Development

Effort = a (KLOC)b person month

3.6 (75) 1.2 person month

640.288 person month

640 person month

Development Time = c (Effort) d Months

2.5 (640) 0.32 Months

19.7 Months

20 Months

Number of People = Effort / Development Time   persons

640 / 20 persons

32 persons

Product 3Organic Mode of Development

Effort = a (KLOC)b person month

2.5 (75) 1.05 person month

232.67 person month

233 person month

Development Time = c (Effort) d Months

2.5 (233) 0.38 Months

19.8 Months

20 Months

Number of People = Effort / Development Time   persons

233 / 20 persons

11.65 persons

12 persons

Question-Related to COCOMO model – 1

Suppose that a project was estimated to be 400 KLOC. Calculate the effort & time for each of the 3 modes of development.

Software Product Typeabcd
Organic2.41.052.50.38
Semi-detached3.01.122.50.35
Embedded3.61.202.50.32
COCOMO MODEL

Solution:

As we know the 3 modes of development are

  1. Organic
  2. Semi-detached
  3. Embedded

Also, we know that

Effort = a (KLOC)b person month

Time = c (Effort)d Months

Here, we are given KLOC = 400

Organic:

Effort = a (KLOC)b person month

2.4 (400)1.05 person month

1295 person month

Time = c (Effort) d Months

2.5 (1295) 0.38 Months

38 Months

Semi-detached:

Effort = a (KLOC)b person month

3 (400)1.12 person month

2462 person month

Time = c (Effort) d Months

2.5 (2462) 0.35 Months

38.4 Months

Embedded

Effort = a (KLOC)b person month

3.6 (400)1.2 person month

4772 person month

Time = c (Effort) d Months

2.5 (4772) 0.32 Months

38 Months

Different project Modes/Types used in the Basic COCOMO 81

Basic COCOMO model: It estimates the software roughly and quickly. It is mostly useful for small medium-sized software. There are three modes of development.

  1. Organic
  2. Semi Detached
  3. Embedded

We used these three different modes of development to calculate the project effort, development time, average staff size, and productivity according to different criteria which are shown below.

 ORGANICSEMI DETACHEDEMBEDDED
Size2 50 KLOC50 300 KLOC300 & Above KLOC
Team SizeSmall SizeMedium SizeLarge Size
Developer ExperienceExperienced Developers NeededAverage Experienced PeopleVery Little Previous experience
EnvironmentFamiliar EnvironmentLess FamiliarSignificant environment changes (Almost new environment)
InnovationLittleMediumMajor
DeadlineNot TightMediumTight
ExamplePayroll SystemUtility Systems, DBMSAir Traffic monitoring, ATM

Features of the COCOMO Models

COCOMO MODEL
  • An empirical model based on project experience.
  • Well-documented, independent model which is not tied to a specific software vendor.
  • Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2
  • COCOMO 2 takes incorporates a range of sub-models that produce increasingly detailed software estimates such as the early design model, reuse model, etc

COCOMO MODEL

As software engineers, we have to face major questions from clients, management, and others. i.e. what is the time and Cost?

Estimating the cost of the project is one of the most challenging jobs for the Software Engineer. One of the best ways to calculate the cost of the project is COCOMO. COCOMO stands for the Constructive Cost Model. It is a Constructive Cost Model which is based on LOC (Lines of Code) the project estimation is done based on the total lines of codes required to develop the system. i.e. Size of the system defines the cost of the project.

Co = Constructive

Co = Cost

Mo= Model

COCOMO = Constructive Cost Model

COCOMO was first developed by Barry W. Boehm in 1981 as a model that is used to estimate the effort, cost, development time, average staff size, productivity, etc.

It is a hierarchy of software cost estimation models. It consists of three hierarchies of increasingly detailed and accurate forms.

  1. Basic COCOMO model
  2. Intermediate COCOMO model
  3. Detailed COCOMO model

Basic COCOMO model: It estimates the software roughly and quickly. It is mostly useful for small-medium-sized software. There are three modes of development.

  1. Organic
  2. Semi Detached
  3. Embedded

We used these three different modes of development to calculate the project effort, development time, average staff size, and productivity according to different criteria which are shown below.

 ORGANICSEMI DETACHEDEMBEDDED
Size2 50 KLOC50 300 KLOC300 & Above KLOC
Team SizeSmall SizeMedium SizeLarge Size
Developer ExperienceExperienced Developers NeededAverage Experienced PeopleVery Little Previous experience
EnvironmentFamiliar EnvironmentLess FamiliarSignificant environment changes (Almost new environment)
InnovationLittleMediumMajor
DeadlineNot TightMediumTight
ExamplePayroll SystemUtility Systems, DBMSAir Traffic monitoring, ATM

BASIC MODEL EQUATIONS

  1. Effort = a (KLOC)b person month
  2. Development Time = c (Effort)d months
  3. Average Staff Size = Effort / Development Time   persons
  4. Productivity = KLOC / Effort    KLOC/ Person-Month
Software Product Typeabcd
Organic2.41.052.50.38
Semi-detached3.01.122.50.35
Embedded3.61.202.50.32

Different between Verification & Validation

Verification & Validation

Verification refers to the set of tasks that ensure that software correctly implements a specific function.

Validation refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements.