What is the flow of the system development project?

THE BUSINESS CONTENTS OF SE WERE INTRODUCED IN THE PREVIOUS ARTICLE.

what is the difference between a system engineer and a programmer? what are the job contents, the advantages and disadvantages of each?

Therefore, in order to make it easier to imagine the actual system development work, I will explain the flow of the system development project that SE actually performs in business.

process of system development as i introduced in the previous article, i will summarize it lightly and in a review.


the general flow of system development is:

• proposal phase: win deals with sales requirements
• definition phase: define customer requirements at the time of proposal
• basic design phase: incorporate requirements into the design overview of development equipment, finalize equipment, determine method and recruitment technology detailed design phase : determining the setting base such as development equipment parameters and codes construction and
• test phase: input the confirmed parameters and code to the development equipment, test the expected operation
• operation and maintenance phase : perform system operation, perform maintenance and trouble response

how to proceed with system development

before we can explain the flow of a system development project, we must first explain that there are two ways to proceed with system development.
there are
two types of development: waterfall development and agile development.

the main difference is whether the requirements definition phase to the construction and
testing phase is done in a single way (waterfall) and iteratively (agile).


most of the system development approaches waterfall development.
agile development is the main approach used for application development, and specification changes are frequently made and used for speedy development.

since the process called iteration is repeated, it is possible to quickly respond to specification changes and customer requests. instead, it is an ideal method for application development rather than system development because it does not require the submission of deliverables such as design materials in each process.

there are many methods of agile development in system development, but this time i will focus on general waterfall development.

flow of project start (proposal phase)

in the case of competitive bidding, specifically, it is as follows. in the case of voluntary contracts, requirements are suddenly defined.
* competitive bidding is a contract method in which you compete with other companies to win one project. voluntary contracts are contract methods that are requested directly from customers without competing with other companies.



acquiring new deals first of all, you need to find a customer who is thinking about developing a new system. the method of finding new projects is mainly sales
◆ interviews with existing customers if they have problems and proposes the introduction of the system.
◆ existing customers are approaching new projects.
◆ to open sales to new customers.

break up into patterns.


IN ANY CASE, SALES ALONE LACKS TECHNICAL EXPLANATIONS, SO IT IS COMMON TO ACCOMPANY SE AT THIS STAGE.

the se to accompany is chosen by veterans, technically strong, and well-explained to customers. there are many companies that have such technical sales positions separately from se. it is an image like the middle employment between se and sales.


if we find a customer who is considering developing a new system, the project will be launched in-house. if it is a voluntary contract, you can immediately enter the requirements definition, but if it becomes a competitive bid, you must go to a detailed stage and propose to win against competitors.

ARRANGEMENT OF BUSINESS REQUIREMENT

It is a Request For Information, in a nutshell, a document that summarizes the requirements for a new system in order to request system developers to provide information about new systems. It is sometimes referred to as a specification.


send summarizing simple business requirements and equipment requests for the new system from the place of placing place to multiple vendors to bid, and ask each company to submit a simple proposal from each company, "if you are a company like this, you can develop your company's system like this.".



the proposal does not determine the details or the detailed price, but asks you to submit an approximate outline and approximate cost.
we will also introduce the contents of the introduced product catalog and similar examples within the company to show how much our company can build.


by doing so, the orderer (user) considers which companies and what equipment and specifications the requirements will be realized.


at this stage, the system development vendor will not be determined because the orderer only gets information for comparison and consideration.


se is responsible for creating proposals for rfi published by customers, responding to inquiries from manufacturers handling products, collecting catalogs, and creating approximate estimates.

RFC PROCUREMENT SPECIFICATIONS

An RFC is a Request For Comment, which, in a nutshell, summarizes the procurement specifications for a new system in order to ask system developers to give their opinions on new systems.


rfcs are not always implemented because they may be omitted or followed by rfps in some cases. the orderer compiles the procurement specifications for the new system based on the rfi answers (proposals) received from multiple system development vendors.


Specifically, about the new system

◆ Procurement method, unit
◆ Specification of conditions of procurement equipment
◆ Designation of deliverables
◆ Bidding requirements, compliance matters
◆ Re-consignment matters
◆ Matters described in contracts, etc., We will summarize the specifications for specific detailed procurement that were not described at the time of RFI.


the purpose is to publicly present the procurement specifications summarized as rfc and get opinions from system development vendors, mainly procurement specifications.



the system development vendor who received the announcement of rfc said, "if it is our company, we will procure such a number of equipment specifically under such conditions, and at that time we will also make such a contract." submit the opinion to the orderer collectively.



in order to prepare a written opinion on this rfc, se will contact the vendor handling the equipment and elaborate on technical specifications.



after receiving the written opinion, the orderer will again compare the procurement methods and conditions of multiple system development vendors to consider which vendors are the closest to their needs and to solidify the requirements they want to achieve with the new system.

VENDOR ORGANIZATION

RFP refers to a Request For Proposal, which is simply a material for requesting a proposal to measure the construction and understanding of a new system in order to determine the vendor to develop a new system.

orderers who have established what they want to achieve with the new system through rfc and business requirements will summarize the requirements for the construction of the new system in more detail.


Specifically, regarding the new system

◆ Procurement method and conditions determined by RFC
◆ Detailed and clarification of business requirements that were ambiguous in RFI
◆ Deadline for system development
◆ System development project system, project operation and promotion method
◆ The conditions

of the project manager etc. are summarized in detail as a request form. Submit it as an RFC to the system development vendor.

