[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-0-en-105":3,"doc-seo-655884-105":59,"doc-detail-655884-en":130},{"code":4,"msg":5,"data":6},0,"success",[7,13,18,23,28,33,38,43,48,51,55],{"id":8,"doc_module":4,"doc_module_name":9,"category_name":10,"show_sort_weight":11,"slug":12},1,"Document","Story & Novel",90,"story-novel",{"id":14,"doc_module":4,"doc_module_name":9,"category_name":15,"show_sort_weight":16,"slug":17},2,"Literature",80,"literature",{"id":19,"doc_module":4,"doc_module_name":9,"category_name":20,"show_sort_weight":21,"slug":22},4,"Exam",70,"exam",{"id":24,"doc_module":4,"doc_module_name":9,"category_name":25,"show_sort_weight":26,"slug":27},5,"Comic",60,"comic",{"id":29,"doc_module":4,"doc_module_name":9,"category_name":30,"show_sort_weight":31,"slug":32},6,"Technology",50,"technology",{"id":34,"doc_module":4,"doc_module_name":9,"category_name":35,"show_sort_weight":36,"slug":37},7,"Healthcare",40,"healthcare",{"id":39,"doc_module":4,"doc_module_name":9,"category_name":40,"show_sort_weight":41,"slug":42},8,"Research & Report",30,"research-report",{"id":44,"doc_module":4,"doc_module_name":9,"category_name":45,"show_sort_weight":46,"slug":47},9,"Religion & Spirituality",20,"religion-spirituality",{"id":46,"doc_module":4,"doc_module_name":9,"category_name":49,"show_sort_weight":46,"slug":50},"World Cup","world-cup",{"id":52,"doc_module":4,"doc_module_name":9,"category_name":53,"show_sort_weight":52,"slug":54},10,"Lifestyle","lifestyle",{"id":56,"doc_module":4,"doc_module_name":9,"category_name":57,"show_sort_weight":24,"slug":58},19,"General","general",{"code":4,"msg":60,"data":61},"ok",{"site_id":62,"language":63,"slug":64,"title":65,"keywords":66,"description":67,"schema_data":68,"social_meta":123,"head_meta":125,"extra_data":127,"updated_unix":129},105,"en","software-development-lifecycle-procedure-10-purpose","Software Development Lifecycle Procedure - 1.0 Purpose","","Software Development Lifecycle Procedure defines how Maine State Government application owners create SDLC artifacts for major application projects in alignment with the SDLC Policy. It establishes purpose, then provides definitions for key deliverables across planning, architecture, database, operations, and requirements modeling. Included artifacts cover acceptance plan, architectural and deployment plans, infrastructure and database design documents, problem statement and role/privilege definitions. It also defines process flow diagrams, use cases, UI prototypes, and user manuals.",{"@graph":69,"@context":122},[70,84,105],{"@type":71,"itemListElement":72},"BreadcrumbList",[73,77,79,82],{"item":74,"name":75,"@type":76,"position":8},"https://docshare.wps.com","Home","ListItem",{"item":78,"name":9,"@type":76,"position":14},"https://docshare.wps.com/document/",{"item":80,"name":30,"@type":76,"position":81},"https://docshare.wps.com/document/technology/",3,{"item":83,"name":65,"@type":76,"position":19},"https://docshare.wps.com/document/software-development-lifecycle-procedure-10-purpose/655884/",{"url":83,"name":65,"@type":85,"image":86,"author":91,"headline":65,"publisher":94,"fileFormat":97,"inLanguage":63,"description":67,"dateModified":98,"datePublished":99,"encodingFormat":97,"isAccessibleForFree":100,"interactionStatistic":101},"DigitalDocument",{"url":87,"@type":88,"width":89,"height":90},"https://docshare.wps.com/thumbnails/software-development-lifecycle-procedure-10-purpose/655884.png","ImageObject",300,407,{"name":92,"@type":93},"Alexandar","Person",{"url":74,"name":95,"@type":96},"DocShare","Organization","application/pdf","2026-10-30","2026-10-25",true,{"@type":102,"interactionType":103,"userInteractionCount":81},"InteractionCounter",{"@type":104},"ViewAction",{"@type":106,"mainEntity":107},"FAQPage",[108,114,118],{"name":109,"@type":110,"acceptedAnswer":111},"Who is required to use this SDLC Procedure and for what projects?","Question",{"text":112,"@type":113},"Application Owners use the Procedure to create SDLC artifacts for major application projects, as required by the SDLC Policy. It specifies the contents of those artifacts.","Answer",{"name":115,"@type":110,"acceptedAnswer":116},"What is the key role of the Problem Statement artifact?",{"text":117,"@type":113},"The Problem Statement provides a high-level summary of what is expected and not expected. It includes background, context, why the application is being undertaken, and what business values it should produce, and it is the only document that must be signed off by all Application Owners without exception.",{"name":119,"@type":110,"acceptedAnswer":120},"Which artifacts relate to deployment and operational readiness?",{"text":121,"@type":113},"The Deployment Plan is a detailed checklist to ensure deployment readiness, and the Acceptance Plan validates successful deployment and formal acceptance. The Operations Manual captures instructions for application operation and administration, including job execution and recurring procedures.","https://schema.org",{"og:url":83,"og:type":124,"og:title":65,"og:site_name":95,"og:description":67},"article",{"robots":126,"canonical":83},"index,follow",{"doc_id":128,"site_id":62},655884,1792964523,{"code":4,"msg":5,"data":131},{"doc_id":128,"user_id":132,"nickname":92,"user_avatar":133,"doc_module":4,"category_id":29,"category_name":30,"doc_title":65,"doc_description":67,"doc_content":134,"file_id":135,"file_url":136,"file_type":137,"file_size":138,"view_count":81,"is_deleted":4,"is_public":8,"is_downloadable":8,"audit_status":8,"page_count":19,"language":139,"language_code":63,"site_id":62,"html_lang":63,"table_of_contents":140,"faqs":141,"seo_title":142,"seo_description":67,"update_tm":129,"read_time":52},962090768658,"https://ap-avatar.wpscdn.com/davatar_6f874abed73319feea01a86fa6f0fab8","Maine State Government  \nDept. of Administrative & Financial Services  \nOffice of Information Technology (OIT)  \nSoftware Development Lifecycle Procedure  \n1.0 Purpose  \nApplication Owners will use this Procedure to create the Software Development Lifecycle (SDLC) artifacts for major application projects, as required by the SDLC Policy 1.  \nThis SDLC Procedure is instituted to support the SDLC Policy. The SDLC Policy mentions artifacts to be created through the life of a major application project. This Procedure specifies the contents of such artifacts. However, beyond the contents, this Procedure does not take a position on the appearance and formatting of such artifacts.  \n2.0 Definitions  \n2.1 Acceptance Plan: This artifact validates the successful deployment and formal acceptance by the Agency of the deployed solution.  \n2.2 Architectural Diagram: This artifact is a visual representation of the solutions architectural design.  \n2.3 Deployment Plan: This artifact is a detailed checklist used by the project team to ensure deployment readiness.  \n2.4 Infrastructure Planning Document: This artifact captures the provisioning blueprint for the infrastructure intended to stand up the application project. This includes complete details of all relevant client devices, terminal emulators, browsers, etc., as well as the full complement of web, application, and database servers.  \n2.5 Logical Database Design Document: This artifact is structured in terms of Entities and Relationships. While it is not expected to finalize all the Attributes of all the Entities, it is indeed expected to contain primary, alternative, and secondary keys, as well as their individual Domains. The Domain of an Attribute is defined by its data type, its size, and its permissible range of values.  \n2.6 Object-Relational Model Document: This artifact applies only if the Business Logic is encoded in an object-oriented programming language. It captures the mapping between objects in the memory with those on the disk. Most contemporary applications implement the Business Logic layer in an object-oriented programming language and house the Data layer in a database. This dichotomy necessitates a mapping between the two kinds of objects. At a minimum, this document should capture the correspondence between classes and tables. It is not mandatory to map inheritances and relationships.  \n1 [https://www.maine.gov/oit/sites/maine.gov.oit/files/inline-files/sdlc-policy.pdf](https://www.maine.gov/oit/sites/maine.gov.oit/files/inline-files/sdlc-policy.pdf)  \nReference 6.1 provides further guidance on this topic.  \n2.7 Operations Manual: This artifact captures all instructions necessary for application operation and administration, including executing batch jobs, restarting aborted/failed jobs, reviewing logs, and all weekly/quarterly/yearly periodic procedures.  \n2.8 Physical Database Design Document: This artifact is structured strictly in terms of the SQL Data Definition Language (DDL) . In other words, this is the core of the 'Create & Alter Script' to be executed downstream by the DBA.  \n2.9 Problem Statement: This artifact captures the high-level summary of what is expected and what is not expected from the application project. It may or may not define every deliverable. However, all downstream deliverables must align with the Problem Statement. It should include the background and context of the application project, including why it is being undertaken, and what business values it is meant to produce. This is the only document that absolutely needs to be signed off by all Application Owners, without exception. Finally, if the contents ofthe Problem Statement are generated under the context of a Project Charter, then that adequately suffices in terms of SDLC Policy compliance and no duplication of effort is warranted. However, it remains the burden of the Application Owners to prove they have generated the entire contents ofthe Problem Statement, without exception, alb","cbCaij5fTgGYBQzh","https://ap.wps.com/l/cbCaij5fTgGYBQzh","pdf",228820,"English","# 1.0 Purpose\n# 2.0 Definitions\n## 2.1 Acceptance Plan\n## 2.2 Architectural Diagram\n## 2.3 Deployment Plan\n## 2.4 Infrastructure Planning Document\n## 2.5 Logical Database Design Document\n## 2.6 Object-Relational Model Document\n## 2.7 Operations Manual\n## 2.8 Physical Database Design Document\n## 2.9 Problem Statement\n## 2.10 Process Flow Diagram\n## 2.11 Roles & Privileges Document\n## 2.12 Use Case\n## 2.13 User Interface Prototype Document\n## 2.14 User Manual\n# 3.0 Applicability","[{\"question\":\"Who is required to use this SDLC Procedure and for what projects?\",\"answer\":\"Application Owners use the Procedure to create SDLC artifacts for major application projects, as required by the SDLC Policy. It specifies the contents of those artifacts.\"},{\"question\":\"What is the key role of the Problem Statement artifact?\",\"answer\":\"The Problem Statement provides a high-level summary of what is expected and not expected. It includes background, context, why the application is being undertaken, and what business values it should produce, and it is the only document that must be signed off by all Application Owners without exception.\"},{\"question\":\"Which artifacts relate to deployment and operational readiness?\",\"answer\":\"The Deployment Plan is a detailed checklist to ensure deployment readiness, and the Acceptance Plan validates successful deployment and formal acceptance. The Operations Manual captures instructions for application operation and administration, including job execution and recurring procedures.\"}]","Software Development Lifecycle Procedure - 1.0 Purpose | PDF"]