Unit-1

Systems Engineering is a transdisciplinary and integrative approach to enable the successful

realization, use, and retirement of engineered systems, using systems principles and
concepts, and scientific, technological, and management methods.

We use the terms “engineering” and “engineered” in their widest sense: “the action of working
artfully to bring something about”. “Engineered systems” may be composed of any or all of
people, products, services, information, processes, and natural elements.

Systems Engineering focuses on:

 establishing, balancing and integrating stakeholders’ goals, purpose and success criteria,
and defining actual or anticipated customer needs, operational concept and required
functionality, starting early in the development cycle;
 establishing an appropriate lifecycle model, process approach and governance structures,
considering the levels of complexity, uncertainty, change, and variety;
 generating and evaluating alternative solution concepts and architectures;

 baselining and modelling requirements and selected solution architecture for each phase
of the endeavour;
 performing design synthesis and system verification and validation;

 while considering both the problem and solution domains, taking into account necessary
enabling systems and services, identifying the role that the parts and the relationships
between the parts play with respect to the overall behaviour and performance of the
system, and determining how to balance all of these factors to achieve a satisfactory
outcome.

Systems Engineering provides facilitation, guidance and leadership to integrate the relevant
disciplines and specialty groups into a cohesive effort, forming an appropriately structured
development process that proceeds from concept to production, operation, evolution and
eventual disposal.

Systems Engineering considers both the business and the technical needs of customers with the
goal of providing a quality solution that meets the needs of users and other stakeholders, is fit for
the intended purpose in real-world operation, and avoids or minimizes adverse unintended
consequences.

The goal of all Systems Engineering activities is to manage risk, including the risk of not
delivering what the customer wants and needs, the risk of late delivery, the risk of excess cost,
and the risk of negative unintended consequences. One measure of utility of Systems
Engineering activities is the degree to which such risk is reduced. Conversely, a measure of
acceptability of absence of a System Engineering activity is the level of excess risk incurred as a
result.
TRANSDISCIPLINARY APPROACH
Transdisciplinarity is described in Wikipedia as an approach which “crosses many disciplinary
boundaries to create a holistic approach.” This emphasis on a holistic approach distinguishes it
from cross-disciplinary, which focuses mainly on working across multiple disciplines while
allowing each discipline to apply their own methods and approaches. Systems engineering is
simultaneously cross-disciplinary and transdisciplinary. (The crossdisciplinary aspect is
discussed in the next section on the Integrative Approach.)
The transdisciplinary approach originated in the social sciences. It “transcends” all of the
disciplines involved, and organizes the effort around common purpose, shared understanding and
“learning together” in the context of real-world problems or themes. It is usable at any level,
from complex to simple, from global to personal. A transdisciplinary approach is needed when
the problem cannot readily be “solved” and the best that can likely be achieved is instead a
“resolution.” The participants in the endeavor need to “transcend” their particular disciplinary
approach to instead come to some overall useful compromise or synergistic understanding that
their disciplines cannot come to on their own (even when working together in a normal
integrative approach with other disciplines).

INTEGRATIVE APPROACH
The integrative approach has long been used in systems engineering and usually involves either
interdisciplinary (e.g.. integrated product teams) or multi-disciplinary (e.g.. joint technical
reviews) methods. The integrative approach by itself can be adequate where the situation is not
overly complex and there are smaller numbers of stakeholders potentially impacted. The
integrative approach can be used when dealing with a highly precedented situation that has been
encountered before and a path to the solution can be readily identified and understood (albeit
there will still be many challenges along the way, technical and otherwise). The integrative
approach includes the traditional multi-disciplinary and inter-disciplinary approaches commonly
used in systems engineering practice. The transdisciplinary approach may be needed in
unprecedented situations or where there is a significant degree of complexity involved. See
Madni (2018).

SYSTEMS PRINCIPLES AND CONCEPTS

