Introduction to Software Engineering and Process Models

Define Software Engineering and Software?

Software is a program or set of programs containing instructions that provide desired functionality.

Software: Instructions (computer programs) that when executed provide desired features, function, and performance.

Software Engineering is the process of designing, developing, testing, and maintaining software. It is a systematic and disciplined
approach to software development that aims to create high-quality, reliable, and maintainable software. Software engineering
includes a variety of techniques, tools, and methodologies, including requirements analysis, design, testing, and maintenance.

Software engineering is a systematic approach to the design, development, operation, and maintenance of a software system.

Describe Key principles of software engineering.

• Modularity: Breaking the software into smaller, reusable components that can be developed and tested independently.
• Abstraction: Hiding the implementation details of a component and exposing only the necessary functionality to other
parts of the software.
• Encapsulation: Wrapping up the data and functions of an object into a single unit and protecting the internal state of an
object from external modifications.
• Reusability: Creating components that can be used in multiple projects, which can save time and resources.
• Maintenance: Regularly updating and improving the software to fix bugs, add new features, and address security
vulnerabilities.
• Testing: Verifying that the software meets its requirements and is free of bugs.
• Design Patterns: Solving recurring problems in software design by providing templates for solving them.
• Agile methodologies: Using iterative and incremental development processes that focus on customer satisfaction, rapid
delivery, and flexibility.
• Continuous Integration & Deployment: Continuously integrating the code changes and deploying them into the
production environment.

Describe different types of software.

• System software
• Application software
• Engineering/Scientific software
• Embedded software
• Web Apps (Web applications)
• AI software

Describe Framework activities.

1. Communication: Project Initiation, Requirements gathering.

2. Planning: Estimating, Scheduling
3. Modelling: Analysis of requirements, Design
4. Construction: Code generation, Testing
5. Deployment: Delivery, Feedback

Describe Umbrella activities.

1. Software project management

2. Formal technical reviews
3. Software quality assurance
4. Software configuration management
 5. Work product preparation and production
6. Reusability management
7. Measurement
8. Risk management

Role of software engineering

• To develop a good quality software product.

• To develop a cost-effective product.
• Develop the product within time schedule and budget.
• Provide sufficient training to the developers.
• Use an appropriate software development model.
• Manage the development of the product.
• Improve the development process.

Software Engineering approach

Two types of approaches: Phased Development and managing the process

Phased Development Process

• Development process consists of various phases.

• Breaks the problem of developing software into set of phases.
• Each phase ends with a defined output.
• Each handling a different concern of software development.
• This ensures that the cost of development is lower than what it would have been if the whole problem was tackled
together.

1)Requirements Analysis

• Understand the problem the software system is to solve.

• Two major activities in this phase:
• problem understanding or analysis.
• requirement specification
• Specify all functional and performance requirements.
• the formats of inputs and outputs.
• all design constraints.

2)Software Design

• Purpose: plan a solution to the problem specified by the requirements document.

• Move from the problem domain to the solution domain.
• Design activity often results in three separate outputs:
• Architecture design- identifies the different components, and their interaction.
• High level design- identifies the modules of the system and the specifications of these modules.
• Detailed design- internal logic of each of the modules is specified.

3) Coding

• Goal of the coding phase is to translate the design of the system into code in a given programming language.
• Coding phase affects both testing and maintenance.
• Programs must be easy to read and understand.

4) Testing

• The basic function is to detect defects in the software.

• Unit testing- different modules or components are tested individually.
• Integration testing- testing the interconnection between modules.
 • System testing- system is tested against the system requirements.
• Acceptance testing- demonstrate to the client, run on the real-life data of the client.

Managing the Process

• Manage the development process.

• Handled through project management.
• Issues :
• How to allocate resources to the different activities in the process.
• Schedule for the activities.
• How to divide work within a phase.
• What can be the risks for the project and how to mitigate them.
• Software plan- used for monitoring and controlling the development process of the project.
• Software metrics -used to measure different characteristics of a software system or the software development process.

Types of Software models

