6SE B SEGP48 Manual VER1

L D College of Engineering, Ahmedabad
Department of Information Technology

AY:2019-20
GTU B.E. 6th Semester

2160701- Software Engineering
Lab Manual
LDCE-IT-SE-MANUAL VER:2020
L D College of Engineering, Ahmedabad
Department of Information Technology
GTU B.E. 6th Semester 2160701- Software Engineering
Practical List
Sr. Aim Hrs
No.
1 SDLC Models 2
Study and Prepare Summarize various Software Models.
Application, Advantages, Disadvantages
2 Software Engineering Project 2
Select a MIS System and Prepare Problem Description, Solution, User Roles and Responsibility,
Inputs and Deliverable Output Products for system
• Prepare List of Requirements with Classification of Requirement (Feasibility, Functional
/Non Functional, Type: User/System, Priority, Delivery Mode: In Phase/Immediate )
• Prepare SRS Document for Selected Project
3 Structured Software Engineering 4
Prepare following software engineering documents
• Data flow Diagrams (0 level to • ER Diagram
Higher levels) Database Queries
• Data Dictionary
4 Object Oriented Software Engineering: Structural UML Diagrams 4
Prepare following diagrams for selected project:
• Class diagram, • Component diagram
• Object diagram • Composite structure diagram
• Package diagram • Deployment diagram
5 Object Oriented Software Engineering: Behavioral UML Diagrams 4
Prepare following diagrams for selected project:
• Use case diagram • Communication diagram
• Activity diagram • Interaction overview diagram
• Sequence diagram • Timing diagram
• State diagram
6 User Interface Design 2
Draw User Interface using CUI/GUI Methods-Menu Driven, Card Driven for selected project.
Prepare Software Design Document for the Project.
7 Software Project Management :Activity Scheduling 2
Prepare the Time Line and Activity Scheduling using Turbo Project, Microsoft Project Tool
Prepare Software Project Plan Document/Gantt Chart for the Project
8 Software Project Cost Estimation 2
Calculate the Various Costs using CoCoMo, Function Point, Algorithmic Cost Modeling
Methods
9 Software Testing 2
Design Test Cases and Scenarios for Testing Software as a parts and as a whole
Prepare Software Project Test Plan Document for the Project
10 Case study on CASE Tools for Software Processes 2
11 Review of Website/ Desktop Application from Software Engineering Perspectives. 2
(LDCE-IT-SE-MANUAL VER:2020) 1
INDEX
GTU B.E. 6th Semester Subject: 2160701- Software Engineering

Student Name : Mavani Hrishita S. Enrollment No:180283116013
Student Name : Rao Vishwa M. Enrollment No: 180283116020
Student Name : Vaghela Yash N. Enrollment No: 180283116027
Sr.
Aim Date Mark Sign
No.
1 SDLC Models
2 Software Engineering Project :SRS Document
3 Structured Software Engineering
Object Oriented Software Engineering: Structural UML

4
Diagrams
5 Object Oriented Software Engineering: Behavioral UML
Diagrams
6 User Interface Design Software Design Document
Software Project Management :Activity Scheduling

7
SPMP- Software Project Management Plan /Gantt Chart
8 Software Project Cost Estimation
9 Software Testing: Project Test Plan Document
10 Case study on CASE Tools for Software Processes
11 Software Engineering Case Study Review.
Faculty Sign:__________________
Practical 1: SDLC Models
AIM: Study and Prepare Summarize various Software Models. Application, Advantages, Disadvantages
Models: Waterfall Model, Iterative Waterfall model, Spiral Model, Prototyping model,V-Shape SDLC,
Agile SDLC
Parameters:
A. Description
B. Diagram
C. Stages/Phases
D. Type of Software where it is applicable
E. Characteristics of Software Project
F. Characteristics of Software Project Team with Size
G. Risk Associated with Project
H. Characteristics of User/Customer
I. Scope and Cost of Change Request Management
1. Waterfall Model :-
A. Description:
• The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model.
• In a waterfall model, each phase must be completed before the next phase can begin and there is
no overlapping in the phases.3
• The waterfall Model illustrates the software development process in a linear sequential flow. This
means that any phase in the development process begins only if the previous phase is complete.
• In this waterfall model, the phases do not overlap, the outcome of one phase acts as the input for
the next phase sequentially.
• All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases.
• The next phase is started only after the defined set of goals are achieved for previous phase and
it is signed off, so the name "Waterfall Model".
B. Diagram:
C. Stages/Phases:
The sequential phases in Waterfall model are −

• Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first phase are studied in this phase and
the system design is prepared. This system design helps in specifying hardware and system
requirements and helps in defining the overall system architecture.
• Implementation − With inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any
faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the product
is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix those
issues, patches are released. Also, to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
• This model is used only when the requirements are very well known, clear and fixed. Product
definition is stable. Technology is understood. The project is short.
• In development of database-related software like commercial projects, in development of E-
commerce website or portal, in Development of network protocol software this waterfall
model can be used
• Requirements are very well documented, clear and fixed.

• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
• Generally, a Waterfall team can be defined as a team of developers that uses Waterfall
methodology to manage its projects. Such teams act according to the above-
mentioned Waterfall principles.
• Such teams usually include more than 15 people because their members are not
interchangeable.
• The structure of Waterfall teams is what we are used to call “a traditional structure of a
software development team”. It includes four roles: a developer, a tester, a business analyst,
and a project manager. Waterfall teams do not include the customers or their representatives.
Now let’s look at the responsibilities of Waterfall team members.
• The developers are people who write the code. They are also called programmers. They act at
all stages of Waterfall projects including the stage of testing.
• The tester is the person who tests the software product. In Waterfall projects, the stage of
testing is the last stage before product delivery. Waterfall testers usually detect bugs and issues
in the final products by using issue tracking applications.
• Business analysts are responsible for making the final product competitive in the software
market. They conduct various researches to achieve this goal.
• The project manager is the leader of Waterfall team. He is the main person responsible for
the quality of the final product.
G. Risk Associated with Project:
Generally, anything that can negatively affect the project or its result is considered a risk.
• Clients may not know exactly what their requirements are before they see working software
and so change their requirements, leading to redesign, redevelopment, and retesting, and
increased costs.
• Excludes the client and/or end user. Its main purpose has always been to help internal teams
move more efficiently through the phases of a project, However, if you work in an industry
other than software, clients often want to be involved during a project, adding opinions and
clarifying what they want as the project moves forward.
• Since the product that you are trying to create will not be produced until the very end,
you are not really sure if you are still on planning or you are already on developing stage.
• Makes changes difficult as Waterfall is based entirely on following a set of steps that keep
teams always moving forward, it leaves almost no room for unexpected changes or revisions.
• Delays testing until after completion as Waterfall insists that teams wait until step four out
of six to test their products. Outside of the software industry, the testing phase could mean
showing a new website design to a client, A/B testing content, or taking any number of steps
to gain empirical data on the viability of the project. At this point, the project has likely taken
considerable time to complete, so large revisions could cause significant delays.
H. Characteristics of User/Customer:
• User should have understood system properly so that changes are not expected during
operation and maintenance.
I. Scope and Cost of Change Request Management:

• Any changes at later stage leads can not be incorporated in existing work flow , therefore leads
to redesigning requirements and incurs high redevelopment cost.
2. Iterative Waterfall Model
A. Description:
• Iterative waterfall model can be thought of as incorporating the necessary changes to the classical
waterfall model to make it usable in practical software development projects.
• Iterative Waterfall Model is the extension of the Waterfall model.
• The iterative waterfall model provides feedback paths from every phase to its preceding phases,
which is the main difference from the classical waterfall model.
• There is no feedback path provided for feasibility study phase, so if any change is required in that
phase then iterative model doesn’t have scope for modification or making corrections.
• Iterative waterfall allows to go back on the previous phase and change the requirements and some
modification can done if necessary.
• This model reduces the developer’s effort and time required to detect and correct the errors.
• In iterative waterfall model, next phase can only begins when the previous phase is completed as
waterfall model.
B. Diagram:
C. Stages/Phases:
The sequential phases in Waterfall model are −

• Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
• Feasibility Study : A feasibility study is an analysis that takes all of a project's relevant
factors into account—including economic, technical, legal, and scheduling considerations—to
ascertain the likelihood of completing the project successfully.
• System Design − The requirement specifications from first phase are studied in this phase and
the system design is prepared. This system design helps in specifying hardware and system
requirements and helps in defining the overall system architecture.
• Implementation − With inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any
faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the product
is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix those
issues, patches are released. Also, to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
D. Type of Software where it is applicable:

• It is applicable only to large and bulky software development projects. This is because it is
hard to break a small software system into further small serviceable increments/modules.
• Large, mission-critical enterprise applications that preferably consist of loosely coupled parts,
such as microservices or web services.
E. Characteristics of Software Project:
• Requirements of the complete system are clearly defined and understood.

• Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team while working
on the project.
• Resources with needed skill sets are not available and are planned to be used on contract basis
for specific iterations.
• There are some high-risk features and goals which may change in the future.
• Generally, an Iterative team can be defined as a team of developers that uses Waterfall
methodology to manage its projects. Such teams act according to the above-
mentioned principles.
• Such teams usually include more than 10-15 people because their members are not
interchangeable.
• The team includes four roles: a developer, a tester, a business analyst, and a project manager.
Waterfall teams do not include the customers or their representatives.
• Highly skilled resources are required for risk analysis.
Now let’s look at the responsibilities of Waterfall team members.
• The developers are people who write the code. They are also called programmers. They act at
all stages of Waterfall projects including the stage of testing.
• The tester is the person who tests the software product. In Waterfall projects, the stage of
testing is the last stage before product delivery. Waterfall testers usually detect bugs and issues
in the final products by using issue tracking applications.
• Business analysts are responsible for making the final product competitive in the software
market. They conduct various researches to achieve this goal.
• The project manager is the leader of Waterfall team. He is the main person responsible for
the quality of the final product.
• More resources may be required.

