Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Engineering - chp6- development phase

Development - Implementation

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Software Engineering - chp6- development phase

  1. 1. MedTech Chapter 6 – Development Phase Programming Paradigms, Best Practices Dr. Lilia SFAXI Slide 1 MedTech – Mediterranean Institute of Technology CS321-Software Engineering MedTech
  2. 2. MedTech Development Phase • The system developer: • Takes the detailed logical information documented in the previous phase and transforms it into machine executable form • Ensures that all of the individual components of the automated system function correctly and interface properly with other components • System hardware, networking and telecommunication equipements are acquired and configured • New custom software programs are developed • Databases are built • Legacy software applications are integrated • Test data and test case specifications are finalized • Unit and integration testing is performed by the developer • Documentation is elaborated Dr. Lilia SFAXI Slide 2 Development Phase
  3. 3. MedTech Requirements • For a development phase to be completed successfully, two elements are required: • A complete set of design specifications • Proper processes, standards and tools • Objectives of the development phase: • Building the system • Testing and integrating the units into larger components • Preparing the technical environment for the system • Approval to progress to the Test phase • Main Goal: • Convert the system design prototyped in the design phase into a working information system that addresses and documented requirements Dr. Lilia SFAXI Slide 3 Development Phase
  4. 4. MedTech Deliverables • System Development Document • Documents all the preparations related to the development of the system • Establishes hardware and network development approach • Methodologies, tools, procedures • Procedures for issue tracking and configuration management • System • Providing a system that meets the business needs and all requirements • Integrated harware, network and/or firmware components that meet all the requirements • Integration Document • Describes the assembly and interaction of the hardware, network and any other component of the system Dr. Lilia SFAXI Slide 4 Development Phase
  5. 5. MedTech Deliverables • Test Analysis Report(s) • Description of the unit tests and the results mapped to the system requirements • Identifies the system’s capabilities and deficiencies and presents them for review • Records results of tests • Conversion Plan (only in migration projects) • Strategies and approaches for migrating data from an existing system to another environment • Implementation Plan • Describes how the information system will be deployed as an operational system • Definition of all planned activities to ensure successful implementation to production Dr. Lilia SFAXI Slide 5 Development Phase
  6. 6. MedTech Deliverables • Operations Manual or System Administration Manual • OM: For mainframe systems • SAM: for distributed systems • Provide detailed instructions for system operations • Release Notes • Summary information regarding the current release of the system being built • Includes major new features and changes, and known problems and workarounds • Maintenance Manual • Document maintenance procedures, standards, or other useful information • Training Plan • Technical and user training needed on the new or enhanced information system • Scheduling of all necessary trainings Dr. Lilia SFAXI Slide 6 Development Phase
  7. 7. MedTech Roles • Agency CIO: Agency Chief Information Officer • Principal advisor on the effective application of IT to business needs • Project Sponsor • Business manager responsible for providing the overall business direction • Executive Sponsor • Responsible to the business for the success of the project • Project Manager • Responsible for the successful execution of the project and for organizing the team • Development Team • Project Stakeholders • Individuals who may be positively or negatively impacted by the execution or completion of a project (Client for ex.) Dr. Lilia SFAXI Slide 7 Development Phase
  8. 8. MedTech PROGRAMMING PARADIGMS Development Phase Dr. Lilia SFAXI Slide 8
  9. 9. MedTech Programming Paradigms: Definition • Programming Paradigms are : • A way to classify programming languages according to the style of computer programming • Various systems of ideas that have been used to guide the design of programming languages • Some languages belong to a specific paradigm, while others fall into multiple paradigms Dr. Lilia SFAXI Slide 9 Programming Paradigms
  10. 10. MedTech Programming Paradigms: Taxonomy Dr. Lilia SFAXI Slide 10 Programming Paradigms
  11. 11. MedTech Programming Paradigms: Taxonomy OK, don’t panic You are not supposed to know them all! Nobody does… * * almost nobody Dr. Lilia SFAXI Slide 11 Programming Paradigms
  12. 12. MedTech Programming Paradigms: Taxonomy • We are just focusing on the most famous: • Functional • Imperative • Logic • Object-Oriented Dr. Lilia SFAXI Slide 12 Programming Paradigms
  13. 13. MedTech Functional Paradigm • Treats computation as the evaluation of mathematical functions combined in expressions • Support a functional way of expressing computations on large and complex structures • The functions are stateless and have no side-effects • In functional languages, the output value of a function depends only on the arguments that are input to the function • Calling a function f twice with the same value for an argument x will produce the same result f(x) each time • Example: f(x) + f(x) = 2*f(x) should always hold Not necessarely the case with non-functional languages, where f can modify a global variable, for example. • No assignment! Dr. Lilia SFAXI Slide 13 Programming Paradigms
  14. 14. MedTech Functional Paradigm: Motivation • Develop programs: • Whose behaviour can easily be analyzed mathematically • Is easy to predict and understand • That avoid harmful side-effects • But: • Less efficient than imperative or object-oriented • They are more used in academia than in commercial software development • Few languages are purely functional, but a lot use the functional paradigm combined with others • Used for: • Massive parallel computing: because the order of execution is irrelevant • Data-flow operations • Statistics Dr. Lilia SFAXI Slide 14 Programming Paradigms
  15. 15. MedTech Functional Paradigm: Examples • Example of functional programming (Lisp) • Function for computing the average of two numbers: (defun avg(X Y) (/ (+ X Y) 2.0)) • Function is called by: > (avg 10.0 20.0) • Function returns: 15.0 • Other example: Non-Functional (Java) vs Functional (Clojure) Dr. Lilia SFAXI Slide 15 public class Squint{ public static void main (String args[]){ for (int i=1;i<=25;i++) System.out.println (i*i); } } (take 25 (squares-of (integers))) Programming Paradigms
  16. 16. MedTech Imperative Paradigm • A paradigm that uses statements to change the program’s state • Consists of a set of commands for the computer to perform • Recognize the fact that computers have a re-usable memory that can change state • Example: x := x+1 • Mathematically, this can only be done by associating a sequence of values with x (x1, x2, …, xn) where xt denotes the value of x at some time t: xt+1 = xt + 1 • A variable can change its value at runtime (assignment)! • All imperative languages have functional features, like basic functions of arithmetic (addition, substraction…) • Are easily translated into machine-code, thus being very efficient Dr. Lilia SFAXI Slide 16 Programming Paradigms
  17. 17. MedTech Imperative Paradigm: Motivation • Develop programs: • That most closely resemble the actual machine itself • That are more natural • That are more efficient • But: • The semantics of a program can be complex to understand or prove (because of side-effects) • Debugging is harder • Order of call is crucial, which makes the program difficult to parallelize • Some very well known imperative languages • C / C++ / C# • Java / Javascript • Pascal, PHP, Python… Dr. Lilia SFAXI Slide 17 Programming Paradigms
  18. 18. MedTech Logic Paradigm • Programming Paradigm based on formal logic • Set of sentences in logical form expressing facts and rules about some problem domain • Basic concept: relation • A logic program is divided into three sections: • series of definitions/declarations that define the problem domain (axioms) • statements of relevant facts (rules) • statement of goals in the form of a query Dr. Lilia SFAXI Slide 18 Programming Paradigms
  19. 19. MedTech Logic Paradigm: Motivation • Advantages: • The system solves the problem, so the programming steps themselves are kept to a minimum; • Proving the validity of a given program is simple. • But: • Not suited for complex programs with intensive calculations • Not commonly used for production applications, more academic • Relatively poor performance of today’s personal computer architecture, optimized for sequential processing • Usage • Expressing problems where it is not obvious what the functions should be • Problem solving and Theorem proving • Artificial Intelligence Dr. Lilia SFAXI Slide 19 Programming Paradigms
  20. 20. MedTech Logic Paradigm: Examples Examples of Logic programming (Prolog) Dr. Lilia SFAXI Slide 20 Programming Paradigms brother(X,Y) :- father(F,X), father(F,Y), mother(M,X), mother(M,Y), male(X). parent(i,j). parent(j,b). ancestor(X,Y):- parent(X,Y). ancestor(X,Y):- parent(X,Z), ancestor(Z,Y). :- ancestor(i,X) X is the brother of Y if they have the same father (F), the same mother (M) and X is male. X is the ancestor of Y if X is a parent of Y or X is the parent of one of Y’s ancestor (Z). Knowing this, and knowing that i is the parent of j and j is a parent of b, find all the ancestors of i.
  21. 21. MedTech Object-Oriented Paradigm • Programming paradigm based on the concept of "objects", which may contain: • Data, in the form of fields, often known as attributes • Code, in the form of procedures, often known as methods. • Moslty combined with the imperative paradigm • Data is combined with procedures to give objects • Imperative paradigm: one would write a procedure which prints the various kinds of object in the program. • O-O paradigm: each object has a print-method, and you "tell" an object to print itself. • 4 principles : • Encapsulation, Abstraction, Inheritance, Polymorphism Dr. Lilia SFAXI Slide 21 Programming Paradigms
  22. 22. MedTech Object-Oriented Paradigm: Motivation • Benefits • Similar to the way human beings perceive the real world • Easy code reuse and extensibility thanks to inheritance • High degree of modularity thanks to classes • But: • Object-oriented programs tend to require more memory and processing resources than procedural programs • It is complex to create programs based on interaction of objects. • Larger program size: Object oriented programs typically involve more lines of code than procedural programs. • Well known examples: • Java, C++, C#, Python, PHP, Ruby, Perl, Delphi, Objective-C, Swift, Common Lisp, and Smalltalk. Dr. Lilia SFAXI Slide 22 Programming Paradigms
  23. 23. MedTech Object-Oriented Paradigm: Examples Examples of OO programming Dr. Lilia SFAXI Slide 23 Programming Paradigms PHP Python class Vegetable { var $edible; var $color; function Vegetable($edible, $color="green"){ $this->edible = $edible; $this->color = $color; } function is_edible(){ return $this->edible; } function what_color(){ return $this->color; } } class Person: """ A person represented by : lastname, firstname, age,address """ def __init__(self, first, last): """Constructor""" self.lastname = last self.firstname = first self.age = 33 self.address= "Tunis"
  24. 24. MedTech PROGRAMMING BEST PRACTICES Development Phase Dr. Lilia SFAXI Slide 24
  25. 25. MedTech Agile Best Practices • When you are restricted with deadlines, traditional programming practices are insufficient • Lengthy analysis design phases, testing at the end… • Some best practices exist in order to help you become an agile software programmer • The smaller cycles of development can seem less rigourous, but are definitely more effective, if applied with discipline Dr. Lilia SFAXI Slide 25 Programming Best Practices
  26. 26. MedTech BP1: Test-First and Test-Driven Programming • An optimal test-coverage (between 75 and 85%) is required to have low-defect and agile code • Test-First programming: • Producing automated unit tests for production code, before you write that production code. • For every small chunk of functionality in production code, you first build and run a small (ideally very small), focused test that specifies and validates what the code will do. • Takes the part of an executable specification • It only makes sense if you end up relying on these unit tests later • Use one of the xUnit family, depending on your language: • Junit for Java • Nunit for C# Dr. Lilia SFAXI Slide 26 Programming Best Practices
  27. 27. MedTech BP1: Test-First and Test-Driven Programming • Advantages of Test-First Programming • Good Test-First teams find that they get substantially fewer defects throughout the system life cycle, and spend much less time debugging. • Well-written unit tests also serve as excellent design documentation that is always, by definition, in synch with the production code. • Many programmers report that “the little green bar” that shows that all tests are running clean becomes addictive. • Positive feedback that help you be more confident and motivated • Use one of the xUnit family, depending on your language: • Junit for Java • Nunit for C# • … Dr. Lilia SFAXI Slide 27 Programming Best Practices
  28. 28. MedTech BP1: Test-First and Test-Driven Programming • Test-Driven Programming • Special case of test-first programming that adds continuous design • The process of writing tests and production code can steer the design as you go • If you can easily imagine a clearer, cleaner method, class, or entire object model, you refactor in that direction, protected the entire time by a solid suite of unit tests. • Presumption behind TDD: • You cannot really tell what design will serve you best until you have your arms elbow-deep in the code. • You can start with a fairly simple code design • Allow the actual code to diverge from the initial design as you go • No architecture changes, just refactoring of code Dr. Lilia SFAXI Slide 28 Programming Best Practices
  29. 29. MedTech BP2: Code Refactoring • Process of clarifying and simplifying the design of existing code, without changing its behavious • As agile teams maintain and extend their code frequently, it tends to become messy • Unhealthy dependencies between classes or packages • Bad allocation of class responsibilities, or too many responsibilities per method or class • Duplicate code, … • Try to maintain code hygiene as you go • Refactor your code to patterns • Use the automated tests already defined to check that the refactoring did not affect the functionality • Use automatic refactoring present in the IDEs (Eclipse, IntelliJ IDEA…) Dr. Lilia SFAXI Slide 29 Programming Best Practices
  30. 30. MedTech BP3: Continuous Integration • Programmers can work separately for hours, days, or even weeks on the same source without realizing how many conflicts (and perhaps bugs) they are generating • Continuous integration involves producing a clean build of the system several times per day • Use tools like CruiseControl (Ant + source control) or Jenkins • Often includes: • Automated compilation • Unit tests execution • Source control integration • Automated acceptance tests Dr. Lilia SFAXI Slide 30 Programming Best Practices
  31. 31. MedTech BP3: Continuous Integration • Continuous Integration Rules • Maintain a single source repository • Every commit should build the mainline on an integration machine • Never leave anything unintegrated at the end of the day • The build should never spend the night in a broken state • Whoever breaks the build at check-in has to fix it again, immediatly • Make it easier for everyone to get the latest executable • Automate deployment • Test in a clone of the production environment • …* * See more in the blog of Martin Fowler about Continuous Integration (references) Dr. Lilia SFAXI Slide 31 Programming Best Practices
  32. 32. MedTech BP4: Simple Code Design • Extensibility is very important for agile teams: • Extensibility is inversely proportional to design complexity • Develop « The Art of What Suffices » • Coding for today’s specified requirements, no more • Trying not to be tempted to add more complexity, just because the technology can do it • YAGNI « You Aren’t Gonna Need It » • All that we add in our software will stay there and follow us through the releases, so don’t put anything you won’t need • Wait until an actual requirement hollers for an extra layer of complexity before introducing it • Stop trying to anticipate changes, just consider them when they come! Dr. Lilia SFAXI Slide 32 Programming Best Practices
  33. 33. MedTech BP5: Pair Programming • Pairing • Having two programmers working at a single workspace • One programmer « drives », operating the keyboard • The other « navigates », watching, learning, asking, talking, making suggestions • The driver: • Focuses on the code at hand: syntax, semantics, algorithm • The navigator: • Focuses more on a higher level of abstraction: the following test, the next technical task, time since last commit, quality of design… • Results in better designs, fewer bugs and better spread of knowledge • Pairs should switch off regularly • Even if short-time productivity may decrease modestly (about 15%), thanks to better produced code, long-time productivity goes way up Dr. Lilia SFAXI Slide 33 Programming Best Practices
  34. 34. MedTech BP6: Common Codebase • Sharing a code base by as many programmers on the team as possible • Practical if the team uses: • Test-first programming, refactoring, continuous integration • A single coding standard (BP7) • Reduces management’s overall vulnerability to staff turnover • Better team management for roles distribution • Simpler, better, more consistant overall design • Help the team deliver more running, tested features per iteration • No more difficulty in integrating the different works at the end of an iteration Dr. Lilia SFAXI Slide 34 Programming Best Practices
  35. 35. MedTech BP7: Agile Coding Standard • Programmers should adhere to a single agile coding standard • In the code form: tabs vs. spaces, curly brackets placement • Naming conventions for classes, methods and interfaces… • Makes it easier to: • Maintain and extend code • Refactor the code • Reconcile integration conflicts • The choice of the standard is less important than the adherence of the whole team to it • Thanks to modern IDEs, this issue is almost resolved, with the definition of the formatting type, even after the code is written Dr. Lilia SFAXI Slide 35 Programming Best Practices
  36. 36. MedTech BP8: Collaborative Workspace • During the Second World War, when England absolutely had to learn how to break very challenging Nazi cryptographic algorithms, they assembled the best mathematicians and cryptographers they could find at Bletchley Park. And they did not, then, place them all in separate offices (cubicles had not yet been “invented”), to slave away at their own pace in isolation. They placed them together as much as possible, encouraging and requiring them to interact with each other. These guys were, in fact, isolated from the rest of the world. They worked, ate, and lived together. It was from this tumultuous convergence that the brilliant ideas emerged that led to code breaking machines (computers!) that eventually cracked the Enigma. These ideas eventually helped win the war. • Assignment for next weak : See the « Imitation Game » Film • (don’t expect any grades for this one J) Dr. Lilia SFAXI Slide 36 Programming Best Practices
  37. 37. MedTech BP8: Collaborative Workspace • Open-area war-room arrangements have been shown to facilitate team communication enormously • At any time, when a programmer is stuck, has a conflict, a question, help is immediatly available, no need to delay it to next day or next week • People can more easily: • Stay on process • Stay focused on the task • Celebrate success • Team cohesion, camaraderie, ambient trust and respect, listening skills, and other measures of social health all improve • A customer representative is encouraged to work with them in the room Dr. Lilia SFAXI Slide 37 Programming Best Practices
  38. 38. MedTech BP8: Collaborative Workspace • But: • Some works, like this article in New York Times, claim that we all need some privacy to be more productive and learn at our own pace • Collaboration is a must, but what if some solitude is too? • Shouldn’t we seek company just when we need it, instead of being obliged to endure it? • Sometimes, being constently in a heterogeneous group can lead to a lot of conflict.. • .. or, if they are friends, it leads to constent chit-chat and a lot of « let’s talk about anything but work » time.. • What about introverts? Dr. Lilia SFAXI Slide 38 Programming Best Practices
  39. 39. MedTech References Dr. Lilia SFAXI Slide 39 • SDLC,, Department of Information Technology: • Programming Language Paradigms, es/, University of Birmingham • VersionOne, Agile Best Practices: 101/agile-software-programming-best-practices/ • Martin Fowler, Continuous Integration: • TextBooks • Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison- Wesley, 1999 • Joshua Kerievsky, Refactoring to Patterns, Addison-Wesley, 2002

    Be the first to comment

    Login to see the comments

  • TusharPatil74

    Feb. 9, 2017
  • OleksandrVinnytskyi

    May. 15, 2018
  • balaganesh82

    Jul. 30, 2018

Development - Implementation


Total views


On Slideshare


From embeds


Number of embeds