Assignments-

ASSIGNMENT 1 :

1. Write a short note on SRS.

Answer: SRS (Software Requirements Specification) is a comprehensive

document that outlines the functional and non-functional requirements of a
software system. It serves as a contract between the stakeholders (clients, end-
users) and the development team, ensuring that everyone has a clear
understanding of what the system is supposed to achieve.

Key components of an SRS include:

1. Functional Requirements: Describes what the system should do, such as

features, interactions, and workflows.

2. Non-Functional Requirements: Specifies performance, security, scalability, and

usability constraints.

3. Use Cases: Scenarios outlining how users will interact with the system.

4. System Interfaces: Details about interactions with external systems or

components.

An SRS helps to prevent scope creep, reduces misunderstandings, and serves as a

reference throughout the development lifecycle.

2. Explain Spiral Model in brief with suitable diagram.

Answer: It provides the potential for rapid development.

 Software is developed in a series of evolutionary releases.

 Early iteration release might be prototype but later iterations provides more
complete version of software.

 It is divided into framework activities (C, P, M, C.D). Each activity represents one
segment of the spiral.
  Each pass through the planning region results in adjustments to

 The project plan

 Cost and schedule based on feedback

 Advantages :

 High amount of risk analysis. Hence, avoidance of Risk is enhanced.

 Strong approval and documentation control.

 Additional functionality can be added at a later date.

 Software is produced early in the Software Life Cycle.

 Disadvantages :
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

3. What is Process? Discuss the process framework activities.

Answer: A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.

 An activity strives to achieve a broad objective (e.g., communication with stakeholders /

partners) and is applied regardless of the application domain, size of the project,
complexity of the effort.
 An action (e.g., architectural design) encompasses a set of tasks that produce a major
work product (e.g., an architectural design model).
 A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.

A typical software process framework includes five core activities:

1. Communication: Engaging with stakeholders to gather requirements and set project

objectives through discussions and analysis.

2. Planning: Defining project schedules, resources, costs, risks, and tasks, creating a
roadmap for the development process.
3. Modeling: Designing system architecture and components, focusing on both
functionality and structure.

4. Construction:

o Coding: Converting designs into executable code.

o Testing: Ensuring the code meets requirements through various testing levels.

5. Deployment: Delivering the software to users and setting up environments, followed by

maintenance if needed.

4. Explain Waterfall Model with suitable diagram?

Answer: When requirement of a problems are well understood then this model is
used in which work flow from communication to deployment is linear.

 This model is used when,

 Requirements are very well known, clear and fixed.

 Product definition is stable.

 Technology is understood.

 There are no ambiguous ( unclear) requirements.

 Ample (sufficient) resources with required expertise are available freely.

 The project is short.

 Advantages :

 Simple to implement and manage.

 Drawbacks :

 Unable to accommodate changes at later stages, that is required in most of

the cases.

 Working version is not available during development, which can lead the
development with major mistakes.
  Deadlock can occur due to delay in any step.

 Not suitable for large projects.

Communication
project initiation Planning
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback

5. Explain Software myths.

Answer: Software myths are misconceptions or false beliefs that many

stakeholders (clients, managers, developers) hold about software
development. These myths can lead to unrealistic expectations, poor project
planning, and inefficiencies in the development process. Myths are typically
categorized based on the stakeholder involved.

Common Software Myths:

1. Management Myths:

o Myth: "We can add more people to the project to meet the deadline."

 Reality: Adding more people to a project late in development can

slow it down due to the overhead of training and communication, as
highlighted in Brooks’ Law.

o Myth: "A detailed, complete specification can be written in the beginning."

 Reality: Requirements often evolve as the project progresses,

making it difficult to lock down everything at the start.

2. Customer Myths:

o Myth: "Once the software is developed, the job is done."

  Reality: Software requires ongoing maintenance, updates, and
modifications due to changing needs or bugs discovered after
deployment.

o Myth: "All I need to do is state what I want; developers will handle the
rest."

 Reality: Customers need to be actively involved throughout the

development cycle to ensure the product meets their expectations.

3. Developer Myths:

o Myth: "The project is going smoothly as long as code is being written."

 Reality: Progress depends on proper design, planning, and testing.

Writing code without a clear direction often leads to delays and
rework.

o Myth: "Once the program works, it's done."

 Reality: Functional software still needs rigorous testing,

optimization, and maintenance to ensure long-term stability and
scalability.

Impact of Software Myths:

Believing in these myths can lead to unrealistic timelines, poor-quality software, and
miscommunication among stakeholders. Overcoming them requires educating teams
and clients about the realities of software development and fostering better
collaboration and communication.