• Although cost of change is lesser, but it is not very suitable for changing requirements.
• More management attention is required.
• System architecture or design issues may arise because not all requirements are gathered in
the beginning of the entire life cycle.
• Defining increments may require definition of the complete system.
• Management complexity is more.
• End of project may not be known which is a risk.
• Highly skilled resources are required for risk analysis.
• Projects progress is highly dependent upon the risk analysis phase.
• User must have detailed idea about software he wants to develop.
• However they may raise change in later stage.
• Change should be such that does not affects overall system structure.
I. Scope and Cost of Change Request Management:
• Although cost of change is lesser, but it is not very suitable for changing requirements.
3. Spiral Model
A. Description:
• This Spiral model is a combination of iterative development process model and sequential linear
development model i.e. the waterfall model with a very high emphasis on risk analysis as well as
prototype model.
• Here software development is performed systematically over the loops and at the same time, in
the same iteration prototype of the software is developed and shows it to the user after completion
of various phases.
• There are four phases in this model. These four phases are iteratively followed one after another
in order to eliminate all the problems, which were faced in the waterfall model.
B. Diagram:
C. Stages/Phases:
• There are four phases in this model which are: Identification, Evaluation and Risk Analysis ,
Engineering and Build. A software project repeatedly passes through these phases in iterations
called Spirals.
Identification
• This phase starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identification of system requirements, subsystem
requirements and unit requirements are all done in this phase.
• This phase also includes understanding the system requirements by continuous communication
between the customer and the system analyst. At the end of the spiral, the product is deployed in
the identified market.
Design
• The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the final design in
the subsequent spirals.
Construct or Build
• The Construct phase refers to production of the actual software product at every spiral. In the
baseline spiral, when the product is just thought of and the design is being developed a POC
(Proof of Concept) is developed in this phase to get customer feedback.
• Then in the subsequent spirals with higher clarity on requirements and design details a working
model of the software called build is produced with a version number. These builds are sent to
the customer for feedback.
Evaluation and Risk Analysis

• Risk Analysis includes identifying, estimating and monitoring the technical feasibility and
management risks, such as schedule slippage and cost overrun. After testing the build, at the end
of first iteration, the customer evaluates the software and provides feedback.
• The following illustration is a representation of the Spiral Model, listing the activities in each
phase.
• When requirements are not clear and when the solution has multi-user, multifunction, multi-
features where faultless integration, data migration are need in such scenario spiral model is use.
• When there is a budget constraint and risk evaluation is important.

• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic priorities as the
requirements change with time.
• Customer is not sure of their requirements which is usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough customer feedback.
• Significant changes are expected in the product during the development cycle.
• Risk analysis is important phase so requires expert people.
• Management is more complex.

• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for small projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive documentation.
• Risk of not meeting the schedule or budget
• User is not able to propose requirements properly.

• User is not concerned about cost.

• During the progress in project important changes are expected.
4. Prototyping Model
A. Description:
• The prototype model was developed on the assumption that it is very difficult to know all the
requirements at the initial stage of a project.
• With using the Prototype Model, the developer develops a simplified version of the proposed
system and displays it to the customer for consideration of that system, as a part of the
development process. The customer gives the feedback by using the system, which are in the
form of requirements.
• Again developers consider these new requirements and new system is developed based on new
requirements.
• The basic idea here is that instead of finalizing the requirements before a design or coding can
proceed, a prototype is built to make clear the requirements, based on his feedback; the SRS
document is prepared.
B. Diagram:
C. Stages/Phases:
Requirement Gathering:
• This is the phase where requirements are gathered during this phase.
• The behavior of the software, what type of need is there, how the software interacts with other
applications are defined in this phase.
• Tools required to build the software are also defined in this phase. Based on these requirements
the prototype model is created.
Quick Design:
• Design is created based on the requirements gathered during requirement gathering phase.
• The technology which is going to be used in the system is decided in this phase.
• The hardware and software to build the software are decided in this phase.
• The database which is going to use is also decided in this phase.
Build Prototype:
• Actual model is prepared in this phase. Coding is done in this phase
• First all the small units called units are prepared in this phase. These units are tested under
―Unit test‖. Then all the units are integrated and ―Integrated test‖ is being performed.
• This model works as prototype model.
Customer evaluation:
• After using the prototype model, customer gives their feedback. if prepared prototype is lacking
in some requirements then customer also gives suggestion for more requirements and changes.
Refine Requirements:
• Newly arrived requirements are processed in this phase, which is the base for new system to
develop. Phases no 2, 3, 4, and 5 are repeated until required design model is prepared. It displays
to the client and if it is approved then related document is prepared.
SRS Documents:
• System Requirement Specification (SRS) documents are prepared, which describe the whole
system requirements.
Design:
• Depending upon SRS document the required model is built.. If any error is there, then again it
needs correction. After making it error free now, it is ready to use.
Implement:
• In this phase the software is ready to implement at client‘s site.
Test:
• At client‘s site, the software is tested for its functionality, correctness and interoperability.
Maintain:
• This is the lifelong phase. Software is maintained for any error in future. By using this system
another system also can be developed.
• In such scenario where there is an absence of detailed information regarding the input to the
system, the processing needs and the output requirements, the prototyping model may be
employed.
• Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems.
• Systems which need users to fill out forms or go through various screens before data is processed
can use prototyping very effectively to give the exact look and feel even before the actual
software is developed.

• When the client has only general view of what is expected from the software product.
• Large and complicated system for which there is no manual process or existing system to help to
determine the requirements and when high risk is associated with the system.
• Prototype model is used for user interface like interactive online system, decision support system
such as medical diagnosis system.

• Team is large consisting of 5-10 members

• Sometimes the start-up cost of building the development team, focused on making prototype is
high.
• It is a slow process.
• Once we get proper requirements from client after showing prototype model, it may be of no use.
• Too much involvement of client is not always preferred by the developer.
• Too many changes can disturb the development team
• Customer could believe the prototype as the working version.
• Developer also could make the implementation compromises where he could make the quick
fixes to the prototype and make is as a working version.
• Client have general view of project.
• Client is available for review process.
• Client is not concerned about cost.

• Client is involved in various stages of development so all the changes are accepted till testing
phase and cost of these changes is high as change is to be made in prototype and not the actual
product which incurs extra cost.
5. Agile SDLC Model
A. Description:
• Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.
• Agile Methods break the product into small incremental builds.
• Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements
• Iterative approach is taken and working software build is delivered after each iteration. Each
build is incremental in terms of features; the final build holds all the features required by the
customer.
• There are some Agile Development Methodologies like: 1) Rapid Application Development 2)
Joint Application Development 3) Scrum 4) Extreme Programming (XP)
Following are the Agile Manifesto principles −
• Individuals and interactions − In Agile development, self-organization and motivation are
important, as are interactions like co-location and pair programming.
• Working software − Demo working software is considered the best means of communication
with the customers to understand their requirements, instead of just depending on documentation.
• Customer collaboration − As the requirements cannot be gathered completely in the beginning
of the project due to various factors, continuous customer interaction is very important to get
proper product requirements.
• Responding to change − Agile Development is focused on quick responses to change and
continuous development.
B. Diagram:
C. Stages/Phases:
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.
• Small to medium-sized software developments.

• Product development where multiple variants are required or desirable.
• Where the main deliverable can be broken down and produced in incremental discrete packages.
• There is one major consideration here though; the requirements and functions developed during
each iteration must be stand-alone and not have major dependencies with other requirements and
functions outside of the current iteration. At the end of the iteration, we should have elements of
product that are ready to release and deploy. If we cannot achieve that, we may not be using
Agile at all.
• Rapid Application Development methodology works best for projects where the scope is small or
work can be broken down into manageable units.
• RAD is also recommended when system components have already been developed by the
organization in the context of other software systems, and these components can be used in the
new system with minor or no modification .
• RAD approach is good when a module of a larger system can be clearly defined in scope,
functions, data, its processes, applications and outputs.
• The RAD approach is efficient when system modules are of same type in design, architecture and
technology and there would not have any problems in smooth integration.
• Scrum works better in environments with rapid changes. It is highly adaptable to the changing
requirements. It is useful when fast feedback is given by stakeholders or users.
• Web based application can be developed using scrum model.
• Extreme Programming works when Requirements are constant changing, high risk in there and
rapid development of software is required then this model is used.

• The agile teams work in close collaboration with each other and are most often located in the
same geographical location.
• Team members of agile project are usually organized by themselves. They take responsibility for
tasks that deliver the working software with desired functionality iteration requires. They decide
individually how to meet iteration‘s requirements
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.

• An overall plan, an agile leader and agile PM practice is a must without which it will not work.
• Strict delivery management dictates the scope, functionality to be delivered, and adjustments to
meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can be driven in the
wrong direction.
• There is a very high individual dependency, since there is minimum documentation generated.
• Transfer of technology to new team members may be quite challenging due to lack of
documentation.
• Customer must be ready to interact throughout the process.
• Used when cost is concern
• Customer emphasize more on timely delivery rather than documentation.
• The role of end users is in designing the system and agreeing the systems.
• End users quickly take involvement and ownership in systems where JAD is used.

• Change management is an inherent part of agile processes. You assess scope and have an
opportunity to include new requirements with every sprint. The product owner determines the
value and priority of new requirements and adds those requirements to the product backlog.
6. V-shaped SDLC Model
A. Description:
• The V-model is an SDLC model where execution of processes happens in a sequential manner in
a V-shape. It is also known as Verification and Validation model.
• The V-Model is an extension of the waterfall model and is based on the association of a testing
phase for each corresponding development stage. This means that for every single phase in the
development cycle, there is a directly associated testing phase. This is a highly-disciplined model
and the next phase starts only after completion of the previous phase.
• Under the V-Model, the corresponding testing phase of the development phase is planned in
parallel. So, there are Verification phases on one side of the ‘V’ and Validation phases on the
other side. The Coding Phase joins the two sides of the V-Model.
B. Diagram:
C. Stages/Phases:
Verification Phases
There are several Verification phases in the V-Model, each of these are explained in detail below.
• Business Requirement Analysis: This is the first phase in the development cycle where the
product requirements are understood from the customer’s perspectiveThe acceptance test design
planning is done at this stage as business requirements can be used as an input for acceptance
testing.
• System Design: Once you have the clear and detailed product requirements, it is time to design
the complete system. The system design will have the understanding and detailing the complete
hardware and communication setup for the product under development. The system test plan is
developed based on the system design. Doing this at an earlier stage leaves more time for the
actual test execution later.
• Architectural Design: Architectural specifications are understood and designed in this phase.
The system design is broken down further into modules taking up different functionality. This is
also referred to as High Level Design (HLD).The data transfer and communication between the
internal modules and with the outside world (other systems) is clearly understood and defined in
this stage.
• Module Design: In this phase, the detailed internal design for all the system modules is specified,
referred to as Low Level Design (LLD). The unit tests are an essential part of any development
process and helps eliminate the maximum faults and errors at a very early stage. These unit tests
can be designed at this stage based on the internal module designs.
• Coding Phase: The actual coding of the system modules designed in the design phase is taken up
in the Coding phase. and is optimized for best performance before the final build is checked into
the repository.
Validation Phases
The different Validation Phases in a V-Model are explained in detail below.
• Unit Testing:Unit tests designed in the module design phase are executed on the code during this
validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early
stage, though all defects cannot be uncovered by unit testing.
• Integration Testing:Integration testing is associated with the architectural design phase.