Systems principles and concepts are the ways that systems thinking and the systems sciences
infuse systems engineering. Examples of some of the principles, concepts and supporting tools
are: mental models, system archetypes, holistic thinking, separation of concerns, abstraction,
modularity and encapsulation, causal loop diagrams, and systems mapping. (The Systems
Engineering Body of Knowledge describes many of these, and more, at
https://www.sebokwiki.org/wiki/Principles_of_Systems_Thinking).

ENGINEERING AND ENGINEERED

Both ancient and modern definitions of Engineering allow for the wide interpretation intended
here. For
example, Google dictionary defines Engineering in two ways:
1. the branch of science and technology concerned with the design, building, and use of engines,
machines, and structures.
2. the action of working artfully to bring something about.
And Wikipedia:
• Engineering is the creative application of science, mathematical methods, and empirical
evidence to the innovation, design, construction, operation and maintenance of structures,
machines, materials, devices, systems, processes, and organizations.
• The term engineering is derived from the Latin ingenium, meaning “cleverness” and ingeniare,
meaning
“to contrive, devise”.

SYSTEM ENGINEERING LIFE CYCLE

• Feasibility Study
• Analysis
• Design
• Implementation
• Testing
• Training and Documentation
• Evaluation and Monitoring
• Maintenance

Feasibility Study
 Initial study
 looks to see if a new system can be built
 at reasonable cost
 in reasonable time
 Find out what people want from the new system by using:
o —questionnaires
o —interviews
o —observation
o inspection of records
Analysis
 Identifies the problems to be solved
 Looks in detail at the current system
 Understands the existing system
 Identifies desired outcomes
 Sets up performance criteria

Design

 Designs the system in line with desired outcomes

 Chooses input, storage and output methods
 Decides on the processes
 Designs input/output screens and layouts of components
 Designs validation tests
 Designs test plans
Testing
• Test plan created during design stage is used to test the system
• Test data is entered
• Results are compared with what was expected
• Remedial action is taken to correct faults
• Validation tests are tested
Evaluation and monitoring
• Checking user requirements and performance criteria have been met
• Assessment of client/user satisfaction
• Setting up review cycle
Maintenance
 • Set up help-desk facilities
• Add extra functions when required
• Improve performance
• Investigate system crashes to prevent them happening

SYSTEM DEVELOPMENT LIFE CYCLE OR

LIFE CYCLE PHASE

he software development process is normally long and tedious. But project managers and
system analysts can leverage software development life cycles to outline, design, develop, test,
and eventually deploy information systems or software products with greater regularity,
efficiency, and overall quality.

What is System Development Life Cycle?

A system development life cycle or SDLC is essentially a project management model. It defines
different stages that are necessary to bring a project from its initial idea or conception all the
way to deployment and later maintenance.

‍
System Development Life Cycle
In this guide, we’ll break down everything you need to know about the system development life
cycle, including all of its stages. We’ll also go over the roles of system analysts and the benefits
your project might see by adopting SDLC.

‍
7 Stages of the System Development Life Cycle

There are seven primary stages of the modern system development life cycle. Here’s a brief
breakdown:

 Planning Stage

 Feasibility or Requirements of Analysis Stage

 Design and Prototyping Stage

 Software Development Stage

 Software Testing Stage

 Implementation and Integration

 Operations and Maintenance Stage

Now let’s take a closer look at each stage individually.

‍
Planning Stage

Before we even begin with the planning stage, the best tip we can give you is to take time and
acquire proper understanding of app development life cycle.

The planning stage (also called the feasibility stage) is exactly what it sounds like: the phase in
which developers will plan for the upcoming project.

It helps to define the problem and scope of any existing systems, as well as determine the
objectives for their new systems.

By developing an effective outline for the upcoming development cycle, they'll theoretically
catch problems before they affect development.

And help to secure the funding and resources they need to make their plan happen.

Perhaps most importantly, the planning stage sets the project schedule, which can be of key
importance if development is for a commercial product that must be sent to market by a certain
time.

‍
Analysis Stage
The analysis stage includes gathering all the specific details required for a new system as well
as determining the first ideas for prototypes.

Developers may:

 Define any prototype system requirements

 Evaluate alternatives to existing prototypes

 Perform research and analysis to determine the needs of end-users

Furthermore, developers will often create a software requirement specification or SRS

document.

This includes all the specifications for software, hardware, and network requirements for the
system they plan to build. This will prevent them from overdrawing funding or resources when
working at the same place as other development teams.

‍
Design Stage

The design stage is a necessary precursor to the main developer stage.

Developers will first outline the details for the overall application, alongside specific aspects,
such as its:

 User interfaces

 System interfaces

 Network and network requirements

 Databases

They’ll typically turn the SRS document they created into a more logical structure that can later
be implemented in a programming language. Operation, training, and maintenance plans will all
be drawn up so that developers know what they need to do throughout every stage of the cycle
moving forward.
Once complete, development managers will prepare a design document to be referenced
throughout the next phases of the SDLC.

Development Stage
The development stage is the part where developers actually write code and build the
application according to the earlier design documents and outlined specifications.

This is where Static Application Security Testing or SAST tools come into play.

Product program code is built per the design document specifications. In theory, all of the prior
planning and outlined should make the actual development phase relatively straightforward.

Developers will follow any coding guidelines as defined by the organization and utilize different
tools such as compilers, debuggers, and interpreters.

Programming languages can include staples such as C++, PHP, and more. Developers will
choose the right programming code to use based on the project specifications and
requirements.

Testing Stage

Building software is not the end.

Now it must be tested to make sure that there aren’t any bugs and that the end-user experience
will not negatively be affected at any point.

During the testing stage, developers will go over their software with a fine-tooth comb, noting
any bugs or defects that need to be tracked, fixed, and later retested.
t’s important that the software overall ends up meeting the quality standards that were
previously defined in the SRS document.

Depending on the skill of the developers, the complexity of the software, and the requirements
for the end-user, testing can either be an extremely short phase or take a very long time. Take a
look at our top 10 best practices for software testing projects for more information.

Implementation and Integration Stage

After testing, the overall design for the software will come together. Different modules or designs
will be integrated into the primary source code through developer efforts, usually by leveraging
training environments to detect further errors or defects.

The information system will be integrated into its environment and eventually installed. After
passing this stage, the software is theoretically ready for market and may be provided to any
end-users.

Maintenance Stage

The SDLC doesn’t end when software reaches the market. Developers must now move into a
maintenance mode and begin practicing any activities required to handle issues reported by
end-users.
Furthermore, developers are responsible for implementing any changes that the software might
need after deployment.

This can include handling residual bugs that were not able to be patched before launch or
resolving new issues that crop up due to user reports. Larger systems may require longer
maintenance stages compared to smaller systems.

Role of System Analyst

An SDLC’s system analyst is, in some ways, an overseer for the entire system. They should be
totally aware of the system and all its moving parts and can help guide the project by giving
appropriate directions.

The system analyst should be:

 An expert in any technical skills required for the project

 A good communicator to help command his or her team to success

 A good planner so that development tasks can be carried out on time at each phase of
the development cycle

Thus, systems analysts should have an even mix of interpersonal, technical, management, and
analytical skills altogether. They’re versatile professionals that can make or break an SDLC.

Their responsibilities are quite diverse and important for the eventual success of a given project.
Systems analysts will often be expected to:

 ️Gather facts and information

 Make command decisions about which bugs to prioritize or what features to cut

 Suggest alternative solutions

 Draw specifications that can be easily understood by both users and programmers

 Implement logical systems while keeping modularity for later integration

 Be able to evaluate and modify the resulting system as is required by project goals

 Help to plan out the requirements and goals of the project by defining and understanding
user requirements

‍
6 Basic SDLC Methodologies
Although the system development life cycle is a project management model in the broad sense,
six more specific methodologies can be leveraged to achieve specific results or provide the
greater SDLC with different attributes.

‍
Waterfall Model

The waterfall model is the oldest of all SDLC methodologies. It’s linear and straightforward and
requires development teams to finish one phase of the project completely before moving on to
the next.

Each stage has a separate project plan and takes information from the previous stage to avoid
similar issues (if encountered). However, it is vulnerable to early delays and can lead to big
problems arising for development teams later down the road.

‍
Iterative Model

The iterative model focuses on repetition and repeat testing. New versions of a software project
are produced at the end of each phase to catch potential errors and allow developers to
constantly improve the end product by the time it is ready for market.
One of the upsides to this model is that developers can create a working version of the project
relatively early in their development life cycle, so implement the changes are often less
expensive.

‍
Spiral Model

Spiral models are flexible compared to other methodologies. Projects pass through four main
phases again and again in a metaphorically spiral motion.

It’s advantageous for large projects since development teams can create very customized
products and incorporate any received feedback relatively early in the life cycle.

‍
V-Model

The V-model (which is short for verification and validation) is quite similar to the waterfall model.
A testing phase is incorporated into each development stage to catch potential bugs and
defects.

It’s incredibly disciplined and requires a rigorous timeline. But in theory, it illuminates the
shortcomings of the main waterfall model by preventing larger bugs from spiraling out of control.

‍
Big Bang Model

The Big Bang model is incredibly flexible and doesn’t follow a rigorous process or procedure. It
even leaves detailed planning behind. It’s mostly used to develop broad ideas when the
customer or client isn’t sure what they want. Developers simply start the project with money and
resources.

Their output may be closer or farther from what the client eventually realizes they desire. It’s
mostly used for smaller projects and experimental life cycles designed to inform other projects in
the same company.
‍
Agile Model

The agile model is relatively well-known, particularly in the software development industry.

The agile methodology prioritizes fast and ongoing release cycles, utilizing small but
incremental changes between releases. This results in more iterations and many more tests
compared to other models.

Theoretically, this model helps teams to address small issues as they arise rather than missing
them until later, more complex stages of a project.

Benefits of SDLC

SDLC provides a number of advantages to development teams that implement it correctly.

‍
Clear Goal Descriptions

Developers clearly know the goals they need to meet and the deliverables they must achieve by
a set timeline, lowering the risk of time and resources being wasted.

‍
Proper Testing Before Installation

SDLC models implement checks and balances to ensure that all software is tested before being
installed in greater source code.

‍
Clear Stage Progression

Developers can’t move on to the next age until the prior one is completed and signed off by a
manager.

‍
Member Flexibility

Since SDLCs have well-structured documents for project goals and methodologies, team
members can leave and be replaced by new members relatively painlessly.

‍
Perfection Is Achievable

All SDLC stages are meant to feed back into one another. SDLC models can therefore help
projects to iterate and improve upon themselves over and over until essentially perfect.

‍
No One Member Makes or Breaks the Project

Again, since SDLCs utilize extensive paperwork and guideline documents, it’s a team effort and
losing one even major member will not jeopardize the project timeline.

What You Need to Know About System Development Life Cycle

Where is SDLC Used?

System development life cycles are typically used when developing IT projects.

Software development managers will utilize SDLCs to outline various development stages,
make sure everyone completes stages on time and in the correct order, and that the project is
delivered as promptly and as bug-free as possible.
SDLCs can also be more specifically used by systems analysts as they develop and later
implement a new information system.

‍
What SDLC Model is Best?

It largely depends on what your team’s goals and resource requirements are.

The majority of IT development teams utilize the agile methodology for their SDLC. However,
others may prefer the iterative or spiral methodologies.

All three of these methods are popular since they allow for extensive iteration and bug testing
before a product is integrated with greater source code or delivered to market.

DevOps methodologies are also popular choices. And if you ever need a refresher course
on what is DevOps, you needn't worry as our team at CloudDefense has got you covered!

‍
What Does SDLC Develop?

SDLC can be used to develop or engineer software, systems, and even information systems. It
can also be used to develop hardware or a combination of both software and hardware at the
same time.

Logical Steps of Systems Engineering

•
The Systems Engineering Process is a comprehensive, iterative and recursive problem
solving process, applied sequentially top-down by integrated teams.. The process is
applied sequentially, one level at a time, adding additional detail and definition with
each level of development.
Types of Logical Steps
• There are four steps that comprise the SE Process are
» Requirement Analysis
» System Analysis Control
» Functional Analysis/Allocation
» Design Synthesis
Requirement Analysis
• Requirements Analysis (Step 1) is one of the first activities of the System Engineering
Process and functions somewhat as an interface between the internal activities and the
external sources providing inputs to the process.
System Analysis and Control
System Analysis and Control manages and controls the overall System Engineering
Process. This activity identifies the work to be performed and develops the schedules
and costs estimates for the effort. It’s the center for configuration management
throughout the systems in engineering process.

1. .
Functional Analysis and Allocation

Functional Analysis and Allocation is a top-down process of translating system

level requirements into detailed functional and performance design criteria. The
result of the process is a defined Functional Architecture with allocated system
requirements that are traceable to each system function.

The initial step is to identify the lower-level functions required to perform the
various system functions. As this is accomplished, the system requirements are
allocated and functional architecture(s) are developed. These activities track
and interact so that as details evolve, they are continually validated against each
other.
Design Synthesis

Design Synthesis is the process of taken the functional architecture developed

in the Functional Analysis and Design step and decomposing those functions
into a Physical Architucture (a set of product, system, and/or software elements)
that satisfy system required functions.