each vendor said of the new system based on the rfp, "if you are a company, you will use such a number of equipment specifically and realize the requirements using such a configuration and such technology, we will work on such a schedule and system." and one proposal.


then submit a more detailed estimate cost than at the time of rfi.


after receiving a proposal for the new system, the orderer evaluates the proposal from each vendor, scores it, and selects the vendor.

the evaluation criteria for the selection of proposals are mainly the quality of the technical content

◆ the increase or decrease in points depending on the point item and the deduction item. (mainly, if we can propose how we can realize the part that customers are not able to decide by what kind of method, we will add points, deducted if the minimum requirements are not met)
◆ exceeding the cut point
◆ construction results at other companies
◆ we will focus on points such as the proposed price.

we then signed an agreement with the highest-point system development vendor, which concludes the proposal phase and then becomes the requirements definition phase.

by the way, of course, we have not been able to make a contract until we win the project by bidding, so we are operating without getting money from customers. if you can't win a deal, it's only a loss of labor costs for a company. if you lose, the project structure in the company will be canceled, and you will be in charge of another project.

after the bid is finalized (requirement definition - operation and maintenance)
after winning the project and signing a contract by bidding, the next phase is to solidify the actual technology and function.
as i introduced the details in the previous article, i will summarize it briefly here and add up the part that i did not explain last time.

requirements definition phase

this is the phase of clarifying the ambiguities at the time of the proposal in order to complete the requirement definition.
the purpose is to define the requirements that customers want to achieve in the system, and what functions and technologies to be realized, and to form consensus with customers.

basic design phase

in order to complete the basic design book, we further pursued "what kind of equipment and what functions and technologies to realize by using" determined in the requirement definition, and defined "what kind of function and technology (design policy, outline, rough numerical value, selection of whether or not to use or not) by what equipment (model number, number, composition)", the goal is to show off that we are designing to meet the needs of our customers.

detailed design phase

in order to complete the detailed design book, we further pursue "what kind of equipment (model number, number, composition) determined by the basic design, what functions and technologies (design policy, outline, general figures, selection of whether or not to use the function)", define "which function and technology will be constructed using what numerical value and setting in each device", the purpose is to complete the installation equipment to the design on the desk.

build phase

in order to build the system, we will carry equipment to the actual site and incorporate the settings using a detailed design document describing "which functions and technologies will be constructed using each device using what numerical values and settings" determined by the detailed design. cable wiring between devices is also performed.
the purpose is to complete the foundation construction of the system requested by the customer.

test phase

test that the equipment actually built works as expected to complete the system construction.

complete all tests by following these steps:

prepare test plans

explain what kind of tests you want to test your customers on what schedule.

In system development, there is a concept of a V-shaped model in which the test is based on the phase of what items and scenarios to test.

specifically,

we will confirm the contents of the analysis of the customer's request at the time of proposal in the acceptance test.
the contents defined in the requirement definition will be confirmed in the comprehensive examination.

in this way, we will respond to confirm the contents considered in the previous phase on the left side of the figure in the test process on the right side of the figure.

let's explain the contents of each test.

unit test

perform simple operation confirmation on the device alone. simple tests such as "power is running normally", "command on shut down normally", and so on.
it is called unit test because it is limited to the function performed by one device alone without connecting to other devices.

combined test

connect the devices to each other and check the operation. this is called a coupling test because it checks functions that cannot be confirmed unless two or more devices are combined, such as "normal access between devices" and "switching to the expected device in the event of a failure".

comprehensive examination

in a real system environment, we will confirm that it can operate in the expected scenario.
the integration test is not a customer environment, and there is no problem wherever you perform it, but the comprehensive test ensures that it can operate in the same environment as the system that runs in production.

various patterns of confirmation are also tested, such as operation at normal time, operation at the time of failure, function confirmation and access confirmation across multiple devices. it is called a comprehensive examination because it is a place to make a comprehensive judgment.

acceptance test

this is a test in which users check the system that was built. customers with less requirements may not do this, but for demanding customers, the test log to the numerical values in the test results list are checked in detail.

once the customer confirms that the requirements and requests issued by the customer are properly reflected in the system, and the customer understands that there is no problem, the test phase ends.

operation and maintenance phase

once the test is complete, the system is up and running. the actual start of system operation is called operation, and if there is any problem during the operation period, it is called maintenance. it is treated with operational maintenance.


many system developers often separate the person in charge of system operation and maintenance from the construction until the system is up and running, so it is actually transferred to operation and maintenance before release.


if there is any problem during the operation period, the customer will contact the maintenance desk instead of the person responsible for the construction. since the form of maintenance is linked to the contract contents, it may be available 24 hours a day, 365 days a year, or it may be handled from 9:00 to 18:00 on weekdays. it is up to you to decide what kind of response you want to take at the time of your contract.

Summary

• in system development, a method called waterfall is used to make proposals, design, build, and operate in a single way.
• we will fight with other companies to submit proposals to win projects.
• after acquiring the deal, we will enter the requirements definition, basic design, detailed design, construction and testing, operation and maintenance phase.
• Since the contract method may differ from the customer or subcontractors depending on each phase, it is common for the system to change little by little depending on the phase.

Key people like pms (project managers) and design leaders will stay from proposal to operation unless they even have any problems.

 

A primer on SE on such system development has been published by Kindle. You can read kindle unlimited for free.

The contents and basics in the blog are the same, but I think that it is easy to understand because it is described in a proper flow.

It's published as Kindle Unlimited, so anyone who subscribes can read it for free. If you want to read in proper order, want to read in e-books at gap time, and try reading for the time being because it is free.