Integration tests are performed to test the coexistence and communication of the internal modules
within the system.
• System Testing:System testing is directly associated with the system design phase. System tests
check the entire system functionality and the communication of the system under development
with external systems. Most of the software and hardware compatibility issues can be uncovered
during this system test execution.
• Acceptance Testing:Acceptance testing is associated with the business requirement analysis

phase and involves testing the product in user environment. Acceptance tests uncover the
compatibility issues with the other systems available in the user environment. It also discovers the
non-functional issues such as load and performance defects in the actual user environment.
• The V-shaped model is the best choice for systems that require high reliability, such as
hospital patient control application and embedded software for air-bag controller in
automobiles due to their provision of test plan which produce test cases in all the phase of the
development.
• The V-shaped model should be used for small to medium sized projects where requirements
are clearly defined and fixed. The V-Shaped model should be chosen when ample technical
resources are available with needed technical expertise
• Requirements are well defined, clearly documented and fixed.

• Product definition is stable.
• Technology is not dynamic and is well understood by the project team.
• There are no ambiguous or undefined requirements.
• The project is short.

• Team must know technology thoroughly.
• Small team of 3-4 members is required.

• It produces inefficient testing methodologies if any changes come across during development.
• If any changes happen in mid-way, then the best documents along with requirement document
has to be updated.
• Adjusting requirements is difficult and expensive.
• Software is developed in the implementations phase, so no prior prototypes of the software are
produced.
• Model doesn‘t provide a clear path for solving problems found during testing phases.
• It doesn‘t handle concurrent event as it is extension of waterfall model.
• Customer is not clear about their requirements at early stage.

• It is inflexible; it has no ability to respond to change. It is very rigid as there is no way to go
back.
Practical 2: Software Engineering Project :SRS Document
AIM: Select a MIS System and Prepare Problem Description, Solution, User Roles and Responsibility,
Inputs and Deliverable Output Products for system
1. Prepare List of Requirements with Classification of Requirement (Feasibility, Functional /Non

Functional, Type: User/System, Priority, Delivery Mode: InPhase/Immediate )
2. Prepare SRS Document for Selected Project
Project Title: Toxic Gas Analyzer (TOGA)
Stakeholders:
• Project leader and project manager

• Android developer
• IOT developer
• Industries
• Suppliers
• User/workers
Major Requirements :
• Hardware module to detect gas leakage

• Android application to view readings of gas levels in atmosphere
Expected Delivery Time(Months): 2 months
User Roles:
• User can login to the system

• User can view sensor readings for various gases
• User can save reading history
• User can view humidity and temperature readings
• User can dial emergency call in case of fire or such causality.
Responsibility of Roles:
Project leader Manage the team dynamics throughout the projects. They ensure the focus of
the team on project deliverable.
Android developer Designing and developing advanced applications for the Android platform.
and tester Unit-testing code for robustness, including edge cases, usability, and general
reliability. Bug fixing and improving application performance.
IOT developer Develop technical solution designs that cover available platform services for
edge device connectivity, device management, data ingestion and management,
streaming and big-data analytics, visualizations, mobility apps, API interfaces
to enterprise applications.
Industry Purchase the product and participate as prime user.
Supplier Plays an important role by supplying components required for developing

hardware module.
User/workers Login to system and interact with it. View gas readings, temperature updates
and call on emergency number using power button in case of emergency.
Major Modules:
1. Hardware Module – Arduino
2. Android application
• Requirements
Requirement No Description Type Nature

System Functional
(ModuleNo.ReqNo) /User /NonFunctional
M1.R1 User Functional
R 1.1: Detect Hazardous gas like Carbon dioxide,
carbon monoxide, benzene, methane, Sulphur dioxide,
hydrogen sulphide.
1. User (Industry, worker)

2. Priority(High, Immediate)
3. Input: gas sensing
4. Output: send readings to application
M1.R2 R 1.2: Send alert on gas level higher than max range User Functional
1.
User (Industry, worker)
2.
Priority(High, Immediate)
3.
Input: gas levels
4.
Output: Enable emergency call option and send
signals to Arduino to ring alarm
M1.R3 R 1.3: Send Temperature updates to application User Functional

2. Priority(High, Immediate)
3. Input: gas sensing
M1.R4 R 1.4: Readings sent by Arduino should be reliable User Non-
Functional
M1.R5 R 1.5: Module should be portable and easily handleable System Non-
functional
M1.R6 R 1.6: Alarms needed to be installed System Non-
functional
M1.R7 R 1.7: HC05 Bluetooth Module Hardware Non-
System functional
M1.R8 R 1.8: MQ-2 for Sensing Methane Hardware Non-
System functional
M1.R9 R 1.9: MQ-7 for Sensing Carbon-monoxide Hardware Non-
System functional
M1.R10 R 1.10: MQ-135 for Sensing Sulphur-dioxide Hardware Non-
System functional
M1.R11 R 1.11: MQ-136 for Sensing Hydrogen Sulphide Hardware Non-
System functional
M1.R12 R 1.12: MQ-137 for Sensing Carbon-dioxide Hardware Non-
System functional
M1.R13 R 1.13: DHT11 for Sensing Temperature and Humidity Hardware Non-
System functional
M1.R14 R 1.14: Arduino MEGA Hardware Non-
System functional
M2.R1 R 2.1: Display gas readings User Functional

2. Priority(High)
3. Input: gas readings
M2.R2 R 2.2: Display Temperature readings User Functional

2. Priority(Medium)
3. Input: temperature readings
M2.R3 R 2.3: Display min max levels of gas User Functional

2. Priority(low)
3. Input: NA
4. Output: minimum maximum range
M2.R4 R 2.4: Emergency call on increased level of gas User Functional

2. Priority(high)
3. Input: gas readings
4. Output: dial emergency number
M2.R5 R 2.5 Timely update gas level in application User Non-

Functional
M2.R6 R 2.6 User cannot modify gas level User Non-
Functional
Priority : medium
M2.R7 R 2.7 Android version 5.0+ System Functional
Priority : low
M2.R8 R 2.8 Android mobile with internet connection System Non-
functional
Priority : high
M2.R9 R 2.9 Bluetooth service System Non-
Functional
Priority : high
M2.R10 R 2.10 Otp verification for security System Non-
functional
Practical 3: Structured Software Engineering
AIM: Prepare following software engineering documents

1. Data flow Diagrams (0 level to Higher levels)
2. Data Dictionary
3. ER Diagram
4. Database Queries
1. Data flow Diagrams (0 level to Higher levels)

a. Context Level Diagram
b. 1st Level Diagram (All Modules)
c. 2nd Level Diagram (Any Two Modules )
a. Context Level Diagram (TOGA)
[DFD – 0 level ]
b. 1st LEVEL DFD DIAGRAM (TOGA)
[DFD – 1 level ]
c. 2nd LEVEL DFD DIAGRAM (TOGA)
[DFD – 2 level ]
2. Data Data Dictionary : (For at least 5 Tables )
Table 1: User
Purpose: store user details and credentials
Fieldname Data Type Constraints Description
IsPK,Is FK,Unique, NOTNULL
user_id Int IsPK Register no.
name Varchar(255) NOTNULL Name
email_id Varchar(255) Unique Email address
password Varchar(255) NOTNULL Password
Mobile_no Number Unique Mobile number of
user
Table 2: SaveReading
Purpose: save gas level reading with timestamp
IsPK,Is FK,Unique,
NOTNULL
sr_no Int IsPK Serial number
user_id Varchar(255) IsFK Register no.
timestamp Varchar(255) NOTNULL Timestamp
category_id Varchar(255) isFK Category id of sensor
current_reading Varchar(255) NOTNULL Sensor reading
latitude Varchar(255) NOTNULL Location of
reading(latitude)
longitude Varchar(255) NOTNULL Location of
reading(longitude)
Table 3: Category
Purpose: Category of sensor
category_id Int IsPK Category id od
sensor
current_reading Varchar(255) NOTNULL Category name of
sensor
Table 4: Temperature
Purpose: save temperature reading with timestamp
Sr_no Int IsPK Serial number
heat Varchar(255) NOTNULL Heat value
humidity Varchar(255) NOTNULL Humidity levels
temperature Varchar(255) NOTNULL Temperature
levels
timestamp Date NOTNULL Timestamp
Table 5: GasLevel
Purpose: Display minimum and maximum gas levels
sr_no Int IsPK Serial number
category_id Varchar(255) IsFK Category_id
min_level Varchar(255) NOTNULL Minimum gas
level
max_level Varchar(255) NOTNULL Maximum gas
level
3. ER DIAGRAM (TOGA)
[ER- DIAGRAM]
4. Database Queries (For atleast 10 Pseudo Database Queries )
1. CREATE TABLE User

(
Name VARCHAR2(30),
Email VARCHAR2(30),UNIQUE_KEY
Mobile_no NUMBER(30),
Password VARCHAR2(30)
)
2. CREATE TABLE SaveReading

(
user_id VARCHAR2(30),FOREIGN_KEY,
timestamp VARCHAR2(30),
category_id NUMBER(30),FOREIGN_KEY,
current_reading VARCHAR2(30),
latitude VARCHAR2(30),
longitude VARCHAR2(30)
)
3. CREATE TABLE Category

(
category_id NUMBER(30),PRIMARY_KEY,
current_reading VARCHAR2(30)
)
4. Insert into User

(`Name`,`Email`,`Mobile_no`,`Password`)
values
(`Hrishita`,`hrishita@ldce.ac.in`,`9019292876`,`abcdefg`)
5. Insert into SaveReading

(`timestamp`,`category_id`,`current_reading`,`latitude`,`longitude`)
values
(timestamp_txt,category_id, current_reading_txt,latitude_get,longitude_get)
where user_id=u_id
6. Select * from Category where category_id=cat_id;
7. Select * from SaveReading where user_id=u_id;
8. Select * from Temperature ;
9. Update User set password=newpass where user_id=u_id and email=e_mail;
10. Select max_level from GasLevel;
Practical 4: Object Oriented Software Engineering: Structural UML Diagrams
AIM: Prepare following diagrams for selected project:

