Software Engineering - chp6- development phase

MedTech

Chapter 6 – Development Phase

Programming Paradigms, Best Practices

Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i

S l id e 1

MedTech – Mediterranean Institute of TechnologyCS321-Software Engineering

MedTech

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. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i

S l id e 2

Development Phase

MedTech

Requirements

• For a development phase to be completed successfully, two elementsare 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


S l id e 3

Development Phase

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


S l id e 4

Development Phase

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


S l id e 5

Development Phase

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


S l id e 6

Development Phase

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 executionor completion of a project (Client for ex.)


S l id e 7

Development Phase

MedTech

PROGRAMMING PARADIGMSDevelopment Phase


S l id e 8

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 intomultiple paradigms


S l id e 9

Programming Paradigms

MedTech

Programming Paradigms: Taxonomy


S l id e 10


MedTech


OK, don’t panicYou are not supposed to know them all!

Nobody does… *

* almost nobody


S l id e 11


MedTech


• We are just focusing on the most famous:• Functional

• Imperative• Logic

• Object-Oriented


S l id e 12


MedTech

Functional Paradigm

• Treats computation as the evaluation of mathematicalfunctions 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 onlyon 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!


S l id e 13


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 paradigmcombined with others

• Used for:• Massive parallel computing: because the order of execution is irrelevant

• Data-flow operations

• Statistics


S l id e 14


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)


S l id e 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)))


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 canchange 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 functionsof arithmetic (addition, substraction…)

• Are easily translated into machine-code, thus being very efficient


S l id e 16


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…


S l id e 17


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


S l id e 18


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


S l id e 19


MedTech

Logic Paradigm: Examples

Examples of Logic programming (Prolog)


S l id e 20


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 samefather (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 isa parent of b, find all the ancestors of i.

MedTech

Object-Oriented Paradigm

• Programming paradigm based on the concept of "objects", which maycontain:• 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 variouskinds 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


S l id e 21


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 linesof code than procedural programs.

• Well known examples:• Java, C++, C#, Python, PHP, Ruby, Perl, Delphi, Objective-C, Swift, Common

Lisp, and Smalltalk.


S l id e 22


MedTech

Object-Oriented Paradigm: Examples

Examples of OO programming


S l id e 23


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"

MedTech

PROGRAMMING BEST PRACTICESDevelopment Phase


S l id e 24

MedTech

Agile Best Practices

• When you are restricted with deadlines, traditional programmingpractices 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


S l id e 25

Programming Best Practices

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 buildand 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#


S l id e 26


MedTech


• 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 thatis 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#

• …


S l id e 27


MedTech


• 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


S l id e 28


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…)


S l id e 29


MedTech

BP3: Continuous Integration

• Programmers can work separately for hours, days, or even weeks on the same source without realizing how many conflicts (and perhapsbugs) 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


S l id e 30


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)


S l id e 31


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 complexitybefore introducing it

• Stop trying to anticipate changes, just consider them when they come!


S l id e 32


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


S l id e 33


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


S l id e 34


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


S l id e 35


MedTech

BP8: Collaborative Workspace

• During the Second World War, when England absolutely had to learnhow to break very challenging Nazi cryptographic algorithms, theyassembled the best mathematicians and cryptographers they couldfind at Bletchley Park. And they did not, then, place them all in separate offices (cubicles had not yet been “invented”), to slave awayat 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. Theyworked, ate, and lived together. It was from this tumultuousconvergence that the brilliant ideas emerged that led to code breakingmachines (computers!) that eventually cracked the Enigma. Theseideas eventually helped win the war.

• Assignment for next weak : See the « Imitation Game » Film • (don’t expect any grades for this one J)


S l id e 36


MedTech


• 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 nextweek

• People can more easily:• Stay on process• Stay focused on the task• Celebrate success

• Team cohesion, camaraderie, ambient trust and respect, listeningskills, and other measures of social health all improve

• A customer representative is encouraged to work with them in the room


S l id e 37


MedTech


• 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 obligedto 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’stalk about anything but work » time..

• What about introverts?


S l id e 38


MedTech

References


S l id e 39

• SDLC, Maryland.gov, Department of Information Technology: http://doit.maryland.gov/SDLC/Pages/SDLCHome.aspx

• Programming Language Paradigms, http://www.cs.bham.ac.uk/research/projects/poplog/paradigms_lectures/, University of Birmingham

• VersionOne, Agile Best Practices: https://www.versionone.com/agile-101/agile-software-programming-best-practices/

• Martin Fowler, Continuous Integration: http://www.martinfowler.com/articles/continuousIntegration.html

• TextBooks• Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-

Wesley, 1999• Joshua Kerievsky, Refactoring to Patterns, Addison-Wesley, 2002