Your SlideShare is downloading. ×
0
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
07 fse implementation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

07 fse implementation

132

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
132
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. B. Computer Sci. (SE) (Hons.) CSEB233: Fundamentals of Software Engineering Software Implementation & Coding
  • 2. Objectives  Explain what is software construction and why it is important  Describe good programming principles/practices  Explain the concept of ‗defensive programming‘  Describe software inspection as a static method to discover defects, errors or problems  Explain the concepts, benefits and problems of software reuse
  • 3. What is Software Construction?  ‗Construction‘ refers to the hands-on part of creating something  Include implementation/coding and debugging; and verification and validation  Generally focus at coding, debugging, some detailed design and some testing (esp. unit testing)  Quality of construction substantially affects the quality of the software
  • 4. What is Software Construction?  According to McConnell (1993), construction may involve: Verifying that the groundwork has been laid so that construction can proceed successfully  Designing and writing routines and modules  Selecting and creating data types and naming identifiers  Selecting control structures and organizing blocks of statements  Finding and fixing errors 
  • 5. What is Software Construction?  According involve: to McConnell (1993), construction may Reviewing other team members‘ design and code and having them review yours  Polishing the code – formatting and writing comments (i.e. internal documentation)  Integrating software components (if built separately)  Tuning the code – make it more efficient, smaller and faster 
  • 6. Why is Software Construction Important?  Depending on the size of project, construction may take 30% - 80% of the total project time  The larger the time spent, the bigger the work affect the success of the project Construction is the pivotal activity in software development  With a focus on construction, there is a great potential for the average programmer‘s productivity to improve (McConnel, 1993) 
  • 7. Why is Software Construction Important? Requirements document and design documents can go out of date, but construction‘s by product, the source code, is always up to date  Ideally software project goes through requirements engineering and modeling activities before construction begins   Construction is the only activity that‘s guaranteed to be done! (McConnel, 1993)
  • 8. Coding Principles  Coding principles and concepts are closely aligned programming style, programming languages, and programming methods  Before you write one line of code, be sure you: Understand of the problem you‘re trying to solve  Understand basic design principles and concepts 
  • 9. Coding Principles  Before you write one line of code, be sure you: Pick a programming language that meets the needs of the software to be built and the environment in which it will operate  Select a programming environment that provides tools that will make your work easier  Create a set of unit tests that will be applied once the component you code is completed 
  • 10. Coding Principles  As you begin writing code, be sure you: Constrain your algorithms by following structured programming practice  Consider the use of pair programming  Select data structures that will meet the needs of the design  Understand the software architecture and create interfaces that are consistent with it  Keep conditional logic as simple as possible 
  • 11. Coding Principles  As you begin writing code, be sure you: Create nested loops in a way that makes them easily testable  Select meaningful variable names and follow other local coding standards  Write code that is self-documenting  Create a visual layout (e.g., indentation and blank lines) that aids understanding 
  • 12. Coding Principles  After you‘ve completed your first coding pass, be sure to: Conduct a code walkthrough when appropriate  Perform unit tests and correct errors you‘ve uncovered  Refactor the code  ■ reorganization technique that simplifies the code without changing its function or behaviour
  • 13. Good Programming Practices  Start with a good design.    The program under development should be functioning at all times   Update the design documents regularly Create additional design documents before adding new major features or functionality The development process consists of adding new functionality without breaking existing functionality Work has to be divided into small incremental steps that can be typically accomplished and code-reviewed in one day.  Even large-scale rewrites should be made incremental
  • 14. Good Programming Practices  Every line of code written or modified undergoes peer review   The smallest team must contain at least two programmers so that they can code-review each other's changes Always attempt to work top-down in:    Design—start with high level objects Implementation—create top-level objects using low-level stubs Modification—change the top-level objects and the overall flow of control first. If necessary, use stubs, or fake new functionality using old implementation (Source: http://relisoft.com/practice.html)
  • 15. Good Programming Practices  Be consistent with formatting  Be consistent with naming conventions  Use global [identifiers] sparingly  Don‘t assume output formats  Add comment to your code – explain what and why (Source: Kim Moser at http://relisoft.com/practice.html )
  • 16. Good Programming Practices  Provide useful error messages  Recover (or fail) gracefully  Push interface up and implementation down  Know what you don't know – prepare for changes (Source: Kim Moser at http://relisoft.com/practice.html )
  • 17. Defensive Progamming  Defensive programming is when the programmer makes necessary assumptions and creates code that anticipates potential problems and specification changes  A good defensive programmer is sufficiently confident in his/her abilities to ignore the traditional belief that ―If it isn‘t broke, don‘t fix it.‖
  • 18. Defensive Progamming  Defensive programming involves: finding problems in the existing code by identifying code inconsistencies and understanding typical uses of the software  anticipating – and preempting – both potential problems with the existing specifications as well as likely changes in user behavior and design specifications, and  streamlining the code to aid readability and simplify maintainability (Mehta, 2009) 
  • 19. Software Inspections  An ‗old school‘ approach  A process to review, analyze and check static system representations such as requirements document, design document, and program source code to look for errors and problems  Static – need not run the software on a computer  Generally, focus at source code
  • 20. Software Inspections  Sometime also known as peer reviews or program /code inspections  Inspections can check conformance with a specification but not conformance with the customer‘s real requirements  But, inspections cannot check non-functional characteristics such as performance, usability, etc.
  • 21. Program/Code Inspection Process  Focus at detecting defects - logical errors and anomalies in the code  Program inspections are very effective in discovering defects  A formal process that involve team of several members  Fagan originally developed this method at IBM in the 1970s with four suggested roles – author, reader, tester and moderator
  • 22. Advantages of Inspection over Testing A single inspection session can discover many errors  During program testing, errors can mask (hide) other errors  Incomplete versions of a software can be inspected without additional costs  To test an incomplete program, specialized test is needed to test the parts that are available (Sommerville, 2004)
  • 23. Advantages of Inspection over Testing  Inspections can search for program defects and other quality attributes of a program  e.g., compliance to standard, maintainability, portability, efficiency, etc. (Sommerville, 2004)
  • 24. Drawbacks/Issues related to Inspections Difficult to introduce formal inspections into software development organizations  Software engineers (programmers) with experience are sometimes reluctant to accept that inspections can be more effective for detecting defects (errors) than testing  Managers may be sceptical as inspections require extra costs during modelling and construction  Inspections may take time to arrange and appear to slow down the development process 
  • 25. Software Reuse In most engineering disciplines, systems are designed by composing existing components that have been used in other systems  Software engineering has been more focused on original development  It is now recognised that to achieve better software quickly at lower cost, we need to adopt a design process that is based on systematic reuse rather than ad-hoc reuse  (Sommerville, 2004)
  • 26. Reuse-based Software Engineering  Application system reuse   Component reuse   The whole of an application system may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families Components of an application from sub-systems to single objects may be reused Object and function reuse  Software components that implement a single well-defined function may be reused
  • 27. Requirements for Reuse  It must be possible to find appropriate reusable components  The reuser of the component must be confident that the components will be reliable and will behave as specified  The components must be documented so that they can be understood and, where appropriate, modified.
  • 28. Benefits of Reuse  Increased dependability Software/components/functions have been tried and tested in working systems  They should be more dependable than new software   Reduced process risk   Less uncertainty in development costs especially if large software components are reused Effective use of specialists Reuse components instead of people  The specialist can create reusable components 
  • 29. Benefits of Reuse  Standards  compliance Standards such as UI standard (e.g., drop-down menu) can be implemented as reusable components to improve dependability as users are less likely to make mistake  Accelerated  development Avoid original development, speed-up production and hence able to market product early
  • 30. Reuse Problems  Increased costs in understanding whether the application/component/ function is suitable for reuse  in testing it to ensure its dependability and in maintaining the reused item   Lack of CASE tool support  Maintaining a component library can be expensive
  • 31. Reuse Problems  Not-invented-here  syndrome Some software engineers may think that writing original software is seen as more challenging than reusing other people‘s software.  Finding and adapting reusable components
  • 32. Summary  You have been introduced to: good programming principles/practices  the concept of ‗defensive programming‘  software inspection as a static method to discover defects, errors or problems  the concepts, benefits and problems of software reuse 
  • 33. THE END Copyright © 2013 Mohd. Sharifuddin Ahmad, PhD College of Information Technology

×