1. Class diagram,
2. Object diagram
3. Package diagram
4. Component diagram
5. Composite structure diagram
6. Deployment diagram
1. Class diagram (All Classes )
A class represent a concept which encapsulates state (attributes) and behavior (operations). Each
attribute has a type. Each operation has a signature. The class name is the only mandatory
information.
Class Name:
• The name of the class appears in the first partition.
Class Attributes:
• Attributes are shown in the second partition.
• The attribute type is shown after the colon.
• Attributes map onto member variables (data members) in code.
Class Operations (Methods):

• Operations are shown in the third partition. They are services the class provides.
• The return type of a method is shown after the colon at the end of the method signature.
• The return type of method parameters are shown after the colon following the parameter name.
Operations map onto class methods in code
• Class Visibility: The +, - and # symbols before an attribute and operation name in a class
denote the visibility of the attribute and operation.
• + denotes public attributes or operations
• - denotes private attributes or operations,
• # denotes protected attributes or operations
Parameter Directionality: Each parameter in an operation (method) may be denoted as

in, out or inout which specifies its direction with respect to the caller. This directionality is shown
before the parameter name.
Relationship
Example: Order Processing
• CLASS DIAGRAM
2. Object diagram (All Objects)
The use of object diagrams is fairly limited, mainly to show examples of data structures.
A. During the analysis phase of a project, you might create a class diagram to describe the
structure of a system and then create a set of object diagrams as test cases to verify the
accuracy and completeness of the class diagram.
B. Before you create a class diagram, you might create an object diagram to discover facts about
specific model elements and their links, or to illustrate specific examples of the classifiers
that are required.
C. Object Names: Every object is actually symbolized like a rectangle, that offers the name
from the object and its class underlined as well as divided with a colon.
D. Object Attributes: Similar to classes, you are able to list object attributes inside a separate
compartment. However, unlike classes, object attributes should have values assigned for
them.
E. Links: Links tend to be instances associated with associations. You can draw a link while
using the lines utilized in class diagrams.
• OBJECT DIAGRAM
3. Package diagram
Package diagrams are used to structure high level system elements. Packages are used for organizing
large system which contains diagrams, documents and other key deliverables.
A. Package Diagram can be used to simplify complex class diagrams, it can group classes into
packages.
B. A package is a collection of logically related UML elements.
C. Packages are depicted as file folders and can be used on any of the UML diagrams.
Example: Order Subsystem
• PACKAGE DIAGRAM
4. Component diagram
Component diagram is a collection of vertices and arcs and commonly contain components, interfaces
and dependency, aggregation, constraint, generalization, association, and realization relationships. It
may also contain notes and constraints.
A. Association
B. Composition
C. Aggregation
D. Constraint
E. Dependency
F. Links
Example : Java Source Code
Library
• COMPONENT DIAGRAM
[COMPONENT DIAGRAM]
5. Composite structure diagram:
A. Composite Structure Diagrams allow the users to "Peek Inside" an object to see exactly what it
is composed of.
B. The internal actions of a class, including the relationships of nested classes, can be detailed.
C. Objects are shown to be defined as a composition of other classified objects.
D. Composite Structure Diagrams show the internal parts of a class.
E. Parts are named: partName:partType[multiplicity]
F. Aggregated classes are parts of a class but parts are not necessarily classes, a part is any
element that is used to make up the containing class.
Example : Computer System

Class, Part, Port, Multiplicity Connectors,Interface
• COMPOSITE STRUCTURE DIAGRAM
6. Deployment diagram
A. They show the structure of the run-time system
B. They capture the hardware that will be used to implement the system and the links between
different items of hardware.
C. They model physical hardware elements and the communication paths between them
D. They can be used to plan the architecture of a system.
E. They are also useful for Document the deployment of software components or nodes
Place and Connections of Software SubSystems
• DEPLOYMENT DIAGRAM
Practical 5: Object Oriented Software Engineering: Behavioral UML Diagrams
AIM: Prepare following diagrams for selected project:

1. Use case diagram
2. Activity diagram
3. Sequence diagram
4. State diagram
5. Communication diagram
6. Interaction overview diagram
7. Timing diagram
1. Use case diagram

Purpose of Use Case Diagram
Use case diagrams are typically developed in the early stage of development and people often apply use
case modeling for the following purposes:
• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts together with domain experts
A standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use
Case Diagram example below:
• Actor
• Use Case
• Communication Link
• Boundary of system
USE Case Relationship:

• Extends
• Include
• Generalization
• USE-CASE DIAGRAM (TOGA)
[USE-CASE DIAGRAM]
2. Activity diagram
• Identify candidate use cases, through the examination of business workflows

• Identify pre- and post-conditions (the context) for use cases
• Model workflows between/within use cases
• Model complex workflows in operations on objects
• Model in detail complex activities in a high level activity Diagram
• ACTIVITY DIAGRAM (TOGA)
[ACTIVITY DIAGRAM ]
3. Sequence diagram
• Model high-level interaction between active objects in a system

• Model the interaction between object instances within a collaboration that realizes a use case
• Model the interaction between objects within a collaboration that realizes an operation
• Either model generic interactions (showing all possible paths through the interaction) or specific
instances of a interaction (showing just one path through the interaction)
Example :Hotel Reservation
• SEQUENCE DIAGRAM (TOGA)
4. State diagram
State machine diagram typically are used to describe state-dependent behavior for an object. An
object responds differently to the same event depending on what state it is in. State machine
diagrams are usually applied to objects but can be applied to any element that has behavior to other
entities such as: actors, use cases, methods, subsystems systems and etc. and they are typically used
in conjunction with interaction diagrams (usually sequence diagrams)
States:
1. Initial State-Entry State
2. Final State -Exit State
Events :
1. Signal event - corresponding to the arrival of an asynchronous message or signal
2. Call event - corresponding to the arrival of a procedural call to an operation
3. Time event - a time event occurs after a specified time has elapsed
4. Change event - a change event occurs whenever a specified condition is met
Transition
1. An element is in a source state
2. An event occurs
3. An action is performed
4. The element enters a target state
Substates:
A simple state is one which has no substructure. A state which has substates (nested states) is called a
composite state. Substates may be nested to any level. A nested state machine may have at most one
initial state and one final state
Example:Heater
• STATE DIAGRAM (TOGA)
[STATE DIAGRAM]
5. Communication diagram
• Model message passing between objects or roles that deliver the functionalities of use cases and
operations
• Model mechanisms within the architectural design of the system
• Capture interactions that show the passed messages between objects and roles within the
collaboration scenario
• Model alternative scenarios within use cases or operations that involve the collaboration of
different objects and interactions
• Support the identification of objects (hence classes), and their attributes (parameters of
message) and operations (messages) that participate in use cases
• Each message in a communication diagram has a sequence number.
• The top-level message is numbered 1.
• Messages sent during the same call have the same decimal prefix, but suffixes of 1, 2, etc.
according to when they occur.
Example : Hotel Reservation Diagram
• COMMUNICATION DIAGRAM (TOGA)
[COMMUNICATION DIAGRAM]
6. Interaction overview diagram
a student who has been accepted into a university. First the student must be accept or decline
admission. After accepting, the student must both register for classes and apply for housing. After
both of those are complete, the student must pay the registrar. If payment is not received in time the
student is excluded by the registrar.
• INTERACTION DIAGRAM (TOGA)
no
yes
es
Request Request Request temp Request temp Request levels

reading reading
send reading send temp send max value

send reading send temp
yes
NO
save request Call request
Connect call
save
acknowledge
NO
[INTERACTION DIAGRAM]
7. Timing diagram
Changes from one state to another are represented by a change in the level of the lifeline. For the
period of time when the object is a given state, the timeline runs parallel to that state. A change in state
appears as a vertical change from one level to another. The cause of the change, as is the case in a state
or sequence diagram, is the receipt of a message, an event that causes a change, a condition within the
system, or even just the passage of time.
Value Lifeline
• TIMING DIAGRAM
• VALUE LIFELINE
Practical 6: User Interface Design Software Design Document
AIM: Draw User Interface using CUI/GUI Methods-Menu Driven, Card Driven for selected project.
Prepare Software Design Document for the Project.
GUI Design Layout(Desktop/Web/Mobile)(7-10 Screen Layout)

Design Principle for GUI
1. Contrast
2. Hierarchy
3. Proximity
4. Alignment
Components
1. Buttons
1. 2 Text Input
2. Dropdown Menu (Combo Box)
3. Radio Buttons and Checkboxes
4. Links
5. Tabs
6. Breadcrumbs
7. Vertical Navigation
8. Menu Bars
9. Accordions
10. Validation
11. Tooltips
12. Alerts
13. Data Tables
14. Icons
Shopping System
• TOGA- Toxic Gas Analyzer:
Design Of Hardware
Enter Credentials
Navigate to
Forgot Password Navigate to
Screen Registration Screen
Login Screen
Enter Details to
get Registered
and click
button
Registration Screen
Check Safe
Levels for
various gas
Click to
Navigate to
whether screen
to check
humidity and
temperature
Check Gas
Levels by
selecting Gas
Name
Home Screen
Shows Realtime
temperature and
humidity in
atmosphere
Temperature-Humidity Screen
Save Gas
Reading with
timestamp
Gas Reading Screen
Click on a gas
name to navigate
to range screen
Gas List Screen
Minimum and
maximum range
at which user will
be notified
Gas Level Range
Enter email and
reset link will be
sent to mail
through which user
can change
password
Forgot Password
Enter details
and change
password
Change Password
Practical 7: Software Project Management :Activity Scheduling
SPMP- Software Project Management Plan /Gantt Chart
AIM: Prepare the Time Line and Activity Scheduling using Turbo Project, Microsoft Project Tool
Prepare Software Project Plan Document/Gantt Chart for the Project
Roles and Responsibilities
Software Engineer: will plan, analyze and design the software project during preparing the
documentations of project.
Programmer: will write the code of the system.
Test Team Member: will test the system to augment the quality.
Training Coordinator: will prepare the stuff-training plan to ensure that necessary skill levels in
sufficient numbers will be available to successfully conduct the software project.
Meeting Tracer: will organize and coordinate the meetings of team members and also meetings with
customers.
DB Administrator: will be responsible from database configuration and management.
Software System Engineer: will help the project team to identify, control, and track requirements and
changes to requirements at any time as the project proceeds and make the architectural design of the
project accordingly.
Project Manager: will plan (schedule, cost and budget), motivate, organize and control the software
team.
User interface designer: will design the web-based user interfaces.
Configuration Manager: will manage different versions of the work products, control the changes that
are imposed and audit and report on the changes that are made. And also will update the project’s web
page regularly.
Name E-mail Roles and Responsibilities
Project Manager, Software Engineer,
Configuration Manager, Programmer, DB
Administrator, Meeting Tracer, Test Team
Member, Training Coordinator.
Software Engineer, Programmer, DB
Administrator, Test Team Member, User
Interface Designer.
Software Engineer, Programmer, Test
Team Member, Configuration Manager,
Training Coordinator.
Software System Engineer, Software
Engineer, Programmer,
DB Administrator, Test
Team Member, Programmer, Configuration
Manager
Work Plan
Work Activities
Work activities of project are given in table 10. The milestone tasks are identified at the third column by
*Milestone mark.
WBS No: Task Name: Milestone