1. Waterfall model
2. Incremental Process models
• Incremental Development model
• Rapid application development model (RAD)
3. Evolutionary Process models
• Prototype Model
• Spiral Model
• Concurrent Development model
4. Component Based Development Model
5. Agile Development Models

Build and Fix Model

• Programmer typically starts to write the program immediately after he has formed an
informal understanding of the requirements.
• Product is constructed without any specifications or any attempt at design.
• Not a well-defined approach
• Has two phases 1. Build the code 2. fix the code.
• Disadvantage:
• A large no. of code fixes is required.
• Suitable for small projects.

Waterfall Model

• The Waterfall Model is a traditional and linear approach to software development that follows a sequential, phased
progression.
• Each phase in the Waterfall Model must be completed before moving on to the next, and changes to earlier phases are
discouraged once they have been finalized.
• The model is called "waterfall" because it resembles a cascading flow, where progress is unidirectional, much like water
flowing over a waterfall.

Two types of waterfall model

• Classical waterfall model

• Iterative waterfall model

Classical waterfall model

• The classical waterfall model divides the life cycle into a set of phases.
• This model considers that one phase can be started after the completion of the previous phase.
• That is the output of one phase will be the input to the next phase.
• Thus, the development process can be considered as a sequential flow in the waterfall. Here the phases do not overlap
with each other.

1. Feasibility Study:
• Goal: Determine financial and technical feasibility of software development.
• Identify possible strategies to solve the problem.
• Analyze solutions for benefits and drawbacks.
• Choose the best solution as the basis for subsequent phases.
2. Requirements Analysis and Specification:
• Aim: Understand customer requirements and document them.
• Requirement gathering and analysis:
• Gather all software requirements from the customer.
• Analyze to remove incompleteness and inconsistencies.
• Requirement specification:
• Document analyzed requirements in a Software Requirement Specification (SRS) document.
• SRS serves as a contract between the development team and customers.
3. Design:
• Goal: Convert SRS requirements into a format for coding.
• Includes high-level and detailed design.
• Develop Software Design Document (SDD) to document design efforts.
4. Coding and Unit Testing:
• Coding phase translates design into source code.
• Each designed module is coded.
• Unit testing checks if each module works correctly.
5. Integration and System Testing:
• Integration: Combine coded modules incrementally.
• System testing:
• Alpha testing by the development team.
• Beta testing by a friendly set of customers.
• Acceptance testing by the customer after software delivery.
6. Maintenance:
• Most important phase, consuming 60% of total effort.
• Types of maintenance:
• Corrective: Fix errors not discovered during development.
• Perfective: Enhance functionalities based on customer requests.
• Adaptive: Modify for new environments (platforms or operating systems).
Disadvantages:
• No feedback path
• Difficult to accommodate change requests.
• Inefficient error corrections
• No overlapping of phases
• Hard to use for real projects.
Advantages:

• Easy to Understand
• Individual Processing
• Properly Defined
• Clear Milestones
• Properly Documented:

Iterative waterfall model

• It is almost the same as the classical waterfall model except some changes are made to increase the efficiency of the
software development.
• The iterative waterfall model provides feedback paths from every phase to its preceding phases, which is the main
difference from the classical waterfall model.
• The Iterative Waterfall Model is a software development approach that combines the sequential steps of the
traditional Waterfall Model with the flexibility of iterative design. It allows for improvements and changes to be made at
each stage of the development process, instead of waiting until the end of the project.

Same as of classical waterfall model, but here there is feedback path

Advantages of Iterative Waterfall Model :

• Feedback Path
• Simple
• Cost-Effective
• Well-organized
• Risk Reduction
• Quality Assurance
• Improved Customer Satisfaction: Predictable Outcomes
• Faster Time to Market
• Easy to Manage
Drawbacks of Iterative Waterfall Model:

• Difficult to incorporate change requests.

• Incremental delivery not supported.
• Overlapping of phases not supported
• Risk handling not supported.
• Limited customer interactions

Prototyping model

