Software Engineering and Design

Need Help With Software Engineering and Design?

View Available
Software Engineering and Design Tutors

Java.expert

Software Engineering and Design Homework
Library

WonderCard

View

Capability Maturity Model

View

Computer Science Questions

View

During the last half century there has been some debate about whether or not areas of computer science should be considered one of the engineering disciplines. Certain experts in software development, design, and application feel that they deserve to be called "software engineers." By now, most people accept the field of software engineering as a legitimate engineering discipline.

Although software engineering is a young field compared to other engineering disciplines such as chemical, electrical, or mechanical, it already has an exciting history full of valuable lessons derived from its early successes and failures. Software engineering covers a huge variety of topics originating both in computer science (such as development processes and methodologies, testing, and refactoring) and social science (such as software estimation metrics and techniques, risk management, and quality assurance). Everyone working with software, to one extent or another, can benefit from studying the history and fundamentals of software engineering.

A typical software engineering course may involve any combination of the following topics:

Traditional software development processes and methodologies (Waterfall, UP, RUP, etc.)
Modern software development processes and methodologies (XP, SCRUM, etc.)
Software development life cycle (SDLC) models
Requirements gathering
Initial (abstract) and detailed system analysis
Initial (abstract) and detailed system design
Testing methodologies (unit, white-box/black-box, integration, user acceptance, Interface, test-driven Development, etc.)
Software maintenance and refactoring
Software architectures and paradigms (2/3/N-Tier Systems, client-server model, P2P Model, distributed computing, Service Oriented Architectures (SOAs), RESTful Paradigm, SOAP Paradigm, WS-* Standards, Cloud Computing, Software as a Service (SaaS), Platform as a Service (PaaS), etc.)
Project management
Software metrics and estimation techniques
Risk management (Planning and Mitigation)
Software quality assurance

Software engineering has grown significantly and now encompasses a very diverse set of topics. Pressman's Software Engineering: A Practitioner's Approach is considered the best introductory book for computer science students along with Sommerville's classic Software Engineering. Frederick Brooks' The Mythical Man-Month is probably the most cited book in the field, detailing how the process of software development can go awfully wrong and stating for the first time that throwing more people on an ongoing project is far more likely to delay it! Code Complete by Steve McConnell and The Pragmatic Programmer by Andrew Hunt are a "must read" for anyone wanting to dive deeper, as is the Design Patterns: Elements of Reusable Object-Oriented Software, written by the famous "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides), which changed forever the way software is developed. Finally, don't miss Joel Spolsky's blog and books, the definitive voice on modern topics of software engineering (or, "what you won't learn from your SE textbook"). For academic resources you should look into conference proceedings and journals published by the ACM, IEEE, Springer, Elsevier, Google Scholar, and CMU's Software Engineering Institute.

Agile Development Methodology

The software industry has been through an intense period of flux in recent years. Should you choose to undertake a career in software (at any stage of its process), you will likely be using agile methodologies, if not a more extreme form (i.e. extreme programming). Software development is a massive undertaking that involves collaboration between architecture, product management, development, testing, design, IT, and infrastructure. Bringing all these components together requires discipline, but the act of producing a software project is often compared to an art form. Typically the process is managed in one of two ways: agile, or waterfall.

To understand agile you must first see the problems organizations encountered with waterfall. The software development lifecycle was split into distinct phases, including gathering, development, testing and deployment. These phases were assigned timelines, much like other types of projects were constrained by budgets. The budget was fixed up front, and renegotiating it was, at best, expensive, and at worst impossible.¹ Inevitably, development wouldn't meet deadlines, because planned work is invariably disrupted by unplanned maintenance in production systems. Because the budget and timeline were fixed, either quality or feature count were sacrificed, but it was usually quality that was sacrificed as the business requirements were equally intractable.

Countless failed waterfall projects led to a mindshift in the process of software development; one which recognized that it took far more time to deploy a feature than to test and find a fault with it. Fast feedback was emphasised, and working software became the priority over extensive documentation. The faster a user could utilize the software, the faster it could be revised to meet business requirements. This was the birth of the agile process.²

Under agile, teams are as small as possible and meet at least daily in scrum meetings³, with all software disciplines usually physically working together. Teams on a larger platform or product integrate their code early and often, unafraid to break down the product as issues will be found faster and thus addressed in an equally timely manner. Teams break work down into the smallest possible chunks, committing to one work requirement at a time and finishing it before releasing more work into the development cycle. By minimizing work in progress, teams finish each requirement faster and increase business confidence in the ability to respond to customer feedback.⁴ When things go wrong, development teams embrace failure through regular retrospective and root cause analysis meetings, using them to improve and grow as software professionals.

Ultimately, graduates go into software development to improve peoples' lives and careers through software: agile has shown itself to be the best way to do that so far.

[1] http://www.scrum-institute.org/What_Makes_Waterfall_Fail_in_Many_Ways.php

[2] http://agilemethodology.org/

[3] https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum

[4] https://www.atlassian.com/agile/wip-limits