1. Project
1.1 Problem Analysis
1.1.1 Meeting with the Customer
1.1.2 Determining the Problems
1.2 Initial Plan
1.2.1 Studying about IEEE std 1058
1.2.2 Determining Cases for Initial Plan
1.2.3 Documenting Initial Plan
1.2.4 Discussion about issues of Initial Plan
1.2.5 Delivery of the first version of Initial Plan *Milestone
1.2.6 Feedback of Initial Plan
1.2.7 Delivery of updated Initial Plan *Milestone
1.3 Software Requirement Specification
1.3.2 Determining actors and use cases
1.3.3 Detailing use cases
1.3.4 Documenting SRS
1.3.5 Discussion about issues of SRS
1.3.6 Delivery of the first version of SRS *Milestone
1.3.7 Feedback of SRS
1.3.8 Delivery of updated SRS *Milestone
1.4 Software Project Management Plan
1.4.2 Determining Cases for SPMP
1.4.3 Documenting SPMP
1.4.4 Discussion about issues of SPMP
1.4.5 Delivery of the first version of SPMP *Milestone
1.4.6 Feedback of SPMP
1.4.7 Delivery of updated SPMP *Milestone
1.5 Software Design Description
1.5.2 Determining Design Entities
1.5.3 Determining Design Entity Attributes
1.5.4 Drawing Design Views
1.5.5 Documenting SDD
1.5.6 Discussion about issues of SDD
1.5.7 Delivery of the first version of SDD *Milestone
1.5.8 Feedback of SDD
1.5.9 Delivery of updated SDD *Milestone
1.6 Coding
1.6.1 Determining the Coding Standard
1.6.2 Coding of General Interfaces
1.6.3 Coding of Infrastructure of Project
1.6.4 Code Review of General Interfaces
1.6.5 Testing of Code side of Product
1.6.6 Meeting with Customer about the Product
1.6.7 Update and Delivery of Product *Milestone
1.7 User Manual
1.7.1 Determining Cases for UM
1.7.2 Documenting UM
1.7.3 Discussion about issues of UM
1.7.4 Delivery of the first version of UM *Milestone
Work packages for each activity are given below:
Activity Number 1.1.1

Activity Code M-Cstm.
Activity Name Meeting with the Customer
Estimated Duration/Effort 0.12 day/ 1.30 man-hour
Resources Needed Personnel: Team Members
Skill: Communication
Tool: Notebook
Travel: N/A
Outputs Borders of the Project
Baselines No
Predecessors
Successors 1.1.2
Completion Criteria Confirmation of the Customer
Implementation
Personnel Assigned Team Members
Starting Date 08 October 06
Completion Date 08 October 06
Cost (Budgeted and Actual) NA
Legacy Comments None
Resource Allocation
Group members have the general information about design techniques of .Net language. PCs will
be used for documentations of the reports that are IP, SRS, SPMP and SDD and coding. Table below
shows software tools to be used by project phase.
WBS WBS Item SOFTWARE RESOURCES

No
1.2 Initial Plan MS Word, MS Project, MS Visio, Photoshop
1.3 Software Requirement Specification MS Word, MS Visio
1.4 Software Project Management Plan MS Word, MS Project, MS Visio
1.5 Software Design Description MS Word, MS Visio, Photoshop
1.6 Coding MS Word, Visual Studio 2005 Professional Edition,
ASP .NET
1.7 User Manual MS Word
Risk Management
Risks Category Probability Impact

(%)
Uncertainty in the format of PS file Process definition 90 Moderate
Development tool unfamiliar Staff experience 70 High
Not enough time for SW integration Business impact 87 Moderate
Staff inexperienced Staff 72 High
Absentees of personnel could result in Staff 75 High
loss of effort
Design and coding deficiencies. Process definitions 70 High
Expected technical changes Development environment 40 Moderate
Documentation Process definition 30 Moderate
May have to train the trainer Staff 55 Low
Incorrect and missing Work package Process definition 45 High
definition
Optimistic schedule for HW/SW Business impact 25 Low
integration
Less reuse than planned Product size 25 Moderate
Customer may change requirement Product size 20 Critical
Misunderstood and/or undetermined Product size 20 Critical
requirements
Process demands not adequately Product size 15 High
planned in estimates
Inappropriate metrics Product size 18 Moderate
Risk Mitigation
PRIORITY Risk Scenarios Risk Alternatives / Resolutions Monitoring

Environment: not suitable Alternatives: Choose a work During the group
for team communication. environment that allows team meetings.
1 communication.
Resolution: Optimizing the
environment situation.
Group deficiency: One of Resolution: Other group Dead line is very close.
1 the members is sick. members are over work.
Communication skill is Alternatives: Group will make a Middle of the coding
4 not enough: In the code meeting with customers. phase.
phase, the new
requirements will be
come.
The development tool is Alternatives: If project member During the
hard to use. is not enough knowledge about implementation phase.
development tool, they will take a
related info from project training
2 coordinator.
Resolution: Before
implementation team will make
mini projects with development
tool.
Project Development and Document/Milestone Schedule
WP Who Will Prepare Start Due Days Dependency on Milestone Document

NO Date Date Task Name
W1 Initial Plan
W2 W1 Software
Requirement
Specification
Software Project
Management Plan
Software Design
Description
Coding
User Manual
Final Product
Project Schedule
• For TOGA
Roles and Responsibilities
Name E-mail Roles and Responsibilities

Hrishita Mavani hrishu10.hd@gmail.com Project Manager, Software Engineer,
Configuration Manager, Programmer, DB
Administrator, Meeting Tracer
Vaghela Yash yashvaghlea@gmail.com Programmer, DB Administrator, User
Interface Designer.
Rao Vishwa raovishwa@gmail.com Test Team Member, Configuration
Manager, Training Coordinator.
Work Plan
WBS No: Task Name: Milestone

1. Project 24-2-2020
1.1 Problem Analysis 23-2-2020
1.1.1 Meeting with the Customer 23-2-2020
1.1.2 Determining the Problems 24-2-2020
1.2 Initial Plan 28-2-20
1.2.1 Studying about IEEE std 1058 25-2-2020
1.2.2 Determining Cases for Initial Plan 25-2-2020
1.2.3 Documenting Initial Plan 25-2-2020
1.2.4 Discussion about issues of Initial Plan 26-2-2020
1.2.5 Delivery of the first version of Initial Plan 27-2-2020
1.2.6 Feedback of Initial Plan 28-2-2020
1.2.7 Delivery of updated Initial Plan 28-2-2020
1.3 Software Requirement Specification 6-3-2020
1.3.2 Determining actors and use cases 2-3-2020
1.3.3 Detailing use cases 2-3-2020
1.3.4 Documenting SRS 3-3-2020
1.3.5 Discussion about issues of SRS 3-3-2020
1.3.6 Delivery of the first version of SRS 4-3-2020
1.3.7 Feedback of SRS 5-3-2020
1.3.8 Delivery of updated SRS 6-3-2020
1.4 Software Project Management Plan 14-3-2020
1.4.2 Determining Cases for SPMP 7-3-2020
1.4.3 Documenting SPMP 9-3-2020
1.4.4 Discussion about issues of SPMP 11-3-2020
1.4.5 Delivery of the first version of SPMP 13-3-2020
1.4.6 Feedback of SPMP 14-3-2020
1.4.7 Delivery of updated SPMP 14-3-2020
1.5 Software Design Description 21-3-2020
1.5.2 Determining Design Entities 16-3-2020
1.5.3 Determining Design Entity Attributes 17-3-2020
1.5.4 Drawing Design Views 17-3-2020
1.5.5 Documenting SDD 18-3-2020
1.5.6 Discussion about issues of SDD 19-3-2020
1.5.7 Delivery of the first version of SDD 20-3-2020
1.5.8 Feedback of SDD 20-3-2020
1.5.9 Delivery of updated SDD 21-3-2020
1.6 Coding 19-4-2020
1.6.1 Determining the Coding Standard 22-3-2020
1.6.2 Coding of General Interfaces 22-3-2020
1.6.3 Coding of Infrastructure of Project 1-4-2020
1.6.4 Code Review of General Interfaces 12-4-2020
1.6.5 Testing of Code side of Product 14-4-2020
1.6.6 Meeting with Customer about the Product 17-4-2020
1.6.7 Update and Delivery of Product 19-4-2020
1.7 User Manual 25-4-2020
1.7.1 Determining Cases for UM 20-4-2020
1.7.2 Documenting UM 21-4-2020
1.7.3 Discussion about issues of UM 22-4-2020
1.7.4 Delivery of the first version of UM 25-4-2020
Work packages for each activity are given below:
Activity Number 1.2

Activity Code Init_plan_AC
Activity Name Initial Planning
Estimated Duration/Effort 0.90 day/ 1 man-hour
Resources Needed Personnel: Hrishita Mavani
Tool: MS Word
Travel: N/A

Baselines No
Predecessors NA
Successors 1.4
Implementation
Personnel Assigned Hrishita Mavani
Starting Date 23-2-20
Completion Date 6-3-20
Activity Number 1.3

Activity Code SRS_AC
Activity Name Software Requirement Specification
Resources Needed Personnel: Hrishita Mavani
Tool: MS Word
Travel: N/A

Baselines No
Predecessors 1.2
Successors 1.4
Implementation
Personnel Assigned Hrishita Mavani
Activity Number 1.5
Activity Code SO_design_AC
Activity Name Software design
Resources Needed Personnel: Yash Vaghela ,Hrishita mavani
Skill: designing, programming
Tool: Android studio, Adobe illustrator
Travel: N/A
Outputs Design framework