• A prototyping model is a software development approach that involves creating a preliminary version of a system or
application to gather feedback, test functionality, and identify potential issues early in the development process.
Build a working prototype of system, before development of the actual software.
• Prototype is a simple or basic implementation.
• It has limited functional capabilities, low reliability, inefficient performance as compared to the actual software.
• It has dummy functions.
• Uses software tools.

Types:

1. Throwaway
2. Evolutionary
3. Incremental

Rapid Throwaway Prototyping

This technique offers a useful method of exploring ideas and getting customer feedback for each of them. In this method, a
developed prototype need not necessarily be a part of the ultimately accepted prototype. Customer feedback helps in
preventing unnecessary design faults and hence, the final prototype developed is of better quality.

Evolutionary Prototyping

In this method, the prototype developed initially is incrementally refined based on customer feedback till it finally gets
accepted. In comparison to Rapid Throwaway Prototyping, it offers a better approach which saves time as well as effort.

Incremental Prototyping

In this type of incremental Prototyping, the final expected product is broken into different small pieces of prototypes and
being developed individually. In the end, when all individual pieces are properly developed, then the different prototypes are
collectively merged into a single final product in their predefined order.
Uses of prototyping model:

• use the prototyping model for development of the graphical user interface (GUI) part of an application.
• useful when the exact technical solutions are unclear to the development team.
• prototyping model can be deployed when highly efficient software is required.

Advantages:

• appropriate for projects that suffer from technical, and requirements risks.
• The customers get to see the partial product early in the life cycle. This ensures a greater level of customer satisfaction
and comfort.
• New requirements can be easily accommodated as there is scope for refinement.
• Missing functionalities can be easily figured out.

Disadvantages:

• increase the cost of development for projects.

• not be appropriate for projects for which the risk is identified later during the development cycle

Spiral model

• This model gets its name from the appearance of its diagrammatic representation that looks like a spiral with many.
• The exact number of loops of the spiral is not fixed and can vary from project to project.
• Each loop of the spiral is called a phase of the software process.
• The exact number of phases through which the product is developed can be varied by the project manager depending
upon the project risks.
• A prominent feature of the spiral model is handling unforeseen risks that can show up much after the project has started.

Objectives determination and identify alternative solutions:

Requirements are gathered from the customers and the objectives are identified, elaborated, and analysed at the start of every
phase. Then alternative solutions possible for the phase are proposed in this quadrant.

Identify and resolve Risks:

During the second quadrant, all the possible solutions are evaluated to select the best possible solution. Then the risks associated
with that solution are identified and the risks are resolved using the best possible strategy. At the end of this quadrant,
the Prototype is built for the best possible solution.

Develop next version of the Product:

During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the
next version of the software is available.

Review and plan for the next Phase:

In the fourth quadrant, the Customers evaluate the so far developed version of the software. In the end, planning for the next
phase is started.

Advantages:

• For projects having many unknown risks that might show up as the development proceeds, the spiral model would be the
most appropriate development model to follow.
• It is much more powerful than the prototyping model.
• Good for large Projects
• Customer Satisfaction

Disadvantages:

• Complex model to follow, since it is risk driven and is more complicated phase structure than the other models.
• Requires knowledgeable and experienced staff in the project.

Incremental Model

Incremental Model is a process of software development where requirements are divided into multiple standalone modules of the
software development cycle. In this model, each module goes through the requirements, design, implementation, and testing
phases. Every subsequent release of the module adds function to the previous release. The process continues until the complete
system is achieved.

• easier to accommodate change requests from the customers.

• Once the initial core features are developed, these are refined into increasing levels of capability by adding new
functionalities in successive versions.
• Each incremental version is usually developed using an iterative waterfall model of development.
• customer feedback is obtained on the delivered version and this feedback is incorporated in the next version.
• Each delivered version of the software incorporates additional features over the previous version and refines the features
that were already delivered to the customer.
Advantages:

• Error reduction
• Incremental resource deployment

Disadvantage:

• Need for good planning.

• Total Cost is high.
• Well defined module interfaces are needed.

Rapid application Development Model

