The word "deliverables" is essential for a project. "what does a deliverable mean?" and "how should i manage the deliverable?" i think that there are some people who think.
This article introduces you to defining deliverables and how to manage them appropriately. keep the basic points down and help you better manage your deliverables in future projects.
the product of system development is the system itself as a program. however, in the development process until the system is completed, various deliverables including various documents are produced, such as "to correct the gap in recognition between the ordering side and the development side" and "for sharing information with the development team".
if you are in charge of a company or store, it is important to understand what kind of deliverables and documents can be produced in each process in order to properly manage the project and proceed with development smoothly.
therefore, in this article, general deliverables and documents produced by waterfall type system development are introduced in a list for each development process! to the end, you'll understand what deliverables and documents you should deliver.
the result of the work being completed project deliverables are the results of a project process for system development and software development. for example, documents such as programs, specifications, and design documents are deliverables.
the evidence of work becomes a deliverable.
if you leave the deliverables such as programs, specifications, and design books, you can prove that the project process is completed.
conversely, deliverables are the result and evidence of the task of "developing systems and software". be sure to prepare the deliverables such as programs, specifications, and design books.
deliverables are not always deliverables
deliverables and deliverables are not identical. deliveries are everything you deliver to your clients. deliverables, on the other hand, apply to the outcome and evidence of a project. intermediate deliverables, final deliverables, and receipts.
deliverables may be mistaken for being limited to final deliverables. however, there may be requests from clients to "check whether there is a difference between the middle and final progress, so i would like you to submit a report of the progress along the way". in this case, some of the intermediate deliverables are also deliverables.
points of deliverable management in a project
next, i will introduce two points of deliverable management in the project.
clarify the final deliverable
first of all, it is important to determine the final deliverable that is the goal of the project.
the final deliverable is designed to achieve the goal. therefore, be sure to be aware of the purpose when deciding on the final deliverable. specific examples of final deliverables include systems and system operating procedures.
at the same time, it lists the elements required for the deliverable. in order for the final deliverable to be completed, intermediate deliverables such as screen configuration instructions, progress management tables, contracts, etc. are required. in this way, we will list the resulting deliverables of the task.
create rules to manage deliverables
create rules to manage deliverables. deliverables are the goal of the project and must be managed appropriately. therefore, it is important to create rules to manage and make them known to the projection members. specific examples of rules include:
- format data
- version control method
- hierarchy when saving folders
- folder naming rules some project management tools have deliverable management capabilities. to compare the benefits and other features of deploying the tool, click here.
the role of deliverables and documents in system development
deliverables in system development refer to documents and documents that are created in each process. system development is divided into detailed processes, and various deliverables are created in addition to the final delivery.
the feature of waterfall system development is that multiple development processes are carried out step by step so that water flows downstream from upstream. and basically, one process is completed and then moved on to the next, and there is no turning back. one of the features of waterfall system development is that a large number of artifacts such as document programs are produced in each process.
so, what role does the deliverables produced in each process play? one is to use the output as a result of the work of the upstream process as input for one downstream process. in this case, incomplete outputs will adversely affect all subsequent processes.
to avoid this situation, is the output of each process reasonable as the next input? in order to check and make decisions, it is necessary to share the deliverables between stakeholders, including clients. this is another role that deliverables play.
deliverables are work-completed results and evidence that work is completed at the same time. it is also important to note that the delivered product is not necessarily a deliverable.
to better manage the deliverables in your project, first clarify the final deliverable. then, we will list the deliverables that will be completed for each task. it is also important to create rules to manage deliverables and make them known to project members.
clearly define and manage deliverables.
example of a waterfall system development
the table above is an example of a typical waterfall system development process. in the development and implementation phase, "programs" developed for each function and module (part) are artifacts, but in other processes, it is safe to assume that some documents are created as deliverables.
in addition, although the results (output) of single unit, coupling, and comprehensive tests may be returned to the development phase, which is an upstream process, the deliverables produced in each waterfall-type process are basically used as input for the next process.
deliverables per development process: 1. planning and requirements definition
in order to solve business problems, what kind of system should be developed, and based on the raised planning (system development project), it is necessary to incorporate even the specific requirements required of the system.
The document mentioned as the deliverable of the request definition is "RFP (Request for Proposal)", which is basically created by the client itself on the ordering side.
rfp is also a useful document for providing consistent input in order to obtain appropriate proposals from multiple system developers. after selecting a system development company, it is also used as input to the requirement definition, which is the first step in the project.
proposals and quotations
Although it is slightly different from the intention of this article,the "proposal" and "quotation" prepared by the system development company as a response to RFP may also be the deliverables of the system development project.
proposals are generally submitted with an estimate of the proposal, which includes proposals centered on presentations, such as proposals for systems that realize the needs of clients, systems as a development company, and how to proceed with projects.
deliverables per development process: 2. requirement definition
in the requirements definition phase, a "requirement definition document" is produced, which is a deliverable that analyzes and examines the requirement definition into input and summarizes the requirements to be realized in the system as a document. the requirement definition document is basically prepared by the development company on the consignment side, but there are cases where it is not possible to include all the needs and requirements of the ordering side in a balance with the budget and delivery date of the project.
therefore, in order to define the final requirements, it is necessary to communicate closely between the ordering side and the consignment side and explore the conclusion point. comprehensive testing after completion of the program and acceptance test design after delivery are also developed during the requirements definition phase.
system requirements
system requirements are requirements that clarify the direction of system development based on the gap between the current business flow and the new business flow. specifically, in order to realize a new business flow, we will select what is systematized and what is not.
as an ordering side, it is important to prioritize what can and cannot be transferred in order to achieve the purpose and goal of system development.
functional requirements
functional requirements are clearly defined as requirements for functions to be implemented in the system being developed. specifically, we will define the requirements required for the system one by one, such as the function and structure of the system, the type of data, and the contents that can be processed.
nonfunctional requirements
nonfunctional requirements are "non-functional requirements" that should be implemented and all requirements required of the system. examples of what you might find are performance such as the processing power that a system should achieve, future traffic growth, scalability to accommodate additional functionality, and security for external threats.
In general, it seems that there are many cases where nonfunctional requirements required for the system are formulated based on six items of "nonfunctional demand grade" formulated by the Information Processing Promotion Agency (IPA).
Reference: Strengthening upstream processes for the construction of information processing promotion (IPA) systems (non-functional requirements grade)
WBS（Work Breakdown Structure）
wbs is a structure diagram in which the process of system development is subdivided by task and the deadline and progress rate are shown. it is a structured structured work required for a system development project while linking it with deliverables, including documents that are milestones (interim goals) for each development process.
it is often created with a graph-visualized schedule (gantt chart) and is used to share the progress schedule of a system development project among stakeholders.
Related article: What is WBS in system development? Explain the basics of project management!
acceptance test design letter
an acceptance test design document is a design document used by the ordering side to check whether the needs and requirements formulated in the requirement definition are met after the delivery of the "system" which is the deliverable of the project.
since the acceptance test itself is a test to verify whether the requirement definition is met, it is a design document created in the requirements definition phase, along with plans and specifications. plans, specifications, and design statements for the "comprehensive test", which is the final confirmation of the development company, will also be prepared.
deliverables per development process: 3. basic design
in the basic design phase, we create a "basic design document" that incorporates the "system requirements", "functional requirements", and "nonfunctional requirements" defined in the requirement definition document to a more specific level, and summarizes the blueprints of the system from the outside as documents.
the last opportunity for the ordering side to be involved in the system development process is the basic design phase. it is necessary to provide accurate feedback to the basic design book, which is the deliverable and output, and eliminate the difference in recognition with the development company as much as possible.
system design
system design is the process of incorporating what kind of software, hardware, and network a system should be configured based on functional requirements (required functions) and nonfunctional requirements (requirements other than functions) formulated in the requirement definition into specific design books and diagrams.
it must be designed to meet nonfunctional requirements such as availability, performance, scalability, security, and operability as mentioned in the requirements definition, as well as functional requirements.
functional design
functional design is the process of creating functional requirements defined in the requirement definition as a more specific design document. as mentioned in the table above, lists, layouts, transition diagrams, etc. of screens, forms, batches, databases, files, etc. are created.
deliverables per development process: 4. detailed design
in the detailed design phase, we produce a deliverable "detailed design document" that summarizes the blueprints that serve as instructions for programmers as documents using the input of the "basic design document" that looks at the system from the outside. in addition to specific design books, development policies and rules are developed to eliminate the skill differences of programmers, and unit and integration test designs are also implemented during the detailed design phase.
development policies and rules
scratch development, which builds systems from scratch, has the advantage of virtually no restrictions on functions, but the disadvantage is that the development period is prolonged and development costs are soaring. in projects with limited delivery times and costs, framework libraries are often used.
the direction of such a system development project is embodied by the "development policy" and the "description rules" formulated for the purpose of absorbing skill differences between programmers.
unit and coupling test design
the system development process after detailed design will move to the "development and implementation phase" based on the detailed design manual, but the programmer will use the blueprints such as "class diagram" and "module composition diagram".
as can be seen from this, in the development and implementation phase of a program, multiple programmers are responsible for developing individual modules divided, combining the resulting modules as subsystems, and combining subsystems to build a single system. this is why unit and integration test designs are performed during the detailed design phase.
deliverables per development process: 5. unit, coupling, comprehensive test
in each test phase, a test implementation report is produced as deliverables and outputs. depending on the test results conducted in accordance with the test plan, specifications, and design manuals, the process may be returned to the development and implementation phase in order to modify the program.
deliverables per development process: 6. acceptance test
the output as a result of the acceptance test is a written receipt that it has finally agreed to accept. however, in order to prepare a thorough system and carry out acceptance tests without mistakes, it is best to have not only test plans, specifications, and design documents, but also "comprehensive test implementation report" delivered as input.
summary: don't forget to designate the required deliverables as deliverables
for companies and store personnel who want to properly manage system development projects, this article has introduced a list of general deliverables and documents produced by waterfall system development for each development process.
in general, the definition of deliverables and deliverables in system development are determined during the requirements definition phase, but not all of the deliverables presented in this article are deliverables.
normally, if the deliverables in the requirement definition, basic design, and comprehensive test are delivered, what kind of deliverables do you want to deliver, including future replacements? at the start of the project, you must carefully identify and specify it.
if you are able to proceed with such appropriate communication and process together, and are looking for the best development company for your company, please consult your system secretary. our expert consultants will listen carefully to your requests and choose the best development company for your budget.
No comments:
Post a Comment