Scribd
Upload
108 views3 pages

Software Development Life Cycle: Design Phase: What Changes To - How!

The design phase transforms business requirements into a detailed system architecture. Key activities include designing system components, interfaces, and databases. Artifacts created include a system design document describing the architecture, and additional documents like data dictionaries, process diagrams, and manuals. The design is reviewed and approved by stakeholders before work begins on implementation.

Uploaded by

Nameless
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
108 views3 pages

Software Development Life Cycle: Design Phase: What Changes To - How!

The design phase transforms business requirements into a detailed system architecture. Key activities include designing system components, interfaces, and databases. Artifacts created include a system design document describing the architecture, and additional documents like data dictionaries, process diagrams, and manuals. The design is reviewed and approved by stakeholders before work begins on implementation.

Uploaded by

Nameless
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Software Development Life Cycle : Design

Phase

January 31, 2017

What changes to ———> How!


Objective:
The objective of this phase is to transform business requirements identified
during previous phases, into a detailed system architecture which is feasible,
robust and brings value to the organization
—————————————————————————————————

Entry Criteria:
The Design step of the SDLC process can begin when the Customer has
approved (signed-off) the Functional Requirements Document.
—————————————————————————————————

Roles And Responsibilities:


Customer :
sponsor project and signs off team effort; review strategy and artifacts.
Business Analyst :
Provide requirements to the design team; review solution design and arti-
facts.
Project Manager :
Finalize data conversion strategy and test strategy;review solution design
and artifacts.
Technical-Architect, Tech-Designer, Design-Team :
Design system architecture, software components, etc; Design walk-through.
Developer/Construction Team :
Assist in finalizing data conversion strategy; review of the architecture and
software components.
Testing Team/Tester :
Assist with identifying and finalizing testing strategy; review of the architec-
ture and software components.
Database Team :
Assist with architecture design and data conversion strategy. The most im-
portant role in this step is that of the Technical Architect as she aims to describe

1
the required functions and operations such as screen layout, business rules,
database layouts for the system in detail and also provide the architectural
plan down to the physical level. ————————————————————
—————————————
Artifacts:
System Design Document (includes System architecture): A system archi-
tecture is the structure of the components of a program or system, their in-
terrelationships and the principles and guidelines governing their design and
evolution over time. The system design provides overall guidance on system
functions, performance requirements, security requirements, platform charac-
teristics and should comprise:
1.Business rules/application logic
2.Interface design (app-to-app, app-to-db)
3.User interfaces (GUI)
4.Database design (data storage and db access)
Some additional artifacts produced due to activities in this phase include :
1.Data Dictionary
2.Process diagrams
3.Screen layout diagrams
4.tables of business rules
5.prototype/Proof-of-Concept

Training Plan :
Training plans are meant to identify the users and how they will be trained
on the new solution. Generally required for large projects.
Maintenance Manual :
The maintenance manual is a document containing system procedures re-
quired to install, configure and support the system. It is created during design
phase and is revised during construction and test phases and finalized in the
implementation phase.
User/operator Manual :
A document that presents the information necessary to employ a system or
component to obtain desired results.
—————————————————————————————————

Review:
Reviewed by the stakeholders other than one who prepares the document
e.g. SDD is prepared by Technical architect and reviewed by all stakeholders
(including those who inherit the plan) such as customer, PM, business analyst,
developer, and tester. Revision may follow.
—————————————————————————————————

Approval:
Approval/sign-off required by customer, developer, tester and business an-
alyst (all stakeholders including inheritors). Once approved the focus shifts to
the next process step.

2
—————————————————————————————————

Exit Criteria:
1.Technical specifications (system design document) is completed and re-
viewed.
2. The artifacts in the Master Test Plan associated with the Design step, are
completed, reviewed and placed in the baseline.
3.Work on the following documents has begun and is in progress.
3.1 Maintenance manual
3.2 Training plan
3.3 Training manual
3.4 User manual
—————————————————————————————————

Comparison between Generic and Custom Software.


Generic Software:
1.Since open source offers flexibility in terms of changes the design need
to be adjustable so that new features can accomodate.
2. The designing is made on the basis of SRS formed earlier, it is ought to
be utmost correct. As generic software provides many services to users, the
design can turn out to be complex.
3. The reason for complex design can be the need to reduce the resources
so one resources can be used by any no. of services and thus connection
between resources and services can cross. Thus making the overall design
outline more complex than custom software.

Custom Software:
1.Comparatively less flexible design as the changes are generally minor.
2.Designing custom software is easy as the information is well defined by
the customer, it makes it easy to process design of software.
3. All the correlations between resources are well established in SRS
formed, and can be designed efficiently using the the diagram that is required
for representing it. As SRS if inspected by the customer, there is very less
chance of making wrong design outline of software.

References:
1. http://sdlc.uconn.edu
2. http://oer.nios.ac.in
3. http://www.coredna.com
4. https://www.itgct.com
5. https://en.wikipedia.org
6. http://stackoverflow.com/

You might also like