• The Rapid Application Development Model was first proposed by IBM in the 1980s.

• The critical feature of this model is the use of powerful development tools and techniques.

• A software project can be implemented using this model if the project can be broken down into small modules wherein
each module can be assigned independently to separate teams.

• These modules can finally be combined to form the final product. Development of each module involves the various basic
steps as in the waterfall model i.e analyzing, designing, coding, and then testing, etc.

Requirements Planning – It involves the use of various techniques used in requirements elicitation like brainstorming, task
analysis, form analysis, user scenarios, FAST (Facilitated Application Development Technique), etc. It also consists of the entire
structured plan describing the critical data, methods to obtain it, and then processing it to form a final refined model.

User Description – This phase consists of taking user feedback and building the prototype using developer tools. In other words, it
includes re-examination and validation of the data collected in the first phase. The dataset attributes are also identified and
elucidated in this phase.

Construction – In this phase, refinement of the prototype and delivery takes place. It includes the actual use of powerful
automated tools to transform process and data models into the final working product. All the required modifications and
enhancements are too done in this phase.

Cutover – All the interfaces between the independent modules developed by separate teams have to be tested properly. The use
of powerfully automated tools and subparts makes testing easier. This is followed by acceptance testing by the user.
The process involves building a rapid prototype, delivering it to the customer, and taking feedback. After validation by the
customer, the SRS document is developed and the design is finalized.

1. Business Modelling:

The information flow among business functions is defined by answering questions like what data drives the business process,
what data is generated, who generates it, where does the information go, who process it and so on.

2. Data Modelling:

The data collected from business modeling is refined into a set of data objects (entities) that are needed to support the business.
The attributes (character of each entity) are identified, and the relation between these data objects (entities) is defined.

3.Process Modelling:

The information object defined in the data modeling phase are transformed to achieve the data flow necessary to implement a
business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.

Advantages:

• The use of reusable components helps to reduce the cycle time of the project.
• Feedback from the customer is available at the initial stages.
• Reduced costs as fewer developers are required.
• The use of powerful development tools results in better quality products in comparatively shorter time spans.
• The progress and development of the project can be measured through the various stages.
• It is easier to accommodate changing requirements due to the short iteration time spans.

Disadvantages:

• The use of powerful and efficient tools requires highly skilled professionals.
• The absence of reusable components can lead to the failure of the project.
• The systems which cannot be modularized suitably cannot use this model.
• Customer involvement is required throughout the life cycle.
• It is not meant for small-scale projects as in such cases, the cost of using automated tools and techniques may exceed the
entire budget of the project.

Applications:

• This model should be used for a system with known requirements and requiring a short development time.
• It is also suitable for projects where requirements can be modularized and reusable components are also available for
development.
• The model can also be used when already existing system components can be used in developing a new system with
minimum changes.
• This model can only be used if the teams consist of domain experts. This is because relevant knowledge and the ability to
use powerful techniques are a necessity.

Component-based development Model

• Component-based architecture focuses on the decomposition of the design into individual functional or logical
components that represent well-defined communication interfaces containing methods, events, and properties.

• It provides a higher level of abstraction and divides the problem into sub-problems, each associated with
component partitions.

• The primary objective of component-based architecture is to ensure component reusability

What is a Component?
A component is a modular, portable, replaceable, and reusable set of well-defined functionality that encapsulates its
implementation and exporting it as a higher-level interface.

A component is a software object, intended to interact with other components, encapsulating certain functionality or a set of
functionalities. It has an obviously defined interface and conforms to a recommended behavior common to all components within
an architecture.
Characteristics of Components

• Reusability − Components are usually designed to be reused in different situations in different applications. However,
some components may be designed for a specific task.

• Replaceable − Components may be freely substituted with other similar components.

• Not context specific − Components are designed to operate in different environments and contexts.

• Extensible − A component can be extended from existing components to provide new behavior.

• Encapsulated − A component depicts the interfaces, which allow the caller to use its functionality, and do not expose
details of the internal processes or any internal variables or state.

• Independent − Components are designed to have minimal dependencies on other components.

