Really?<\/em><\/h2>\nThis definition of software engineering illustrates the importance of applying engineering approaches to software. This application has shown, time and time again, capable of managing large-scale projects with repeated success.<\/p>\n
Software engineering processes allow software to be extended<\/em> rather than designed from scratch, to ensure client requirements are met wholly, and to maximize the effectiveness of communication within development teams.<\/p>\nThese processes can be categorized into one of four\u00a0broad<\/em> categories that make up a layered model for software engineering practices. This model, while generic in nature, provides a flexible framework from which more specific process modeling can evolve.<\/p>\nLayer Model of Software Engineering<\/h2>\n
Such that engineers in China may use similar approaches as Danish engineers to build bridges, so too might software engineers in the United States use similar practices as engineers from Argentina in designing new business software. Conceptually, software engineering can be divided into the following layers of focus\/discipline (1):<\/p>\n
\n- Tools\u00a0<\/strong>– Automated or semi-automated support for processes and methods.<\/li>\n
- Methods<\/strong> – Technical how-tos for building software including guidance for communication, construction, modeling, and testing.<\/li>\n
- Process<\/strong> – The strategies used to deliver successful software products. Defines the context in which tools and methods are applied.<\/li>\n
- Quality Management<\/strong> – Various frameworks to provide a means of process improvement for software products and serves as the foundation of software engineering.<\/li>\n<\/ul>\n
Process Model of Software Engineering<\/h2>\n
The above aspects of software engineering represent basic conceptual dissections of larger focal points in software engineering. One aspect of particular note is the process<\/em> layer. This layer encompasses the collection of activities, actions, and tasks performed to deliver products successfully (1). The broad applicability of this layer makes it worth particular focus.<\/p>\nProcess Framework<\/h2>\n
A software engineering process model can be broken down into a more granular\u00a0framework<\/em> to help address needs more specifically. While such frameworks can be (and should be) catered specifically to projects, a general outline can serve as a strong foundational guide:<\/p>\nCommunication<\/h3>\n
Communication with project stakeholders is essential to establish project requirements. Without accurate knowledge of a project’s objectives, there stands little chance for success. It’s important to note a project stakeholder is anyone<\/em> with a vested interest in the successful outcome\u2014clients, developers, managers, C-suite are all included.<\/p>\nPlanning<\/h3>\n
Planning helps identify the tasks that need to be completed to meet project goals, identify possible risks, and describes technical challenges more completely. Robust planning helps ensure a project’s goals are realized within achievable timelines and with anticipated resource requirements. Simply put; planning increases the likelihood projects will be delivered on-time and on-budget.<\/p>\n
Modeling<\/h3>\n
Modeling is an essential stage in the software engineering process\u2014and design process really\u2014where initial ideas are given form. Much like a bridge-builder would first sketch a bridge, so too should software engineers first “sketch” a software product. This stage includes things like UML diagrams, flow charts, and basic object modeling.<\/p>\n
Construction<\/h3>\n
This stage takes the concepts from the modeling stages and gives them a more concrete form. While initial construction stages may not produce deliverable products, this stage does result in more concrete expressions than prototypes and\/or discrete tests. The goal of the construction stage is to give form to project ideas.<\/p>\n
Deployment<\/h3>\n
Also referred to as\u00a0delivery<\/em>, this stage encompasses the process of handing the result of a completed development cycle to a customer for feedback. Note: development cycles can result in either partial\u00a0or<\/em> complete products, depending on project goals.<\/p>\nUmbrella Activities<\/h2>\n
In addition to the five processes within the process framework, there are other activities relevant to software engineering. These activities, referred to as Umbrella Activities<\/em>, are more flexible in nature and can be applied somewhat universally within several stages of development. These are the eight most common umbrella activities:<\/p>\n\n- Tracking & Control<\/strong> – The ability to assess project progress with respect to the project plan and take action accordingly. May include projections based on task completion times, re-allocation of resources, or issuance of communication to stakeholders.<\/li>\n
- Risk Management<\/strong> – The practice of assessing possible risks to the outcome or quality of the project. May include assessment of resource shortages, changed requirements, or market conditions.<\/li>\n
- Quality Assurance<\/strong> – Actions taken to maintain a level of quality deemed necessary to meet project outcomes in a manner satisfactory to stakeholders.<\/li>\n
- Technical Review<\/strong> – Conduct audits at each stage of the process framework to assess errors and address them before transitioning to the next process stage.<\/li>\n
- Measurement<\/strong> – Defining and collecting data related to processing, project, and product to assess and assist the development team in achieving successful project outcomes.<\/li>\n
- Configuration Management<\/strong> – The practice of managing change throughout the processes such that errors are minimized and the rate of progression towards project outcomes is maximized.<\/li>\n
- Reusability Management<\/strong> – Defines, establishes, and maintains guidelines for the creation of project assets (including software components) that can be reused throughout the project. This may include such specific items as decoupled methods to more general tools such as testing suites.<\/li>\n
- Product Preparation & Management<\/strong> – Tasks related to activities involved with the creation of models, documentation, project logs, and other project-specific informational resources.<\/li>\n<\/ul>\n
Closing Thoughts<\/h2>\n
The field of software engineering is vast but united by a shared goal: coupling common engineering practices to software. It’s through these quantifiable, repeatable, and systematic processes that large-scale, complex, and even multi-disciplinary projects achieve success. While every project may necessitate a unique adaptation of these processes, nearly all can benefit from their most generic direction and guidance.<\/p>\n
References<\/h2>\n\n- McGraw Hill, et al. ISE SOFTWARE ENGINEERING: A PRACTITIONERS APPROACH<\/i>. 9th ed., McGraw-Hill Education, 2019.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Software engineering can be defined as the application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software. That is\u2014the application of engineering to software. The above is the official definition of software engineering offered by the Institute of Electrical and Electronics Engineers in their Standard Glossary of Software Engineering […]<\/p>\n","protected":false},"author":2,"featured_media":612,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[246],"tags":[257,256],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/604"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=604"}],"version-history":[{"count":1,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/604\/revisions"}],"predecessor-version":[{"id":606,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/604\/revisions\/606"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/612"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=604"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=604"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=604"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}