Managing Complexity in Software Engineering Projects

Managing Complexity in Software Engineering Projects

Slides from a lecture a gave to students about to undertake a year long group software engineering project as part of a Masters program. The lecture focused on practical approaches to managing complexities that arise in software projects.

0d1ebe207cdc93dd14513bd70c7220c0?s=128

Michael Papasimeon

March 14, 2017
Tweet

Transcript

  1. Software Engineering Project Some Advice for Managing Software Project Complexity

    Dr. Michael Papasimeon 14 March 2017
  2. Sources of Complexity Domain Requirements Design Code Test Deployment Configuration

    Management Project Management [Schedule + Budget + Resourcing] Team Client + many others... ... lets look at a few of these and some practical advice for handling different types of complexity...
  3. Requirements Expect requirements to change and evolve over the life

    of the project. Organize your requirements Grouping Prioritisation Break them down into smaller requirements Functional vs non-functional requirements Cross-cutting requirements Dependencies betweeen requirements Conflicting requirements Translate into user stories in a systematic matter Useful to keep track of requirements (e.g. the ones the team has implemented, how long they took etc.)
  4. Design Design as an interpretation of requirements before you code.

    Software designs help manage complexity. Software design help you to manage coupling, cohesion, modularity. Effective artifact for communication with team members and client. Helps to split up/divide the work amongst team members. Can help to make estimates. Expect your design to evolve and change over the course of the project. Helps determine what components will need to change in each sprint. Practical Advice: Architectural Overview A one page overview of your overall software design (that is kept up to date) can be really useful for all team members and for communicating with the client.
  5. Code Don’t re-invent the wheel - look for libraries (especially

    open source ones that can solve specific problems). Use community (for your language) coding standards + conventions Document your code + consider a document generator (e.g. Sphinx) Make use of technology that assists in improving the quality of your code (e.g. linters, type annotators, code standard checkers). Organise your code base according to community conventions. Organise your code base so its easy for different team members to work on different parts of the system without stepping on each others toes (an aspect of having a high quality design). Prototype... especially with unfamiliar technologies.
  6. Test Different types of test are required to test different

    parts of a complex software system. Make use of existing testing frameworks for the environment you are using. Consider the use of a continuous integration system (build and run all your tests overnight). Don’t neglect user testing. Unit/Component Testing Ensuring individual components work as specified. Integration Testing Ensuring components work together as specified. This is about testing your architecture/design. System Testing Ensuring the system as a whole works as specified and meets the requirements of the client.
  7. Deployment Don’t leave deployment to the last minute. Don’t underestimate

    the complexities of deployment. Ensure your deployment procedure is documented and tested. Cross-platform deployment adds complexity, but may be a client requirement.
  8. Configuration Management Revision control... goes without saying; but configuration management

    is much more than this. Will your team have a dedicated configuration manager? How will you manage concurrent development? How will you handle branches (e.g. is each new feature a separate branch?) Who is responsible for merging pull requests and merging branches? What happens if a pull request can’t be merged? What happens if someone breaks the build? Does it make sense to have multiple repositories? What will you have in your definition of ”done”?
  9. Team Complexities arising from team interactions and team conflicts are

    often the hardest problems to solve in team software projects. Creating a positive team environment. Making and learning from mistakes. Flexibility. Compromise. Communication is critical. Make sure that everyone on the team understands what it is you are trying to achieve. Don’t be afraid to ask questions if you are not sure.
  10. Client Keep open, regular and honest communication with your client.

    Set expectations. Negotiate. Be honest about what you can and can’t achieve. Provide opportunities for the client to give you feedback on your progress... don’t ignore the feedback.
  11. Some final advice... Be systematic Be organised Be reasonable Compromise

    Communicate Tackle issues early This team software engineering project can be very challenging, but it can also be one of the most rewarding experiences in your software engineering education. Make the most of it!