Advantages

• Ease of deployment − As new compatible versions become available, it is easier to replace existing versions with no impact
on the other components or the system as a whole.
• Reduced cost − The use of third-party components allows you to spread the cost of development and maintenance.
• Ease of development − Components implement well-known interfaces to provide defined functionality, allowing
development without impacting other parts of the system.
• Reusable − The use of reusable components means that they can be used to spread the development and maintenance
cost across several applications or systems.
• Reliability − The overall system reliability increases since the reliability of each individual component enhances the
reliability of the whole system via reuse.
• System maintenance and evolution − Easy to change and update the implementation without affecting the rest of the
system.
• Independent − Independency and flexible connectivity of components. Independent development of components by
different group in parallel. Productivity for the software development and future software development.

Requirement Engineering and Modelling

Requirements Elicitation:

Requirements elicitation is the process of gathering and defining the requirements for a system. It involves identifying, collecting,
and documenting the needs and expectations of stakeholders, including users, customers, and other relevant parties. The goal is
to ensure a comprehensive understanding of what the system is expected to accomplish. Techniques used in requirements
elicitation include interviews, surveys, workshops, observations, and studying existing documentation. This phase is crucial for
laying the foundation for a successful development process by capturing accurate and complete requirements.

Requirements Specification:

Once requirements are elicited, the next step is requirements specification, which involves documenting and describing the
gathered requirements in a clear and unambiguous manner. The specifications serve as a reference for both the development
team and stakeholders, providing a detailed understanding of what needs to be implemented. This documentation can take
various forms, including textual descriptions, diagrams, use cases, and prototypes. A well-written requirements specification
ensures that all stakeholders have a common understanding of the project's scope and objectives, reducing the likelihood of
misunderstandings or misinterpretations.

Requirements Verification and Validation:

Verification and validation are two distinct processes that ensure the correctness and effectiveness of the requirements.

• Requirements Verification: This process involves checking that the documented requirements meet specified criteria for
completeness, correctness, consistency, and clarity. Verification ensures that the requirements align with the intended
scope of the project and adhere to quality standards. Techniques for verification include inspections, walkthroughs, and
reviews.
• Requirements Validation: Validation, on the other hand, focuses on confirming that the specified requirements accurately
represent the stakeholders' needs and that the proposed system will meet those needs when implemented. This process
ensures that the system will be effective in its intended environment. Validation techniques include prototyping,
simulations, and end-user evaluations.

Both verification and validation are iterative processes that occur throughout the development lifecycle. They help prevent errors
and misunderstandings early in the process, reducing the risk of costly changes later on. Successful verification and validation
contribute to the overall quality and success of the software development project.

Requirement management

Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the requirement and
controlling the communication to relevant stakeholders.

Requirements elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below –

• Interviews

• Brainstorming Sessions

• Facilitated Application Specification Technique (FAST)

• Quality Function Deployment (QFD)

• Use Case Approach

Use Case Diagram

A UML use case diagram is the primary form of system/software requirements for a new software program underdeveloped. Use
cases specify the expected behaviour (what), and not the exact method of making it happen (how).

A key concept of use case modelling is that it helps us design a system from the end user's perspective.

It is an effective technique for communicating system behaviour in the user's terms by specifying all externally visible system
behaviour.

Use Case

• System function (process - automated or manual)

• Named by verb + Noun (or Noun Phrase).

• i.e. Do something

• Each Actor must be linked to a use case, while some use cases may not be linked to actors.

A Use Case diagram illustrates a set of use cases for a system, i.e. the actors and the relationships between the actors and use
cases.
The include relationship adds additional functionality not specified in the base use case. The <<Include>> relationship is used to
include common behaviour from an included use case into a base use case in order to support the reuse of common behaviour.

The extend relationships are important because they show optional functionality or system behaviour. The <<extend>>
relationship is used to include optional behaviour from an extending use case in an extended use case. Take a look at the use case
diagram example below. It shows an extend connector and an extension point "Search".
SRS