Baselines No
Predecessors 1.4
Successors 1.5
Implementation
Personnel Assigned Hrishita Mavani, Yash Vaghela
Activity Number 1.6

Activity Code Code_AC
Activity Name Coding
Resources Needed Personnel: Yash Vaghela
Skill: programming
Tool: Android studio IDE. Arduino IDE
Travel: N/A
Outputs Working project

Baselines No
Predecessors 1.5
Successors 1.4
Implementation
Personnel Assigned Yash Vaghela
Cost (Budgeted and Actual) 5,60,000
Activity Number 1.7
Activity Code Manual_AC
Activity Name Creating user manual
Resources Needed Personnel: Vishwa Rao
Tool: Ms Word
Travel: N/A
Outputs User guide

Baselines No
Predecessors 1.6
Successors NA
Implementation
Personnel Assigned Vishwa Rao
Resource Allocation
Group members have the general information about design techniques of .Net language. PCs will
be used for documentations of the reports that are IP, SRS, SPMP and SDD and coding. Table below
shows software tools to be used by project phase.
WBS WBS Item SOFTWARE RESOURCES

No
1.2 Initial Plan MS Word, MS Project, MS Visio, Photoshop

1.3 Software Requirement Specification MS Word, MS Visio
1.4 Software Project Management Plan MS Word, MS Project, MS Visio
1.5 Software Design Description MS Word, MS Visio, Photoshop, Adobe Illustrator
1.6 Coding MS Word, Android studio, Arduino IDE
1.7 User Manual MS Word
Risk Management
Risks Category Probability Impact

(%)
Uncertainty in the format of PS file Process definition 90 Moderate

Development tool unfamiliar Staff experience 70 High
Not enough time for SW integration Business impact 87 Moderate
Staff inexperienced Staff 72 High
Absentees of personnel could result in Staff 75 High
loss of effort
Design and coding deficiencies. Process definitions 70 High

Expected technical changes Development environment 40 Moderate
Documentation Process definition 30 Moderate
May have to train the trainer Staff 55 Low
Incorrect and missing Work package Process definition 45 High
definition
Optimistic schedule for HW/SW Business impact 25 Low

integration
Less reuse than planned Product size 25 Moderate

Customer may change requirement Product size 20 Critical
Misunderstood and/or undetermined Product size 20 Critical
requirements
Process demands not adequately Product size 15 High

planned in estimates
Inappropriate metrics Product size 18 Moderate
Risk Mitigation
PRIORITY Risk Scenarios Risk Alternatives / Resolutions Monitoring

Environment: not suitable Alternatives: Choose a work During the group
for team communication. environment that allows team meetings.
1 communication.
Resolution: Optimizing the
environment situation.
Group deficiency: One of Resolution: Other group members Dead line is very close.
1 the members is sick. are over work.
Communication skill is not Alternatives: Group will make a Middle of the coding
4 enough: In the code phase, meeting with customers. phase.
the new requirements will
be come.
The development tool is Alternatives: If project member is During the

hard to use. not enough knowledge about implementation phase.
development tool, they will take a
related info from project training
2 coordinator.
Resolution: Before
implementation team will make
mini projects with development
tool.
Project Development and Document/Milestone Schedule
WP Who Will Prepare Start Date Due Days Dependency on Milestone Document
NO Date Task Name
W1 Hrishita Mavani 23-2-20 28-2-20 5 Initial Plan

W2 Hrishita Mavani 29-2-20 6-3-20 7 W1 Software
Requirement
Specification
W3 Hrishita Mavani 7-3-20 14-3-20 8 W1,W2 Software Project
Management Plan
W4 Yash Vaghela 15-3-20 21-3-20 7 W2 Software Design
Description
W5 Yash Vaghela 22-3-20 10-4-20 20 W2,W4 Coding
W6 Vishwa Rao 11-4-20 19-4-20 8 W5 Testing
W7 Vishwa Rao 20-4-20 23-4-20 5 W2 User Manual
Project Schedule
Research
I Task Name Start Finish Duration February-March

23- 26-2 28- 3-3 5-3 7-3
2 2
1 Study Features 23-2-20 24-2-20 2d
2 Study technology 23-2-20 28-2-20 5d
3 Study Web 28-2-20 5-3-20 7d
Services
Research Chart
Documentation
23- 25-2 3-3 5-3 7-3
2
1 Requirement 24-2-20 25-2-20 2d
gathering
2 Software 26-2-20 29-2-20 4d
requirements
Documentation Chart
Analysis

1-3 2-3 3-3 5-3 9-3
1 Sort collected 1-3-20 2-3-20 2d

information
2 Feasibility study 3-3-20 6-3-20 3d
Analysis Chart
Designing

7-3 9-3 12-3 19-3 21-3
1 Create design 7-3-20 9-3-20 2d

form
2 Design user 9-3-20 17-3-20 8d
interface
3 Review and 17-3-20 21-3-20 4d
redefine design
Designing chart
All phase chart

23- 29-2 3-3 7-3 14-3 21-3
2
1 Research 23-2-20 29-2-20 6d
2 Documentation 24-2-20 29-2-20 5d
3 Analysis 1-3-20 6-3-20 5d
4 Design 7-3-20 21-3 14d
Practical 8: Software Project Cost Estimation
AIM: Calculate the Various Costs using CoCoMo, Function Point ,Algorithmic Cost Modeling Methods
Estimation Plan
The cost and schedule for conducting the project (PS) as well as the methods, tools, techniques,
used to estimate project cost, schedule, resource requirements, external input and output data associated
confidence levels are presented below.
Function Point method is used for size estimation of the project. The functions of the project are
identified according to the user requirements defined during the initial meetings. These functions are:
External inputs:
• New Patient Information Add
• New Patient Information Delete
• New Patient Information Update
• Patient Disease Identification and Therapy Information Add
• Patient Disease Identification and Therapy Information Delete
• Patient Disease Identification and Therapy Information Update
• Drug Information Add
• Drug Information Delete
• Drug Information Update
• Drug Stock Input-Output Information Add
• Drug Stock Input-Output Information Delete
• Drug Stock Input-Output Information Update
• Disease Information IC P-10 Add
• Disease Information ICP-10 Delete
• Disease Information ICP-10 Update
External Output:
• Patient Registration
• Drug Registration
• Stock Registration
• Warning Message
External Enquiry:
• Access to Patient Records
• Access drugs which are given to patient before
• Access to Drugs Records
• Access to stock records
• Access number of decreasing drugs records
• Access to drug names and codes records
External Interface Files:

• Wireless network interface
Internal Logical File:
• Doctor Table
• Patient Table
• Drug Table
• Disease Names Table
• Disease Groups Table
Function Levels
Components Count Low Average High Total
External Inputs 16 9x3 6x4 1x6 54
External Outputs 4 2x4 2x5 0x7 18
External Inquiries 6 4x3 2x4 1x6 26
Internal Logical Files 5 5x 7 0 x 10 0 x 15 35
External Interface Files 1 0x5 0x7 1 x 10 10
Total Unadjusted FP (UFP): 143
Table 1 Unadjusted Function Point Table
In Table 1, the Degree of Influences (DI) is shown:

Characteristic Degree of Description
Influence (DI)
1. Data Communication 2 Output Data Entry is required
2. Distributed data processing 4 Online and in both directions
3. Performance 3 Response time is critical
4. Heavily used configuration 2 Security and timing issues
5. Transaction rate 4 Service level agreements are high level
6. Online data entry 5 More than %90 is online data entry
7. End user efficiency 3 Six of more of the elements
8. Online update 5 Data lost is essential
9. Complex processing 3 Three of the elements
10. Reusability 4 Modulated coding
11. Installation ease 1 Only server-side installation
12. Operational ease 1 Minimizes the need of paper handling
13. Multiple sites 1 Identical hardware and software
14. Facilitate change 3 Three of the elements
Total Degree of Influence (TDI): 41
Table 2 Degree of Influences
The scale of criteria weights for the table 1 (TDI):

0 1 2 3 4 5
No influence Incidental Moderate Average Significant Essential
The table shown above lists the replies of the system to the specific questions depending on the
IFPUG documents.
Three Formulas for Size Estimation of the FIS;

▪ Total Degree of Influence (TDI) = Sum of the Influence Factors
▪ Value Adjustment Factor (VAF) =0.65 + (0.01 * TDI)
▪ Function Points (FP) = VAF * unadjusted FP
Value Adjustment Factor (VAF) = (TDI x 0.01) + 0.65 = (41 x 0.01) + 0.65 = 1.06
Adjusted Function Point Count (FP) = UFP x VAF = 1.06 x 143 = 151.58
The number of lines of code is then defined by:

Line of Code = (SLOC per FP for Java) x FP = 30 x 151.58 = 4547.4
Effort Estimation
An LOC-oriented estimation model is used for effort estimation. The number of lines of code is then
defined by:
LOC = FPx Language Factor (Language Factor vary by Language of Programming)
KLOC = 4.547 (4547.4 LOC)
Then the effort is:
Effort (Coding) = a x Size b
Development Time (T) =c*(Effort)^d
a and b are constants that depend on the project, and size is measured in thousands of lines of
code (KLOC).
Software Project a b c D
Organic 3.2 1.05 2.5 0.38
Semi-detached 3 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
Because of the decision, that the software project has an “organic” structure.
a = 3.2 is determined for Organic Project

b = 1.05 is determined for Organic Project
c = 2.5 is determined for Organic Project
d = 0.38 is determined for Organic Project
E = 3.2 x 4.547 1.05= 3.2 x 4.90 = 15.68 (man month)
COCOMO model is used to calculate the schedule estimation for the PS. COCOMO model calculates
effort in man months.
COCOMODevelopment Time (T) =c*(Effort Applied)^d = 2.5 * ( 15.68) ^ 0.38 ≈ 7.11 Months
“c ” and 'd' depends on the modes of the difficulty so that d is decided as 0.38 as it is for the other organic
software projects. COCOMO model calculates effort in staff months (19 days per month or 152 working
hours per month).
Therefore such a software project needs:

