Software Engineering - chp6- development phase

MedTech
Chapter 6 – Development Phase
Programming Paradigms, Best Practices
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
MedTech – Mediterranean Institute of Technology
CS321-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. Lilia SFAXI
Slide 2
Development Phase

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

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

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

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

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

MedTech
PROGRAMMING PARADIGMS
Development Phase
Dr. Lilia SFAXI
Slide 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 into
multiple paradigms
Dr. Lilia SFAXI
Slide 9
Programming Paradigms

MedTech
Programming Paradigms: Taxonomy
Dr. Lilia SFAXI
Slide 10

MedTech
OK, don’t panic
You are not supposed to know them all!
Nobody does… *
* almost nobody
Dr. Lilia SFAXI
Slide 11

MedTech
• We are just focusing on the most famous:
• Functional
• Imperative
• Logic
• Object-Oriented
Dr. Lilia SFAXI
Slide 12

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

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

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

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

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

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

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

MedTech
Logic Paradigm: Examples
Examples of Logic programming (Prolog)
Dr. Lilia SFAXI
Slide 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 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.

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

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

MedTech
Object-Oriented Paradigm: Examples
Examples of OO programming
Dr. Lilia SFAXI
Slide 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 PRACTICES
Development Phase
Dr. Lilia SFAXI
Slide 24

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

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

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

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
Dr. Lilia SFAXI
Slide 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…)
Dr. Lilia SFAXI
Slide 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 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

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

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

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

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

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

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

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

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

MedTech
References
Dr. Lilia SFAXI
Slide 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_lectur
es/, 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

Software Engineering - chp6- development phase

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Software Engineering - chp6- development phase

Similar to Software Engineering - chp6- development phase (20)

More from Lilia Sfaxi

More from Lilia Sfaxi (20)

Recently uploaded

Recently uploaded (20)

Software Engineering - chp6- development phase