"SRS" stands for Software Requirements Specification. It is a document that serves as a comprehensive and formal agreement
between the client and the development team regarding the detailed requirements of a software project. The SRS outlines the
functionalities, features, constraints, and other characteristics that the software product is expected to exhibit.

Class Based Models

• Class-based modeling represents the objects that the system will manipulate, the operations that will be applied to the
objects to effect the manipulation, relationships between the objects, and the collaborations that occur between the
classes that are defined.
• The elements of a class- based model include classes and objects, attributes, operations, class responsibility, collaborator
(CRC) models, collaboration diagrams, and packages

Identifying Analysis Classes

• External entities that produce or consume information to be used by a computer-based system.

• Things (e.g., reports, displays, letters, signals) that are part of the information domain for the problem.
• Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the
context of system operation.
• Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.
• Organizational units (e.g., division, group, team) that are relevant to an application.
• Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of
the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects

Behavioural Model( Introduction)

We can represent the behavior of the system as a function of specific events and time. The behavioral model indicates how
software will respond to external events or stimuli. To create the model, you should perform the following steps:

• Evaluate all use cases to fully understand the sequence of interaction within the system.
• Identify events that drive the interaction sequence and understand how these events relate to specific objects.
 • Create a sequence for each use case.
• Build a state diagram for the system.
• Review the behavioral model to verify accuracy and consistency.

Design Engineering
• Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the
software. Initially, the blueprint depicts a holistic view of software.

• That is, the design is represented at a high level of abstraction— a level that can be directly traced to the specific system
objective and more detailed data, functional, and behavioral requirements.

Software Design is also a process to plan or convert the software requirements into a step that are needed to be carried out to
develop a software system

Design Principles

• Should not suffer from “Tunnel Vision” –

It should not only focus on completing or achieving the aim but on other effects also. A good designer should consider
alternative approaches, judging each based on the requirements of the problem, the resources available to do the job,
and the design concepts.

• Traceable to analysis model –

It should satisfy all the requirements that software requires to develop a high-quality product.

• Should not “Reinvent The Wheel” –

It should not waste time or effort in creating things that already exist. Due to this, the overall development cost will get
increased.

• Minimize Intellectual distance –

That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain

• The design should exhibit uniformity and integration- A design is uniform if it appears that one person developed the
entire thing. Rules of style and format should be defined for a design team before design work begins. A design is
integrated if care is taken in defining interfaces between design components
• Accommodate change –
The software should be designed in such a way that it accommodates the change implying that the software should adjust
to the change that is required to be done as per the user’s need.
• The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are
encountered- Well designed software should never “bomb.” It should be designed to accommodate unusual
circumstances, and if it must terminate processing, do so in a graceful manner.
• Review to discover errors –
The design should be reviewed which means that the overall evaluation should be done to check if there is any error
present or if it can be minimized.
• Design is not coding and coding is not design –
Design means describing the logic of the program to solve any problem and coding is a type of language that is used for
the implementation of a design.

Design Concepts

1. Abstraction:

• It simply means to hide the details to reduce complexity and increases efficiency or quality.

Types of abstraction:

• Procedural
 • Data

• Control

2. Refinement

Refinement helps the designer to reveal low-level details as design progresses. Both concepts aid the designer in creating a
complete design model as the design evolves.

3. Modularity
4. Software Architecture:
5. Pattern- a repeated form
6. Structural Partitioning:
7. Information Hiding

Functional Independence

• Software with effective modularity, that is, independent modules, is easier to develop because function may
be compartmentalised and interfaces are simplified (consider the ramifications when development is conducted by a
team).
• Independent modules are easier to maintain (and test) because secondary effects caused by design or code modification
are limited, error propagation is reduced, and reusable modules are possible.

To summarize, functional independence is a key to good design, and design is the key to software quality.

• independence is measured using two qualitative criteria:

• cohesion and coupling.

• Cohesion is a measure of the relative functional strength of a module.

• Coupling is a measure of the relative interdependence among modules.

Cohesion Coupling

Cohesion is the concept of intra-module. Coupling is the concept of inter-module.