Staff = Effort / Duration = 15.68 / 7.1 = 2.20 persons
Cost Estimation
The salary of each group member is 40000Rs./p.m @152 Hr p.m, therefore the estimated cost of
the Project is:
15.68 man month = 15.68 x 152 (hours in a month) = 2383.36 man hours
Cost = Effort x $ (the hourly salary)
C = 2383.36 man-hours x (40000/152)man-hours=6,27,200Rs.
• For TOGA
External inputs:
• New User Information Add
• User Information Delete
• User Information Update
• Update gas Readings
• Update Temperature
• Update user profile
• Update user location
External Output:
• User Registration
• Temperature Readings
• Gas Readings
External Enquiry:
• Access to User Records
• Access to gas Readings
• Access to user location
• Access to gas level range
• Access to temperature Readings
External Interface Files:

• Wireless network interface
• Bluetooth interface
Internal Logical File:

• User Table
• GasLevels Table
• Temperature Table
• SaveReadings Table
• Category Table
Function Levels
Components Count Low Average High Total
External Inputs 7 4x 3 3x4 0x6 24
External Outputs 3 1x4 2x5 0x7 14
External Inquiries 5 3x 3 2x4 0x6 9
Internal Logical Files 5 5x 7 0 x 10 0 x 15 35
External Interface Files 2 0x5 1x7 1 x 10 17
Total Unadjusted FP (UFP): 99
Table 1 Unadjusted Function Point Table
In Table 1, the Degree of Influences (DI) is shown:
Characteristic Degree of Description
Influence (DI)
1. Data Communication 3 Output Data Entry is required
2. Distributed data processing 2 Online and in both directions
3. Performance 3 Response time is critical
4. Heavily used configuration 1 Security and timing issues
5. Transaction rate 3 Service level agreements are high level
6. Online data entry 4 More than %90 is online data entry
7. End user efficiency 4 Six of more of the elements
8. Online update 5 Data lost is essential
9. Complex processing 3 Three of the elements
10. Reusability 4 Modulated coding
11. Installation ease 3 Only server-side installation
12. Operational ease 4 Minimizes the need of paper handling
13. Multiple sites 3 Identical hardware and software
14. Facilitate change 4 Three of the elements
Total Degree of Influence (TDI): 46
Table 2 Degree of Influences
The scale of criteria weights for the table 1 (TDI):

0 1 2 3 4 5
No influence Incidental Moderate Average Significant Essential
The table shown above lists the replies of the system to the specific questions depending on the
IFPUG documents.
Three Formulas for Size Estimation of the FIS;

▪ Total Degree of Influence (TDI) = Sum of the Influence Factors
▪ Value Adjustment Factor (VAF) =0.65 + (0.01 * TDI)
▪ Function Points (FP) = VAF * unadjusted FP
Value Adjustment Factor (VAF) = (TDI x 0.01) + 0.65 = (46 x 0.01) + 0.65 = 1.11
Adjusted Function Point Count (FP) = UFP x VAF = 1.11 x 99 = 109.89
The number of lines of code is then defined by:

Line of Code = (SLOC per FP for Java) x FP = 35 x 109.89= 3846.15
Effort Estimation
An LOC-oriented estimation model is used for effort estimation. The number of lines of code is then
defined by:
LOC = FPx Language Factor (Language Factor vary by Language of Programming)
KLOC = 3.846(3846.15LOC)
Then the effort is:
Effort (Coding) = a x Size b
Development Time (T) =c*(Effort)^d
a and b are constants that depend on the project, and size is measured in thousands of lines of
code (KLOC).
Software Project a b c D
Organic 3.2 1.05 2.5 0.38
Semi-detached 3 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
Because of the decision, that the software project has an “organic” structure.
a = 3.2 is determined for Organic Project

b = 1.05 is determined for Organic Project
c = 2.5 is determined for Organic Project
d = 0.38 is determined for Organic Project
E = 3.2 x 3.846.99= 3.2 x 4.90 = 12.14 (man month)
COCOMO model is used to calculate the schedule estimation for the PS. COCOMO model calculates
effort in man months.
COCOMODevelopment Time (T) =c*(Effort Applied)^d = 2.5 * ( 12.14) ^ 0.38 ≈ 6.4 Months
“c ” and 'd' depends on the modes of the difficulty so that d is decided as 0.38 as it is for the other organic
software projects. COCOMO model calculates effort in staff months (19 days per month or 152 working
hours per month).
Therefore such a software project needs:

Staff = Effort / Duration = 12.14 / 6.4 = 1.89 persons
Cost Estimation
The salary of each group member is 40000Rs./p.m @99 Hr p.m, therefore the estimated cost of
the Project is:
12.14 man month = 12.14 x 99 (hours in a month) = 1201.86 man hours

Cost = Effort x $ (the hourly salary)
C = 1201.86 man-hours x (40000/99)man-hours=4,85,252Rs.
Practical 9: Software Testing: Project Test Plan Document
AIM: Design Test Cases and Scenarios for Testing Software as a parts and as a whole
Prepare Software Project Test Plan Document for the Project
1. Test Cases need to be simple and transparent:

Create test cases that are as simple as possible. They must be clear and concise as the author of the test
case may not execute them. Use assertive language like go to the home page, enter data, click on this and
so on. This makes the understanding the test steps easy and tests execution faster.
2. Create Test Case with End User in Mind
The ultimate goal of any software project is to create test cases that meet customer requirements and is
easy to use and operate. A tester must create test cases keeping in mind the end user perspective
3. Avoid test case repetition.
Do not repeat test cases. If a test case is needed for executing some other test case, call the test case by its
test case id in the pre-condition column
4. Do not Assume
Do not assume functionality and features of your software application while preparing test case. Stick to
the Specification Documents.
5. Ensure 100% Coverage
Make sure you write test cases to check all software requirements mentioned in the specification
document. Use Traceability Matrix to ensure no functions/conditions is left untested.
6. Test Cases must be identifiable.
Name the test case id such that they are identified easily while tracking defects or identifying a software
requirement at a later stage.
7. Implement Testing Techniques
It's not possible to check every possible condition in your software application. Software Testing
techniques help you select a few test cases with the maximum possibility of finding a defect.
• Boundary Value Analysis (BVA): As the name suggests it's the technique that defines the
testing of boundaries for a specified range of values.
• Equivalence Partition (EP): This technique partitions the range into equal parts/groups that tend
to have the same behavior.
• State Transition Technique: This method is used when software behavior changes from one
state to another following particular action.
• Error Guessing Technique: This is guessing/anticipating the error that may arise while doing
manual testing. This is not a formal method and takes advantages of a tester's experience with the
application
8. Self-cleaning
The test case you create must return the Test Environment to the pre-test state and should not render the
test environment unusable. This is especially true for configuration testing.
9. Repeatable and self-standing
The test case should generate the same results every time no matter who tests it
10. Peer Review.
After creating test cases, get them reviewed by your colleagues. Your peers can uncover defects in your
test case design, which you may easily miss.
Popular Test Management tools are: Quality Center and JIRA
TestCaseID Test Scenario: Check User Register with valid Data Pass/Fail
T1 Test Steps:
Pass
1. Go to registration screen
2. Enter Details
3. Click Submit
Test Data: Name = Hrishita Mavani , Email= hrishu10.hd@gmail.com,
Mobile_no = 8306790082, password= hrishi123
Expected Results: User should Register into application

