Skip to main content
Software Engineering

Return to Answer

checklist += http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande?currentPage=all "it’s far from obvious that something as simple as a checklist could be of much help..."
Source Link
gnat
gnat
  • 20.5k
  • 29
  • 117
  • 310

Start with a checklistchecklist. (You knew that was the first step, right?)
Make sure the checklist lists all of the standard documentation for your current project. ie. UML Diagram, functional spec, high-level and low-level designs, etc... The systems engineer in me will suggest using an RTVM (requirements traceability verification matrix)

Pick a sample program to work on. If you can't come up with one, google "code katas" or check out Google's codejam archive of challenges. Or just build a calculator. :-)

Build the functional spec for your sample program. Then move into the high-level design, UML diagram, etc... Build it to spec. Test it. Every time you find a significant flaw in your spec (as defined by your current work practices), then you need to step back to that stage of the SDLC and revise before moving forward again.

For your first round, go ahead and keep it small. Cycling through the process is more important than overkill within any particular stage. For subsequent rounds, add in the features that you left off. Tracing, logging, performance analysis, test-scaffold, etc.. What you'll want to add will depend upon what your employer expects for your real work.

After you have iterated through the design / build / test / repeat cycle several times, you'll have built up skill and experience in the "heavyweight" components that are worrying you now. The iterations will also show you the interconnection between the various stages and the documentation generated. The valuable lesson there is showing how a 5 minute code change can have a multi-hour ripple effect elsewhere due to doc updates and testing requirements.

Start with a checklist. (You knew that was the first step, right?)
Make sure the checklist lists all of the standard documentation for your current project. ie. UML Diagram, functional spec, high-level and low-level designs, etc... The systems engineer in me will suggest using an RTVM (requirements traceability verification matrix)

Pick a sample program to work on. If you can't come up with one, google "code katas" or check out Google's codejam archive of challenges. Or just build a calculator. :-)

Build the functional spec for your sample program. Then move into the high-level design, UML diagram, etc... Build it to spec. Test it. Every time you find a significant flaw in your spec (as defined by your current work practices), then you need to step back to that stage of the SDLC and revise before moving forward again.

For your first round, go ahead and keep it small. Cycling through the process is more important than overkill within any particular stage. For subsequent rounds, add in the features that you left off. Tracing, logging, performance analysis, test-scaffold, etc.. What you'll want to add will depend upon what your employer expects for your real work.

After you have iterated through the design / build / test / repeat cycle several times, you'll have built up skill and experience in the "heavyweight" components that are worrying you now. The iterations will also show you the interconnection between the various stages and the documentation generated. The valuable lesson there is showing how a 5 minute code change can have a multi-hour ripple effect elsewhere due to doc updates and testing requirements.

Start with a checklist. (You knew that was the first step, right?)
Make sure the checklist lists all of the standard documentation for your current project. ie. UML Diagram, functional spec, high-level and low-level designs, etc... The systems engineer in me will suggest using an RTVM (requirements traceability verification matrix)

Pick a sample program to work on. If you can't come up with one, google "code katas" or check out Google's codejam archive of challenges. Or just build a calculator. :-)

Build the functional spec for your sample program. Then move into the high-level design, UML diagram, etc... Build it to spec. Test it. Every time you find a significant flaw in your spec (as defined by your current work practices), then you need to step back to that stage of the SDLC and revise before moving forward again.

For your first round, go ahead and keep it small. Cycling through the process is more important than overkill within any particular stage. For subsequent rounds, add in the features that you left off. Tracing, logging, performance analysis, test-scaffold, etc.. What you'll want to add will depend upon what your employer expects for your real work.

After you have iterated through the design / build / test / repeat cycle several times, you'll have built up skill and experience in the "heavyweight" components that are worrying you now. The iterations will also show you the interconnection between the various stages and the documentation generated. The valuable lesson there is showing how a 5 minute code change can have a multi-hour ripple effect elsewhere due to doc updates and testing requirements.

Source Link
user53019
user53019

Start with a checklist. (You knew that was the first step, right?)
Make sure the checklist lists all of the standard documentation for your current project. ie. UML Diagram, functional spec, high-level and low-level designs, etc... The systems engineer in me will suggest using an RTVM (requirements traceability verification matrix)

Pick a sample program to work on. If you can't come up with one, google "code katas" or check out Google's codejam archive of challenges. Or just build a calculator. :-)

Build the functional spec for your sample program. Then move into the high-level design, UML diagram, etc... Build it to spec. Test it. Every time you find a significant flaw in your spec (as defined by your current work practices), then you need to step back to that stage of the SDLC and revise before moving forward again.

For your first round, go ahead and keep it small. Cycling through the process is more important than overkill within any particular stage. For subsequent rounds, add in the features that you left off. Tracing, logging, performance analysis, test-scaffold, etc.. What you'll want to add will depend upon what your employer expects for your real work.

After you have iterated through the design / build / test / repeat cycle several times, you'll have built up skill and experience in the "heavyweight" components that are worrying you now. The iterations will also show you the interconnection between the various stages and the documentation generated. The valuable lesson there is showing how a 5 minute code change can have a multi-hour ripple effect elsewhere due to doc updates and testing requirements.