Cohesion represents the relationship within a module. Coupling represents the relationships between modules.

Increasing cohesion is good for software. Increasing coupling is avoided for software.

Cohesion represents the functional strength of modules. Coupling represents the independence among modules.

Highly cohesive gives the best software. Whereas loosely coupling gives the best software.

In cohesion, the module focuses on a single thing. In coupling, modules are connected to the other modules.

Cohesion is created between the same module. Coupling is created between two different modules.

There are Six types of Cohesion There are Six types of Coupling

1. Functional Cohesion. 1. Common Coupling.

2. Procedural Cohesion. 2. External Coupling.
3. Temporal Cohesion. 3. Control Coupling.
4. Sequential Cohesion. 4. Stamp Coupling.
5. Layer Cohesion. 5. Data Coupling
6. Communication Cohesion. 6. Content Coupling.
 Project scheduling & Cost Estimation
Numerical measures that quantify the degree to which software, a process or a project possesses a given attribute.

• Without measure it is impossible to plan, detect problems, and improve a process and product.
• A software engineer collects measure and develops metrics so that indicators will be obtained.
• An indicator provides insight that enables the project manager or software engineers to adjust the process, the
project, or the product to make things better.

Metrics help the following.

• Determining software quality level

• Estimating project schedules
• Tracking schedule process
• Determining software size and complexity
• Determining project cost
• Process improvement

The five essential, fundamental metrics:

• Size (LOC, etc.)

• Cost (in dollars)
• Duration (in months)
• Effort (in person‐month)
• Quality (number of faults detected)

Conventional metrics

• Size‐oriented metrics
• Function‐oriented metrics
• Empirical estimation models

User‐Case oriented metrics

Functional Point (FP) Analysis

• Function Point Analysis (FPA) is a method or set of rules of Functional Size Measurement. It assesses the
functionality delivered to its users, based on the user’s external view of the functional requirements. It measures the
logical view of an application, not the physically implemented view or the internal technical view.
• The Function Point Analysis technique is used to analyze the functionality delivered by software and Unadjusted
Function Point (UFP) is the unit of measurement.

Objectives of FPA

• The objective of FPA is to measure software development and maintenance independently of the technology used
for implementation.

• It should be simple enough to minimize the overhead of the measurement process.

• It should be a consistent measure among various projects and organizations.

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables
2. Number of External Output (EO) Output screens and reports
3. Number of external inquiries (EQ) Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces (EIF) Shared databases and shared routines.

The Function Point (FP) is thus calculated with the following formula.

FP = Count-total * [0.65 + 0.01 * ∑(fi)]

= Count-total * CAF

where Count-total is obtained from the above Table.

Fi is value adjustment factor

CAF = [0.65 + 0.01 *∑(fi)]

and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF (where i ranges from 1 to 14).
Usually, a student is provided with the value of ∑(fi)

Also note that ∑(fi) ranges from 0 to 70, i.e.,

0 <= ∑(fi) <=70

and CAF ranges from 0.65 to 1.35 because

When ∑(fi) = 0 then CAF = 0.65

When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

COCOMO 2 MODEL

COCOMO 2 stands for Constructive Cost Model 2, which is a software cost estimation model that estimates the effort, duration,
and size of a software project based on various factors such as the project characteristics, the development environment, and the
personnel capability

COCOMO 2 consists of three submodels:

● Application composition model: a submodel that estimates the effort and size of a software project based on the number of
object points, which are the units of functionality that are composed using graphical user interface tools or code generators

● Early design model: a submodel that estimates the effort and size of a software project based on the number of function points,
which are the units of functionality that are derived from the user requirements

● Post-architecture model: a submodel that estimates the effort and size of a software project based on the number of source
lines of code, which are the units of functionality that are implemented using a programming language

COCOMO 2 uses the following formula to calculate the effort in person-months:

- Effort = A * Size^E * EM

- where A is a constant, Size is the estimated size of the project in object points, function points, or source lines of code, E is an
exponent that depends on the submodel, and EM is an effort multiplier that reflects the influence of various cost drivers