Actual Results: As Expected
T2 Test Scenario: Check User Login with valid Data Pass
Test Steps:
1. Go to Login screen
2. Enter Email-id
3. Enter Password
4. Click Submit
Test Data: Email = demo Password = 1234
Expected Results: User should Login into an application
Actual Results: As Expected
T3 Test Scenario: Testing MQ135 SENSOR for CO2 pass
Test Steps:
1. lighter was used to produce the flame and heat while the piece of paper was
ignited and put out to produce smoke.
2.
Test Data: 2,000 to 5,000 ppm
Expected Result: Send user alert and ring alarm
Actual Result: Send user alert and ring alarm
T4 Test Scenario: Testing MQ7 SENSOR for CO Pass
Test Steps:
Entry of Direct test data
1. Methane Exposure was not carried out because of the risks involved
(Unwanted ignition).
Test Data: 800 ppm
T5 Test Scenario: Testing MQ138 SENSOR for Benzene Pass
Test Steps:
1. Benzene Exposure was not carried out because of the risks involved
Test Data: 10 ppm
T6 Test Scenario: Testing MQ2 SENSOR for METHANE Pass
Test Steps:
2. Methane Exposure was not carried out because of the risks involved
Test Data: 50,000 ppm
T7 Test Scenario: Testing MQ2 SENSOR for Hydrogen Sulphide Pass
Test Steps:
Hydrogen Sulphide Exposure was not carried out because of the risks
involved .
Test Data: 100 ppm
T8 Test Scenario: Testing MQ136 SENSOR for Sulphur dioxide Pass
Test Steps:
Sulphur dioxide Exposure was not carried out because of the risks involved
Test Data: 0.03 ppm
Expected Results: User should choose level of subject for exam
T9 Test Scenario: Test Data updating in less internet Fail
Test Steps:
Connect with weak network
Open gas reading screen
Test Data:
Expected Result: Gas Reading should update
Actual Result: Gas reading fails to update
T10 Test Scenario: Save gas readings with location Pass
Test Steps:
3. Turn off GPS
4. Go to application
5. Save current readings
Test Data: readings
Expected Result: send message to turn on location service
Actual Result: send message to turn on location service and data will not be
saved
T11 Test Scenario: Save Temperature readings with location Pass
Test Steps:
6. Turn off GPS
7. Go to application
Save current readings
Test Data: readings
Expected Result: send message to turn on location service
Actual Result: send message to turn on location service and data will not be
saved
T12 Test Scenario: Call Emergency number when power button is triple clicked Pass
only if gas level is high
Test Steps:
Entry of high levels of gases to database
Triple click power button
Test Data: high gas level i.e. 100ppm of benzene
Expected Result: call emergency number
Actual Result: call emergency number
T13 Test Scenario: Call to Emergency number should not connect and send Pass
warning message when power button is triple clicked but gas levels are low
Test Steps:
Entry of low levels of gases to database
Triple click power button
Test Data: low gas level i.e. 0ppm of benzene
Expected Result: send warning message
Actual Result: send warning message
T14 Test Scenario: Testing Against Known False Alarm Triggers. Pass
Test Steps:
The main triggers of false alarms in smoke and thermal based fire
detectors.
Test Data: Humidity (Tested at 70% Humidity, Cigarette, Steam
Expected Result: No false alarm
Actual Result: No false alarm
T15 Test Scenario: Send location information on calling emergency number Pass
without internet or low internet
Test Steps:
8. Turn off internet
Increase gas levels
9. Call emergency number
Test Data: cache location
Expected Result: cached location must be sent
Actual Result: cached location is be sent
Practical 10: Case study on CASE Tools for Software Processes
AIM: Case study on CASE Tools for Software Processes
Project group hase to prepare case study of one of the CASE Tool
Central Repository - CASE tools require a central repository, which can serve as a source of common,
integrated and consistent information. Central repository is a central place of storage where product
specifications, requirement documents, related reports and diagrams, other useful information regarding
management is stored. Central repository also serves as data
dictionary.
Upper Case Tools - Upper CASE tools are used in Planning,
Analysis and Design stages of SDLC.
Lower Case Tools - Lower CASE tools are used in
Implementation, Testing and Maintenance.
Integrated Case Tools - Integrated CASE tools are helpful in
all the stages of SDLC, from Requirement Gathering to
Testing and Documentation.
CASE tools can be grouped together if they have similar
functionality, process activities and capability of getting
integrated with other tools.
Scope of Case Tools: The scope of CASE tools goes
throughout the SDLC.
Case Tools Types
A. Diagram tools
These tools are used to represent system components, data and control flow among various software
components and system structure in a graphical form. For example, Flow Chart Maker tool for creating
state-of-the-art flowcharts.
B. Process Modeling Tools

Process modeling is method to create software process model, which is used to develop the software.
Process modeling tools help the managers to choose a process model or modify it as per the requirement
of software product. For example, EPF Composer
C. Project Management Tools

These tools are used for project planning, cost and effort estimation, project scheduling and resource
planning. Managers have to strictly comply project execution with every mentioned step in software
project management. Project management tools help in storing and sharing project information in real-
time throughout the organization. For example, Creative Pro Office, Trac Project, Basecamp.
D. Documentation Tools
Documentation in a software project starts prior to the software process, goes throughout all phases of
SDLC and after the completion of the project. Documentation tools generate documents for technical
users and end users. Technical users are mostly in-house professionals of the development team who
refer to system manual, reference manual, training manual, installation manuals etc. The end user
documents describe the functioning and how-to of the system such as user manual. For example,
Doxygen, DrExplain, Adobe RoboHelp for documentation.
E. Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency, inaccuracy in the
diagrams, data redundancies or erroneous omissions. For example, Accept 360, Accompa,
CaseComplete for requirement analysis, Visible Analyst for total analysis.
F. Design Tools
These tools help software designers to design the block structure of the software, which may further be
broken down in smaller modules using refinement techniques. These tools provides detailing of each
module and interconnections among modules. For example, Animated Software Design
G. Configuration Management Tools

An instance of software is released under one version. Configuration Management tools deal with –
Version and revision management, Baseline configuration management,Change control
management. CASE tools help in this by automatic tracking, version management and release
management. For example, Fossil, Git, Accu REV.
H. Change Control Tools

These tools are considered as a part of configuration management tools. They deal with changes made to
the software after its baseline is fixed or when the software is first released. CASE tools automate
change tracking, file management, code management and more. It also helps in enforcing change policy
of the organization.
I. Programming Tools
These tools consist of programming environments like IDE (Integrated Development Environment), in-
built modules library and simulation tools. These tools provide comprehensive aid in building software
product and include features for simulation and testing. For example, Cscope to search code in C,
Eclipse.
J. Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype provides initial look
and feel of the product and simulates few aspect of actual product.Prototyping CASE tools essentially
come with graphical libraries. They can create hardware independent user interfaces and design. These
tools help us to build rapid prototypes based on existing information. In addition, they provide
simulation of software prototype. For example, Serena prototype composer, Mockup Builder.
K. Web Development Tools

These tools assist in designing web pages with all allied elements like forms, text, script, graphic and so
on. Web tools also provide live preview of what is being developed and how will it look after
completion. For example, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.
L. Quality Assurance Tools

Quality assurance in a software organization is monitoring the engineering process and methods adopted
to develop the software product in order to ensure conformance of quality as per organization standards.
QA tools consist of configuration and change control tools and software testing tools. For example,
SoapTest, AppsWatch, JMeter.
M. Maintenance Tools
Software maintenance includes modifications in the software product after it is delivered. Automatic
logging and error reporting techniques, automatic error ticket generation and root cause Analysis are few
CASE tools, which help software organization in maintenance phase of SDLC. For example, Bugzilla
for defect tracking, HP Quality Center.
• Case study on Programming Tool –
• Arduino IDE
The Arduino Software (IDE) allows you to write programs and upload them to your board. In
the Arduino Software page you will find two options:
1. The online version of ide works with reliable internet connection. No need to update the IDE.
Always latest IDE version will be used by default. No installation is required in this case. Go to
And follow the below given steps.
2. If you would rather work offline, you should use the latest version of the desktop IDE. Arduino
IDE Can be Accessed using this link https://www.arduino.cc/en/main/software.
Click on download
Once the download is completed run the setup file to install IDE on computer.
• Launch the IDE.
• The Default Empty Sketch Will open when IDE is launched. In this empty sketch write
the code.
• Once the code is Written Upload code using following steps.
Upload the Code

using this button
Select the Port on which

Arduino is attached
• Android Studio IDE
About Android studio:
Android Studio is the official integrated development environment (IDE)

for Google's Android operating system, built on JetBrains' IntelliJ IDEA software and designed
specifically for Android development. It is available for download
on Windows, macOS and Linux based operating systems. It is a replacement for the Eclipse
Android Development Tools (ADT) as the primary IDE for native Android application
development.
Why to use:
On top of IntelliJ's powerful code editor and developer tools, Android Studio offers even more
features that enhance your productivity when building Android apps, such as:
• A flexible Gradle-based build system

• A fast and feature-rich emulator
• A unified environment where you can develop for all Android devices
• Apply Changes to push code and resource changes to your running app without restarting your app
• Code templates and GitHub integration to help you build common app features and import sample
code
• Extensive testing tools and frameworks
• Lint tools to catch performance, usability, version compatibility, and other problems
• C++ and NDK support
• Built-in support for Google Cloud Platform, making it easy to integrate Google Cloud Messaging
and App Engine.
Working with Android Studio
Run the Android Studio, startup page will be loaded as shown
Click on start
new project
Select from various activities
Configure project
Once configured the Application will be loaded
Menu Bar
Tool Bar
Manifest File
Java Files
Resource Files
Project
Structure
Code Editor
Log messages
When you build and run your app with Android Studio, you can view adb output and device log
messages in the Logcat window.

Practical 11: Software Engineering Case Study Review.
AIM: Review of Website/ Desktop Application from Software Engineering Perspectives.
Name of Mobile Application: TOGA- Toxic Gas Analyzer
Segment : Industry
Major Functionalities:
• Toxic gas detection

• Alert workers about high gas levels
• Emergency call by Power button click
Ease of User Interface: UI is easy to use and novice user can easily navigate in app
No of Users(Approx.) :150-200
Targeted Users with Types :Novice workers of factory with very less experience can use application
Input: Data
Output: Statistics and Report
No of Screens/Pages/Cards(Approx.) :7 screens
Media Upload/Download: NA
Money Payment Interface(If Any): NA.
Query/ Feedback/Complaint Resolution: Quick response is given through email
FAQs Sections:
• How gases are detected

• How do I know if I need alarm
• How emergency call is made
• Causalities that can cause by increased gas levels
User Manual (If Any): Hardware (Arduino module) comes with user manual
User Guidance (if any): There is GUI based user guide in app
Type: Online/ Offline/ Mixed Mode: Online
Update Mode: Online
Critical Point of Failures: (When application is consider as failure ): App will need constant internet
connection.
Security Features: OTP based login makes app secure.

Alternatives/Similar Application (if Any): gas leak smell gas detector
Advantages over Competing Application: gas detection is not accurate.

6SE B SEGP48 Manual VER1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

6SE B SEGP48 Manual VER1

Uploaded by

Copyright:

Available Formats

L D College of Engineering, Ahmedabad

Department of Information Technology

GTU B.E. 6th Semester

GTU B.E. 6th Semester Subject: 2160701- Software Engineering

2 Software Engineering Project :SRS Document

3 Structured Software Engineering

Object Oriented Software Engineering: Structural UML

6 User Interface Design Software Design Document

Software Project Management :Activity Scheduling

8 Software Project Cost Estimation

9 Software Testing: Project Test Plan Document

10 Case study on CASE Tools for Software Processes

11 Software Engineering Case Study Review.

The sequential phases in Waterfall model are −

E. Characteristics of Software Project

• Requirements are very well documented, clear and fixed.

F. Characteristics of Software Project Team with Size

I. Scope and Cost of Change Request Management:

The sequential phases in Waterfall model are −

D. Type of Software where it is applicable:

E. Characteristics of Software Project:

• Requirements of the complete system are clearly defined and understood.

F. Characteristics of Software Project Team with Size

G. Risk Associated with Project:

• More resources may be required.

I. Scope and Cost of Change Request Management:

Evaluation and Risk Analysis

D. Type of Software where it is applicable

E. Characteristics of Software Project

• When there is a budget constraint and risk evaluation is important.

F. Characteristics of Software Project Team with Size

• Risk analysis is important phase so requires expert people.

G. Risk Associated with Project:

• Management is more complex.

• User is not able to propose requirements properly.

I. Scope and Cost of Change Request Management

E. Characteristics of Software Project

F. Characteristics of Software Project Team with Size

G. Risk Associated with Project:

I. Scope and Cost of Change Request Management

D. Type of Software where it is applicable

• Small to medium-sized software developments.

E. Characteristics of Software Project

• Web based application can be developed using scrum model.

F. Characteristics of Software Project Team with Size

G. Risk Associated with Project:

• Not suitable for handling complex dependencies.

• More risk of sustainability, maintainability and extensibility.

I. Scope and Cost of Change Request Management

The different Validation Phases in a V-Model are explained in detail below.

• Integration Testing:Integration testing is associated with the architectural design phase.

• Acceptance Testing:Acceptance testing is associated with the business requirement analysis

E. Characteristics of Software Project

• Requirements are well defined, clearly documented and fixed.

F. Characteristics of Software Project Team with Size

G. Risk Associated with Project:

I. Scope and Cost of Change Request Management

1. Prepare List of Requirements with Classification of Requirement (Feasibility, Functional /Non

Project Title: Toxic Gas Analyzer (TOGA)

• Project leader and project manager

• Hardware module to detect gas leakage

Expected Delivery Time(Months): 2 months

• User can login to the system